'Reset to original' for previously modified SC, or remove NWDI control

[Matt_Fraser]

Some while back we had modifications to both SAP_ESS and SAP_MSS in our Portal system, and of course we have used NWDI to track and manage those modifications during support pack applications.  However, we have since dropped the modifications to MSS, using the SAP-delivered code instead, although we still are keeping some ESS modifications.  I would like to be able to drop the status of 'modified' for the SAP_MSS component so that I no longer have to wait for length NWDI imports to get updates into our systems and instead can just let JSPM do its work.  In the past I successfully managed to do this for SAPPCUI_GP, but I no longer can seem to figure out how to achieve this end.

Our portal is on 7.01 sps10 (currently moving to sps13), and the ESS component is 603 sp10 (moving to sp12; the backend ERP system is 604 sps10 going to sps13).  The MSS component is 600 sp20 (moving to sp21).  The NWDI system is also on 7.01 sps13.

Starting with our sandbox portal, I redefined the associated NWDI track so that SAP_MSS was no longer marked as developed SC.  I kicked things off in JSPM, using the support package stack option, with the system under NWDI control as a DEV/CONS system.  Everything worked fine, except that both SAP_ESS and SAP_MSS were recognized as modified and therefore not deployed by JSPM.  JSPM is now at 7.01 sp13 pl0 (though internally it reports itself as sp12 pl0, so there must not have been any change from sp12 to sp13).

I thought I would now be clever and restart JSPM using the single support packages option, as in the past this has allowed me to overwrite a modified SC with the SAP-delivered one.  No dice.  JSPM still insists MSS is a modified component and will not allow deployment except via NWDI.

Ok, fine.  It's a sandbox.  I can afford to get rough, though I prefer not to, as the idea here is to figure out what I'm going to do in the DEV, TEST, and PROD systems later.   Anyway, following the instructions in Note 1462405 (Remove NWDI Control of SAP AS Java for JSPM / SUM), I removed the runtime system from the track, and then restarted JSPM.   This didn't work; JSPM still insists that the system is under NWDI control and won't let me deploy the SC.  I restarted the SDM and tried again, with no change (actually, I had to restart the SDM after removing the RTS from the track before JSPM could even logon).

After more searching, I found Note 1147113 (JSPM: This system is not under NWDI control), and followed those instructions.  In the Jspm.JSPM.DataModel.xml file, sure enough I found the 'nwdiRole' setting still at 'DEV(2)' and the 'nwdiSystem' setting at 'true', so I edited the file per the Note, changing the values to 'NOT_NWDI(0)' and 'false' respectively.  I then tried JSPM again, but it still insists the system is under NWDI control.  I restarted the SDM after confirming my edits in the xml file, and tried again.  It doesn't work.

Per Note 1632696 and SDN Thread 1646379, I deleted the three 'DataModel' files so that JSPM would re-initialize the model from scratch, but it still thinks it's an NWDI-controlled system, and the newly recreated DataModel file doesn't even have a reference to NWDI control at all.  Clearly the 7.01 version of JSPM is not getting this information from these xml files, and it is not getting it from NWDI; it's persisting it somewhere else.

Does anyone have any idea where that somewhere else might be?  Or how to get JSPM to 'forget' that it once was an NWDI-controlled system?  Or if not that, to simply allow me to "reset to original" on a Software Component (similar to what we can do in SPAU and SPDD)?

Best regards,

Matt

[Matt_Fraser · Accepted solution]

I have resolved this problem with the help of SAP Customer Support.  The trick really does lie with Note 1462405 (Remove NWDI Control of SAP AS Java for JSPM / SUM), but the problem was that the runtime system, where I was executing JSPM, was indeed persisting track information from NWDI for old tracks previously deleted.  If you follow the practice of migrating your runtime systems to a new track whenever you apply ESS/MSS support packs, as many do, and delete your old tracks before removing the runtime system information from it, then this problem could occur.

To avoid the problem, it's important to remove the runtime system from the track per the instructions in Note 1462405, without first deselecting the "Integrate Runtime System into JSPM scenario" checkbox, and before deleting the track (if you do delete it ever).

