I have still not forgotten the initial days when we are trained on XI by SAP there were lot of questions on version management and transport mechanisms and things are not very clear at that stage .We have also seen lot of times the customers asking details about the reliability and complexity of version and transport mechanisms.
After really working in a project for integrating File server with SAP IS-U and involved in the transition of development objects to QA I strongly feel that transport and version mechanism in SAP XI is as good as ABAP transports if we orderly structure the components in the IR and ID and understand the interrelations between different objects of IR and ID.
Let me provide the typical system landscape of Development and QA, which we used in our project.
There are two types of transport mechanisms in XI.
1.File Level Transport: Files are exported and imported into SAP XI OS level folders of development and QA respectively. This is relatively easy as there is no need of setting up any additional software’s but its risky as the process is not automated as the files have to be FTP’ed from development to QA XI boxes and any failure of the transport cannot be tracked and audit logs will not be available.
2.Change Management System (CMS): This is a GUI based tool, which has to be installed on the XI box for providing the user-friendly browser which is used for automating the transport mechanism and tracking any transport failures. However there is an initial level effort for setting up the CMS and stabilising it.
Depending on the complexity and time lines we can choose any of the transport mechanism. Since our interfaces are not that complex due to generalisation of the IR and ID objects and due to the unavailability of basis at the client site we have chosen the file level transport mechanism. After setting up the SLD in QA with the required transport targets for business systems of SLD the exercise of transporting the targets took 3 days time for 120 IR and ID objects with work load shared by 2 people.
Let me list down the transport process quickly and an appropriate way for ease of transition to different boxes.
Process in SLD:
1.We need to set different transport targets for the required business systems which are used in the scenario objects (ID) of developments. It is just assigning the business system of development to another business system of QA, which is just the replica of dev BS.
2.We need to export the SLD objects from the development to QA SLD. Detailed process can be referred from service market place or SAPHELP.
Process in IR:
1.We need to organise the IR objects in the name spaces properly and ensure that all objects of the name space are correctly available. Ex: Message types, Data types are present in the appropriate name spaces.
2.We need to ensure all the usage dependency objects for the required if any are also available.
3.We can transport the objects at the name space level or SWCV level initially depending on the complexity. We can do it by using the Tools->Export Design Objects Wizard in the development IR. We can see that the file that is getting generated using the wizard has the name File: XI3_0_SWCV Description_Version number.tpz when exported at the SWC level and File: XI3_0_SWCV Description-nsps_Version number.tpz when exported at namespace level. We need to ensure that all the reference objects also are exported together to avoid run time failures in QA box. For Ex: We have generic message types, data types, BPM’’s which are used by all namespaces in the corresponding SWCV. When we are importing the interface specific name spaces into QA IR it has imported successfully as we do not need activate the objects in QA IR. But when we tested it has given run time errors that required message type or data type cannot be found. We re-imported the generic name space objects and usage dependency objects into QA IR, tested the interface and it works fine after that.
4.We can transport each and every individual object of the IR like data type, message type,idoc type,rfc ..etc…by using the same wizard and the file name that is generated when exporting individual objects is File: XI3_0_SWCV Description -objs_VersionNumber.tpz
5.We have to make sure that if any custom RFC modules are developed for JCO calls that required connection parameters have to be changed to point to appropriate sand box. However this can be avoided by using gethostname and getclientname methods in JCO calls.
6.We also need to ensure that if any custom ABAP objects are developed in XI box those requests also have to be transported for avoiding run time failures in QA XI box.
Process in ID:
1.We can export configuration object either at the scenario or service or individual object level.
2.File Name conventions in the ID:
File: XI3_0_directory-selection_VersionNumber.tpz- Export of Individual Objects
File: XI3_0_ScenarioName_VersionNumber.tpz- Export of Scenario Objects
File: XI3_0_ServiceName_VersionNumber.tpz- Export of Service Objects
File: XI3_0_PartyName_VersionNumber.tpz- Export of Party Objects
3.However we can transport at the scenario level initially so that we can have a clear logical grouping of whether all the required individual objects like sender agreements, receiver determinations..etc are present for an interface to work.
4.Unlike IR when we import the scenarios in ID the configuration metadata will be lost and have to be manually entered in the QA ID. For Ex: Parameters like source directory, filename scheme, FTP server will vanish and have to be entered appropriately as required for QA sand box. After entering the metadata we need to activate all the scenario objects in the ID. After successful activation your interfaces are ready for testing.
Process in Runtime:
1.Check in the transaction SXMB_MONI of QA ABAP stack whether the interfaces are working as desired.
I just tried to put up my little experience in the blog thinking that it can be useful. As far as I understand from my little experience versioning and transporting mechanisms in XI is good if the objects are clearly understood.
8 Comments
