SAP Landscape Design

ContentsSAP System Architecture.......................................................................................................................................................3

Central Instance................................................................................................................................................................3

Central Services Instance..................................................................................................................................................3

Database Instance.............................................................................................................................................................4

Dialog Instance..................................................................................................................................................................4

Client deployment strategy...................................................................................................................................................5

Client landscape with transport paths...............................................................................................................................5

Development systems (DEV).............................................................................................................................................5

Quality Assurance System (QAS).......................................................................................................................................7

Production system (PRD)...................................................................................................................................................8

Transport strategy.................................................................................................................................................................8

Everything Goes, In Order.................................................................................................................................................8

Everyone Works in the Same Client..................................................................................................................................9

Master Data: Everything that Can be Transported, Will be Transported........................................................................10

No Transactions will be executed in the Configuration Client.........................................................................................10

Server infrastructure...........................................................................................................................................................11

Solaris Chemtech Pvt.Ltd., Karwar..................................................................................................................................11

Solaris Chemtech Pvt. Ltd, Gurgaon................................................................................................................................11

System printing infrastructure............................................................................................................................................11

SAP System ArchitectureAn SAP system consists of SAP instances. An SAP instance is a group of processes that are Started and stopped at the same time. In SAP NetWeaver 7.0, there are the following Instances:

Central instance Central services instance Database instance Dialog instance

All instances, except the database instance, are identified by an instance number, which is a Two-digit number between 00 and 97 that is unique on a host. Instances can reside on one Host or they can be distributed on several hosts.

Central InstanceEvery SAP system must have one central instance, which includes:

Usage type AS ABAP

o Dispatchero Work processes (dialog, batch, spool, or update)o Gatewayo Internet Communication Manager (ICM)o Internet Graphics Service (IGS)

Usage type AS Java

o Java dispatchero Server processeso Software Deployment Manager (SDM)o Internet Graphics Service (IGS)

When the central services are located on a separate instance, the configuration of the central Instance is the same as the configuration of the dialog instance. If the central services are not installed as a separate instance, the message server and Enqueue server is part of the central instance.

Central Services InstanceThe central services instance – Java central services instance (SCS) or ABAP central Services instance (ASCS) –), forms the basis of communication and synchronization for the Java or ABAP clusters. The ASCS can only be installed for a high availability system with AS ABAP. A central services instance consists of the message server and the enqueue server:

Message server

Only one message server can run on each AS Java or AS ABAP usage type. The message server handles the communication between the dialog instances and also supplies information to the SAP Web dispatcher about load balancing.

Enqueue server

The enqueue server contains a lock table that handles logical database locks plus infrastructure locks set by Java server process. The enqueue server also synchronizes data in a Java cluster. In usage type AS ABAP, the enqueue server handles only locks on data objects.

Database InstanceThe database instance is a mandatory installation component for the installation of an SAP system. AS Java and AS ABAP have separate database schemes. When AS ABAP with AS Java (also known as Java Add-In) is installed, the AS ABAP and the AS Java database schemes are installed in the same database. It is not recommended to use separate databases for the AS Java and AS ABAP scheme.

The AS Java scheme, named SAP<SAPSID>DB, holds the data stored by AS Java and all deployed application objects. The ABAP scheme is named SAP<SAPSID>

Dialog InstanceDialog instances are optional and can be installed on separate hosts. Dialog instances include:

Usage type AS ABAP

o Dispatchero Work Processes (dialog, batch, spool, or update)o Gatewayo Internet Communication Manager (ICM)o Internet Graphics Service (IGS)

Usage type AS Java

o Java dispatchero Server processeso Internet Graphics Service (IGS)

When you add a dialog instance, it belongs to the software cluster. The central instance initiates an update of the dialog instance so the dialog instance has access to the deployed applications on that cluster (this also includes usage types such as EP or PI).A cluster always needs a load balancing solution, for example, SAP Web dispatcher.

A Typical distribution of ECC components

