cancel
Showing results for 
Search instead for 
Did you mean: 

Questions on Runtime systems

former_member189501
Participant
0 Kudos

Hi to all

I have two questions:

1)

SAP says do not use the system where the JDI s installed as runtime system, I suppose in order to avoid the CMS deadlock described in note 754143. Right ?

Suppose we have three system D (develop), T (test) and P (Pro). Teh JDI is instaleld in D. We define the track Development with the runtime systems T as "test" and P as "production".

As I understood the deploy on the D system happen automatically as soon the activation is triggered into the Dev Studio IF the system D is used as runtime system.

Please could you clarify how we can keep aligned the D environment with the system T and P from the point of view of he deployment if we cannot use the D system as runtime environment ?

2) Suppose we have three system D (develop), T (test) and P (Pro). Teh JDI is instaleld in D.

We defined the tracks DEVELOP and MAINTENANCE, connected by a 'repair' connection.

If I understood weel the DEVELOP track and the MAINTENANCE track should have the Development and the Test runtime system in exchanged order:

the system indicated as Test for the DEVELOP track has to be indicated as Develop for the Maintenance track.

Then the runtime Production system has to be defined for the DEVELOP track only ?

Regards

Accepted Solutions (0)

Answers (2)

Answers (2)

0 Kudos

Hi Mauro,

As for your question regarding how to synchronize the Dev Test and Prod systems when only Test and Prod have been defined as runtime systems,what you can do is deploy the application manually using NWDS in Dev and when everything is ok activate and release the activity.

Regards

Sidharth

former_member189501
Participant
0 Kudos

Hi, thanks H. for the info.

I understood the MAINTAIN track and the DEVELOP track MUST to have different runtime systems.

We need at least, (minimun), 3 different systems (development1 and test on the DEVELOP track and development2 on the MAINTEN track) in order to maintain an old relese of SC while a new release is in progress, right ?

It's then responsability of the 'connection repair' defined between the tracks to move the software from the DEVELOP track to the MAINTEN track.

Please, in which moment of the DEVELOP track the software will be copied also to the MAINTEN track ?

New question about the Consolidation phase.

At the beginning we configured ONLY the runtime development for the DEVELOP track. So the work o teh developers was deployed automatically on that system as they activate their activities into the Developer studio.

As traiing we released the activities and we saw them into teh Consolidation tab queue ready for transport (NO Consolidation runtime system was in place).

Anyway we selected them and run the import. The CMS said it gone well.

After that the activities of the developers were into the Assebly tab queue.

My dubt is that after the import we saw our application working fine on the envirnment indicated as runtime develop system.

I need to clarify if this is the correct behaviour:

A) In this case using only the development runtime system into a track it does not have sense to relase the activities.

The development activity then end at that point and there is nothing else to do into the CMS.

If you need at that point the SCA of your work, to import them elewhere you can find it under the ../Jtrans directory (on condition that you reeased them)

Right?

B) It's an bug of the CMS to allow to run the import from the Consolidation tab while there is no consolidation runtime registered ?

Or it do not represents a real, physical import of software but only a logical step needed to move ahead the sw ?

we suppose when we run the import from the Consolidation tab queue we overwritten again the application on the development runtime system, but I'm not sure of that.

Former Member
0 Kudos

CMS does not overwrite deployments in a runtime system if you perform an import in a stage that has no runtime system assigned.

The SCA of your SC is created in the Assembly stage. Only if your transports have gone through this stage you will find an SCA file in the JTrans directory. Before the Assembly stage individual SDA's are deployed. After the Assembly stage complete SCA's are being deployed.

former_member189501
Participant
0 Kudos

Thanks Pascale,

but so when we run the import from the CMS tab what happened ?

We saw he CSM woking some minute and the actiones released moved to the Assembly tab page.

It means in order to produce SCA files having one rutime system only you have to do "import" anyway to move the software ahead, even if no other runtime system is in place right ?

Regards

Former Member
0 Kudos

When you run the imports the transport administration (system state, etc.) is updated by CMS and if a runtime system is connected to the particular stage a deployment is performed as well.

Correct, you just need to perform the imports to move the transports to the next stage.

former_member189501
Participant
0 Kudos

Thanks Pascale

Now it's clar for me the role of the runtime RTS's:

they just need for the deploy of the developments. The developments goes ahead anyway.

Please, what about my question n the MAINTENANCE track (a second track connectd to the DEVELOP track by a "repair" connection)? Do you have any experience on that too ?

regards and tahnsk in advance

htammen
Active Contributor
0 Kudos

Hi Mauro,

1)

The deadlock is one reason you shouldn´t you a runtime system for NWDI. The other reason is performance. NWDI especially the CBS but also a bit the DTR are resource consuming services. Therefore they should run at a different system. In bigger development departments you should also think about clustering or split these service at more than one system.

So you should at least have one server for D,T,P and NWDI.

2)

Where did you read that if you work with development and maintenance track you should reverse the usage of development and test runtime system?

The best solution is to have a separate landscape (D,T,P) for each track (one for dev. and one for each maintenance). This is of course very cost intensive. A workaround is to use the same landscape for every track. In that case you have to ensure that before you deploy an application you first undeploy another version of the same app.

This solution has it´s limitation if you use backend systems (databases, R/3 systems, ...) that require a certain version at the frontend.

Regards

Helmut