BW transport issue: object locked despite transport is released

Recently I saw a situation where object was not able to be included into the transport. System was indicating that the objects is locked via pop-up message (TK117):

Object XXX locked for request/task <SID>Kxxxxxx

Choose ‘Display object’ or ‘Cancel’.

However, the object was not locked by any transport neither task. The transport that the error mentioned was released and moved across the landscape long time ago.

To solve this issue, I went to t-code SE03 then in menu Requests/Tasks -> Unlock Objects (expert tool) and via this I was able to unlock object.

Notice that 1^st option – Unlock Object List needs to be selected. Transport Request/Task input field needs to be populated with the task no of the Transport Request in which the error message indicates that it is locked in.

 

Behinds the scenes what this t-code is doing is to remove a lock entry from table TLOCK (Change and Transport System: Lock Table). The table basically holds all the objects that are locked in the TRs. In my case for some reason while I released the TR the lock entry wasn’t removed from the table. And it is not known to me what was that reason…

 

Doing further research about the error I found also SAP Note 2537981 - SE13 | TK117 | Request lock on nonexistent task/request, rep ZSLA_DELETE_ORPHANED_TLOCK_2. The Note describes how to removed the lock entry (so called orphaned lock) for LIMU TABT objects.

 

SAP background jobs and processes behind transports (CTS)

Transport system of SAP objects is a component that enables the controlled movement of software configurations, developments, and customizations across different systems in a landscape. It ensures deployment of changes from development to testing, quality assurance, and ultimately to production systems.

There are several steps involved while particular objects is being moved. Proper sequence and list of the steps executed depends on what type of objects are present in the transport request (TR).

Some of the ABAP steps are performed in the SAP system. These are:

- ABAP Dictionary activation (A)

- Distribution of ABAP Dictionary objects (S)

- Table conversion (N)

- Matchcode activation (M)

- Import of application objects (D)

- Update of version management (U)

- Execution of XPRAs (R), XPRA = EXecution of PRograms After import  or Executable Program for Repair and Adjustment

 

When there is a transport request being imported into target systems following steps are executed:

Step                                                                     Program (ABAP prg/OS level cmd) executing step

SHADOW_IMPORT()                                              OS cmd: R3trans

DD IMPORT (H)                                                    OS cmd: R3trans

DD ACTIVATION (A)                                             ABAP prg: RDDMASGL

DISTRIBUTION OF DD OBJECTS (S)                       ABAP prg: RDDDIS0L

TBATG CONVERSION OF DD OBJECTS (N)               ABAP prg: RDDGEN0L

tpmvntabs                                                          OS cmd: tp

MAIN IMPORT (I)                                                 OS cmd: R3trans

tpmvkernel (C)                                                    OS cmd: tp

TBATG CONVERSION OF MC OBJECTS (N)               ABAP prg: RDDGEN0L

IMPORT OF SELFDEFINED OBJECTS (D)                  ABAP prg: RDDDIC1L

VERSION UPDATE (V)                                           ABAP prg: RDDVERSL

EXECUTION OF REPORTS AFTER PUT (R)                ABAP prg: RDDEXECL

 

Transport related jobs (RDD*) jobs:

Job/ABAP program RDDIMPDP (or JOB_RDDNEWPP) - a dispatcher (transport deamon) program for transport activities running within NetWeaver/ABAP platform based systems. It receives information from the external transport program (OS level programs) tp and R3trans via table TRBAT. The job is normally scheduled by ABAP program RDDNEWPP.

Shadow import – SAP system upgrade relevant only. It importss the upgrade data into Customizing tables, as well as the transport requests of add-ons, support packages, and languages.

DD import – is a phase where the Data Dictionary (DDIC) objects are imported into the target system during the transport process. The DDIC objects include data elements, tables, views, domains, and other dictionary-related components.

DD activation - Job/ABAP program RDDMASGL - runs Data Dictionary Activation, if there is an object in the TR has Data Dictionary object and it was imported before, during Data Dictionary Import.

DISTRIBUTION OF DD OBJECTS - Job/ABAP program RDDDIS0L – phase where the Distribution tasks related to DDIC objects are performed during the transport process. This phase handles the distribution and activation of DDIC objects across the SAP system landscape. RDDDIS0L runs the report RDDGENBB, if the transport request object list has at least one DDIC object, its DDIC import and DDIC activation already happened and the object has to be adopted on database level. Table structures are changed if necessary.

TBATG CONVERSION OF DD OBJECTS - Job/ABAP program RDDGEN0L - this phase refers to the conversion of DDIC objects during the transport process. It is the conversion from the original system format to a format of the target system.

Tpmvntabs - phase is responsible for updating the database tables related to transport management in the target system. During this phase, the transport tool performs various tasks related to transport management tables to ensure their consistency and synchronization with the transported objects. These tables store information about TR, their status, logs, and other relevant data.

MAIN IMPORT - phase where the actual objects contained in the TR are imported into the target system. Tasks like object integration, object activation, dependency resolution, conflict resolution and post-import activities are executed.

