The transport of pure JAVA code and the XI stuff differs at CTS+?

[Former Member]

We know that the transport of pure JAVA code and the XI stuff differs at NWDI.

How about CTS? Pure Java stuff and XI stuff also differ at CTS transport? If so, what is it?

Thanks!

[Former Member · Accepted solution]

Nobody interested?

[FrankMisch · Accepted solution]

Hi,

I already have read this posting before but a comparison both for CMS and CTS+ with regards to XI and Java would result in a lager document.

Currently there is none in the SDN. To create such a document would be tempting but currently I find no time for this.

So perhaps some key points as short list:

One of the purposes of CTS+ had been to unify the transport aspects of different Non ABAP content types.

I would think that this had been reached or will be reached in the following point:

GUI integration during export:

The export trigger for CTS+ had been integrated into the different export wizards or dialogs for XI, SLD and SAP Portal in more or less the same way offering the steps: Select export mode, select export objects, create and/or select transport request, assign objects to requests and release transports.

Starting with NW 2004s EhP1 the same steps are integrated into the transport view of the NW Developer Studio. So the unification for the export between XI and Java is quite good starting with EhP1.

Management and monitoring of systems and tracks:

The general features, which are used to create transport domains, register systems, monitor systems and to create tracks are the generic CTS features. So there is clearly a unification.

Import:

The import is also triggered from within the CTS. So this is also unified.

Yet - as the development of Java differs in some more general aspects from the development in XI - there are still differences:

System landscape and assembly

The development of IB Repository objects had always been quite comparable to the Java development including the number of systems (DEV-CONS-PROD) of the standard landscape and the fact that the assembly based on a SWCV in the CONS systems is often useful (no object is forgotten during export).

In contrast to this the configuration objects of the IB Directory had been less comparable to the Java development as for the Directory we have more the use case for distribution of configuration objects than the goal to do transports along DEV-CONS-PROD. Especially the CMS assembly had been a step which made no real sense in the Directory case as a full assembly would result in a full export of the Directory. This had been improved by making assemblies in CTS optional und by supporting transports of changes from DEV along the whole transport route.

This differs from the behavior on the Java side, so yes this is a difference but a good one

Componentization

The componentization had not been changed. In Java we find Development Configurations, SWCVs and DCs which are to some extend comparable to the IB Repository structures: SWC, SWCV, Namespaces. But the IB Directory structure is still different (Parties, Services etc.).

Build, Deployment etc.

The Java specific steps as build on CBS and deployment of the results had also neither been changed nor transfered to XI concepts or the other way around.

Nevertheless the cache refresh on the IS runtime back-end can remotely be compared in some aspects to the deployment of Java code on the Java Web As.

But also no changes there. There are experiments to produce during XI exports XI SCAs, which can be deployed via SDM. A quite good idea in terms of

unificiation - but nothing official up to now.

States of objects

In the lifecycle of object in XI and Java we have similar states - but the naming is still not unified:

Java

Open submit> inactive activate> active release for transport> exported

XI

Open -submit&activate(=one step)----> transportable release for export----> exported

Tools

The XI functionality had not been transferred to the development studio. So you will still have to use to different development environments.

Removed unwanted differences or restrictions

Yet there had been some challanges of the past had been caused by restrictions of CMS rather than by the differences between Java and XI.

CTS+ provides some improvements in this direction. They can be summarized in the following advantages of CTS+ compared to CMS:

Enhanced CTS allows to 
use the ABAP change and transport system (CTS) for ESR transports 
build transport routes with an arbitrary number of systems 
define arbitrary system roles 
define multiple direct successor systems for each system 
select arbitrary objects for transports in any system -> no assembly necessary 

So that's all for now - hope you find it helpful.

Regards

Frank