With the following customizing you will be able to define a virtual system to use it in a SAP Solution Manager 7.1 ChaRM project.
This blog is valid for Solution Manager 7.1, the screenshots were taken from a Solution Manager 7.1 SP5.
We will see the required steps to define the virtual system firstly in the TMS landscape of the managed systems and after in SMSY or in LMDB/SMSY.
There are two possibilities, the first one consists in defining the virtual system at TMS on the domain controller system of the managed TMS landscape, usually located in the development system, and afterward in the SMSY, this method is the one used too in Solution Manager 7.0 to define a virtual system.
The second option, starting in Solution Manager 7.1 SP05, consists in defining the virtual system at TMS on the domain controller system of the managed TMS landscape, usually located in the development system, and afterward in the LMDB, this will create the system in SMSY.
Virtual System is a type of SAP Systems which can be used to solve the problem that you face when you don´t install all the systems you have planned for your system landscape at the same time, e.g., when the project is just started. In Transport Management System (TMS), you can configure SAP Systems as Virtual Systems in the transport domain so that you can model the transport routes of your whole system landscape before having all systems in place. More importantly, in ChaRM those Virtual Systems can be used as place holders in the task list, which means the project cycle can be generated and change processes can be started without any delay even if some physical systems are not yet ready. Most of the TMS display functions can be used for Virtual Systems, but no real transport can be performed in them.
Please be aware that the development systems (source systems) must not be Virtual System, otherwise the project task list in ChaRM cannot be generated successfully because we need a real IMG project and a CTS project here.
1. Defining virtual system in TMS and in LMDB->SMSY
1.1. Managed systems TMS configuration
Logon to domain controller system of the TMS managed landscape, client 000 and create the virtual system:
/nstms ->Overview ->Systems
SAP System->Create Virtual System
Note: We recommend that the system ID should be identical with the future physical system which will replace this virtual system; this will reduce the follow up effort to adjust the transport groups and directories.
In this case I have only a SMM solman system with ChaRM configured in client 001.
I created this managed landscape: SMM:100->SMM:200->SMM:300 and I need to add a virtual system after this SMM:300 system for example:
Create VI1 with CTC=1
Note: If your planed physical system is purely non-ABAP, then for the Virtual System the CTC parameter should be set as 0.
Define the transport routes of the managed TMS landscape: SMM:100->SMM:200->SMM:300 -> VI1:100
I want to join the virtual system VI1:100 to the production system SMM:300:
Note: enter the working client which is planned in future. If the Virtual System represents a purely non-ABAP system in future there is no need to specify the target client for the transport routes because they should be client independent.
Ensure that the Single transport strategy is selected for VI1:
1.2. LMDB configuration
Go to the solman system used to managed this landscape: SMM:001
I call /nlmdb -> Host editor
Enter a host name:
Select: Create New Host
Note: We recommend that the host name should be identical with the future physical host name which will replace this virtual host name
Enter the fully qualified domain name and save.
Create the technical system:
Note: Usually you will know under which installation number the system will be installed in the future, it is really important to enter this data and also later any systerm number, 111 for example.
See also note 1767384 Maintenance of installation no. & system no. in SolMan 7.1, for the non-ABAP systems that usually does not know installation number and system number in LMDB you could filled the information manually in LMDB or leave the information empty, but if you leave this information empty ensure you have implemented notes 2153616 and 2130165.
Enter here any system number like 11111.
Save and Next:
Select and click on Add icon:
Create client: enter the future client number that you will use for the final production system:
Enter the future Logical system name:
Note: Starting in Solman 7.1 SP10 ensure that the property tmsdomain is maintained in LMDB with the correct transport domain, see KBA 2127997 ChaRM check error for projects with virtual systems.
As soon as you save the system in lmdb the system is added to SMSY but without the transport domain and virtual flag.
In case you have a virtual system for a double stack you need to do the same for the Java side, this will create an entry in SMSY under Technical Systems->Java.
Please take into account that every time you make a modification in the system in LMDB, the information is sent to SMSY.
Note: If you want to create a virtual system for a non-Abap system take the following into account: strictly speaking there is no non-ABAP virtual system from the basis point of view. And in LMDB/SMSY we also only consider ABAP systems can be virtual.
Nevertheless, in ChaRM we do provide a possibility to configure a virtual system which "looks like" non-ABAP system, and after that you may use this system in the ChaRM project. So the original idea was just to provide such kind of flexibility. This does not mean that we invented a new system type as virtual non-ABAP system.
1. There must be a system entry in SMSY
2. That system should be marked for at least one ABAP instance, because only in this way ChaRM will get to know this is a virtual system
3. You must assign that system, without a client, to a logical component
1. It does not matter whether the system is ABAP or non-ABAP, because no change will be made in virtual system and we just need a place holder in the task list
2. The product instance selection is also not important, keep in mind this is just a virtual system so we do not need to pay much attention here
3. The technical system is also not important
4. For non-ABAP system the communication system/client is also not important
So, create in LMDB a technical system for the virtual system with System type "Application server ABAP (ABAP)" and then use the same SID for creating a technical system type "Aplication server Java (Java)", then create a product system containing both technical systems.
We know that you want to use the system as non-ABAP system but right now we are just trying to create the ChaRM task list with a place holder. So even if this configuration is not correct for your future system, to create the task list we have use this trick.
In addition, if someday you want to replace the virtual ABAP/non-ABAP system to a real ABAP/non-ABAP system, you will need to adjust the STMS and LMDB-SMSY configuration. Then you should close the project and create a new task list in the same project and in this way we can ensure all data is consistent.
2. Solution Manager Configuration
As system VI1 is created in LMDB I can see VI1 system created in SMSY but still not with the correct data:
Now go to solman and run /nib_gen to generate the ibase component for this VI1 system (as the ibase component is not created).
Go to SMSY to the domain controller system of the TMS landscape where the virtual system is defined and run a “Read System Data remotely”:
Now go again to VI1 and you will see that the virtual flag and transport domain is added correctly:
Now the virtual system can be added to the logical component that you want to use in your ChaRM project.
3. Replace Virtual System with Physical System
Basically there are three steps to replace a Virtual System in ChaRM:
1. Delete Virtual System in STMS (valid for both procedures)
Go to client 000 of the domain controller system, enter transaction STMS and delete the relevant Virtual System. Note that this action will only delete the system from the list, the transport buffer and directory on the operation system level will not be touched. So when the new physical system is created with the same system ID it can inherit all those old transport data automatically.
2. Create Physical System in STMS with the same SID (valid for both procedures)
Include the new physical system to this domain and approve it in the domain controller. After that you need to re-configure all those transport parameters and make sure the transport route settings are still correct and consistent.
3. Refresh System Data in SMSY (valid for first procedure)
What you need to do is to press the “Read System Data Remote” button from both domain controller system and the Virtual System itself. After that the Virtual Product System flag should be removed in the Header Data tab of the Virtual System entry in SMSY, which means it is already a physical system from now on. For ABAP stack systems then you will also need to generate the RFC destinations in client 000 and the working clients of ChaRM. In the end by opening the project cycle task list again the system’s Reachablity status will be changed to “Active”. We suggest that at this stage you should perform a ChaRM check to ensure that all the configurations are correct and consistent. As long as there is no error in it then you may continue to work in this landscape. All those old change documents can be used without any issue and those transport requests which are already in the import buffer for the new physical system can now be transported directly without any other manual activities or adjustments.
With this procedure you don´t create the system with the same SID, the same installation number, and the same database host in the LMDB, then a duplicate occurs in the SMSY when the real system is registered, see note 1687980.
Directly after registering the system, change the name of the extended SID of the registered system to the extended SID of the virtual system in LMDB.
For example, if the virtual system PXY is imported from the TMS and the system registration in LMDB assigns PXY00001 for the real system in SMSY, change the extended SID PXY00001 in the LMDB to PXY. After you save the data, the virtual system PXY is overwritten with the real system PXY in the SMSY. All logical components remain valid and refer immediately to the real system.
3´. Refresh system data in LMDB->SMSY (valid for second procedure)
After the installation of the real system, the system is registered to the SLD and LMDB. This could generate a duplicate in the SMSY (see note 1687980).
To avoid this ensure that you from the beginning created the system manually in LMDB with the future SID name, the future installation number, the future database host and the future client.
In the case a duplicate entry is created in SMSY after registering the real system, change the name of the extended SID of the registered system to the extended SID of the virtual system in LMDB.
4. Then complete the project maintenance cycle and create a new task list for the same project in order to get this TMS change at ChaRM project level.
Please check SAP notes:
1878718 ChaRM/QGM: project configuration issues
1687980Virtual transport system in SMSY 7.1
1694004 Dealing with duplicate technical system names (SIDs)
1719972 ChaRM: Long SMSY name does not work
1802717 Read System Data Remote in Solution Manager 7.1
1767384 Maintenance of installation no. & system no. in SolMan 7.1