Essential Basis for SAP (ABAP, BW, Functional) Consultants Part-II

This blog is continuation of Essential Basis for SAP (ABAP, BW, Functional) Consultants Part-I

Transport system in SAP is used to move objects from one system to another system, most of the time in one direction.

This is the picture we visualize when we think about transport system in SAP. Someone made some changes or created a new program that is captured in transport, after releasing it, Basis imported in QAS system then again Basis imported in Prod system, its kind of linear flow attached tightly in sequence (Dev to QA then QA to Prod).

I want to bring the real picture which in turn will raise some questions and answers all of them!

Q : What happens when someone release any transport request?

A : SAP creates two files at operating system level. In transport directory usually at location /usr/sap/trans there are two directories one is "data" and other is "cofiles". Cofile contains information like when it is released when imported with what RC code and time-stamp kind of information. Inside data directory it creates dump of the content which was present inside the transport, these dumps are database and operating system independent. See the arrow direction in above diagram, transport are released from DEV, two files got created, when Basis will go to import those transport in QAS system SAP will read the data dump file and write it back to database of QAS.

Interesting fact is for the example Dev can be on Window/MS-SQL; QAS can be on Linux/DB2 and PRD can be on Solaris/Oracle. The same set of data file and cofile will be read and content of data file will be written back to their respective database.

Q : What will happen when QAS system is down/unavailable, someone created an object in DEV and after capturing it in transport, he released the transport, Is it possible to import that transport in PRD without importing it to QAS?

A : As the arrow suggests, YES. The transport number should be added manually to the PRD transport buffer and it can be imported without any glitch.

One more step in same direction  -- If support pack level is same or the object captured inside transport has no structural conflict with other system then simply copy the data file and co-file of the required transport and put it to the directory of your target system landscape, add the transport number to import buffer and import it, you will get the same object in new landscape.

Okay, lets come out of operating system level and goto SAP, see below screenshot.

This is a normal transport route designed by Basis where transport released from Dev system goes to Quality and from Quality to Production and training system.

Please notice the orange color lines coming out of Dev system these two lines are called Consolidation route. The line or lines which comes out from Quality is called delivery route. Consolidation routes are attached with Transport layer, delivery routes are not.

The transport layer has interesting connection with ABAP Developers, which I have noticed most of the them are not aware of.

From these two screenshot its evident that packages are related to Transport Layer, SAP delivered packages are attached with transport layer named SAP and Z packages needs to go in some Z package. You can have more than one Z tansport layer and you can attach some of your Z package to one Z layer rest in another Z layer. You can change from one Z layer to another from SPACKAGE/SE21 else SE80 transaction.

To be able to transport development objects, you must define a package that is not local (such as $TMP)

Before closing part 2 of this blog, let me briefly describe about SAP parameters.

When we start SAP system, some parameters/variables are read from OS level Environment Variable at the same time all possible parameters with their default value are embedded/hard-coded in Kernel of SAP, so they are always there. In process of starting a flat/text file stored at OS level is read which is called default profile (DEFAULT.PFL). Default profile is used to store those parameters which are same for all instances of SAP like where is Database, where is message server what is the name of the SAP system and other stuffs. If you will put some other parameter with value(non-default); they will override the kernel default value. After default profile another flat/text file is read known as Instance profile. This file is used to store those parameter related to particular instance and their value can be different from one instance to another instance like total number work process in one instance memory parameters etc.

SAP parameters are of two type from runtime perspective. If the value of any static parameter will be changed it will not come to effect unless SAP is not restarted. Those parameters which are dynamic will come to effect immediately but they will wash-out when SAP will be restarted, because they are not written down to any of the two parameter files at OS level.

Q : How to check if any parameter is dynamic or static?

A : Goto transaction RZ11 put the value of parameter. If there is tick mark (hard-coded) means its Dynamic otherwise not.

Tcodes to check-out sap parameters: RZ10, RZ11, RSPFPAR and RSPARAM(report)

In my next blog and most probably final part we will discuss about RFC/SM59 connections and other remaining useful topics.