cancel
Showing results for 
Search instead for 
Did you mean: 

NWDI SP Level

Former Member
0 Kudos

Hello,

I am on EP7.0 and upgrading the ESS/MSS BP's and I want to know whether NWDI should be kept at the ame level as the DEV,QAT and PRO systems ..if yes then going one level up which system should be patched first ...?

Any help would be highly appreciated.

Accepted Solutions (0)

Answers (2)

Answers (2)

former_member198228
Active Participant
0 Kudos

Hello Subash,

I would suggest keep the dev and nwdi at the same patch level. If QAT and Production are on a different patch level, please make sure the libraries you import into the tracks are the same patch level at the QAT and production system.

Make sense?

Abdul

Former Member
0 Kudos

Hello Abdul,

Thanks for the reply. Can you just brief out what are the activities to be performed on the NWDI for ESS/MSS upgrade...

Also ,before starting the upgrade do we need to patch the R/3 Backend system first or can start on the Portal or it does not matter.

Please help.

Message was edited by:

SubhashTripathi

former_member198228
Active Participant
0 Kudos

Hello Subash,

So if you have modified the ESS/MSS and now want to adjust your modification with the ones shipped by SAP here is what i would suggest

Use JSPM to update your dev system and choose the option nwdi controlled

JSPM will now move the scas to you NWDI inbox directory.

Import the sp1 scas into your track

This will show any conflicts that arise. If there are conflicts adjust these from NWDS. if not just activate them and move it to cons.

then to test and prod.

The sequence of if R/3 is updated first or the portal does not matter, but in the end both should be at the same patch level.

Hope that helps

Abdul

Former Member
0 Kudos

Abdul,

Thanks for the reply. Please let me know that with sp1 you mean the new SP or the old one .....also why there is a need of running jspm under nwdi control and and having the modified sca in the inbox folder ....as any way we are creating a new track and moving the old changes....to it..

Also once the old changes are applied to the new SP and we transport it to DEV and CONS systems ...then to move to QAT and PRO do we do a normal transport or copy the sca file to the inbox folder of these runtime systems and use jspm...?

I hope I am not going off the way.

Looking forward to your reply,

Message was edited by:

SubhashTripathi

former_member198228
Active Participant
0 Kudos

Hello Subash,

with sp1 i mean the new SP. by running jspm it will confirm the manifests and only move those files that have been modified vs everything if you were to do it manually.

No you would do normal transports using nwdi to move it to qat and pro system

Abdul

Former Member
0 Kudos

Read Marion Schlotte's blog on this subject: /people/marion.schlotte/blog/2005/10/25/jdi-software-vs-jdi-content

Former Member
0 Kudos

Hello Abdul,

Thanks for the reply. I have some other questions:

1) Do we create separate tracks for ESS and MSS becasue my client here has separate..?

2) How do we add new sca (new SP) and the required components to the Track created ...do we need to deploy them to NWDI first..?

Looking forward to your reply.

former_member198228
Active Participant
0 Kudos

Hello Subash,

Kind of a long thread now isn't it? Anyway, here is kind of a guidline i follow when creating tracks. You could search documentation for the best practice.

a. Requirement to give permissions for different developers to different tracks

b. release cycle of the scs contained in the tracks.

If either of the above conditions are true then have a separate track.

In order to add the sca to the track, you don't deploy but import it from the landscape configurator.

Hope that helps

Abdul

luciano_leitedasilva
Contributor
0 Kudos

Hi there,

You must apply the pacth first on the DEV system. After the tests be done you should release these changes to QA system and after more tests when everything be right you can create a new version and release the changes to Prod system.

This is my point of view.

Regards,

Luciano