Skip to Content

Common pitfalls using the NWDI

As I recently had to do a lot of sysadmin work on the NWDI I fell into a lot of traps myself so this is a list of some of the most common things I experienced and how we could resolve them. As this is in nowise complete, please feel free to add your own. Problem 1:Help, after some changes to the track my development components do not build anymore, SAP-JEE, SAP_BUILDT, SAP_JTECHS compartments are suddenly empty.Solution:Do a restore system state on the tabs “Development” and “Consolidation” in the Transport Studio view of the CMS UI. Import the compartment SAP-JEE, SAP_BUILDT, SAP_JTECHS again. If you have just created the track, see if those SAP compartments are listed in the Required Software Components table of your track (Tab “Track Data”). You will probably need to restart the NW Studio. Also you should “sync Used DCs” for that failed DC. Description: After each change on the track you must do a restore system state. It sucks and I am not sure why this needs to be. Problem 2:I created a new Software component in the SLD. It does not appear in the list when I want to add a SC to my track.Solution:In the CMS Web UI, on the Landscape Configurator -> Domain Data there is a button “Update CMS”. This button loads all SCs from the SLD and somehow refreshes the cache. Problem 3:I added some new dependencies to my SC in the SLD, how can I update this in my track?Solution:You have to press the “Update CMS” again on the Domain Data tab. Then you go to your track remove the SC from the list and and add it again. After that you must do a “Restore System State” again. Clients also must delete their Development Configuration for that track and import it again. Problem 4:For some unknown reason my DCs to not build or my import does not work, though everything builds locallySolution:I would check first if you have enough space on the file system of the NWDI Server. For us it is the major reason why something does not work though it should. Unfortunately no log files gives a clue about that! You can for example delete some of the older versions of your assembled SCAs that lie in the /usr/sap/JTrans/CMS/archives folder to make some space. This directory has to be cleaned up on a regular basis as the assembly really creates a lot of archives. Whenever an assembly happens a new SCA file is created in the archives folder and each SCA file can easily be more than 100MB. Also the CBS uses a lot of space for building the DCs though a lot of space is freed afterwards again. But during an import of a large SCA, space can temporarily run out. Another good thing is to try initialize the compartment in the CBS Web UI. Select your build space and the Software Compartment with the broken DCs. Go to the tab Initialize the compartment. This deletes all local files and starts a fresh sync and fresh rebuild. With some SPs we had that problem when we introduced new public parts in DCs. The build log often complained about a missing public part though it was there. Initialize compartment solved the problem. Problem 5:The build log compains about missing public parts though they are presentSolution:Initialize compartment. (See Problem #4). Problem 6:Some DCs need to be deleted (most common thing here, the the vendor name was wrong. Does somebody know how to set a default vendor in the NW Studio ?). How can I get rid of them?Solution:This is explained in SAP Note #864515  The sum up: Sync the DCs. Go to the DTR perspective and choose the DCs in the Workspace -> inactive of your track. Then you do a “delete subtree “on the _comp directory under the DC. This activity will be immediately checked in. After that you must delete the corresponding myDc.dcref file in the SCs->TopLevelComps folder Problem 7:My track sucks, I want to delete itSolution:You delete the track in the CMS Web UI. If you want to delete the workspaces that were created for that track you must do that with the DTR commandline tool.  If that does not work here is a suggestion by Stefan Thibeault (Thanks a lot!):“I ended up deleting the workspaces using SAP #855537, which deletes workspaces using Internet Explorer and web folder.”Problem 8:We have a request in the CBS that never finishes and seems to be waiting foreverSolution:  Restart the NWDI Server, see if that request still exists after restart. If no open requests exists it might be that you must set the mode for the build space back to OPEN if it is still PRIVILEGED. But you should be really sure that no “OPEN” requests exist for that buildspace (it shows that in the buildspace overview)
You must be Logged on to comment or reply to a post.
  • Hello, I’m not sure if I am asking this question right, but what if you have SCs (for ESS), both standard SCs and including DCs that are modified in a track that has no runtime systems. Later you add the runtime systems and save the changes which ask about a “save” or “save and restore” option. If you choose save and restore, will that rebuild all of the buildspace, INCLUDING the changed DCs or will it revert everything back to the standard? I ask b/c after doing this and choosing the “save” option only, all of my ESS DCs are broken.
    • Hi,
      I am not sure if you know your landscape in detail but you need to “restore System State” after track changes. The restore puts the SCs that were imported into the track into the inbox of development again. Then these SCs are imported. To understand what really happens I would recommend to you to choose “save” and not the “save and restore” button (like you actually did). Then go to your dev inbox and click on the button “restore system state” in the right corner. A popup opens that shows you all the SCs that will be put into the inbox of development. They will be put there but not yet imported. The advantage of doing this is that you can see what SCs are actually imported and you can even manually delete entries if you are not sure you want a specific SC overwritten. But the import should not overwrite any changes of you. The only possible thing could be that the SCs contain versions that conflict with your changes.  But you can check this after the import in the DTR conflicts view.
      ESS is a special case and you should read the ESS cookback attached to SAP Note #872892. This applies to the case if you have changed Web Dynpro DCs that was delivered by SAP and you need to import a new Service Pack of ESS into the system and you want your changes preserved.
      The problem here is that the you cannot resolve conflicts inside Web Dynpro DCs so easily. The solution they describe is to create a separate track with the new ESS release (without your modification) and then to copy/paste your changes into a new track manually! I think this scenario is an absolute nightmare!!!
      If I am wrong here please correct me! I actually have not done this with ESS myself.
      • Hi, thanks for the info. That is why I did “save” in the first place, I was worried that doing save and restore would overwrite the changed DCs in the track. I agree that doing a restore system state from the import tab would clear up the broken DCs, but it sounds it would also overwrite the changed DCs, correct? I personally did not make the DC changes. It was our offshore development team and the only “reference” I have to them is in the assembly tab of the track. Are you saying the only way to resolve this is to have the development team re-activate those changes from NWDS again after I restore the system state?

        I am familar w/ the ESS cookbook, but that is more for SP application updates, correct? We are not doing an SP update, but it sounds like this issue may be similar.

        So again, it sounds like I (or dev team) need to re-activate or re-do the DC changes from NWDS after restoring system state, correct?

        • >So again, it sounds like I (or dev team) need to re-activate or re-do the DC changes from NWDS after restoring system state, correct?

          No, as far as I know the restore system state will NOT overwrite any of your changes. I mean that would be pretty fatal. As I understand it, the software components gets imported but you have already versions of the files in your DTR workspace that are newer than those that are in the SCA. It would only overwrite your changes if the SCA contains versions of files that are newer than those in your workspace. This can be the case when you do a SP upgrade of ESS.

  • David,
    I know very long time you kep this blog in the SDN but somehow i navigated and ended up with this blog, hope you becomes master now in the NWDI. We’ve a issue with delete DC from the track, as you mentioned in this blog to remove DC from the track first we need to remove the project from DCs folder then from SCs folder but mistakenly without having proper knowledge we removed the project from SCs folder, i.e “xyz.dcref” then we tried to remove it from the DCs folder and it showed the delete option in gray(disabled). Is there any option to remove the project from DCs folder though i removed it from SCs folder.

    Sandeep Bonam