SAP Landscape
I spoke to a friend recently who had just given an interview in SAP technologies. Interview went pretty well and she was asked some regular questions and some extremely tricky ones. She was able to clear it and move ahead with the next rounds…but while we were discussing about it, there was this one question we would always come back to and discuss more. That got me to do a search and write up this substantial details on the topic
Any organisation running ERP, regardless of the size, will need to work with various versions or instance of the same ERP application, for development, testing and maintenance activities. When multiple people are working on the same application, technical system specialists must be able to install new standard software versions; the ABAP developers must be able to continue their developments; the functional specialists must be able to test and accept new/changed software; project members must be alto to perform integration tests. In the ideal scenario, each of these requirements in supported by a separate environment. However, in reality we either create a system instance or by doing a logical environment split. A system instance is created by installing the SAP software on a physically separate hardware.
Client means a separate SAP logon environment, a client is an entity with independent information and data. Various SAP clients can be defined within one SAP system instance in order to distinguish among several logically separated environments. A client is not an environment, its just a primary field called mandt in most of the SAP database tables. All programs applied by a user employ the client to select and update data in the SAP database, without having to explicitly specify in the ABAP code. There is client dependent data, which is user master data and authorization data and most of customizing settings. The client independent data are ABAP programs, ABAP dictionary definitions. Although they are created and started from within one client, they are stored and used independently from the client.
Continuous synchronization takes care of new or changed functionality and periodic refresh of the entire environment. SAP transport Management System takes care of transferring new/changed ABAP developments and customizing settings. Each isolated piece of functionality can be established individually, released for transport, exported from source client, imported and tested in target client; and finally accepted and implemented in the SAP production system. This development of new functionality is an ongoing process. In order for the production system to resemble the development system as closely as possible, there must be a periodic refresh. The development system is refreshed to look like the production system as over time due to incomplete developments or abandoned functionality, the development system will have some polluted code, which needs to be stabilised.
The SAP R/3 system consists of two or more separate SAP systems. There are many variants of an SAP System Landscape. It can have One System, two systems or more systems. Let us dwell into each of these to know more. One SAP R/3 System logically subdived into two of more clients which are used for development and production. Since the development happens on the production system, a logical/technical error can affects the options for working in all clients. Data security problems also exist and hence having a single SAP R/3 system is not viable.
Two System SAP R/3 systems have two physically separated SAP systems for production and development. On development system, there are at least two clients: one for executing all developments and another for testing/ acceptance. The advantages of the two System model are 1> Since development and testing is on different clients of the same system, it is very quick and flexible for developments. 2> One can minimize the extra effort needed to exchange and monitor the transport of new program versions from development to SAP production System. The disadvantage of this model is that each separate system’s master and transaction data will be out of sync, which will affect testing in the development system. Testing properly in the ERP environment is difficult without having test data that closely resembles the production data. We can selectively update a small portion of master and transactional data from production system, this can be done with tools like eCATT, LSMW; but there is no straightforward solution.
Three System SAP R/3 system has a development system, an acceptance system and a production system. The acceptance system is in the size of the production system so that a complete database copy can be made. The benefits of this system are 1> Developers can rely on the exact customizing settings and authorizations used in production during their test activities. 2> Elaborate testing of complex functionality such as interface testing is better supported because the master data in acceptance system will be completely identical to the master data in production. 3> Solving incident messages are better supported as one can easily replicate the incident. Copying production data to the acceptance system is more straightforward than it is in the two system model. Some disadvantages are 1> post-processing of confidential data from the production system may be necessary. 2> Open transports in-between the acceptance and production system must be secured before a database copy and then restored.
Nice taking to all of you. Thanks for reading.. 🙂