This blog will help in understanding the concept of transport request attributes and how it will help in transport management. This will help in achieving good governance of transport requests in big SAP implementation projects.
Pre-requisite: Basic knowledge of SAP transport request.
- Introduction
Transport requests are used to transfer the changes done to existing objects or new objects created in the development system to quality and then finally to production system.
Production system has real and confidential data, hence while importing transports to production system transport requests needs to be verified correctly. Any mistakes in transport list can hamper existing functionality which intern will cause in change backout and development failure.
The order in which transports should be imported to production needs to be same as per the sequence they were moved in Quality/Acceptance system.
In big SAP implementation projects which are having more than 100 transport requests created by developer / functional, there will be more chance of missing transport request in final list of production. If any transport is missed in the production list, there are several possible risks involved.
Other factors involved are number of developers working on the same project, developers working on the same objects , transports which are being moved in case of production bug fixes and multiple projects being run in single environment.
- Possible risks if transport is missed in the production list:
1. Wrong object versions can go to production: If there are multiple transport requests for one object and one of the transport requests is missed during production move, then this will lead to incorrect version of the object.
For e.g. for report program ‘ZTEST’ one transport request ‘AB123’ was created and moved from DEV system to Acceptance system. Later on there was a defect detected in Acceptance testing.
Then to fix this defect again new transport request ‘AB456’ was created and moved to Acceptance box. Now while preparing the production transport list for program ‘ZTEST’, latest transport request for defect fix ‘AB456’ was missed. Then incorrect version of program ‘ZTEST’ will go to production system and same defect which was already fixed in acceptance testing will remain unfixed as it is.
2. Possibility of RC8 Error during transport movement to production: If any transport of dependent object is missed in the final list of production movement then transport movement will result in RC8 Error.
E.g. there are 2 transport requests one is for table and another is for data element which is used in table. Both table and data element are new objects and does not exist in production before transport movement.
Object Type | Object Name | Transport Request |
Data Element | ZDTELE | AB1234 |
Table | ZTABLE | AB5678 |
Now while preparing final transport list for production movement if transport ‘AB1234’ for Data Element ‘ZDTELE’ is missed then while moving transport request ‘AB5678’ (i.e. for table) RC8 error will occur.
Hence transport movement will end up with error and intern will need analysis on transport failure. Again for missing transport request separate change management process will be required to move transport to production.
Above mentioned are major risks during production transport movement and may cause HUGE BUSINESS IMPACT.
To avoid such issues because of simple mistakes, good transport management and tracking is needed in projects.
- Steps for better transport management and tracking:
o Create custom transport attribute.
o Maintain custom transport attribute for each new transport request for specific development before releasing it. Hence the entire transport list related to development will have attribute maintained.
o Fetch the list of transports from E070A table where attribute name = custom attribute name.
o This result will give complete list of transport requests for which custom attribute was maintained.
o This will avoid human error of missing any transport request in production transport list.
o Transport attribute maintenance check can be enforced for specific projects. E.g. In development environment multiple projects are being run and if we want to make transport attribute maintenance mandatory only for our project then this check can be performed specific to project ID by implementing method ‘CHECK_BEFORE_RELEASE’ of BADI “CTS_REQUEST_CHECK”.
o Once this check is implemented developer/functional will not be able to release transport request without maintaining transport attribute.
o Hence at the time of production move list of transports for specific development can be fetched from E070A table where transport attribute value =’XXXXXX’.
- Scenario for how attribute maintenance will help in better management of transports:
In single project there are multiple developments going in parallel. Each development will have separate requirement specification document with unique number of requirement document.
Below is example:
Project Name: Project1
Now under project1 there are multiple developments executed,
Development Name | Requirement Spec. Document number |
DEV1 | R1111 |
DEV2 | R2222 |
DEV3 | R3333 |
Now if we create a custom transport attribute ‘ZREQ_DOCNO’ for maintaining requirement specification document number.
Then while creating transport requests for development (i.e. DEV1), maintain transport attribute ZREQ_DOCNO = ‘R1111’ (which is req. spec. doc. Number for DEV1).
Now if there are total 40 transport requests were created for DEV1 then list of transports can be fetched from “E070A” table where TRANSPORT ATTRIBUTE =’ ZREQ_DOCNO’ and ATTRIBUTE VALUE = ‘R1111’.
This data fetch from E070A table will give complete list of transports created for DEV1 and there will not be any miss in transport list.
Also this transport request maintenance can be made mandatory based on project ID by implementing BADI.
Transport attributes creation and BADI implementation is explained in detail further.
- How to create Transport Attribute? We can create custom transport Attributes (Z-attribute) for easier project level transport tracking. This custom transport attribute can be maintained, so that we can find specific development transports according to custom Transport Attribute values. You can use attributes to define change requests. Also using these Attribute values, we can perform transport analysis.
- Steps for creation of TP Attribute:
1. Go to transaction SE03 (Transport Organizer Tools).Select Display/Change Request Attributes option.
2. 2. Click on ‘Create’. New pop-up window will appear. 
3. Now enter the respective values for new custom Attribute:
Attribute: Enter the Attribute name for i.e. “ZREQ_DOCNO”
Short Description: Enter Short description “Project1 Transport Attribute”.
There are 3 options which need to be selected according to purpose of this attribute:
1. Attribute Value Obligatory: This specifies whether the attribute can only be assigned with a value. If it is essential that value should be specified for the attribute, then select attribute value obligatory.
2. Attribute Assigned Externally: If this field is selected, the attribute is assigned using external interfaces only. You can then no longer add this attribute to a request, or delete it from a request. Mostly this option will not be used as we need to track transport requests in SAP.
3. Attribute can only be assigned once for Each Request: If this field is selected then you can only assign this attribute once for each transport request.
We can also make these attributes mandatory to specific development client by mentioning client specific settings.
So here we will select option 1 & 3 to create custom attribute: then SAVE.
Now new attribute “ZREQ_DOCNO” will be available for maintenance through SE01.
- How to maintain transport attribute?
1. Go to SE01. Display transport request.
2. Go to properties tab of transport and enable change mode.
3. Attribute “ZREQ_DOCNO” will be available for maintenance in attribute list.
4. Select the attribute and enter the value for the attribute e.g. If we are creating transport request for DEV1 and requirement document number
for DEV1 is “R1111” then we can maintain attribute having same value.
We can define Attribute value such as some unique number for each Development for e.g. Design Document number will be different for each development. If we maintain transport attribute value “R1111” (i.e. Requirement Doc. Number) for all transport requests specific to one of the development i.e. DEV1, then it will be easier to track all the transport requests related to DEV1 for production movement.
So there will not be any chance of missing any transport request during production movement of the development.
We can find out the list of transport requests having specific attribute value From E070A table:
This selection will give list of transports for which Attribute “ZREQ_DOCNO” is maintained with value “R1111” e.g. if there were three transport requests created for DEV1 so this selection will give all the three transports in output.
This way we can identify all the transports for specific project or development. Risk for missing transports in the list during production movement will be minimized to great extent.
But there can be a miss, if somebody forgets to maintain attribute for transport request before releasing the request, then what will happen?
Still we will not be able to track that specific transport request for which attribute was not maintained.We can make this Transport Attribute Check mandatory based on few conditions.
Many projects use intelligent naming conventions for Transports. For example Project ID is mentioned in Transport request description or Design Document number is mentioned in Transport description.
Now if we make Transport Attribute maintenance mandatory, it will be mandatory check for all projects in specific development box. We can make this check obligatory project-ID specific.
- How to automate the process of Transport Attribute maintenance?
The transport attribute maintenance can be made mandatory project specific by implementing BADI “CTS_REQUEST_CHECK”.
CTS_REQUEST_CHECK: This BADI has multiple methods through which various checks can be implemented for transport requests. Method ‘CHECK_BEFORE_RELEASE’ is called before a transport request is released transport request through SE01 transaction.
By using this method we can implement our own check related to transport request:
1. 1. Check attributes and short text of transport request.
2. 2. Objects included in transport request.
BADI implementation steps:
Transport request attribute check can be implemented specific to project or according to the short text of transport request. E.g. In development environment , if currently multiple projects are run i.e. Project1,Project2,Project3……Project(n) and we want to make transport attribute maintenance mandatory only for our project (i.e. Project1) which will help in better transport tracking.
In such scenario, we can make TP attribute mandatory for specific project by implementing BADI check.
Many projects use intelligent transport naming conventions (transport request short text). E.g. Transport request description contains PROJECT ID and based on which we can make this attribute check mandatory.
E.g. TR1234 (Transport Request) -> DEV: Project1:SE38_ZTESTPROGRAM (Short text)
Now while releasing the transport request TR1234, we can check if transport request short text/description contains our project ID i.e. Project1 in this case. If yes, then check if transports attribute “ZREQ_DOCNO” is maintained for TR1234. If NO, then throw error ‘Please maintain required attribute’, while releasing the request through SE01.
We can maintain configuration for which project ID which transport attribute should be maintained, so check can be made dynamic.
1. 1. Create custom table ‘ZATTRICHECK ‘having 2 fields Project ID and Transport Request Attribute.
2. 2. Maintain ‘ZATTRICHECK ‘table with Project ID (i.e. project which will be present in Transport Request short text) and Transport attribute which
needs to be checked for particular project ID.
So for below example, if Transport short text contains “Project1”, then by implementing BADI check can be performed to see whether “ZREQ_DOCNO” attribute is maintained or not while releasing the transport request.
3. BADI Implementation Steps:
- Go to transaction SE19 and create BADI implementation for classic BADI “CTS_REQUEST_CHECK”.
- Implement method CHECK_BEFORE_RELEASE.
- Source code implementation:
1.First check if transport request is “Higher-Level Request”, if transport is Higher-Level then only Attribute check should be performed.This check can be performed by querying E070 table.
2.If transport is higher level, then fetch Project ID and Transport Attribute from custom table ‘ZATTRICHECK ‘into internal table.
3.Fetch transport attributes maintained for the current transport request from E070A table.
4.Check if transport request short text for Project ID in custom table ‘ZATTRICHECK ‘. If short text contains Project ID which is in custom table,then perform further check for transport attribute.
5. Check if custom table TP attribute present in Attributes fetched from E070A table for this transport request.
6. If transport attribute is not present then populate the error “Please maintain required attribute”.
- Implementation Source Code:
*$*$**********************************************************************************************************
*$*$ PROGRAM ID : ZCTS_REQUEST_CHECK *
*$*$ TITLE : BADI Impl.to check Transport Attribute *
*$*$ AUTHOR : SANJANA LINGRAS *
*$*$ DESCRIPTION : BADI implementation to check if required *
*$*$ transport attribute is maintained before *
*$*$ release of TP. *
*$*$------------------------------------------------------------------------------------------------------------------------------------*
METHOD if_ex_cts_request_check~check_before_release.
TYPES: BEGIN OF y_tpchk,
zprojid TYPE zattricheck-zprojid,
ztpattri TYPE zattricheck-ztpattri,
END OF y_tpchk,
BEGIN OF y_attri,
ztkorr TYPE e070a-trkorr,
zattri TYPE e070a-attribute,
END OF y_attri.
DATA : t_tpchk TYPE STANDARD TABLE OF y_tpchk,
t_attri TYPE STANDARD TABLE OF y_attri.
DATA : w_request TYPE e070-strkorr,
w_result_tab TYPE match_result_tab,
w_flag TYPE string.
CLEAR w_request.
FIELD-SYMBOLS : <fs_tpchk> TYPE y_tpchk,
<fs_attri> TYPE y_attri.
FREE : t_tpchk,
t_attri.
SELECT SINGLE “Check whether TP is higher level request
strkorr
INTO w_request
FROM e070
WHERE trkorr EQ request.
IF sy-subrc EQ 0
AND w_request IS INITIAL.
SELECT zprojid “Fetch proj.ID and attribute from custom table
ztpattri
FROM zattricheck
INTO TABLE t_tpchk.
IF sy-subrc EQ 0.
SORT t_tpchk
BY zprojid.
ENDIF.
IF t_tpchk IS NOT INITIAL.
SELECT trkorr “Fetch Attribute for current transport request
attribute
INTO TABLE t_attri
FROM e070a
FOR ALL ENTRIES IN t_tpchk
WHERE attribute EQ t_tpchk-ztpattri
AND trkorr EQ request.
IF sy-subrc EQ 0.
SORT t_attri
BY ztkorr
zattri.
ENDIF.
ENDIF.
UNASSIGN <fs_tpchk>.
LOOP AT t_tpchk
ASSIGNING <fs_tpchk>.
FREE w_result_tab.
“Check if transport short text contains project ID which is maintained in custom table.
FIND ALL OCCURRENCES OF SUBSTRING <fs_tpchk>-zprojid IN text
RESULTS w_result_tab.
IF sy-subrc EQ 0
AND w_result_tab IS NOT INITIAL.
READ TABLE t_attri
ASSIGNING <fs_attri>
WITH KEY zattri = <fs_tpchk>-ztpattri
BINARY SEARCH.
IF sy-subrc NE 0 “If attribute is not maintained then throw error
AND <fs_attri> IS NOT ASSIGNED.
“Populate error message with Attribute Name
(WITH <fs_tpchk>-ztpattri)
ENDIF.
ENDIF.
ENDLOOP.
ENDIF.
ENDIF.
ENDMETHOD.
4. 4. BADI Implementation Result: If developer or functional tries to release transport request without maintaining required transport attribute error will be thrown. User will not be able to release request without maintaining attribute for our specific project.
This way we can eliminate the risk of missing the transport in final transport list for production.
- Benefits of Transport Tracking:
1. Eliminate the risks: Proper transport tracking will reduce potential human errors in preparing final transport lists.
2. Save efforts of change management: If transports are managed properly within the project then it will reduce the burden of change management which is required for missing transports movement.
3. Cost benefits: It will reduce the cost which is required for extra change management efforts and rework on transports.
4. Less Rework: Production transport movement will be smoother and no rework will be needed for analysis of issues or errors.
Before moving transport list to production it is always a good idea to recheck the list.
Preventing transport movement issues and risks before production move is always better than solving them after production move.
Keeping the transport list clean and simple will prevent lot of issues arise later on :smile:
- SAP Managed Tags:
23 Comments
| User | Count |
|---|---|
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
