Yes we do!
...
(since August of the year 2024)
A virtual or external system can be part of your landscape.
If a transport request is waiting in the import queue, we are considering it like an performed import, if there is a follow-up system. We are here assuming that the virtual system should be used for quality gate or tracability reasons.
If a transport request is waiting in the import queue, we are considering it like a waiting import, if there is no follow-up system. We are here assuming that the virtual system will be replaced by a real system later on.
If the transport request is not waiting but the virtual system will be the next system in the transport track, the virtual system will be considered as system where the import can be performed next using the CC5 import feature. If the import will be triggered, it the transport request will not be imported (since this is not possible) but it will be added to the import queueIt can be the DEV, QAS or PRD system.
Some TMS activities are skipped for virtual or external systems. For instances we can neither read the import return code for such a system nor perform an import. We cannot open/close CTS project status switches, …
For import status calculation a Transport Request will be considered as imported as soon as it is registered to the import queue. This will garantee, that status “Imported into DEV”, “Ready for Production” or “Imported into P” can be calculated even if the DEV system is a virtual system or if the PreProd system is a virtual system or if the Prod system is a virtual system.
A virtual system is provided as next system for import only if it is the followup system and if the Transport Request is not registered to the import queue of the virtual system so far. The import can never be performed but the Transport Request can be added to the import queue using the CC5 import feature. If the Transport Request is already registered to import queue of the virtual system, the virtual system will not be provided as next system because the import can/will never happen.
The followup system of a virtual system is not provided as next system until the Transport Request is registered to its import queue. This solution is ensuring that CC5 is never bypassing the quality gate established by the virtual system. An administrator has to forward the Transport Request to the import queue of the followup system manually. if you want to have an alternative behaviour, you have to create an improvement request enabling us to implement a configuration switch. For now we are assuming that there is an idea - a need - behind the use of the virtual system.
If a Transport Request is registered in the import queue of a virtual system, we are checking the import status of the followup system. For real systems we do that only if then import got successfully executed. By this solution CC5 will be able to continue import processing as soon as an administrator is forwarding the Transport Request to the import queue of the followup system.
A virtual system is virtual but CC5 still need to find a way to read the import queue. Therefore you have to establish a working connection somehow:
You are using SAP Solution Manager as central system. The virtual system got created in STMS of a domain controller known by LMDB (have a look at tab “Transport Domains”). The domain controller is sending its data to a SLD (via RZ70) automatically or on request. The LMDB of SAP Solution Manager is fetching the SLD data of the domain controller system automatically or on request. The virtual system is displayed in LMDB on tab “Virtual Systems” of the section “Transport Domains” after it got created and sent to SLD and forwarded to LMDB. You generated a “Technical System” of the virtual system there in LMDB. Now you are ready. CTS is able to use the virtual system. It is using the defined communication system to access the import queue. You have to define proper TMW RFC destinations of the communication system, of course.
The virtual system is defined in the a domain controller. CC5 is installed on this domain controller or on a system directly connected to this domain controllerof the same transport domain. → Nothing to do. The virtual system is defined locally and can be accessed by TMS services. You have to define TMSORG destination pointing to the communication system.
The virtual system is defined in a foreign transport domain. There is a domain link established. → Nothing to do. The virtual system is known locally and can be accessed by TMS services. You have to define TMSORG destination pointing to the communication system.
The virtual system is defined in a foreign transport domain. There is no domain link established. → In You are not using SAP Solution Manager there might be a solution. Maybe SAP Solution Manager is using the domain controller as communication system. If you are not using SAP Solution Manager as contolling system, you have to define a TMSORG RFC destination pointing to any real system of the same transport domain, e.g. the domain controller itself. → This solution has to be verified. It is just an idea for now. → The virtual system is unknown to CTS till you implement BADI CTS_BADI_FOREIGN_SYSTEM. If BADI implementation SCTS_UPGINT_SYS_BADI_IMP is existing in your system it might be sufficient to maintain a entry in table SCTS_UPG_ATC_SYS. You need to have a RFC destination which should be a RFC destination pointing to the communication system.