/
How to distribute transport requests between TM servers using report /RTC/TM_LD_10

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

  1. Connectivity

    • The target TM system must be connected to the source TM system (via Systems and Groups).

  2. Target Routes

    • Ensure that the target TM system is included in the destinations used for distribution.

  3. Maintain Mapping Table

    • Populate the mapping table /RTC/TM_LO3 with appropriate entries.

  4. Schedule the Report

    • Schedule the report /RTC/TM_LD_10 periodically.

Explanation of Table Fields: /RTC/TM_LO3

Field Name

Description

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

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:

  1. Cofile Timestamp

    • The system attempts to retrieve the Export Date and Export Time from the cofile.

    • Priority: Highest — If successful, this timestamp is used.

  2. 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.

  3. 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.

  4. 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.

  5. 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

  1. Cofile Timestamp

  2. Export Log Timestamp

  3. Datafile Timestamp

  4. System Current Date/Time

  5. /RTC/TM_SPECS Target System Timestamp (if applicable)

  6. 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.

  1. 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.

  2. 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.

  3. Distribution Process

    • Transport requests with STATUS = D (Distribute) or STATUS = R (Repeat Copy) are subject to the distribution process.

  4. 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

  1. STATUS = C → Request is copied if directories differ → STATUS = D (Success) or STATUS = R (Failure)

  2. 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:

  1. 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.

  2. 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.

  3. 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

  1. STATUS = F and SIGNDATE ≤ Cutoff Date → Request is marked for deletion.

  2. 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.

  1. 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.