Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

Release 5.2.3.0

Released on May 04, 2021

New Feature

Priority Key Title Release Note
Medium SC-705 Send previous RC to Jira when updating the Jira issue This new feature in the TM Integration Framework is a prerequisite for the Jira App "SAP Transport Integration for Jira" feature: SmartChange History pannel.
When updating the Jira Issue property from SAP (after TR import/after TR approval), both the current Return Code and the previous Return Code are transferred to Jira.
Medium SC-627 Collision Exception for Translations With this new feature, you can now exclude translations from collision checks.
In order to do so, you need to maintain Translations (LANG-Objects) as collisions exceptions, via TM>Qulaity Assurance>tab 'Collisions'>tab 'Exceptions'.
For instance, the following exception definition will ignore all Translations from the Quality Assurance Collision checks:
PgID | Obj | Object Name
LANG | * | *

Also, the Collision results popup has been enhanced to display also the Program ID column.
This way you can differentiate between entries like LIMU REPT (Report texts) and LANG REPT (Report text translations), for instance.
Medium SC-624 Enforce '4 eyes principle' for Approval Type (content or technical) per Transport Level With this new feature, the maintenance screen for Transport Levels, section "Second set of eyes" has been enhanced as follows:
* "Different approver" -> becomes -> "Content and technical approval must be done by different users"
A new option is added:
* "Per approval type (content or technical) do not allow users to approve for multiple groups"

With the new option, you can now configure TM to check the 4 eyes principle for the same signature type (content/ technical) when there are multiple signature levels (user groups) within the signature type.
Medium SC-623 Code Profiler detected security issue "Missing AUTHORITY-CHECK in RFC-Enabled Functions" [v2] Issue:
Code Profiler tool highlighted the following security issue in the SmartChange coding:
"Missing AUTHORITY-CHECK in RFC-Enabled Functions"

Root cause:
This Code Profiler test case checks whether an RFC-enabled function module fails to perform specific authorization checks for its business logic.

Solution:
SmartChange coding has been enhanced to perform additional authority checks on the calling user for the RFC-Enabled Functions. The user must have the authority to execute specific SmartChange function modules - Authority Object ZRTC_COM, Activity RF - Remote SmartChange FM execution (authority field /RTC/SC_AC).
Medium SC-622 Code Profiler detected security issue "Missing AUTHORITY-CHECK in Reports" [v2] Issue:
Code profiler tool highlights the following security issue in the SmartChange coding:
"Missing AUTHORITY-CHECK in Reports"

Root cause:
This Code Profiler test case identifies reports that do not have an explicit AUTHORITY-CHECK.

Solution:
SmartChange coding has been enhanced to perform additional authority checks. The user must have the authority to execute specific SmartChange reports - Authority Object ZRTC_COM, Activity RX - SmartChange Report Execution (authority field /RTC/SC_AC).
Medium SC-272 New TM Status Switcher With this new feature, a new TM status switcher is now available:
- Report /RTC/TM_STAUTS_SWITCHER_NEW
- Configuration transaction: /RTC/TM_SW

Since there are many switcher programs available, the new switcher is a first step in merging all functionalities into one central report, easy to configure and schedule.

Currently, the new switcher encapsulates all functionalities of the current standard switcher (/RTC/TM_STATUS_SWITCHER) and, in addition, the following features:
* Switching Transports and Packages from Current -> Current
* Filtering based on Project/Destination

Transaction /RTC/TM_SW represents the configuration cockpit for the new switcher. With it you can specify the settings for the new main switcher program '/RTC/TM_STATUS_SWITCHER_NEW', and it is also possible to schedule it.

User Manual

Features:
All variants for the switcher can be maintained with transaction /RTC/TM_SW.
A variant represents a set of settings for the switcher, corresponding to one transport level.

In the tree on the right side of the configuration cockpit, containing all defined transport levels, all switcher variants are displayed.
You can create a variant by clicking on 'New entry' in the tree toolbar, and make the settings on the right side of the screen. After saving, the new variant will be displayed in the tree and all datasets (variants), also the new one, can be chosen for editing, activation or deletion.

A variant must be set as 'Active' in order to be processed.

With the green job button in the application toolbar, it is possible to schedule the program '/RTC/TM_STATUS_SWITCHER_NEW' as a job or change the settings of the job if it is already scheduled.
The job will run all the active variants.
It is also possible to jump to the latest log of the job.

Defining a switcher variant:

Requests / Packages
Here you can specify if the switcher should process only requests, only packages or both requests and packages.
If packages should be processed, it is possible to switch only closed packages, only open packages or all packages.

Import
The field 'Check import' can be set only if the transports/packages are to be switched from status 'Current'.
If this field is set, some specific import information is to be checked:
- Return code
- Import date/time
- Import into ...
If this field is not set, no checks about the imports are done.

