Dual Maintenance Management

Dual Transport Management has been, is and will continue to be an integral part of any SAP Upgrade project. Its mostly done manually and leaves everything to the manual verification of dual maintenance of transports in both the upgraded and non-upgraded system in spreadsheets. This blog will explain how we can automate this process and also be able to track and maintain the mapping of equivalent transports between two equivalent SAP systems.

The entire objective of dual maintenance is to keep the current and the upgraded system in sync with each other. Dual maintenance starts as soon as the upgraded system becomes available.

We mostly have two types of transports which qualify for dual maintenance:

◈ New Transports: These are the new transports which will be created once the system becomes available to the team for dual maintenance.

◈ Retro Transports: These are the existing transports which have been in Dev and QA system and never made to Production.

Assumptions:

DC1 – Existing ECC Dev System

DC2 – Upgraded ECC Dev System

Prerequisites:

◈ RFC Connection between upgraded(DC1) and non-upgraded system(DC2).

Customizing Activity:

DC1:

◈ Go to T Code SE03 and double-click on Display/Change Request Attributes.

◈ Create a new attribute by clicking on Create button

◈ Maintain all the required fields. Attribute value obligatory must be checked during the dual maintenance phase. Save the attribute.

DC2:

Repeat the customizing steps in DC2 system and create ZDC1_TRANSPORT attribute in SE03.

After the above customizing is done, the attribute can be maintained in the transport now.

Workbench Changes:

DC2:

Create an RFC enabled FM with below parameters:

Importing: IV_TRANS

Exporting: ET_DC2TRANS

Source Code:

◈ Get DC1 transports from E07A table’s attribute.

◈ Get DC2 transport object details from E070 and E071 tables.

◈ Merge above data into ET_DC2TRANS.

DC1:

Create a program in SE38 with the below logic:

1. Provide DC1 and DC2 transports on the selection screen.

2. Refer to the table E07A to check its attributes which will provide DC1’s equivalent DC2 transports.

3. Get the Objects List from E070 and E071 to build IT_DC1TRANS.

4. Call an RFC enabled FM created in DC2 using the DC2 transports retrieved in step 1 above.

5. Compare IT_DC1 TRANS and ET_DC2TRANS.

6. Raise an error message based on the type of conflict occurred.

Types of error handling you can include based on the above logic:

This tool can be used as an independent tool by transport reviewers, configurators as well as developers to make sure their transports are in sync.

This functionality can also be extended to force the developers/configurators to maintain this attribute and make it mandatory before releasing the request.

BADI CTS_REQUEST_CHECK can be implemented for this purpose.

Similar logic provided for the tool can be implemented here in CHECK_BEFORE_RELEASE method.

There may be scenarios where there may be no need to do dual maintenance such as Remediation fixes in DC2 system. We have two options here:

1. Maintain authorization checks in the BADI’s and provide Team Lead/Administrator the authority to override the checks and be able to release the transport in any case.

2. Maintain additional attribute ZTEXT in the transport with comments stating why dual maintenance is not needed for this transport. This logic can then added to the tool and BADI.

The attribute maintenance provides great transport tracking especially if you are copying Prod client for the new Dev system to be upgraded and minimizes the risk of losing version management.

It also provides you an audit trail by giving the provision of additional comments in the transport in cases of dual maintenance exceptions.