Standard SAP ERP Central Component (SAP ECC) does not provide an easy way to identify and track all transports related to a given work package such as Reports, Interfaces, Conversions, Extensions, Forms, and Workflow (RICEFW) objects, configuration designs, security changes, change requests, or testing issues. An accurate list of transports in the correct sequence is required whenever a work package is ready for migration from development to test and production. If not done correctly, the outcome may be a missing transport or an out-of-sequence transport.

Many projects work around this problem by using methods such as maintaining the transport list for each work package (key object or change request) in a Microsoft Excel spreadsheet. However, with no reliable way to enforce compliance for updating this spreadsheet each time a new transport is released, it is often out of date and inaccurate. Furthermore, it becomes even more difficult to produce a comprehensive list of transports that includes all corresponding transports from all work streams (such as functional and security) in the correct release order.

SAP’s solution to this problem is to implement Change Request Management (ChaRM). However, if your project is not yet ready to commit time and resources to a full ChaRM implementation, then your ABAP developer can build a lightweight alternative to ChaRM, a simple transport management system, in as little as one weekend. This alternative enables you not only to clearly identify all SAP ECC transports associated with a particular change request or work package, it also helps you monitor their collective import and export status as those transports race toward the production system.

I show you, step by step, how to build and implement this solution, which involves creating a couple of tables, a table maintenance generator, some quick ABAP, and implementation of two Business Add-Ins (BAdIs).

Design Overview

The process to set up this simple transport management system involves the following four steps:

• Step 1. Create a change master table ZTROBJECTMASTER to store a master list of all change requests and work packages (key identifier)
• Step 2. Create a transport tracking table ZTRTRACKING to store assignment of each transport to a valid key identifier and transport status
• Step 3. Implement BAdI CTS_REQUEST_CHECK
• Step 4. Implement BAdI CTS_IMPORT_FEEDBACK

This article assumes a four-system SAP ECC landscape: development (DEV), integration test (SE), regression test (QA), and production (PE), as shown in Figure 1. If you are using a three-system landscape, then make the necessary adjustments with the table design as you build this solution. The same applies if you don’t use the system acronyms SE, QA, and PE mentioned in this article. Figure 2 shows an overall flow diagram of how various components of the solution work during the transport release process.

Figure 1

Four-system SAP ECC landscape

Figure 2

Transport release process flow

Step 1. Create a Change Master Table

In transaction SE11, create table ZTROBJECTMASTER using the entries in Table 1. This table stores a master list of all change requests and work packages (key identifier). Table 2 explains each of the fields you need to set up to create table ZTROBJECTMASTER.

Table 2

Fields for table ZTROBJECTMASTER

Table 2

Detailed description of fields in table ZTROBJECTMASTER

Next, in the Delivery and Maintenance tab, specify Delivery Class A as this is an Application table and select Display/Maintenance/Allowed, which facilitates maintenance of this table. Then switch to the Technical Settings screen by pressing Ctrl-Shift-F9) and select APPL0 (this is a transparent master table) in Data Class and 0 (up to 1900 data records) in the Size category. If you are expecting a higher number of records in this table, increase the Size category to 1 or higher.

Then create the table maintenance generator for table ZTROBJECTMASTER by going to transaction SE11 and following menu path Utilities > Table Maintenance Generator. Give the table a name, then follow menu path Environment > Modification > Maintenance Screens. Switch to Screen Painter and modify the input attributes of the UserID, ChangedOn, and ChangedAt fields to display only (no Input) as shown in Figure 3. These fields need to be made display only as the program populates these fields with the correct values.

Figure 3

Element list in Screen Painter of table maintenance for ZTROBJECTMASTER

Figure 4

Add event 21

Figure 5

Code to automatically populate display-only fields

Figure 6

Table maintenance screen of table ZTROBJECTMASTER

Step 2. Create a Transport Inventory Table

The transport inventory table provides all you need to know about a transport including transport description, owner, date and time of release from development, and import date time with return code from each environment (test and production) in your landscape. This table virtually eliminates the need to use transaction SE01 or SE09 to check a transport’s status.

