cancel
Showing results for 
Search instead for 
Did you mean: 

How to Add Pre-Production system in CMS Track

Former Member
0 Kudos

Hi All,

We have NWDI 7.0 system which has CMS configured for transport import of NW 7.0 system.

We had Dev->QA->Production systems as of now for CMS track.

Now we are planning to add preprod system in our landscape.

So new flow will be : Dev->QA->PreProd-> Prod

In CMS, We only see tabs for Dev, test and Production So thinking if there is a way to connect PreProd system in this CMS track.

Please suggest if this is possible and how can we do it.

Thanks,

Shivam

Accepted Solutions (0)

Answers (4)

Answers (4)

junwu
Active Contributor

go to landscape configurator

select your track--->runtime system---> tick the checkbox you want

former_member189220
Active Contributor
0 Kudos

Hello Shivam,

Your description matches very well to a TEST system. This is one of the purposes - to test the performance. I might offer to your attention 3 options:

1.

You might use:

1.1. the Track Connections (for "permanent" track connection);

1.2. or SCA Forwarding (this will allow you to forward any SCA approved from this track to any other one, regardless of the configured track connections);

1.3. and the Production track

concepts.

You will configure in the present track, on the CMS - Landscape Configurator - PROD RTS - the Pre-Production system.

After you create track connection from this track to the Production one, when you do "transport" the SCA, you will need to import it in PROD RTS of the "Production Track". This will deploy the final customization SCA version on the Production RTS. Yet, the PROD RTS has to be configured in the production track.

The drawback of this solution is, that you need to use 2 tracks. However, there is no other way, because in the CMS in development configuration track one might configure only 4 RTS (as a whole) and only 2 after the Assembly process has finished. (I do not refer here the special track types like: Single and Production tracks - there the RTS is different, as well as the DTR workspaces and the CBS buildspaces).

The pro of this solution is that you will have all the 5 RTS configured in the CMS, at once (and you will not need to change them).

1.1. About "Track Connections" please refer to this guide.

Track Connections options:

Transport - or a.k.a. "take from here and put there". Usually is done between different layers of Development. This is option for your scenario!

(Technology Layer to Business Logic Layer)

Repair - it is done in the same development layer.

(f.e. such Repair connection might be used in tracks dedicated to the Web Dynpro Layer - so the bugs in this layer not to interfere the work in the Business Logic Layer development)

(Backward Transport - in order to fix the bugs in the same level of development)

1.2. For once SCA forwarding, please refer to this guide

Forwarding Software Component Archives

1.3. How to configure Production Track? You might find guidance here:

Automated Deployment into Multiple Production Systems

Please do not get confused the document talks about "multiple" PROD system. One might define even 1 PROD system in 1 PROD track and it will still work. The importance of the Production track is that there are NEITHER DTR workspace, NOR CBS buildspace. This is why in the Production track no DTR and CBS URLs are defined. There is no "development" in this track, but only deployment to the PROD RTS.

2.

The 2nd option is to simply replace the configuration of the existing track. You just open the RTS - TEST system and replace the relevant configuration settings of the Pre-Production. What you need to do after this is just re-Assemble and re-Test. When the import in the CMS - Transport Studio - TEST has completed, the SCA will be deployed on the Pre-Production (the RTS you have defined in TEST)

If I were you I would not have used this approach. It is true the logs are not deleted from the CMS and you will have all the logs of all the imported SCAs in TEST RTS - no matter which RTS you have defined. However, there might be a kind of confusion when you do refer to the logs, if necessary. Anytime you will have to consider one more thing - for which RTS is this log. Moreover, you will need to change the configuration every time when you do transport a change of the SCA - from TEST to Pre-PROD and vice versa.

3.

The last option is to move the entire software logistic process to the CTS+ .

Then on the STMS transaction - AS ABAP - one might create as complex topology as they would like. You create there 5 RTS and you will have 5 development configurations in the CM Services.

The great advantage of CTS+ is the most detailed-available granularity of the software transport. When it is selected Software Transport with Transporting Activities, there will be 5 DTR ws and 5 CBS buildspace (and you will be able to transport single activities). This means, the source code might be changed even when it is in PROD!

This is unthinkable when one uses CMS. If a bug is discovered on such later phase like PROD, the track has to be re-written, then CONSOLIDATED, then ASSEMBLED, eventually TESTED and APPROVED and finally deployed on PROD. With CM Services the source code is on the PROD DTR and on the TEST DTR as well (for your scenario even on the Pre-PROD). Then if the change is not big, the source code might be fixed and synchronized with the PROD RTS (which is actually deployment).

Another great advantage is that with Activity Transport, one might transport a single activity, without waiting the other Predecessors to be activated. In CMS it is possible to transport only on SCA level. In CM Services (with CTS+) you might transport SDAs and activities.

The only "restriction" is that the CM Services MUST not be on the RTS, which will synchronize with. Not that something will stop you to install on RTS the NWDI an configure CM Service. It is just that the Synchronization will not work because there are always some SCA which requires off-line deployment (and hence a restart of the AS Java, which will lead to restart of the CM Services and this will break the synchronization process)

For more details on how-to implement CTS+ transport scenario, please get acquainted with the entire content of this document:

How To... Configure CM Services in SAP NetWeaver 7.3 and Up

Best Regards,

Former Member
0 Kudos

Thank you Milen and Jun.

So from the above discussion looks like we cannot add Pre-Prod system in NWDI track between QAS and Production system.

Reason we are adding pre-prod system is to have Performance testing system in our landscape which can be used by teams in case they want to generate production like load and test the system performance SLAs.

Regards,

Shivam Mittal

junwu
Active Contributor
0 Kudos

just tick the "Test" checkbox, it will be your preproduction system

former_member189220
Active Contributor
0 Kudos

In the NWDI - CMS - Transport Studio are possible the following RTS:

Development,

Consolidation,

Test (a.k.a. Quality)

Production.

Why do you need pre-production RTS? What kind of difference do you define between the TEST and the "Pre-Production" System.?

By definition, the TEST system is EXACTLY system copy of the PRODUCTON system.

Of course nobody might create the same production workload on TEST, but at least the version.SPS.Patch_levels of the SCAs must be the same (as well as the configuration settings).

Hence, if you have followed the recommendations then it is not needed the Pre-Production RTS.

In addition to what Jun has posted (although it is not possible to define Pre-Production RTS) - please bear in mind to not forget configuring 5xx18 port! (where the xx is the number of the central AS Java instance: f.e. J00 is the instance number then the SDM port would have been 50018)

When the target deployment (RTS) is 7.0x, the deployment happens with the facilitation of the S.D.M.

So, the P4 protocol communication, with NW AS Java 7.0x, is through 5xx18 port