Skip to Content

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.

9.TransI.png

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!

9.TransII.png

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.

9.TransIII.png

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.

9.TransIV.png9.TransV.png

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.

10.parameterI.png

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.

10.parameterII.png

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.

10.parameterIII.png

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.

Please rate this, if you liked it to make it visible to others.

Your comments/suggesting are most welcome.

Link to third part of this blog:

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

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Vinoth Kumar

    Thanks for details.

    Can you tell, what exactly happens when SAP is restarted. I heard from Basis, SAP is restarting, and system will be unavailable for next 1hour or so… but not sure what happens..

    (0) 
    1. Ishteyaque Ahmad Post author

      Hey Vinoth,

      Thanks for your query. I would like to give answer in three installments so that you can stop whereever it starts OHT (over head transmission) 😀

      A. One hour for SAP restart is too much, unless we are not talking about many instances. For one SAP system one hour is playing extra safe. If basis team has taken one hour downtime to perform some maintenance activity which involves restart as well then its OK especially if there is Java Stack involved, most of us (basis guys) do not much rely on java restart, this java guy sometime takes unpredicted time to come up specially after change of java parameter or kernel upgrade and if its support pack upgrade then… {once in my case it took straight 5 hours just to come up}

      If your SAP system is on cluster/High Available then before taking restart cluster needs to be freezed/frozen then take restart of SAP and unfreeze the cluster again.

      B. When SAP is started:

      1. First it checks if database is running or not and connection can be established successfully or not. If yes then OK else database is started.
      2. Then message server is checked if it is already running or not, if not then its started too
      3. Finally main instance is checked. In this process all type of work process is started, each work process tries to connect itself to database and dispatcher if connection to anyone of them will fail the work process will die.

      The starting sequence is taken from a profile file called Start profile, rest of the information is fetched from Default and Instance profile.

      C: One level down:

      1. With help of OS environment variable and entry from Default profile the name of SAP and location of database home and SID is found, a special work process named “sapstartsrv” is started if not already running. This process takes care of further start process. With help of database connectors (varies from database type) it will be checked if database is up or not and if it is up, the database should be in “open” state.
      2. “sapstartsrv” service reads Start profile and sets environment variable like LD_LIBRARY_PATH, SHLIB_PATH and LIBPATH. Further, a program sapcpe is called to replace existing kernel file, fresh kernel files are copied from location /usr/sap/<SID>/SYS/exe/run/  to /usr/sap/<SID>/<InstanceName>/exe/
      3. If message server is installed on different server in case of distributed installation or High Availability installation the message server process and enqueue process should be started separately before starting any other instance, the connectivity to database is not needed for message server process and enqueue process. Lock table is created in memory where enqueue process is running and it is unique across SAP system. Message server also takes care of license of overall SAP system, so hardware key of this server is used.
      4. In the process of starting main or dialog instance, Instance profile is read for information like how many work process and their types(dialog, background etc), with what memory and lots of other parameter. When a process in process of starting various types of initialization and connectivity check happens, for the example memory gets allocated in RAM for each process, kernel version is checked, library files are read and loaded, each process establishes connection with database files. After successful birth of a process, it rushes to have connection with its Dispatcher process for registration.
      5. If it is ABAP+Java then signal has been sent to start java bootstrap program, which in turns whole new sequence of java startup is triggered.

      Does this answers your query at some extent?

      (0) 
  2. Benedict Venmani Felix

    Hi Ahmad,

    Very insightful blog. Can you please give more clarity about,

    i) Transport Layer

    ii) Parameters

    What they are and how they are used by the system?

    Thanks,

    benedict

    (0) 

Leave a Reply