TBATG CONVERSION OF MC OBJECTS - Job/ABAP program RDDGEN0L - this phase refers to the conversion of Modifiable Customizing (MC) objects during the transport process. This phase is responsible for converting the MC objects from the original system format to a format suitable for the target system. Modifiable Customizing objects are system-specific configurations and settings that can be customized by customers. These objects are typically maintained in client-dependent tables and are specific to individual systems. During the transport process, these objects need to be converted to make them compatible with the target system.

Tpmvkernel -

IMPORT OF SELFDEFINED OBJECTS - Job/ABAP program RDDDIC1L – it does import of ADO (Application Defined Objects) from table TRBAT.

VERSION UPDATE - Job/ABAP program RDDVERSL - refers to the process of updating the version information of the transported objects in the target system. This phase ensures that the system recognizes and tracks the correct versions of the imported objects.

EXECUTION OF REPORTS AFTER PUT - refers to the execution of specific reports or programs after the objects contained in the transport request have been successfully imported and applied to the target system. Job/ABAP program RDDEXECL - runs as Method Execution (XPRA), if an application has their own object in the transport object list and it was imported during Main Import, and their application specific method/function/program has to run.

 

Other ABAP programs related to transports:

RDDPROTT - displays the log for a specific transport request. Used by t-code SCTS_LOG -Transport Log Overview.

RDDFDBCK - import feedback process, Message After Exporting or Importing Requests

RDDDIC3L - deleting obsolete or no longer required entries from the transport request buffer in the SAP system.

RDDMNTAB - runs a move nametab, for a new ABAP objects that were imported, their runtime objects have to be put in the active runtime environment.

RDDDIC0L – Exports ADO (Application Defined Objects) objects

RDDDIC1L – Imports ADO objects

RDDDIC3L - Generates ABAP programs and screens

RDDVERSE –Version Management: Version at Export

 

Important tables:

TRBAT - it forms the interface between the transport control program tp and the SAP system. To trigger an ABAP step, tp writes control information to this table. The JOB_RDDNEWPP phase schedules the event-driven background job.

TRBATS - Communication Table for Deployment Control

TRJOB - Job ID (e.g. 07444600) that is running at some point of time in teh SAP systems is entered in this table.

 

More information:

Change and Transport system

2147060 - Import steps not specific to transport request

No Routine (ROUT) objects in BW4 transport of transformations

You may notice that in BW4 based systems transporting of Transformation is simplified. In classic versions of BW there were usually objects like Routine included in the transport requests in case particular Transformation contained them. The objects (OBJECT = ROUT) represent either formula in transformation rules or Start/End/Expert Routine. Such transport requests look like below one:

Routine objects of the Transformations are stored in table RSTRANSTEPROUT (Rule Type: Routine). They still are there in the table in case of BW4 systems.

However, in BW/4 based systems there are no transport entries like that anymore. Reason is that, routines and formulas are embedded with transformation metadata. The table RSTRANSTEPROUT has a column CODE that contains all the code of a particular routine and formula. Because of that the ROUT object are not necessary anymore. This change is in place since SAP BW/HANA 1.0 SP04.

 

More information:

2548884 - Formula handling and transport related problems in BW/4HANA

SAP Transports: difference between R3TR and LIMU

Development objects in SAP world are being moved within the SAP systems via so called SAP transports. SAP system records all changes made (ABAP workbench or customizing changes) in the system in transport requests. Particular object that is being transported is uniquely identified via below combination of keys within the transport. There can be many objects included in one transport.

 

Program ID (PGMID, 4 char)

Object Type (TROBJTYPE, 4 char)

Object Name (SOBJ_NAME, 10 char)

 

Program ID - identifies the type of the transport entry. It has following values:

R3TR - Name for Repository objects and Customizing objects, so called Full/Group Object

LIMU - Subobject of Repository/Development objects

LANG - Language specific part of object, e.g. some selection text of the ABAP program that are maintained there. This can include different language versions of such a text elements.

CORR - Comment (Automatic)

* - Comment Line

Object Type – Type of particular objects, e.g. PROG for Program, CLAS for ABAP Objects Class, ADSO for DataStore Object, HCPR for SAP HANA Composite Provider etc.

Object Name – particular object technical name itself

 

A difference between R3TR and LIMU is that the R3TR stores an information about the whole object (let it be an ABAP class). Whereas the LIMU stores an information about subjects e.g. a method of the ABAP class. Best practice from my point of view is to always transport object in full. Means instead of just taking a piece of sub object to take whole object. Of course as you are the only developer that is working on the whole object.

Few words about SAP transports

For developers coming to SAP world from different ecosystems it is sometimes confusing to understand how does SAP (e.g. within NetWeaver) works with transporting of developer objects. As a starter, there are few terminology things as per different types of development objects transporting:

ABAP world:

Change and Transport System (CTS) - organizes development projects in ABAP Workbench and in Customizing, and then transport the changes between the SAP systems in system landscape.

Transport Management System (TMS) - it is infrastructure for the transports, provides tools to configure transport routes, display import queues, import requests, transport workflow etc.

