CTS: check/reject Transport Request in target system before/during Import..?

[Private_Member_7726]

Hi,

Does anyone know a way to configure/extend Change and Transport System (CTS) to check/reject (customizing) Transport Request before/during import in Target System?

I have searched up and down and found the (classic) CTS BADIs:

CTS_EXPORT_FEEDBACK
CTS_IMPORT_FEEDBACK
CTS_REQUEST_CHECK

but they do not fit what I'm trying achieve.

What I'm actually trying to achieve is either:

- reject particular (customizing) request at target system based on (external) Transport Request Attributes, or

- configure "QA System", which is currently set up to deliver into two "productive systems", to not "forward" customizing requests with certain Transport Request Attributes (or any other information allowing to distinguish between requests, if it fits the task better) to one of the target systems.

I'd prefer not to have to go and ask Basis to reconfigure "QA Setup", unless it involves straightforward and easy to explain changes.

EDIT in: I also intend to use one particular unending "CTS Project" to identify the requests that need to be "sorted" and delivered: sometimes to both systems, sometimes just to one. I'd prefer not to have to create two or more projects, however.

EDIT in 2: I'd also prefer to not have to set up something like 2 QA systems (one per productive system) and relay on manually rejecting certain requests...

Thank you and best regards,
Janis

[raymond_giuseppi · Accepted solution]

You could try to use CTS_IMPORT_FEEDBACK to remove request from unwanted target system.
For example, read queue with 'TMS_MGR_GREP_TRANSPORT_QUEUE', remove request with 'TMS_MGR_MAINTAIN_TR_QUEUE' command 'DELFROMBUFFER'.
Regards,
Raymond

[Private_Member_7726 · Accepted solution]

Thanks, CTS_IMPORT_FEEDBACK will probably not work, because target queues are filled only after QA approval. The QA setup looks like this:

If I'm interpreting the protocols correctly:

after the import to QA system, request merely gets added to the queue/buffer of "virtual system" ISW and not the queues of target systems. There are no "after import" steps on ISW (at least protocols do not indicate any).

After QA approval, some time later, request gets deleted from ISW and "somehow goes" to ISP and ISC queues. So I'd need something like "Approval Feedback" on which to start monitoring and cleaning target queue(s).

Were ISP the "delivering system" for ISC, it could actually work (ISP hast to receive everything, ISC - just the transports meant to land there).

But thank you very much - that gives me another idea, where I could look for extension possibilities: the step, which cleans ISW buffer and does the "Selection for import" steps in target systems.

cheers
Janis

[Private_Member_7726 · Accepted solution]

I'm abandoning this - because I don't have enough understanding of what's going on, where...

I tried do debug rejection of the request first but wasn't able to understand where and how the ISW "buffer" cleanup actually happens. FuBa TMS_MGR_ACTIVATE_TR_REQUEST is something that gets called on Approval/Rejection and, so far I could understand, it "dispatches command" via RFC.

Anyway, I shouldn't be messing with implicit enhancements anywhere in "TMS/CTS" and I don't see/find extension possibilities offered by SAP.

Trying to periodically "monitor" and "clean" queues on target system sounds very dicey.

Thanks, everyone 🙂