Purpose
With the following customizing you will be able to define a virtual system to use it in a Solution Manager 7.1 ChaRM project.
This blog is valid for Solution Manager 7.1, the screenshots was taken from a Solution Manager 7.1 SP5.
Overview
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 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 may not want to install all the systems you have planned for your system landscape at the same time, e.g., when the project is just started. In basis 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. 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 CTS project here.
1. Defining virtual system in TMS and also in SMSY
The way to do this configuration is perfectly explained in “ChaRM_ST400_Virtual_System.pdf” document attached to note 1520678, although the document is for Solution Manager 7.0 can be used also for Solution Manager 7.1. LMDB is not getting any information about this virtual system. Go to the end of this document to see how to replace Virtual System with Physical System in this situation.
2. Defining virtual system in TMS and in LMDB->SMSY
2.1. Managed systems TMS configuration
See chapter “2.STMS Configuration for Managed Systems” from document ChaRM_ST400_Virtual_System.pdf attached to note 1520678.
Go 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
Edit mode
I want to join the virtual system to the production system SMM:300
Note: enter the working client which is planned in future. 2. 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.
Save
Ensure that the Single transport strategy is selected for VI1:
See also chapter “2.STMS Configuration for Managed Systems” from document ChaRM_ST400_Virtual_System.pdf attached to note 1520678, the documents that you can see in this note are really really good!!!
2.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:
Usually you will know under which installation number the system will be installed in the future
Save
Save and Next
Add product
Select and click on Add icon
Create client: enter the future client name
Enter the future Logical system name:
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.
For this:
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
Not Important:
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 System type "Application server ABAP (ABAP)" and then the same technical system for System type "Aplication server Java (Java)", this will create the entry in SMSY under "Product systems" for the system and another under "Technical system"-> Java, then add the java logical component to the entry in SMSY under "Product systems".
Mark an Abap instance like relevant, this will make that ChaRM knows that the system is a virtual system because from the basis point of view only ABAP system can be virtual.
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 non-ABAP system to a real non-ABAP system, you will need to adjust the STMS and 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.3. 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.
Note: If you want to use virtual systems in the project you will requires a domain link because there is no RFC possible to virtual systems. So if you really want to use virtual system in this project, then you have to create domain links between your managed domain controller system to solman system.
Now go to document “ChaRM_ST400_Virtual_System.pdf” attached to note 1520678 - Change Request Management Configuration & Operation Guide and follow section 3.5 “3.5 Create Logical Components for Virtual System”, etc.
Important is section “4.2 Replace Virtual System with Physical System”, let me copy the steps here and add some comments for the replacement of the system in LMDB
Basically there are three steps to replace a Virtual System in ChaRM. They are:
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.
Related Content
Related Documentation
- See also the document “ChaRM_ST400_Virtual_System.pdf” attached to note 1520678 Change Request Management Configuration & Operation Guide
Related Notes
Please check notes:
1687980 Virtual transport system in SMSY 7.1
1520678 Change Request Management Configuration & Operation Guide
1694004 Dealing with duplicate technical system names (SIDs)
1719972 ChaRM: Long SMSY name does not work
No comments:
Post a Comment