Non-ABAP world:

The CTS is used to transport ABAP objects. There is also Enhanced Change and Transport System (CTS+), used to transport also non ABAP objects, mostly JAVA based artefacts (like SAP BusinessObjects, SAP Cloud Platform, SAP Enterprise Portal, SAP HANA. SAP Hybris Commerce Suite, SAP Manufacturing Integration and Intelligence (SAP MII), SAP Mobile Platform, SAP NetWeaver Development Infrastructure (NWDI), SAP NetWeaver Master Data Management, SAP Process Integration (PI), etc.).

HANA world:

When it comes to HANA development artefacts there is so called SAP HANA Application Lifecycle Management (HALM) or CTS+ for SAP HANA. It is used to move HANA objects throughout their application development lifecycle. There is also SAP HANA Transport for ABAP (HTA) that can be used to synchronize objects and packages from the SAP HANA repository to the SAP HANA Transport for ABAP repository (HTA repository) in the ABAP system and add them to a transport request. Concerning this there is SAP HANA Transport for ABAP for SAP HANA Deployment Infrastructure (HTA for HDI). The HTA for HDI is the successor of HTA. T-code for HTA is SCTS_HTA.

SCP world:

Lastly when it comes to SAP Could Platform (SCP) there is suite of solution to support change management of either pure could related development artifacts (so called cloud native) and hybrid applications.

Now back to ABAP world. At last year TechEd there was a git-enabled CTS (gCTS) solution presented. This is basically the SAP move towards DevOps thing that is present in non-SAP ecosystems. SAP is trying to leverage state-of-the-art processes and tools that are out there mostly in form of open source project within the SAP change management. It comprises of two main components:

• Git-based versioning like branch and merge support

• Connect ABAP processes with Continuous Integration (CI) tools (e.g. Jenkins, Bamboo, GitLab, etc.)

For me this is still quite a faraway future. These tools are currently not present in SAP system out-of-the-box. It is a usual case that to deploy it they require a significant effort to implement it. There needs to be other non SAP server available to run e.g. CI server etc. Because all of these many customers are not getting all advantages of DevOps. Thus are stuck with old technology, only utilizing what is available out of the box from SAP. As a side note the CI is a complex topic but it is a practice of merging all developers working copies to a shared code line several times a day.

Note that there is also abapGit as open source project. However, SAP is not using it and they came up with their own implementation of the git for purposes of the gCIT.

One more remark on how SAP NetWeaver transports are working. It is an important thing is to understand that in SAP NetWeaver transports only records that a change was made to a particular object. It does not records what the change was about. In other words, the systems always create a kid of a snapshot of the involved object. For the version, management there is a different thing – Version history, build in developer t-codes like SE8/SE38 (going forward all this will be replaced by the git based repositories). Also all the changes done are only stored in original system (so called development system). They are not moved to any other system in the landscape. It means that complete version history of all repository objects are only remain in the development system. This is also in line with SAP strategy that advises customer to always retain the development system. There can be special cases in case the DEV is being replaced (deleted or somehow not planned to be used anymore) and there is a need to get all the version history to the new DEV system. In such a case see SAP Note 130906 - How can versions be transported?. It describes possible workaround to exported the complete version database and import it the other system (e.g. a system copy of “old” DEV system).

The fact that system only records object into which the change was done is important to understand as there may pop up many transport collisions between multiple developers working on same objects. E.g. in case there are several methods being developed in one ABAP class it is not possible to just move the one method and do not include others which are there. Simple just to put an entry like LIMU METH <method_name> into the transport request won’t move the particular method. Along such an entry, also the whole class definition (R3TR CLAS <class_name>) needs to be present in the transport request.

More information:

ABAP: CTS, gCTS

nonABAP: CTS+

HANA: HALM

SCP: Software Logistics for SAP Cloud Platform

Running out of transport request numbers?

In large SAP installations serving multinational companies where many SAP clients are heavily customized within one SAP system there can be a huge IT department where even hundreds of SAP developers are working. While developing either a new of changed functionality the developers are using transport numbers to carry the changes across the systems in a landscape. On top of that, also SAP functional consultants are moving their changes via customizing transport requests. In such an environment after few years, the SAP installation can face an issue that number range that is providing numbers for the transport requests is running out of the numbers.

Normally the number range for the transport requests generates the numbers within the range ( <SID>K900000 - <SID>K999999 ). Theoretically, there can be up to 100k transport requests with the range. If the number get closer to the 999.999 it means that, the system is reaching to the limits of that particular number range.

Starting with SAP ERP Release 4.6A (back then around year 2000 called R/3 system) a new interval will be automatically used by the SAP NetWeaver based system. It is the range ( <SID>K9A0000 - <SID>K9ZZZZZ ). This will guarantee that another more than 40 million free transport requests numbers are available for future.

 

More information:

106911 - Transport system: number range filled for requests

1674286 - How to modify CTS transport number range (ABAP)

2951296 - Transport TR range getting exhausted