By default, the transport inventory table holds transports in the correct order of their release. You can use transaction SE16N (an alternative to the classic data browser transaction SE16) to perform basic queries such as finding all transports for a given change request number or by another key identifier.

To set up this table, go to transaction SE11 and create a table with the name ZTRTRACKING. Then in the Fields tab, create all the table fields with length and description as shown in Table 3. You may also have to create the required data elements if you can’t find existing similar data elements in your SAP system ZTROBJECTMASTER. Finally, adjust the field length and description to match your specific requirements, if any.

Table 3

Fields in table ZTRTRACKING

Table 4

Detailed description of fields in the transport inventory table

Next, follow menu path Table Maintenance Generator > Environment > Modification > Events and add events 01 (BEFORE_SAVE) and 21 (FILL_NOINPUT_FIELDS) (Figure 7). In the following steps, you write ABAP code so that event 01 performs integrity validations before saving the data records, while event 21 automatically populates the display-only fields.

Figure 7

Overview of form routines for ZTRTRACKING

Figure 8

Code to automatically populate display-only fields before saving the data in the database

Figure 9

Table maintenance screen of table ZTRTRACKING

Step 3. Implement BAdI CTS_REQUEST_CHECK

Create an implementation ZCTS_REQUEST_CHECK for BAdI CTS_REQUEST_CHECK. You use ZCTS_REQUEST_CHECK to validate whether an SAP ECC transport has been assigned to a key identifier in table ZTRTRACKING before that transport can be released. This is called from the Transport Workbench (transaction SE09 or SE01) each time a user attempts to release a transport and serves as the key to enforcement of the change management and transport policy of this solution.

In transaction SE19, select Classic BAdI and enter CTS_REQUEST_CHECK (Figure 10). Click the Create Impl. button and in the screen that appears, enter ZCTS_REQUEST_CHECK for the Implementation Name (Figure 11). Then switch to the Interface tab and implement method CHECK_BEFORE_RELEASE by double-clicking the method name (Figure 12).

Figure 10

Select Classic BAdI CTS_REQUEST_CHECK

Figure 11

Enter ZCTS_REQUEST_CHECK for the Implementation Name

Figure 12

Method CHECK_BEFORE_RELEASE

Figure 13

ABAP code in method CHECK_BEFORE_RELEASE

Figure 14

Enter the code in Figure 13 into the Class Builder

Save and activate all the objects created so far. Then test your BAdI implementation (method CHECK_BEFORE_RELEASE) by pressing F8 or by selecting Method > Test/Execute. For unit testing of your BAdI implementation, use a transport that has already been released and then a transport that is yet to be released (Figure 15).

Figure 15

Test method CHECK_BEFORE_RELEASE

Step 4. Implement BAdI CTS_IMPORT_FEEDBACK

Create an implementation ZCTS_IMPORT_FEEDBACK for BAdI CTS_IMPORT_FEEDBACK to provide real-time updates of the transport status in the centralized transport registry (table ZTRTRACKING) whenever a transport migrates through the system landscape to an integration test, regression test, and production environment.

As before, in transaction SE19 select Classic BAdI and enter the BAdI name CTS_IMPORT_FEEDBACK. (CTS_IMPORT_FEEDBACK is the only component of this solution that needs to be transported to each target system.) In the next screen, enter ZCTS_IMPORT_FEEDBACK for the Implementation Name and press Enter. This takes you to the Interface tab in Figure 16.

Figure 16

Method FEEDBACK_AFTER_IMPORT

In the Interface tab, enter a suitable description in the Implementation Short Text field. Double-click Method FEEDBACK_AFTER_IMPORT to open an implementation window for writing some code. Enter the code shown in Figure 17 using the Class Builder. If necessary, replace the destination DEV with the name for your development environment.

Figure 17

ABAP code in method FEEDBACK_AFTER_IMPORT