Client deployment strategyThe client deployment strategy is a detailed description of which SAP software clients will be utilized and configured, as well as the technical settings for each client in each system. A client is a logically independent unit within an SAP software system and contains specific customer business data that are not accessible from other clients in the system. Clients also share resources, such as system wide programs and data. Configuration work and testing is performed in clients, and there is typically one client for productive use. Prior to starting any configuration work in any system, you need to define the client roles and deploy them to the system landscape

Client landscape with transport pathsECC development System ECC Quality system ECC Production system

BI development System BI Quality system BI Production system

Development systems (DEV)Client 170/320 - SandboxThis is the Test Client for all customizing work. No transports come from this client. It is intended to be a client that is refreshed periodically from either 150/300 (Customizing) or 160/310 (Unit Test). Customer project members as well as consultants test new configuration in this client before creating it in 150/300 (Customizing). Everyone is given the SAP_ALL authority in this client. Ideally this client is maintained on a separate server in the landscape. Most customers do not have the funding to supply a separate server just for a Sandbox client so we show it here on the DEV system. Nothing is this client is safe or protected. Eventually, everything created in this client will be wiped out.

Client 150

Client 160

Client 170

Client 200

Client 210

Client 200

Client 300

Client 310

Client 320

Client 400

Client 410

Client 400

In an ideal situation, the functional consultants train the customer project members in this client. The consultant leads the configuration activity on the Sandbox client (170/320). On the Customizing client (150/300), the customer project member creates the configuration and assigns it to a new transport with their name.

Client 150 – SecurityThis client is used to generate the Activity Groups, User ID’s, Profiles, Authorizations and other objects needed in the Production clients. This client will be the central user administration which can deploy users for the required systems and clients. The transfer will happen using the Idoc (Intermediate document) and will be the sole client for managing the users in the SAP landscape.

Client 150/300 – CustomizationThis is a unique client. It is the origination client for all functional transports across the landscape. It is the only client in the landscape that cannot be recreated with a client copy. It cannot be refreshed; it can only be restored.

This client is governed by the TMS Methodology. In practice this means that all transports released in this client must be transported to Production. In practice this means that any configuration created in this client, assigned to a transport, that is later found to be either not needed or incorrect, Must Be Deleted in This Client.

The reason for this is the pervasiveness of the integration of R3. It is entirely possible for some piece of configuration to be created in 330 which fixes some obscure problem. It is then ignored until either Unit Testing or Integration Testing. It may be a piece of configuration that is client independent in which case it cannot be discovered until Integration Testing. At that point the error that was fixed on DEV will be discovered anew on QAS because that piece of customization was not transported. It will be located and transported.

These types of scenarios are a leading cause of missed deadlines on projects. Someone turns something on or off that affects everyone else in the client or the system. Valuable time is spent running down phantoms. While this is not totally avoidable, it can be mitigated to a great extent by following the TMS Methodology. If all released transports must go to Production, tracking down a missed piece of configuration is relatively easy. It is either in a transport that has yet to be transported or a transport that has not yet been released. There is no third category of “garbage” transports that are labeled “Do Not Transport”. The methodology dictates that the objects in that transport must be deleted. Too often, missed configuration is found in these “garbage” transports. Avoidable delays are created while the object is moved to another transport, typically creating more delays because unforeseen problems arise during the movement of the needed object out of the “garbage” transport. All too often, a group of objects is needed that is contained in a series of “garbage” transports.

By following the TMS Methodology, Everything Goes, In Order; “garbage” transports are eliminated as an issue.

No transactional data is created in this client. No transactions are run in this client under any circumstances. Customization is created in this client and transported to the Unit Test Client or Integration Test Client for testing.

The Customization Client is the earliest version of the Production Client. It is unique and irreplaceable. It is treated as such by the TMS Methodology.

Client 300 – ABAPThis client is used by the ABAP programmers to create new ABAP code. It contains all the transports that the Unit Test client (310) receives. It should also receive all the master data loads that the Unit Test client receives. It can be refreshed from the Gold Client (300).

