Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Can blocking of transport-release due to ATC-findings be circumvented for RS_LXE_LOG_EXPORT?

BaerbelWinkler
Active Contributor

As mentioned elsewhere we'll soon be switching to central ATC-checks where priority 1 and 2 findings will prevent the release of tasks and transports.

During discussions leading up to this change, one of our processes related to translations was mentioned, which might run into trouble due to this and I'd like to know beforehand, if there's an option to prevent the block on the task/transport release in those circumstances.

Translations for new or updated source code (and other workbench entities) are routinely provided and saved by developers via transaction SE63. Three times a week a batch job "collects" all the newly created/updated translations and puts them into a new transport-request which then gets automatically released. This is done via SAP standard program RS_LXE_LOG_EXPORT.

"Unfortunately", the translation transports also contain the object the translation is for, therefore including ABAP-code which may well have findings with priority 1 or 2 thus blocking the transport's release and holding back all other translations included in it. Without manual intervention before the next scheduled execution of the job two days later, there's a risk - even if small - that new translations will overtake the older and blocked ones.

So, is there an option either within program RS_LXE_LOG_EXPORT or in the ATC-settings in general, to ignore any findings and release the translation-related transport regardless?

We are on NW 7.50 with EHP8 and moving to central checks done in a NW 7.52 system. Searching for the report-name didn't find anything and neither did anything "jump out" when I browsed through its code.

Thanks and Cheers

Baerbel

1 ACCEPTED SOLUTION

BaerbelWinkler
Active Contributor
0 Kudos

After switching on "Blocking on error" in the development system, I was able to quickly test this now myself:

  1. Picked a program which I knew has prio 1 findings
  2. Went to SE38 and "translated" a random text from DE to EN
  3. Entry for translation found in LXE_LOG
  4. Executed RS_LXE_LOG_EXPORT manually with relevant parameters
  5. Transport for translations gets created and released without problems

Interestingly enough, when I then run a check for the released transport it does report the ATC findings for the program, including prio 1 which is a bit misleading I think. Checking the transport's object list it only has entries for PGMID = LANG and I'm wondering if ATC-checks could perhaps be ignored for these to avoid confusion?

2 REPLIES 2

BaerbelWinkler
Active Contributor
0 Kudos

Some more thoughts:

I'm aware that ATC-related activities can be triggered via an implementation of Badi CL_IM_CTS_REQUEST_CHECK where code can then be added in method CHECK_BEFORE_RELEASE or perhaps CHECK_BEFORE_RELEASE_SLIN (although that sounds like it's just related to the the extended syntax check). So, I'm wondering if there's perhaps an option to tell the process to not run the ATC-checks at all if it gets triggered via a batch-job or if the transport title contains specific terms? I searched for various terms but didn't find any promising leads yet.

BaerbelWinkler
Active Contributor
0 Kudos

After switching on "Blocking on error" in the development system, I was able to quickly test this now myself:

  1. Picked a program which I knew has prio 1 findings
  2. Went to SE38 and "translated" a random text from DE to EN
  3. Entry for translation found in LXE_LOG
  4. Executed RS_LXE_LOG_EXPORT manually with relevant parameters
  5. Transport for translations gets created and released without problems

Interestingly enough, when I then run a check for the released transport it does report the ATC findings for the program, including prio 1 which is a bit misleading I think. Checking the transport's object list it only has entries for PGMID = LANG and I'm wondering if ATC-checks could perhaps be ignored for these to avoid confusion?