Now activate the class/method (Figure 17) and your BAdI implementation (Figure 16) by clicking the activate icon or pressing Ctrl-F3. You have to activate these separately — activating one without the other one is a common source of error.

Create a Remote Function Call (RFC) destination DEV using transaction SM59 in your SE, QA, and Production systems. When prompted during the BAdI implementation, assign the BAdI implementation (ZCTS_IMPORT_FEEDBACK) to a separate transport request, as it will have to be migrated to other SAP ECC environments within your landscape (Figure 18). You don’t need to transport other objects created during this implementation.

Figure 18

Transport request with BADI implementation ZCTS_IMPORT_FEEDBACK

In transaction SE37, create remote-enabled function module Z_UPDATE_TRANSPORT_STATUS (Figure 19). This is the function module called from your BAdI implementation in Figure 17. This function module updates table ZTRTRACKING when a transport has been imported into test and production environments.

Figure 19

Add the single tables parameter T_REQUESTS in function module Z_UPDATE_TRANSPORT_STATUS

In the Tables tab, specify a single tables parameter T_REQUESTS of type SCTS_IMP. Then click the Source code tab and add the ABAP code in Figure 20 to the function module (download an editable version here). In transaction SE37, unit test function module Z_UPDATE_TRANSPORT_STATUS by providing the required parameters when prompted.

Figure 20

ABAP code to add to Z_UPDATE_TRANSPORT_STATUS

Go back to transaction SE19 and unit test your BAdI implementation method FEEDBACK_AFTER_IMPORT. Click the entries icon in Figure 21 to supply the test data in Figure 22.

Figure 20

Test screen for method FEEDBACK_AFTER_IMPORT

Figure 22

Sample test data for method FEEDBACK_AFTER_IMPORT

Implementation

Now you have built the simple transport management system and are ready to implement it. Here are the steps:

• Step 1. Maintain the check table and value range
• Step 2. Maintain the change master table (ZTR01)
• Step 3. Activate BAdI CTS_REQUEST_CHECK

• Step 4. Activate BAdI CTS_IMPORT_FEEDBACK

Step 1. Maintain the Check Table and Value Range

In transaction SE11, create and populate check table ZGROUPID for the Group ID field (Figure 23).

Figure 23

Sample records in checktable ZGROUPID

Decide on all the required Group IDs that represent a broad grouping of Object IDs on your project. Use a generic value such as PROJECT or DEFAULT if it is too early for you to finalize the list of required Group IDs. 

Next, create a value range for Change Type and Release/Deployment fields for table ZTROBJECTMASTER if it has not already been done. This step is optional but highly recommended to ensure only the allowed and predefined values are entered in the subsequent steps.

Step 2. Maintain the Change Master Table

Use transaction ZTR01 and add all open change requests and Object IDs to the Change Master table. Figure 24 shows some examples.

Figure 24

Sample records in the Change Master table

In the future, each time a new change request is approved or new Object ID is created on your project, you have to add it to the Change Master table. Therefore, your project should identify a single or a selected group of owners (e.g., one from each team) to maintain this table.

Step 3. Activate BAdI CTS_REQUEST_CHECK

After you activate BAdI CTS_REQUEST_CHECK, all transports in your system must be registered or entered in table ZTRTRACKING prior to their release. Therefore, ensure that your project team is ready to implement this functionality and is on board.

Depending on the size and complexity of your project team, you may want to start small (pilot) and expand as you go. You may want to start with implementing this solution only for workbench transports, and expand to customizing and security transports later. Alternatively, if your project has multiple users who are authorized to release transports, for example, start with one of them. Refer to the code in Figure 13 on how you can restrict the implementation of this solution to selected users.

When you release a transport, you see a pop-up message (Figure 25). Press Enter and you go to transaction ZTR02 to complete the transport registration against a valid change request.

Figure 25

New pop-up message in Transport Organizer upon releasing a transport

Figure 26

Enter required key fields in transaction ZTR02

Step 4. Activate BAdI CTS_IMPORT_FEEDBACK

