NWDI with CM Services and CTS+: Correct setup for Process Orchestration

[Former Member]

Hi experts,

I have a basic question to understand the concept of CM Services of NWDI exactly.

We have a Process Orchestration landscape in which we are doing both PI and BPM developments. We plan to set up NWDI together with CTS+. We have 3 systems: Dev, QA and Prod.

I was able to configure everything so far on the development system to ensure that development works (both PI and BPM). However there are still some open questions to understand the concept completely:

1. How do we need to set up the TMS settings correctly? We have done it as follows so far. Do we also need "DC" method? And if yes, why? If I save this configuration, the development configuration in NWDI is created without a runtime system.

2. Do we need a runtime system or can we configure everything without a runtime system? What is the purpose of it? Do we have 1 runtime system for all 3 stages DEV, QA and PROD or is the runtime system only PROD system?

Thanks for clarification and Best Regards

H.

[Former Member · Accepted solution]

After playing around a little bit with all the options, I found out the following:

CTS+ PO Development System settings on SolMan:

- For the BPM part of Process Orchestration you need to use the Deploy Controller (DC)

- For the PI part of PO XI/PI is required

- For any SLD transports SLD option is required

- A development configuration needs to be created to ensure transports via CTS+ together with the usage of NWDI

- Source System Settings needs to be activated: This activates the transport organizer to create transport requests for this system. This needs to be done for each system for which exports should be done (usually only development system).

CTS+ PO User-Acceptance System settings on SolMan:

- Source System Settings: Not checked since no sources are transported from the acceptance system

- A development configuration needs to be created to ensure transports via CTS+ together with the usage of NWDI

I also created a document which describes the whole configuration in detail. Please refer to link: http://scn.sap.com/docs/DOC-47484

Best Regards

Harald

[ErvinSzolke]

Hi,

runtime system is a system that is holding only runtime objects (e.g. no sources or build archives any more). This is a system where you deploy and run your application. If you have a 3 system landscapce dev , qa and prod, then yes, you need to configure 3 separate runtime systems, one runtime system for each of these.

See also

http://wiki.scn.sap.com/wiki/display/Java/CM+Services

http://scn.sap.com/docs/DOC-8576?rid=/webcontent/uuid/c0ce1dd8-c020-2b10-d080-a1cd3e985af1

I hope this helps.

Best Regards,

Ervin

[Former Member]

Hi Ervin,

Thanks for the helpful answer.

But I can already deploy a BPM project via NWDS on the development machine without a runtime system. Why is this possible?

For the configuration of the TMS parameters (as in the screenshot above), do I then need to also use the DC method to activate the creation of a runtime system in the development configuration? Do you know if this is correct for BPM? The links unfortunately always only refer to XI/PI or Portal...

Thanks and Best Regards

Harald

[ErvinSzolke]

Hello Harald,

there are two ways to deploy.

1. directly via NWDS

2. centrally using your development infrastructure (I guess your case is TMS that initiates the deployment).

If you go for option one, then you completely ignore the central development. That case you can deploy to that very engine you specify in your NWDS, and nowehere else.

If you have Dev, QA, and Prod, then you always have to change the NWDS preferences to do the direct deployment to each of these machines, while in case of central development your TMS system handles where, when and what to deploy. If you have a 3 system landscape then option 1 is way error prone, I don't recommend it, I recommend rather to go for central deployment.

Option 1 is rather meant for local development, local tests, smaller developments with few developers (or even only 1). Direct deployment does not consider the development cycle at all (no development config, (no tracks -- in CMS scenario), it just deploys your app directly).

Regarding your question addresses DC method I am not sure.

Best Regards,

Ervin

[Former Member]

Hello Ervin,

Thanks again! That makes it much more clearer to me.

However I have one more question:

When I make any changes to a BPM process in NWDS a new activity is created (we have set up TMS to use activity-based transports. For this each system needs to have a development configuration, which I now changed by using the mentioned "DC" deploy method). I can release this activity which is then attached to a transport which is moved to the target system. This is I think what you mean by handling the changes via TMS?

The images below show the transport of an activity-based transport from dev (DI1) to the qa system (AI1).

But, according to your last reply, how should I then test a BPM process on the development machine for example? Means: How can I deploy the BPM process (developed on PO dev system) to the development runtime system via NWDS? Only by right-clicking on the process and by selecting build and deploy is not correct as far as I understood (since this is the direct NWDS way, which is error-prone).

Thanks and Best Regards

Harald

[ErvinSzolke]

Hi Harald,

you are correct, in order to test your changes you can dedicate a server (that is not dev/qa/prod) that you use to test your changes directly before checking in and activating your changes. This is why I wrote previously that if you want to do local tests, then of course a direct deployment is the solution. I only meant that way that if you do central development with multiple developers, then of course you go for check-in, activatio, release,import, central deployment, etc, but for testing reasons each developer can delpoy the change directly to their local test machine and test before handing over the change for central development.

Best Regards,

Ervin