Since ABAP programs are client independent, code created here can be tested in this client or in the Unit Test client (310). Having a separate ABAP client allows the functional teams to test their configuration in parallel with ABAP development.

Client 160/310 – Unit TestThis is the first client where official testing occurs. The Unit Test Client is for testing individual transactions and configuration; i.e., the smallest unit of a transaction or business process. Everyone works in the Unit Test Client. All transactions are executed in the Unit Test Client. ABAP code, Security Activity Groups, Data loads, Configuration, Master Data, Batch Jobs are all tested in this client. This client is the earliest version of what Production will look like with data in it.

This client can be refreshed with a client copy. This means that no transports are created here. Nothing unique is created or generated in this client. When problems are found there are two options for resolution; testing in the Sandbox client with the subsequent creation of the fix in the Customizing Client or creation of the fix in the Customizing client without the need to test in Sandbox. In either case, the fix is created in the Customizing Client, ideally by the Customer project member, and transported to the Unit Test Client for further testing.

In limited and specific circumstances that are always documented by a SAPnet note, manual configuration must be performed in a client other than the Customization client. When this is needed, the Unit Test client can be opened for the purpose of performing that customization, then closed again.

In fact, this is not a violation of the TMS Methodology, Everything Goes, In Order; but a corollary. If it cannot be transported then it must be done in every client. The purpose of Everything Goes, In Order is to prevent overlooking some piece of configuration forgotten in a “garbage” transport. If it cannot be transported, then the problem fixed by the manual configuration will manifest itself in every subsequent client and require the same manual process to be performed, preserving the intent of the Methodology.

Quality Assurance System (QAS)This is the Integration Test system. It is the closest version of the Production System. After Go Live this system is usually refreshed from the Production client periodically. This gives the developers a static version of the production client in which to conduct tests. Before Go Live this system is used for more extensive testing. Completed Unit Tests are strung together in longer tests that constitute the entire business process. In addition multiple business processes are run simultaneously to simulate the production environment.

Client 200/400 – Gold ClientThis client receives all transports from the Unit Test client (160/310). It is used to refresh the Integration Test client (250). It contains all the transports and master data loads. It contains no transactional data.

This client can be recreated with the transports from the Unit Test client (160/310) or it can be refreshed from either the Unit Test client (160/310) or the DEV Gold Client (150/300).

Client 210/410 – Integration Test ClientThis client is used for Integration Testing. Integration Testing consists of Unit Tests strung together to comprise a complete business process. Eventually all business processes are tested together to simulate the production environment.

This client can be recreated with transports from the Unit Test client (160/310). It can be refreshed from the Integration Gold Client (200/400) or the DEV Gold Client (150/300) or the Unit Test Client (160/310). It would typically be refreshed by the Integration Gold Client (200/400).

Production system (PRD)This is the Production system. It contains live data and is used to record the business transactions for the customer. It typically contains one client.

Client 200/400 – Production

Transport strategyThe transport strategy is a plan for moving SAP software system change requests through the system landscape. This plan ensures that the development and configuration teams adhere to a consistent policy and procedure concerning the following information:

The release of system change requests The timing of imports Approvals for transporting system change requests

There needs to be a proper and disciplined TMS lifecycle methodology,

Everything Goes, In Order. Everyone works in the same client. Master Data: Everything that can be Transported, Will be Transported. No Transactions will be executed in the Configuration Client.

Everything Goes, In OrderOne of the major mistakes than can occur on a SAP project is to allow the flexibility of the TMS system to become a license to leave transports in the queue. Nothing can get a project off track quicker than a list of transports sitting in an import queue for several months with no action on them. The longer released transports wait in the queue, the more corrupt and unreliable the institutional memory about those transports becomes until finally, no one is left on the project who can remember the original purpose of those transports.

The solution is to require all transports to be moved all the way to Production. The standard response by the functional people is to complain about cluttering up the production system with garbage transports. This is a fallacy. The only place transports accumulate is in the log files and these are maintained by Basis. By requiring that all transports move through to Production the chance of missed items is eliminated.