If you have already deleted the track, you will need to recreate it with the same name as before and with the same "developed software components" as before.  Then you will need to add your runtime portal system to the track configuration, with the "integrate" option, and save it.  Then,you will need to remove the runtime system from the track (but do not deselect the "integrate" option), and save it.  This will remove the track data saved in the runtime system's database, and which JSPM reads.  Only after removing the system from all NWDI tracks, past and present, can you remove NWDI control over JSPM and thus have more control over whether to import a modified or standard version of ESS, MSS, etc.

Note that you may be able to 'reset' a modified SC without removing all NWDI control by ensuring that the runtime system is in one track only and that this track does not include this SC as developed.  However, it's easy enough to remove all NWDI control entirely and then reinstate it again later, if this is what you need to do.

So, what if you don't have good records of which tracks the RTS (runtime system) belonged to, what SCs were developed in those tracks, and so forth, and those tracks are now deleted?  Where can you find this information?  The answer is in the portal RTS database, in table BC_CMSRTS.  The column CONFIGTYPE will show 'dev' for the modified SCs (in the NAME column), and TRACKNAME will show, obviously, the track name.  If your RTS lists tracks here that you have deleted in NWDI, you will need to recreate those tracks using the same name and add the same SCs as developed, in order to add and then removethe RTS from the track.  This will clear those entries from BC_CMSRTS, and JSPM will be happier.

Best regards,

Matt

[benjamin_houttuin · Accepted solution]

Thanks Matt for all your work on this topic! Will need it tomorrow

[benjamin_houttuin · Accepted solution]

Well that didn't go as planned...

We have ESS and MSS customized in our copied DEV system.

We have it copied to test our SPS. I had to connect the system in the NWDI track first before I could disconected "the neat" way. In the connecting phase it will deploy the customized SCAs to the system (dont know why they where alredye there) this took 5 hours. After that I disconnected in NWDI and checked the table BC_CMSRTS and indeed the ESS MSS entries where gone .

But... This didn't gave me the default SAP (non customized) SCAs yet.

So I started up JSPM and got ready for updating ESS MSS and by updating revert them back to original SAP code. But JSPM still tells me that ESS and MSS are locally modified versions and it will not deploy, it will only copy the 2 SCAs to a CMS subfolder. Tried JSPM in God Mode but still no result.

My last resort was good old SDM, so I loaded the ESS and MSS for SDM deployment and voila both back to SAP original.

I hope I get some feedback on what I did wrong or is this the only way to do it.

PS this system is an old 7.0 (non EHP).

[Matt_Fraser · Accepted solution]

Hi Benjamin,

Sorry to hear this was so frustrating, but it seems you got a happy result in the end.  It has been a year since I did this for our systems, so I'm working on old memories now.  I seem to recall that in my case, JSPM reported that the SCs were locally modified, but as the system was then no longer under NWDI control it then allowed me to deploy the standard SCs over the top.  I did not have to use SDM in this case.  Possibly this had to do with it being on NW 7.01 instead of 7.00, although I couldn't swear to that.  Also, it may have been due to the fact that I was loading newer versions of the SCs, not trying to load the same version that was already installed.  Perhaps that was the source of your issue, though I think "God mode" should then have allowed it anyway.

The real test, now that you've deployed via SDM, is whether it works the way you want it to with your next JSPM deployment.  It seems like it should.

As for the 5 hour wait while NWDI synchronized a track with an RTS in which the same versions were already deployed, yeah, that's one of the things I have always disliked about NWDI.  It is an exercise in frustration and patience, for sure.  I'm not surprised you had to do that.  Newer patch levels of NWDI improved this behavior -- it got better at detecting that the same component versions were already in the RTS and so wouldn't always redeploy -- but it still seems to take a long time.  I look forward to converting ESS/MSS to Webdynpro ABAP so that the development is in the backend and NWDI is out of the picture.  That will be a bit of a project, however.

Regards,

Matt

[benjamin_houttuin]

Thnx for the quick reply Matt.

regarding the versions I was updating to a higher SCA version so it was the same as your case.

My guess is that the next JSPM update will now indeed work fine.

I think why it kept going wrong is that the system is still under NWDI control for other components in other tracks (non ESS MSS) but thats a wild guess. Or indeed 7.01 might changed it.

Regarding moving to ABAP I fully agree for this. I'm from the Java "school" but this implemented crap and NWDI gives more trouble then reward sometimes. I love the SAP FIori development btw... Use abap se80 and Eclipse together, seems a good deal! Anyway this is going offtopic. So thnx again.

Cheers!