REALTECH SmartChange SP5 HF01

The /RTC/TM_BACKUP report has been improved in this release to include the SmartChange tables and HTTP RFCs that are used in the SmartChange Integration Framework.

In this release, SAP messages now use the Ticket ID instead of the technical key for the Ticket assigned to a transport request. The Ticket ID and technical key are can be different depending on the ITSM type (e.g. Service Now)

With this feature, the configuration for the TM Integration Framework - TM Workflow step configuration has been simplified.

The actions for the UPD item type no longer have to be configured manually. They are delivered as default as active, depending on the ITSM type.

Supported UPD actions for each ITSM type can be checked in table /RTC/TM_IF_SERVD.

The templates for configurations have been updated accordingly, the following templates have been impacted:

• TEMPLATE_ JIRA CLOUD
• TEMPLATE_ JIRA SERVER
• TEMPLATE_ SNOW_INC

We have added a new feature in this release that enables the display of import and approval data in the ITSM SmartChange panel for deleted transport requests from TM Workflow Monitor and moved to the History.

The difference between the deleted requests and those reaching the end of their lifecycle will be made visible through the use of different icons.

In this release, the report /RTC/TM_SYNC_SAP_ITSM has been enhanced as follows:

• you can now filter by ITSM ID instead of ITSM Type. If the ITSM ID remains empty, then all the ITSMs are taken into consideration.
• you can now run the report in Test Mode, allowing you to see which ITSMs and corresponding transport requests will be processed.

Also, due to feature https://rtcom.atlassian.net/browse/SC-1351 , no prerequisite configuration is necessary for the UPD/SYNC action. As default, if the ITSM is active and its corresponding ITSM Type supports the synchronization feature, it will be considered by the report.

With this feature, you can now release multiple transport requests and add them to TM via the OData service. In order to achieve this, the $Batch operation has been implemented.

The batch operation in the OData protocol can combine multiple requests into a single request. Batch requests are submitted as a single POST request to the /odata/v2/$batch URI. The maximum number of request count allowed in a batch request is 180. Multiple requests in a batch are processed independently of each other. All request operations in the same changeset follow the everything or nothing rule i.e. failure of a single operation causes the whole $batch to fail. Partial changes are not done.

Prerequisites:

• Trusted RFC destination between TM server and DEV originating client for the transport request, with the following naming convention: ZRTC4_TM_<targetSID>_<targetClient>_TRUST, where <targetSID> is the SID of the development system, and <targetClient> is the source client of the transport request.
• The SAP user should have the role /RTC/SC_INTEGRATION (authorization for using trusted RFC connections - object S_RFCACL)
• All tasks of the transport requests must be previously released by the developer!

Functionality

If the transport request has the status “Modifiable”, it will be released and according to the TM configuration on the development system, it will be added to the TM workflow.

If the transport request has already been released, with the same OData call, you can add the transport request to the TM workflow. For this, the transport files must already exist on the TM Server.

Possible outcome error messages:

• ‘Task &1 of transport &2 is not released’
• ‘Transport request &1 could not be added to project &2 and destination &3’
• ‘Cofile for request &1 not found. Insertion denied!’
• ‘Transport request &1 is already in TM’

Example for releasing 2 TRs with the all-or-nothing concept (same changeset)

URI: /sap/opu/odata/RTC/TM_GW_SRV/$batch

• HTTP Method: POST
• HTTP Header
  • Content-Type multipart/mixed;boundary=batch_test
• HTTP Request Body:

  --batch_test
  Content-Type: multipart/mixed;boundary=change_set1--change_set1
  Content-Type: application/http
  Content-Transfer-Encoding: binaryPUT TR_TO_TMSet(CrudMode='C',TransportReq='MDQK900186',ExternalUser='TestUser') HTTP/1.1
  Content-Type: application/json{
  "ProjectName": "BASIS",
  "DestName":"DEFAULT200",
  "ExternalUser": "user"
  }--change_set1
  Content-Type: application/http
  Content-Transfer-Encoding: binaryPUT TR_TO_TMSet(CrudMode='C',TransportReq='MDQK900184',ExternalUser='TestUser') HTTP/1.1
  Content-Type: application/json{
  "ProjectName": "BASIS",
  "DestName":"DEFAULT200",
  "ExternalUser": "user"
  }--change_set1----batch_test--

As part of the ServiceNow app "SAP Transport Management for ServiceNow" certification the scope of the application had to be moved to x_real_app1. The ServiceNow TM Integration Framework configuration template has been adjusted for Item type ‘UPD’ accordingly.

The following templates are affected by this update:

SNOW template: TEMPLATE_ SNOW_INC

Work Item UPD - New Path /api/x_real3_app1/rtc

In the previous versions, there was a discrepancy in how collisions were displayed in the simulation approval compared to the make approval process.

The program has been corrected. This release solves this issue.

Jobs scheduled for program /RTC/TM_IMPORT_SYSTEM_QUEUE are canceled sometimes, logging the following error:
"Internal session terminated with a runtime error CALL_FUNCTION_REMOTE_ERROR."

On the system, the following short dump is generated:
Runtime error: CALL_FUNCTION_REMOTE_ERROR
Short text: "SQL error SQL code: 1205 occurred while accessing table /RTC/TM_RFC_LOG".
ABAP Program: /RTC/TM_CL_RFC_LOG============CP
The error occurs during an RFC call to another system. A short dump is also written in the target system with more detailed information about the cause of the error.

The function module /RTC/TM_RFC_LOG was changed to avoid deadlock when the table /RTC/TM_RFC_LOG is updated.
In order to avoid the short dump because of the deadlock on table /RTC/TM_RFC_LOG, the lock/unlock mechanism was added at DML actions (INSERT, DELETE) to the table.

The status for the ENHO object type was displayed incorrectly due to missing timestamp adjustments of versions when the object was modified in DEV.

The object versionability check has been extended to include checks in the "versobj" and "versobj_alias" tables. This enhancement now considers the active version in the development system.

The "Overrides lock user" button in the Pop-Up, which displays objects not included during transport synchronization between systems, causes confusion as the 'Locking Request' column remains empty for locked objects.

In this release, we have made some updates to the Pop-Up that appears when synchronizing transports between systems. The “Overrides lock user” button has been renamed to “Override” for clarity. This change was made because if an object is locked, the 'Locking Request' column will be empty. Furthermore, we have adjusted the ALV to optimize the display of information, reducing the need for excessive scrolling. As a result, the reason for a message will now be located in the last column.

This release addresses an issue in Synchronization Management related to the deletion of CDS Views. In the previous version, when a CDS View was deleted in the MAINT system and the original TR was synchronized, the deletion of the objects was not properly included in the corresponding Rollout request, leading to an error.

The program has been corrected.

At double click on the Rollout nr in the Synchronization Management Object Comparison - Workbench Objectlist, the following error message interrupts processing:
”RFC Error. The current application has intentionally triggered a termination with a short dump."

On the corresponding DEV system, the following short dump is registered:
Runtime error: MESSAGE_TYPE_X
ABAP Program: SAPLOLEA

The program has been corrected.