Missed items are those corrections that are put into a transport with other items that are deemed to be either unimportant or a configuration dead end. Because the transport is released in the Development system everything works as expected, no thought is given to moving that transport to the Integration system until after integration testing has begun and the configuration doesn’t work because of the missed item. Everything goes; In Order eliminates the need to remember the entire contents of each transport for the functional teams. There are no missed items because every released transport must be migrated forward.

The next functional team objection to this tenant is a philosophical one; broken configuration will be transported to the production system along with the correct configuration. This is a true statement. It has no negative impact on any system. As long as the correct configuration is imported in the production system immediately after the broken configuration, no one will ever know that the configuration was ever broken.

The next objection is also philosophical, I want to transport garbage data into a new client, typically the Unit Test client, but I don’t want to clean up after myself. I want to leave the garbage data in the Unit Test client and only put good data in the production client. This is where the discipline of the methodology kicks in. Using a set

of test data is perfectly acceptable, especially in the beginning of the configuration process when master data is still in a state of flux and constant change. Once the master data has solidified, a simple deletion transport cleans up the test data in the Unit Test client. Again, sending both transports through at the same time to the Production client has the net effect of the test data never really existing in the Production client.

Everything goes; In Order eliminates transition difficulties when consultants are assigned another person’s transports to manage. The simple assumption can be made that since all released transports will eventually make their way into the Production system, simply fix the existing problems in the Development client and eventually that transport will migrate through the system and fix whatever the original problem was. No continuity of institutional memory is required. Simply assuring oneself that all released transports have been imported into the system in question eliminates any undiscovered configuration hanging out in a forgotten transport somewhere. The fix can be made and migrated to the appropriate system with the confidence that nothing has been overlooked.

Everything goes; In Order imposes discipline on the functional teams by requiring all released transports to be migrated. Until the transport is released, they are free to leave it in the Configuration client. Until the transport is released they are free to add and delete corrections from it. But once it is released it will be migrated to the Production client.

The second half of this tenant, In Order, attempts to eliminate predecessor issues with transports. By maintaining the order of import from the Customization client into the Unit Test Client when the QAS system is brought online all of the existing transports can be moved in a block. Likewise the same method can be used when the PRD system is brought online.

In Order guarantees, that any unknown predecessors are transported properly. Typically, transports move very quickly between the Customization client and the Unit Test client but much more slowly between the Unit Test client and the Integration client. Because of the rate of change between the Customization and Unit Test client a transport may in fact have a predecessor that is not identified until the attempt to import it into the QAS system. Then when it fails, the unknown predecessor must be identified.

In Order, eliminates this issue. It maintains a known working list of transports and the order of import into the Unit Test client. The assumption can be made that if the order of import was successful into the Unit Test client, that same order of import will be successful into both the QAS system and the PRD system.

Everyone Works in the Same ClientThis one is typically easier to implement; not doing it means more work for the functional teams. This tenant also involves the client strategy methodology which will be discussed in detail in a later section.

Simply put all functional teams are required to perform all activities in the same set of clients. All configurations are created in the same client. Unit testing is performed in the same client, different from the Configuration client. Integration testing is performed in the same client by all functional teams, typically on the QAS server.

There is one notable exception to this tenant and it is not present on all projects. Payroll Unit Testing can be requested to occur in a separate parallel Unit Test client. Payroll functions lock most areas of HR during processing. Once initial configuration for Payroll is complete, more detailed HR configuration can occur in areas that do not directly affect Payroll processing. However, Payroll processing can and does affect those areas making it difficult or impossible for the other areas of the HR team to continue configuration while Payroll Unit Testing is occurring. Thus a separate parallel Payroll Unit Test client is the typical solution. Payroll configuration must be created in the same Configuration client and migrated to all clients in the exact same

manner as other configuration. Having a separate Unit Test client for payroll is not a necessity. Payroll Unit Testing in the standard Unit Test client can be built into the project plan.