Return code:
If 'Check import' is set, a return code must be defined. No request/package with a return code equal or higher than the one defined in the field 'RC' will be switched.

Import date/time:
If 'Switch only, when import is older than' is set, the defined time is used as a filter so that no switch will be done unless at least the defined time has passed since the last import.

Import into:
Here you can specify one of the three alternatives:
- Into all systems: import must have happened into all target systems
- Into one system: import must have happened into at least one target system
- Into the following systems: If this option is selected, you must define a list of target systems. The import must have happened into all defined systems, in order for the transport/packages to be switched.

Also, you have the option to make a setting for Virtual/Locked systems:
If 'Check virtual systems' is set, the request/package will not be moved if a virtual system is among the checked target systems. By default, virtual systems are ignored.
If 'Ignore locked systems' is set, the request/package will be moved even if there is a locked system among the checked target systems, for which the import has not happened yet. As default, locked systems are not ignored.

Project/Destination
If the check box "Switch only, if assigned to the following project/destination combination" is set, you must define a list of Project/Destination combinations.
The list is used as a filter for selecting the transports/packages to be moved.

Observations:
When switching packages, if at least one transport request in the package does not meet the selection criteria, the package will not be moved.

When switching into status 'Current', approvals are automatically granted by the System, ignoring transport-level settings (second set of eyes, different approver, etc) or user group settings. Also at this step, the transport files are copied into the target systems.
User Exit 'MAKE_APPROVAL' is executed in the background as part of the approval process, so please make sure your implementation, if any, can run in the background.
If any error occurs ( ex. the transport files cannot be copied because the target system is unreachable), the transport/package will remain in status "Signature" and approval must be granted manually in the TM Monitor.
Medium SC-120 Usability: Configuration to activate new TM features in table /RTC/TM_OPT With this feature, the TM Admin can now easily activate and deactivate optional TM features corresponding to table /RTC/TM_OPT directly from TM>Global Settings, via the new tab 'Feature'.

The following TM features are available:
* Notify only TM Users
* No export without TM
* Send all workflow emails
* Enable email receiver optional
* Ignore locked systems

Notify only TM users:
If this option is selected, notifications are sent only to TM users. Otherwise, non-dialogue users can also be notified of pending approvals. In this way, e-mail distribution lists can be addressed via dummy users.

No export without TM:
If this option is selected, the release button in the TM BAdI popup (export a transport request without adding it into TM) will be hidden so there is no way to bypass the TM workflow.

Send all workflow emails:
If this option is selected, users will receive a workflow notification (pending approval) in all cases, regardless of the existing exclusion criteria. Possible exclusion criteria are, for example, that a user who is authorized to approve two consecutive approval steps does not receive an email after the first approval.

Enable email receiver option:
If this option is activated, the receiver can be freely selected when deleting a transport request out of the TM workflow.

Ignore locked systems:
If the field is checked, when TM BAdI is configured to insert the transport request into TM Monitor with status 'Current', the technical approval is automatically performed. The transport files are not copied if the target system is virtual or locked.

Bugs

Priority Key Title Release Note
Medium SC-714 Report /RTC/TM_LD_15: the selection parameter for TM server is not taken into consideration during distribution Issue:
In report /RTC/TM_LD_15, the parameter for the TM server is not taken into consideration for distribution.
It is used only partially during processing, to read the /RTC/TM_GROUP table which may cause inconsistencies when the TM server is moved to a different system, for instance.

Root cause:
Programming error.

Solution:
The code was corrected.
Medium SC-713 Runtime Error when adding CPM request in SE09 Issue:
A short dump occurs when adding a CPM request in SE09, in object /RTC/TM_CL_CLUSTER_OP.

Root cause:
Programming error - wrong parameter type

Solution:
The program has been corrected.
Medium SC-710 Collision/Overtakers Pop-Up is not displayed during the first Technical Approval Issue:
If TM>QA>Collisions is configured to "Only show overtakers" and more than one user group is used to sign technical approval, the popup to show the collisions is displayed only during the last technical approval.

Root cause:
Programming error

Solution:
The program has been changed to show the collisions popup for each user group.
Medium SC-708 Typing error in TM>Transport levels maintenance screen Issue:
Wrong text for 'Quality Assurance Check' in the maintenance screen for transport levels. (TM>Transport levels)

Root cause:
Typo error.

Solution:
Texts and translations were corrected.
High SC-702 Dump CALL_FUNCTION_REMOTE_ERROR and CALL_FUNCTION_SEND_ERROR when TR containing critical objects is released Issue:
A runtime error occurs when trying to release a transport request that contains critical objects.
The following two short dumps are generated:
CALL_FUNCTION_REMOTE_ERROR -> Canceled Program /RTC/SAPLTM_CHECK
CAL_FUNCTION_SEND_ERROR -> Canceled Program /RTC/SAPLTM_AUTH