Activate and transport BAdI CTS_IMPORT_FEEDBACK to all SAP ECC environments (SE, QA, and Production) in your system landscape and also create an RFC destination DEV in those environments. This BAdI provides the real-time import status of a transport from the SE, QA, and Production environments and updates this information in table ZTRTACKING in the DEV environment.

Start with exporting CTS_IMPORT_FEEDBACK to SE and gradually move to other environments with Production being the last. In future, you can also use this BAdI to send real-time email notifications to transport owners once their transport has been imported into a target environment. This reduces follow-ups and manual lookups in the system.

If exporting this BAdI to other environments is not a preferred option for you, then alternately you can write an ABAP program for a transport status update and set it up as a batch job in the DEV environment. This program periodically reads the transport log and updates table ZTRTRACKING. You can use example code from routine UPDATE_TRANSPORT_STATUS for this purpose.

Reporting and Error Corrections

One of the key features of the simple transport method is that consolidated information about all released transports, including associated key identifiers and import or export status is stored in a single place — the ZTRTRACKING table. Therefore you can use transaction SE16N to query this data in multiple ways including by change request number, Object ID, Group ID, release number, transport owner, or transport number.

Let’s say CR# 90189 has passed the regression test and is ready to move to production. You query ZTRTRACKING by CR# 90189 and you see all transports related to this key identifier. They are in the correct sequence, in the order of release from development (Figure 27).

Figure 27

Track transports by Change Number

Similarly, if there are multiple changes associates with a single Object ID or Group ID, you can run your query by any of these key fields and you see all related transports (Figure 28).

Figure 28

Track transports by Group ID or System ID

Figure 29

Track by release number

In addition, with each query, you not only see all relevant transports but also the transport description, transport owner, release date time from development, import date time, and return code from SE, QA, and Production in a single-line horizontal view (Figure 30). There is no need to use transaction SE09 and painfully retrieve transport logs one transport at a time.

Figure 30

Transport descriptions

Such a report can use selection criteria to first query the ZTROBJECTMASTER table and display all available change requests. Then, by double-clicking a change request display, you see all transports associated with it. You can further drill down on the transport number and then switch to transaction SE01 to display the transport details.

Resolve Transport Issues

From transaction SE16N, you can also use data stored in table ZTRTRACKING to help resolve transport issues. You can identify all transports for a given change request number or release number that did not make it to production or any other environment (Figure 31). For example, a blank PE Date and PE Time as shown in Figure 31 indicates this transport has not yet made it to the production system.

Figure 31

Identify potential transport issues

Error Corrections

Like any system, the simple transport management system is only as good as the entered data. If errors are introduced, you can use transactions ZTR01 and ZTR02 to make necessary corrections.

You can use transaction ZTR01 to delete or modify an incorrect key identifier or change request in table ZTROBJECTMASTER. If necessary, you can also make subsequent updates, if any, in table ZTRTRACKING using transaction ZTR02.

Transaction ZTR02 can reassign a transport to another key identifier in table ZTRTRACKING. For this, you may have to first delete the incorrect record and then create a new one with the correct assignment. You can copy the record being deleted and then modify it to reflect the new assignment.

In addition, with transaction ZTR02, you can perform offline entry of records to account for transports that were released prior to implementation of this solution or during a temporary deactivation. For all records added in offline mode, subroutine UPDATE_TRANSPORT_STATUS populates display-only fields, as usual, including the export or import status from the development, testing, and production environments.

In general, transport management, should be managed just like a business process, which at the basic level involves assigning a process owner, doing regular monitoring, and making continuous improvements and error corrections.

Narendra Agrawal

Narendra Agrawal has more than 15 years of experience in SAP implementation and mobile solutions. He holds a master’s degree in industrial management from a top institute in India and certifications in SAP, project management, Java, and .NET. Narendra joined Accenture in 2007 where he serves as a manager within SAP practice. Narendra resides in Charlotte, NC.

You may contact the author at narendra.k.agrawal@accenture.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.