SAP CPS Dev

[former_member1244799]

Hi All, Could you please advise on the below query. We have implemented SAP CPS in our Dev environment. Our client wants to use one SAP CPS Dev environment to schedule the jobs in SAP Dev, QA and pre prod systems. They want to use one more CPS environment to schedule the jobs in Production system. Could you please give the pros and cons of having one SAP CPS dev environment to schedule the jobs in SAP Dev, QA and pre prod systems. Also which one do you suggest, having 3 SAP CPS environments for Dev, QA and Preprod or one SAP CPS environment for Dev, QA and pre prod systems. I have to take this points to my client. Also could you please suggest how the licenses work on the above scenarios. Thank you in advance. Regards, Ramana

[nanda_kumar21 · Accepted solution]

This is more of a consulting question than of a support.

The recommendation is to have to DEV, QAS, SBX or PREPROD separate systems for a number of reasons, few right on top of my mind.

1. The decision you make is going to ultimately impact the way you design a job definition.and job chain. It is extra effort if you have just one non-prod cps. For example, when you have to submit a job chain, in single non-prod CPS, you have to add Job Chain parameters to submit them in different environment, which is not the case if you have CPS system for each env.
2. File events are severely impacted. For example, you have a file event defined for DEV environment and QA in same CPS, now which one will you migrate to PRD?

thanks

Nanda

[former_member1244799 · Accepted solution]

Hi Nanda,

Just to have a discussion.

I had a talk with my colleagues, With one non-prod CPS, we can make duplicates of the job definition for QAS and Pre prod and change the parameters and the job name, hence by looking at the job definition we will know which environment the job definition belongs to. If we have 3 separate env's, still we export and import and change the parameters. Why can't we do this thing with one non prod CPS?

For file events which are defined in same CPS also, is not the same thing, whether we migrate  Dev or QA file event to Prod as we have to any way change the required parameters.?

Also as you know we only run the jobs ondemand basis in non prod CPS and we schedule them on Calendars in Prod. So we assume there will not be much load in non prod CPS.

Please advise and thank you so much.

Regards,
Ramana

[nanda_kumar21 · Accepted solution]

hi Ramana,

Exactly, do you see the additional effort required to duplicate the job definitions?

Also

1. You create a job definition for Dev system, then you duplicate and create a new one for QAS and you run it during testing cycles. Now which of these two would you promote to production?
2. If you have named the job definition itself to contain DEV or QAS SIDs, you can't change that when you import into production. So will you create one more for production or rename the job definition in production? Is changing something in production directly, a best practice?
3. It is best practice to make sure the file path for file events are same and consistent across the landscapes, so SIDs should be avoided in the file path.
   1. /usr/sap/inputfile/ - best practice
   2. /usr/sap/DEV/inputfile - not best practice. you can use import rule to change it though.
   3. Either way, in the above case, i have only one file event create in DEV CPS, which i'm going to migrate to QAS(change file path if need be through import rule) then test it and then migrate it to PRD in same way.
   4. If i have a file event created for DEV, say DEV_FILE_EVENT and QAS_FILE_EVENT in the same non-prod CPS, which one will i migrate to PRD? so in PRD, will you rename the file event again?
   5. Changing the file path is OK, because it is still the same object, but changing the File_Event object itself means you creating a new object by renaming it to a new one.

thanks

Nanda

[former_member1244799 · Accepted solution]

Thank you so much Nanda for giving much clarification. Do you still see anything so that I can put in front of my client?

Regards,

Ramana

[nanda_kumar21 · Accepted solution]

You can also state the standard reasons for having a 3 system landscape, for example, patching. You need to patch SBX first  to see if there is any issue before proceeding to patch the rest of the systems.

thanks

Nanda

[former_member1244799 · Accepted solution]

Thank you so much Nanda