How to distribute transport requests between TM servers using report /RTC/TM_LD_10
Overview
The report facilitates the seamless transfer of transport requests between two TM (Transport Management) systems. Based on predefined mapping rules in the /RTC/TM_LO3
table, the function identifies eligible transport requests on the source TM system and distributes them to the target TM system. This process ensures consistent transport workflows across environments, reduces manual effort, and minimizes errors. The distribution is managed via a scheduled report (/RTC/TM_LD_10
), which automates the process according to the configured mappings and system connections.
Source TM System:
Table
/RTC/TM_LO3
Contains the mapping configuration (maintained by the customer).Table
/RTC/TM_LO31
Logs distributed orders (automatically populated).Report
/RTC/TM_LD_10
Schedule this report periodically to execute the distribution.
TM Configuration on the Source TM System
Connectivity
The target TM system must be connected to the source TM system (via Systems and Groups).
Target Routes
Ensure that the target TM system is included in the destinations used for distribution.
Maintain Mapping Table
Populate the mapping table
/RTC/TM_LO3
with appropriate entries.
Schedule the Report
Schedule the report
/RTC/TM_LD_10
periodically.
Explanation of Table Fields: /RTC/TM_LO3
Field Name | Description |
---|---|
S PJ NAME | Project name on the source TM system. |
S DESTI | Destination name on the source TM system. |
D TM | SID of the target TM system. |
S LEVEL | Transport level on the source TM system. |
S APPROVAL | Approval status on the source TM system (T for technical, C for content). |
D PJ NAME | Project name on the target TM system. |
D DESTI | Destination name on the target TM system. |
MSG TEXT | Displays system status messages. For instance, If a target system is not available, an error is logged in the MSG TEXT field |
S TAKE DEP | If set to X, defined dependencies in the source system are copied to the target system. |
DEACTIV | If set to X, the system is not considered for distribution |
STATUS | Status the request gets loaded in the target TM system. |
S TAKE ATTRIBUTE | If set to X, defined TM Attributes in the source system are copied to the target system. |
S TAKE NOTES | If set to X, defined notes in the source system are copied to the target system. |
S USE SIGN DATE | nn |
Example Mapping in Table /RTC/TM_LO3
Field Name | Example Value |
---|---|
S PJ NAME | Basis |
S DESTI | Default |
D TM | SBD |
S LEVEL | Quality |
S APPROVAL | T |
D PJ NAME | Basis |
D DESTI | Default |
MSG TEXT |
|
S TAKE DEP |
|
DEACTIV |
|
STATUS | C |
S TAKE ATTRIBUTE |
|
S TAKE NOTES |
|
S USE SIGN DATE |
|
Technical Details
Reference Timestamp Determination
The reference timestamp (Export Date and Export Time) for transport requests is determined using a multi-step fallback strategy. The process follows these steps in priority order:
Cofile Timestamp
The system attempts to retrieve the Export Date and Export Time from the cofile.
Priority: Highest — If successful, this timestamp is used.
Export Log Timestamp
If the cofile timestamp is not available, the system tries to obtain the Export Date and Export Time from the export log.
Priority: Second — If successful, this timestamp is used.
Datafile Timestamp
If the export log timestamp is also unavailable, the system uses the timestamp from the datafile.
Priority: Third — If successful, this timestamp is used.
System Current Date and Time
If none of the above methods are successful, the system falls back to the current system date and time.
Priority: Lowest — Used only if no other timestamp sources are available.
Target System Handling
If the target system is listed in the /RTC/TM_SPECS table of the target system, then the Export Date and Export Time from the target system are used.
If no target system entry is found, the approval date and time (SIGNDATE and SIGNTIME) are used as the reference timestamp.
Summary of Priority Order
Cofile Timestamp
Export Log Timestamp
Datafile Timestamp
System Current Date/Time
/RTC/TM_SPECS Target System Timestamp (if applicable)
Approval Date/Time (if no other timestamps are available)
This approach ensures that the most accurate and relevant timestamp is used for the export, with fallbacks in place to guarantee a usable reference in all scenarios.
Distribution of Transport Requests
The distribution of transport requests follows a structured process with clear rules and status transitions. Below is a step-by-step breakdown of how transport requests are distributed.
Eligible Requests for Distribution
Transport requests in the
/RTC/TM_LO31
table with STATUS = C (Copy) or STATUS = R (Repeat Copy) are eligible for distribution.Distribution only occurs if the source and target TM systems have different transport directories.
Copying Data and Cofile
The system attempts to copy the data file and cofile to the target system.
Success: If both files are successfully copied, the STATUS is set to D (Distribute).
Failure: If the files are not successfully copied, the STATUS remains R (Repeat Copy), and the system will attempt to copy the files again in the next run.
Distribution Process
Transport requests with STATUS = D (Distribute) or STATUS = R (Repeat Copy) are subject to the distribution process.
Completion
If the transport request is successfully distributed, the STATUS is set to F (Finished), indicating that the transport request has been fully copied and distributed.
Summary of Status Transitions
STATUS = C → Request is copied if directories differ → STATUS = D (Success) or STATUS = R (Failure)
STATUS = D or STATUS = R → Distribution process is triggered → STATUS = F (Finished) if successful
Deletion of Transport Requests
To maintain system performance, it is recommended to clean up the /RTC/TM_LO31
table periodically. The deletion process is guided by the following rules:
Purpose
Delete transport requests that are no longer required to keep the system clean and maintain performance.
Only transport requests with STATUS = F (Finished) are eligible for deletion.
Selection Criteria
The user defines the approval period for the transport requests to be deleted.
Requests with an approval date (SIGNDATE) before the defined cutoff date are selected for deletion.
Example Deletion Rule
If a deletion is configured to remove transport requests with an approval date up to 01.01.2024, all transport requests with STATUS = F and an approval date on or before this date will be deleted.
Summary of Deletion Process
STATUS = F and SIGNDATE ≤ Cutoff Date → Request is marked for deletion.
Deleted Requests: Requests that meet the criteria are permanently removed from the
/RTC/TM_LO31
table.
Abort Conditions (Loader Interruption)
The loader may abort the distribution process under specific conditions. These conditions are described below.
Invalid Project/Route Combination
The system verifies the Project/Route combinations in the source and connected TM systems.
Abort Condition: If a Project/Route combination is not valid in either system, the loader process is interrupted.