One major concern for parallel test clients is the danger that configuration transports will not be imported in a timely manner or forgotten altogether. This concern is obviated by the first tenant, Everything Goes, In Order. If a Project implements a separate Payroll Unit Test client, it becomes part of the landscape and receives all transports at the same time as the standard Unit Test client. As we shall see in the client strategy section, the basic tenants of the TMS Lifecycle Methodology have the flexibility to handle any unique needs for a given project.

This tenant can be further expanded with the addition to the statement; everyone does the Same Work in the Same Client. This means that the Configuration Client is only for configuration, no transactions are entered there. The Unit Test client is for all functional areas and requires that all functional teams must load required data either with a transport, data load program or manual entry. The same applies for the Integration Test client. There is only one Integration Test client; all functional teams must test there.

To summarize, the tenant Everyone Works in the Same Client and its expansion, Everyone Does the Same Work in the Same Client, actually allows for great flexibility to meet apparently unique needs of an individual project. In combination with the first tenant, Everything Goes, In Order, literally any client strategy can be implemented based on the project requirements.

Master Data: Everything that Can be Transported, Will be TransportedThis tenant is almost self-explanatory. With each version of R3, a greater percentage of Master Data can be transported. With version 4.6, almost everything except MM Master Data can be transported. This has several advantages.

Combined with the first tenant, Everything Goes, In Order, Everything that Can be Transported, Will be Transported ensures that all transportable Master Data will end up in the Production client. And it will be available for use along the way in the Unit Test and Integration Test clients. Older versions of R3 required writing custom data load programs for most Master Data. This introduced uncertainty into the process of populating clients with Master Data. Version control of data loads is very difficult. It requires an enormous amount of planning and discipline on the part of all functional teams. Every time Master Data is changed, the decision is debated over which clients need the new version of the Master Data.

This tenant ensures that new transportable Master Data makes it into all the clients, preserving synchronicity across the landscape. New versions of transportable Master Data are imported into all clients, eliminating version control issues. Non-transportable Master Data is significantly reduced and is more manageable.

No Transactions will be executed in the Configuration ClientThis tenant becomes self-evident as the other tenants are embraced. The functional teams typically police themselves for this tenant. Entering transactions in the Configuration Client typically pollutes some Master Data to the point where it has to be regenerated. In conjunction with the first three tenants; moving all transports, requiring the functional teams to transport all Master Data and work in the same client, this tenant is the final piece of the TMS Lifecycle Methodology that ensures a logical, practical, repeatable process is embraced by all members of the project.

Server infrastructureThe server infrastructure defines how the systems are laid out and distributed. The physical servers are of concern here, and their facility-related requirements are included in the server infrastructure document.

Solaris Chemtech Pvt.Ltd., Karwar

Solaris Chemtech Pvt. Ltd, Gurgaon

The servers are connected to a SAN box and share storage according to the allocation for each file system. For performing the backup of the SAP, Tivoli software is installed on UDNWEB1 and acts as the Tivoli server manager (TSM) and Tivoli ERP client/agent is installed on all other systems for performing the individual backup on tape media. The tape media are loaded in a central pool that is managed by the TSM.

System printing infrastructureThe system printing infrastructure is a documented definition of how the printing environment is laid out and distributed. Areas of concern are as follows:

Business needs Expected volumes Print/fax servers and protocols Physical location of printers Printing for special purposes, such as bar codes

x-series serverHost-UDNWEB1IP-192.168.4.21

p-series serverHost-UDNUEP1IP-192.168.4.12

p-series serverHost-UDNUBP1IP-192.168.4.13

p-series serverHost-UDNUPP1IP-192.168.4.16

p-series serverHost-UDNUBD1IP-192.168.4.15

p-series serverHost-UDNUED1IP-192.168.4.17

p-series serverHost-UDNUEP2IP-192.168.4.18

x-series serverHost-UDNWEB1_DRIP-192.168.4.xx

p-series serverHost-UDNUEP1_DRIP-192.168.4.xx

p-series serverHost-UDNUBP1_DRIP-192.168.4.xx

p-series serverHost-UDNUPP1_DRIP-192.168.4.xx