Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos
In first XI Software Logistics 1: SLD Preparation of this series, we discussed SLD preparation, which is the first and prerequisite step for transporting XI objects.

Now when we have moved all our SLD objects, it’s a time to get an overview of the XI Software Logistics Solution.

In general any software logistics solution isn’t merely confined with transporting objects. It’s more about tracking the changes to the objects, organising transport units, maintaining the logs of the transports and much more. If we take a look at the XI Software Logistics Solution, it offers below functionalities.

1. Organisation of Shipment Content
2. Version Management
3. Transporting XI objects


Organisation of Shipment Contents:


The very term ‘shipment’ is not valid for configuration (ID) objects since they contain customer specific data and never shipped. Hence functionality ‘Organisation of Shipment contents’ exclusively applies to design (IR) objects. From logistics perspective, Product is the shipment unit and it exists in different versions. It further comprises one or more software components, which in turn have different versions. Next level of organising contents is namespace that serves as manageable development unit.



The relation between Products and SWCV is already defined in SLD and hence while transporting IR objects Products don’t appear in navigation tree.

Version Management:

Version Management is the key characteristic of any software logistics solution and XI uses different methods for different types of objects. Even the versioning in transport vary for IR and ID objects.
For creating and maintaining versions of Products and Software Components, we use SLD where we can even establish the dependency between products and software components. Versioning of IR and ID objects is managed using change lists. When an object is saved for first time, a new version is created and added to change list. Once the change list activated, the version gets closed and changes are visible for all users.

Versioning in Transports:
When we speak of XI object transports, we essentially refer to the object versions, which are transported from source IB to target IB. And as mentioned earlier, there is difference in IR and ID objects versioning.

Integration Repository:
A new version of design object is created in target IR once we import the transported object from source. So version V2 is created when we import equivalent version from source. Sounds simple? Watch out. Now a newer version V3 is created and further imported. So now we have version V3 as well in target IR. Good. But now here comes the twist. Again I transport an older version V1 to target repository. What happens? Does it overwrite newer version?



Answer is no. IR doesn’t overwrite newer version. Rather newer version is always maintained as the current active version irrespective of the sequence of transports. So V3 will be the current version.
Another key point here is design objects follow ‘originality principle’. What do we mean by that? It means that only system in which IR object is developed (DEV) contains original object while other repositories (CON, PRD) always hold its copies. And that object should only and only be changed in its original system. If you change it into say IR of your CON system then you are likely to end up in version conflict when you next time import objects in CON system. So always lock your IR objects in target repository. Trust, I defied this once and invited trouble for myself.

Integration Directory:

In ID, the transport sequence does matter. A new version is always created as and when objects are imported into target directory.



So as in above diagram, version V3’ is created when we import V1 despite of recent versions being in Productive Directory.

Now before we move on, lets discuss how to handle XI content delivered by SAP.

Handling XI Content delivered by SAP:


For easier integration of applications and business processes, SAP delivers XI content for various products. For the complete list of XI contents offered by SAP, visit below URL.
https://service.sap.com/nw04 -> SAP Netweaver in Detail ->Process Integration ->SAP Exchange Infrastructure ->SAP XI in detail -> XI Content Catalog
This Integration Process content contains design objects (like integration scenarios, interfaces, mappings) which we import in Integration Repositoy. For the details on how to do this, check SAP note no. 705541-Importing XI Content.
This content being Integration Repository content, follows the rules of IR versioning. SAP delivers higher versions of objects in units of Support Package. Consider we’ve imported XI Content for SRM 5.0 Support Package 2 and developed some interfaces based on this. Now SAP comes out with Support Package 4. Let’s evaluate what will be the implications of importing this new Support Package. First and important thing, this being support packge, it essentially refers to the same SWCV which in this case is SRM 5.0 implying that Support Package corresponds to SWCV. Now if we go one level below and consider namespaces, then there are two possibilities. One the higher versions of design objects are part of same namespaces or SAP has introduced some new objects in new namespaces. This will vary with every support package and respective release notes should provide details lists of the objects included. But key point here is new support package should not contain any deletions which would adversely affect functionality of interfaces. When I checked with SAP, fortunately they replied informing there won’t be any deletions. So our earlier interfaces should work properly with new Support Package. Incidentally, there could be some version conflicts if you’ve modified XI content and you’ll need to resolve it. In next blog in this series, we’ll discuss ‘version conflict and its resolution’ in detail.

Transporting XI Objects:

Now enough with concepts and let’s get to the business of transporting XI objects.
Broadly XI transport can be split into two activities.
1. Exporting the objects from source IB
2. Importing the objects into target IB

There are two different mechanisms for XI transports.
· Transport using File System
· Transport using CMS (change Management System)



Transport using File System:

In addition to export / import it involves an additional step of moving the files between systems. Pictorially it can be represented as



From the context menu (right click) of objects you can export IB objects by choosing ‘Transport using File Transfer’. Alternatively you can use Tools -> Export menu as well. When IB objects are exported, a packaged binary file( .tpz) is created in the respective export directory of source server. Further you need to move this file to import directory of target system. Now you can import the object in target system IB from Tool -> Import menu.

Export and Import Directories are as –



Transport using CMS (Change Management System)
When you compare with earlier method, definitely CMS is a sophisticated method of transporting XI objects. CMS offers sort of single window approach. Its web GUI conveniently enables importing both IR, ID objects, checking the transport logs, keeping the track of transports moved. In addition, for transport from CON to PRD system, you can designate some approval authority to regulate and approve transports to PRD system. Having said this I think it still has to evolve to offer complete tracking of changes. Unfortunately present CMS doesn’t allow you to display the objects included in the respective export list. You need to separately document it. Incidentally, CMS is not part of WAS and we additionally need to install and configure it. It is a part of JDI (Java Development Infrastructure) initially introduced for managing Java logistics.

In next blogs of this series, we’ll take a look at the CMS setup and export/import functions.
1 Comment