The issue can be reproduced when TM Server is on the Development system, the /RTC/TM_BADI has the setting 'Check critical objects' active, and the transport request contains critical objects flagged as 'Error' in TM>Quality Assurance>Critical objects.

Root cause:
Programming error

Solution:
The program has been corrected.
Medium SC-697 Error message 'Ping failed: RFC-Destination ZRTC4_TM_XXX does not exist' when adding an external TR to TM Issue:
When an external transport request is manually added to the TM Workflow Monitor, an error message like "Ping failed: RFC-Destination ZRTC4_TM_XXX does not exist" is displayed. The transport request is added to the TM Workflow nevertheless.

Root cause:
Usually, the RFC destination 'ZRTC4_TM_<sid>' from TMS to an external transport does not exist. Still, the report tries to read additional information from the external system and cannot connect to it, informing the user.

Solution:
This scenario should not be treated as an error, it is common not to have an RFC destination for external systems.
The message is not displayed anymore.
If the system is not reachable from TMS, the additional information cannot be gathered (ex. CTS project), but the processing is not interrupted.
Medium SC-694 Requests tab in SM>Object Comparison detail section shows request tasks Issue:
When selecting an object detail section in SM>Object Comparison, in the Requests tab, the list of transport requests includes tasks.
The tasks should not be displayed in detailed transports of the object, for neither Customizing nor Workbench.

Root cause:
Programing error - the tasks are displayed together with the transport request.

Solution:
The program has been corrected.
Only transport types 'W' (Customizing), 'K' (Workbench), 'T' (Transport of copies) are displayed.
High SC-675 TM Import Scanner hangs with no log information of which system needs troubleshooting Issue:
Report /RTC/TM_IMPORT_SCANNER_MAIN remains hanging sometimes. Reading the job log provides no valuable information of where or why it stopped, making it difficult to troubleshoot.

Root cause:
In case a target system is down, the import scanner is logging only the returning error of the RFC_PING. But sometimes, it is exactly the RFC_PING call that remains hanging. (This might be caused by a Kernel error - additional investigation is required if this occurs).

Solution:
For each target system that the program is scanning, the log message "Ping system <SID>..." is added before initiating the RFC connection. This way, if the job remains hanging, you will know exactly what system is causing the error for further troubleshooting.
Critical SC-669 CDS views (DDLS-Objects) are displayed as 'Not Modified on DEV' after being synchronized Issue:
When synchronizing CDS Views (Object type DDLS), the objects appear as different in SM>Object Comparison, even after the synchronization. The displayed status is 'NOT MODIFIED ON DEV', instead of 'EQUAL', even though the log displays entry "Status changed to 'EQUAL'".

Root cause:
Programming error

Solution:
The program has been corrected, an additional check has been added to the program for version comparison in case differences were found.
High SC-660 External TR is not added to SM>Task List when imported via TM - implementation in standard Issue:
External TRs are not added to SM>Task List when imported into the MAINT system via TM (System Queue/Personal Queue). 
When imported via STMS, The SM analysis is triggered and the TR is added to the Task List.

Root cause:
SyM Analysis is not triggered after import via TM.

Solution:
The TM program was changed to trigger the SyM BADI after the import of the transport request, which will start the SyM Object Analysis.
High SC-569 SM>Customizing overview screen has to many scroll bars Issue:
In SM>Customizing Overview, there are too many scrolls required to see the information, especially when the detail section is open.
The issue is can be reproduced for customizing objects with multiple tables, like roles (ACGR-objects), when the screen is too small, information is not displayed properly.

Root cause:
Error in screen custom control attributes

Solution:
The program has been corrected.
High SC-235 Transport Request has status 'Signature' when added to TM Workflow, even if in TM_BADI the status is set to 'Current' Issue:
If in transaction /RTC/TM_BADI in the development system, the 'Status' is set to "Current", and a target system corresponding to the first level in TM is locked or virtual, then automatic approval is not granted.
The transport request remains in status 'Signature', waiting for approval.
Manual approval can then be granted in TM Monitor with no restrictions based on the status of the target system.

The issue can be reproduced when TM Server is not on the Development System.

Root cause:
The copy process executed in the background for the Co and data files is not triggered if the system is locked or virtual. As a result, the request is not signed.

Solution:
A new field was added in the table /RTC/TM_OPT table (IGNORE_LOCKED). This field can be maintained also from SmartChange>Settings>Global>Feature: 'Ignore locked system'.

As default, the feature is not active. The TM loader works as before (as described in the section "Issue").
If the feature is activated, when TM_BADI is configured to insert the transport request into TM Monitor with status 'Current', the technical approval is automatically granted for virtual and locked systems. For these type of systems, the transport files are not copied to the target system(s) at this step (similar to manual approval in TM Monitor).

Powered by Automated release notes for Jira
  • No labels