Skip to Content

Introduction

The current NWDI landscape has grown out of the need to combine an existing production environment for Java development with the new component model concept supported by NWDI.

This paper contains recommendations about the setup of tracks, track landscapes, and development processes; these guidelines have been found useful and reliable for the software production at SAP.

The concepts presented here are documented in detail in the SAP Library for SAP NetWeaver (http://help.sap.com -> SAP NetWeaver Development Infrastructure).

Recommendation

Only use one NWDI for the development of multiple releases of software components (SCs).

Basic Landscape

Setup of Tracks and Runtime Systems

Track for Development of a New Release

One track is sufficient for the development of one release of a software component. It offers the complete production environment for all phases of development including the quality assurance steps that guarantee high quality software. The track itself is simply a logical container for organizing the development process in a structured way.

image

Recommended Use of Runtime Systems in a Track

Since the Change Management Service (CMS) of the NWDI enables you to attach up to four runtime systems to a track – one for each state of the software – the following use of runtime systems has proven itself as most effective.

  • Runtime system ‘Development’: Immediate testing of the newest changes.

    The runtime system in the development state is especially effective when it is combined with regular automated tests, for example an automated test that runs every night. In this way a lot of errors can be detected very early in the process. The overall quality of the software improves.

    Variant:
    If you think that local tests by the developers are sufficient for the overall quality of your software, it is possible to omit the runtime system from the development system. The first integration test system will then be the runtime system of the “Test” system.

  • Runtime system ‘Test’: Testing of consolidated software state.
    This system offers a test environment for the software that mirrors the production environment.
  • Runtime system ‘Production’: Deployment in the production system

Organization of the Development Process

The development cycles at SAP are managed in milestones and phases.

Milestones are software versions for which a certain set of software features must be developed.

Phases are the time periods in which the specific tasks for the milestone are carried out, for example, development, testing, and integration tests (MIT).

New milestones are developed in the development system of the NWDI track. This offers system offers an area for big structural or architectural changes and the development of new functions. These tasks are usually covered by the development phase.

After the development and test phase the software state is released and transported into the consolidation system, thereby performing a source code split.

This is to provide stable software and to offer an environment for small corrections. The development system and consolidation system are connected by retro-transports that allow to transport small corrections back to the development system and to avoid double maintenance.

The Development Process

The development of new milestones is combined with automated tests in the runtime system of the development state (DEV).

Corrections to the production state are done in the consolidation system (CONS) and are transported back to the development system.

Development Phase

The developers develop and test their new functionality in the local Developer Workplace. This consists of an SAP NetWeaver Developer Studio and a locally installed J2EE Engine. After the local tests, the developers check in and activate their changes. This triggers the central build in the Component Build Service (CBS) of the NWDI and the results of this build are deployed in the runtime system of the development location.

The runtime system DEV of the development location is the first environment for integration tests of changes from different developers.

Correction Phase

The start of correction phase involves the transport of the milestone from the DEV to CONS. After that, corrections to the milestone are done in CONS. These corrections are transported back to DEV by internal back transports. The fixes made in the correction phase can be assembled and deployed in the test system until the quality of the software has matched the necessary criteria.

Handover to Production

After successful tests in the test system, the milestone is handed over to the production team that needs to approve it (Approval).

Deployment to Production

The production team defines and publishes a schedule specifying when the new milestones will be deployed.

Restrictions of the “Single Track Setup” Development and maintenance within one track are only possible as long as the production state and the development state are based on the same Support Package level of the SCs which are not developed in the track.

As soon as you want to start development based on a new Support Package and still retain the production system, you need to set up a maintenance track as described in Advanced Landscapes.

Recommended Steps on Developer Level

  • DEV: When should I activate my activities?

    Activate your activities after the following steps:

    1. Change locally in IDE
    2. Deploy on local test engine
    3. Check in and activate after successful local test
  • DEV: When should I release a change request?

    Release your change requests in the Developer Studio after successful tests (automatic tests) in the runtime system attached to the ‘Dev’ state. This will trigger the further transport through the landscape.

Recommended Steps on Administrator Level

  • TEST: When should I import into the test system?

    Import any software versions (Milestones) that require intensive testing into TEST. The advantage of using the TEST system instead of a runtime system at the CONS location is that the time the imports are started can be controlled exactly

  • PRODUCTION: When should I import into the production system?

    Import the software into the production system after successful tests in TEST guarantee an error-free production use of the software.

Advanced Landscapes

Tracks for the Maintenance of a Release

The maintenance of a release is supported by NWDI using a second track. A transport connection delivers changes from the development track to the maintenance track. A repair connection transports corrections made in the maintenance state back into the development track, thus avoiding double maintenance where possible.

image

For a detailed description of the maintenance scenario, see the SAP NetWeaver library: (http://help.sap.com -> … -> Application Maintenance with the NWDI)

How to work with back transports

After a software version has been deployed in the production system, you are confronted with the problem that you need to patch the production state, while at the same time you are developing new functionality in the development location. To avoid double maintenance of these corrections, they are transported automatically to the development location if a repair connection is configured between the tracks.

The following procedure outlines the back transport process for the developers:

  1. Release your transport. It shows up in the import queue of the previous track immediately.
  2. Import the transport.
  3. Check in the conflict view after the import into DEV, resolve the conflicts and activate the change.
  4. Release your transport if you had to resolve a conflict. This resolves the conflict in the follow-on workspaces automatically.

Track Landscape for the Development of Scenarios with Deployment on Multiple Production Systems

To realize more complex development scenarios, it is possible to combine multiple tracks in a track chain. In this way, it is possible to set up a succession of development phases or maintenance steps before the development is deployed in the productive systems.

(For information about the setup of production tracks, see (http://help.sap.com -> … -> Automated Deployment into Multiple Production Systems)

image

To report this post you need to login first.

63 Comments

You must be Logged on to comment or reply to a post.

    1. RK RK
      Hi Guenter,

      I got a query regarding the transport to multiple systems. couldnt find the solution yet.

      I created a track DEV – QA – PROD and it is working fine.

      now i have a requirement in which i got a couple of other servers (EP1 AND EP2) , where the changes should be deployed to them too.

      I have the following questions:
      1. should i create two seperate tracks, one for EP1 and another for EP2 or would one track including these two is enough

      2. whether it is two tracks or one track for these systems, EP1 AND EP2, what should i enter when creating the track for “Software Components for Development” and “Required Software Components” sections?

      Thank you

      (0) 
      1. Guenter Schiele Post author
        Hi,

        sorry for the late reply. I hope the information does not come too late.
        1. If you want to deploy the software in parallel you need to create two track.
        2. Enter all the software components that you want to deploy in the Required Software Components table. Leave the table for the developed software components empty as well as the input fields for the DTR URL and CBS URL.

        For more information see Automated Deployment into Multiple Production Systems

        Best regards,
        Günter

        (0) 
        1. Som kolli
          Hi Guenter,

          Could you please let me know if you have any information on merge tools for Model based development like webdynpro?

          We are using NW 2004s SP7 .

          Thanks
          Som

          (0) 
          1. Guenter Schiele Post author
            Hi Som,

            I’m sorry, but I don’t have exact information about merge tools for model based development. I know that Web Dynpro offers some support for merging but I don’t know as of which release/SP level this is available.
            Maybe you could ask the people who work in the area of the NW Developer Studio.

            Best regards,
            Günter

            (0) 
  1. Pascal Willemsen
    One question: Which runtime systems do you configure in the maintenance track(s)? If you use the same systems I can imagine that you get conflicts/mixes of software versions.
    (0) 
    1. Guenter Schiele Post author
      Hi Pascal,

      you are right! For the maintenance track you need  to use separate runtime systems. If you use the same runtime systems your software will be constantly overwritten by deployments either from DEV or for COR.

      In principle you can also see this in the last picture.

      Best regards,
      Günter

      (0) 
      1. Lad Santosh
        Hi,

        Thanks Guenter, your information is very precise.

        The sdn blog authenticate most of my understanding, however I need few of your inputs.

        We have ECC 5.0 , EP 6.0 , ESS/MSS Webdynpro and NWDI installed on one host with different instance and port no. We have installed NWDS in EP developer system.

        Created one track for Development with Runtime system “Dev” as we are in “Blue Print’ phase no QA and Production available as of now.

        1. Few days back we have changed track data as below ..
        While installation of NWDI we have configured Development Runtime SDM Host and Port as “NWDI” SDM Host and Port no, We have changed this setting recently to “ECC” development server SDM host and port no. As we have noticed all the ESS MSS WebDynpro should get deploy over the ECC development server and should used SDM of ECC rather than NWDI. Is this setting right or wrong?
        Do we need to restore the system status of Development and reimport the entire component in Development and consolidation? Please advice.

        When my EP developer create package in NWDS for modification in existing ESS WebDynpro, which Build space he should use? LJD_ESSTrack_C or LJD_ESSTrack_D.

        We currently have one track. Perhaps the SDN blog mentioned about
        the maintainance track. Fortunately we would like to modify the SAP provided ESS/MSS WebDynpro, Do we need “Maintainance” track? Do we need “Consolidation” runtime system configured to this track?

        I am following about reimport is just because we have h/w restriction and if we start unnecessary import, it will impact our development operation adversely with high I/O.

        Thanks in advance.

        Sanny.

        (0) 
        1. Guenter Schiele Post author
          Hi Sanny,

          1. Yes, you need to restore the system state after the reconfiguration because of two reasons:
          a) Your buildspaces have been reset after the reconfiguration, so the required SCs need to be imported again
          b) Since you want to deploy the ESS/MSS on the ESS runtime system the restore system state will take care of that.

          2. Your developer needs to work in LJD_ESSTrack_D

          3. As long as you don’t apply SAP support packages you don’t need a second track. (For more information see the weblog of Manohar Sreekant: Best Practices@JDI : Branching Patterns & Use Cases.

          Best regards,
          Günter

          (0) 
  2. Sistemi Open SAP
    The post is very good and complete but new questions come out:

    Please, could you give more informations on the backtransports ? They are not indicated at all into the the HelpOnline documenation.

    1) At point “Advanced Landscape” you says the corrections are transported automatically to the development location if the Dev runtime system is conigured into the MAINTENANCE track (of type Repair). Plese, this is supposed to occur when the SC in the Development Track arrive to which system ?

    2) If we have to fix the old release into the Test system while the new one is in progress on the Development system of the track DEVELOP, it means we have to deploy the souce code too as well on the test system. And this is not always true, especially when you install the sw at customer site.
    Please, do we need to deploy the source code as well on all the systems ?

    Regards and thanks in advance

    (0) 
    1. Guenter Schiele Post author
      Hi Mauro,

      the repair connection always connects a follow-on track with a track that is previous in the track chain.
      When you have configured a repair connection the fixes will be transported as soon as you release the change request(s) in the development system of the COR track for example.
      Once they are released they appear automatically on the tab “Development” in the DEV track. There they will wait for import until you decide to take the fixes over into the current development state.

      For your second question I think that I need to clarify that you have only two states in the track where the source code is available. These are the locations “development” and “consolidation”. These are the only “systems” where you can edit the source code.
      When you have configured a runtime system for Test you deploy only archives after assembly and approval.
      The changes/fixes that you do in either development or consolidation of your COR track will be transported back to the DEV track. On Test you will only deploy the Software Component Archives (SCAs) that you create in the assembly step.

      I hope that this answers your questions.

      Best regards,
      Günter Schiele

      (0) 
      1. Sistemi Open SAP
        Thanks Günter, your infomation is very precise.

        Please,I have some other questions related to the tracks configuration that is missing into the official documenation:

        1) Suppose we have three systems (DEV, TST,PRD)running EP60/KM and the JDI is installed on the DEV system. The CMS contains the track DEVELOP and MAINTENANCE.
        The DEVELOP track and the MAINTENANCE track should have the Development and the Test runtime system in exchanged order ?
        I mean the system indicated as Test for the DEVELOP track has to be indicated as Develop for the Maintenance track ?
        Then the runtime Production system has to be defined for the DEVELOP track only ?

        2) Oss NOte 754143 says do NOT use the sytem where the JDI is installed as Runtime system on the CMS tracks, in order to avoid the CMS deadlock described in note during the Offline deployment.
        But we have to do it anyway, we do not have others systems.
        Please could you explain a little bit:

        2.0) When the Offline Deployment is supposed to happen ? Which kind of objects trigger this type of deployment ?.
        Are there a workaround, ie manual deploy, for them ?
        We are going to develop only Webdynpro, please tell us if these objects can cause the CMS deadlock.

        2.1) If we define the track DEVELOP with the runtime systems TST as “test” and PRD as “production”.
        As I understood the deploy on the DEV system happen automatically as soon the activation is triggered into the Dev Studio IF the system DEV is used as runtime system.
        Please could you clarify how we can keep aligned the DEV environment with the system TSTS and PRD from the point of view of the deployment if we cannot use the DEV system as runtime environment ?

        Best Regars and thansk in advance

        (0) 
        1. Guenter Schiele Post author
          Hi Mauro,

          Question 1:
          I’m not quite sure if I understood your first question correctly.
          Why would you want to exchange the order of the runtime systems?

          Let me try to understand your situation:
          You have installed three runtime systems (DEV, TST, PRD). The JDI is installed on the runtime system and you have defined two tracks, DEVELOP and MAINTENANCE. So far I think I’m clear.

          Now comes the tricky part. You have configured the DEVELOP track so that the runtime system DEV is connected to the location “Development”. The runtime system TST is connected to the location “Test” and correspondingly PRD to the location “Production”. So far so good.

          In the MAINTENANCE track you are now short of runtime systems. Correct? To compensate you want to use the runtime system TST also as runtime system in the location “Development” of the MAINTENANCE track.
          This is technically possible. However, this configuration NOT RECOMMENDED! The import in the test location of DEVELOP always deploys complete SCAs. The activation and automatic deployment of the development location of MAINTENANCE only deploys DCs that have been changed and rebuild.

          Therefore do NOT configure TST as runtime system for Test-DEVELOP and Development-MAINTENANCE!

          For the production system the same statement is true. Only use it in one location. If the productive code is contained in track DEVELOP attach it to Production-DEVELOP.
          If the productive code has been moved to MAINTENANCE, the production system would probably be better attached to the Production-MAINTENANCE system.

          Question 2:
          2.0 Offline deployment happens when you deploy primary libraries or engine services. Web Dynpro objects should not cause an offline deployment (but you should ask this the Web Dynpro experts).
          A workaround would be that you deploy the offline components directly with the deployment tool SDM. But this would also mean that CMS looses the information about the system state of your J2EE Engine in DEV.
          If the Web Dynpro team approves, DEV should be ok as CMS.

          2.1  As I said above, if Web Dynpro approves use CMS on DEV.

          I hope this helps you.

          Best regards,
          Günter Schiele

          (0) 
          1. Sistemi Open SAP
            thanks Guenter,
            I’m starting to understand how JDI is really supposed to work.

            About Q1)
            I understood the MAITEN track and the DEVELOP track MUST to have different runtime systems.
            We need at least, (minimun), 3 different systems (development1 and test on the DEVELOP track and development2 on the MAINTEN track) in order to maintain an old  relese of SC while a new release is in progress, right ? 
            It’s then responsability of the ‘connection repair’ defined between the tracks to move the software from the DEVELOP track to the MAINTEN track.
            Please, in which moment of the DEVELOP track the software will be copied also to the MAINTEN track ?

            New question about the Consolidation phase.
            At the beginning we configured ONLY the runtime development for the DEVELOP track. So the work o teh developers was deployed automatically on that system as they activate their activities into the Developer studio.
            As traiing we released the activities and we saw them into teh Consolidation tab queue ready for transport (NO Consolidation runtime system was in place).
            Anyway we selected them and run the import. The CMS said it gone well.
            After that the activities of the developers were into the Assebly tab queue.
            My dubt is that after the import we saw our application working fine on the envirnment indicated as runtime develop system.
            I need to clarify if this is the correct behaviour:

            A) In this case using only the development runtime system into a track it does not have sense to relase the activities.
            The development activity then end at that point and there is nothing else to do into the CMS.
            If you need at that point the SCA of your work, to import them elewhere  you can find it under the ../Jtrans directory (on condition that you reeased them)
            Right?

            B) It’s an bug of the CMS to allow to run the import from the Consolidation tab while there is no consolidation runtime registered ?
            Or it do not represents a real, physical import of software but only a logical step needed to move ahead the sw ?
            we suppose when we run the import from the Consolidation tab queue we overwritten again the application on the development runtime system, but I’m not sure of that.

            Regars

            (0) 
            1. Guenter Schiele Post author
              Hi Mauro,

              we’re getting there 😉
              The moment when the software component archive (SCA) is forwarded to the MAINTAIN track is when you approve of this SCA on the tap “Approval”. After that you will see the SCA in the import queue Development of the MAINTAIN track.

              As for the new questions:
              A) The consolidation system represents a physical location of your software in the DTR. Just like in the development system you have an active and inactive workspace _C in your DTR and the respective Development Configurations which you can download into the Developer Studio.

              The consolidation system is intended to provide a separate state of your software where you could do fixes in your SCs when you are developing the whole lifecycle of an SC in only one track.
              For cost saving reasons you can omit the runtime system at the consolidation system since you can test the software alternatively in the Test system.
              You cannot the import into the consolidation system because during the assembly step the SCA is generated on the basis of the software in the consolidation system. All SCAs you find in the Jtrans directory stem from the assembly step and not from the release for transport in the development system. So DO NOT skip the consolidation system even though you don’t have a runtime system attached to it.

              B) I answered this question in parts already above. It is not a bug that you need to import into the consolidation system. The software lifecycle process of Development -> Consolidation -> Test -> Producution was originally optimized for development and maintenance of one release in only one track.
              The practical use of the NWDI has proven that for cost saving reasons one runtime system can usually be omitted in the track configuration. This usually is the runtime system in the consolidation system. The consolidation system, however, is always there and has a crucial function for the assembly process.

              The systems Development and Consolidation are always present in a track configuration since they represent physical “source code locations” that are configured in DTR.
              The systems Test and Production correspond to actual runtime systems which you also can see when you configure a track without any runtime systems. In the Tranport Studio you will then only see the tabs Development, Consolidation, Assembly, Approval. The tabs Test and Production only become visible as soon as a runtime system is configured for these locations.

              Regards,
              Günter Schiele

              (0) 
  3. Deborah Pandra
    When I make a correction in the CONS system, I check-in the changes to the DTR, activate the activities and release to the transport.

    When exactly these changes are deployed to the CONS system?
    I made a change in a WebDynpro DC and I couldnt see the change after a while. Does the WAS have a timing to do the deploy?
    I also changed a Java Project DC that is referenced by an EAR project DC. I changed the Java Project, and also activate and release the transport of it, but I cannot see the changes.

    Is there any configuration to have lastest code deployed in the WAS as soon as I transport the activities in the CONS?

    thanks!
    Deborah Pandra.

    (0) 
    1. Guenter Schiele Post author
      Hi Deborah,

      the changes in the CONS system are deployed directly after activation of your activities in the CONS system, if – and this is crucial – the WAS you are looking at is configured as runtime system for the location Consolidation in CMS.

      You can check this in the CMS Web UI in the Landscape Configurator on the tab Runtime Systems. Also make sure that the automatic deployment is not disabled in your track configuration.

      Regards,
      Günter Schiele

      (0) 
      1. Deborah Pandra
        Hello Günter,
        thanks a lot for your reply. In the landscape configurator I only have configured the DEV and the Test runtime systems. Regardless that, the CONS buildspace was created since I can download all the source from the devConfiguration in the IDE. It seems that the CONS buildspace is running in the same host as the DEV buildspace.

        1- Is the CONS buildspace created even if I dont configure the CONS runtime system?
        2- is it ok if I configure a CONS runtime system with the same host as the DEV runtime system?

        thanks again,
        Deborah Pandra.

        (0) 
        1. Guenter Schiele Post author
          Hi Deborah,

          1 – When you configure a track you always get a DEV and a CONS buildspace regardless of the runtime systems.

          2 – It’s not recommended to use the same runtime system for DEV and for CONS because the deployments during activation would constantly overwrite each other.
          The configuration of a runtime system for CONS is optional since you can also test the CONS state of the software in the TEST system after the assembly.

          Regards,
          Günter Schiele

          (0) 
          1. Deborah Pandra
            Hi Günter,
            1- If you configure a CONS runtime system, does it have the same buildspace as the CONS buildspace created with the track?

            2- If you disabled the “automatic deployment” in DEV and enable it for CONS runtime system, the DCs will not overwrite each other, right?

            3- In the DEV buildspace, having the DEV runtime system enabled for automatic deployment, the changes are deployed when I activate an activity. In the CONS buildspace, when a change is exactly deployed?

            4- I want to be able to access the CONS buildspace deployed changes, without having to import it to TEST runtime system. I have the DEV buildspace with the automatic deployment disabled in the DEV runtime system. is it possible to access the CONS buildspace changes deployed, that are activated in CONS (after activating or assembly)? or when having DEV and TST runtime systems, Will I be able only to access deployed files in DEV buildspace and TST buildspace only?

            thanks again

            (0) 
            1. Guenter Schiele Post author
              Hi Deborah,

              let’s see if I have some answers for you:

              1 – The runtime system that you configure for CONS automatically gets the content of the CONS buildspace with the deployment.

              2 – When you disable the automatic deployment in DEV you have stopped the automatic deployment after activation. This is correct. However, I don’t see the benefit of this solution. Switching the automatic deployment on and off always is a reconfiguration of the track and since the automatic deployment in DEV and CONS is only done on demand, that is when new changes actually trigger a rebuild of the DC, you might end up with more and closer monitoring of your changes than you gain.

              3 – The automatic deployment in CONS works exactly as in DEV. CMS deploys immediately after activation.

              4 – I guess I don’t understand this question. What do you mean by accessing deployed changes. Do you mean you want to see them work in the runtime environment, that is on the runtime system?
              To access the source files you have the DEV and CONS (inactive) workspaces that you can work with in the Developer Studio.
              You will see the content of your CONS buildspace run on the runtime system that you configure for CONS. Either after the import of the changes into CONS (cf. the import steps of the import logs in CMS Transport Studio) or after activiation in the CONS workspace if you do changes there.

              Just for clarification: Unlike DEV and CONS the systems TEST and PRODUCTION do no have buildspaces. These systems correspond directly to the runtime systems configured. Importing into TEST and PRODUCTION contains only SCA deployment while in DEV and CONS you have also source import into the DTR workspaces and activation of those sources.
              Only DEV and CONS denote the locations where you are able to change the software.

              I hope this clarifies your understanding of the NWDI.

              Regards,
              Günter Schiele

              (0) 
              1. Deborah Pandra
                Hi Günter,

                I’m understanding how is the mix between runtime systems and buildsystems.
                But I still have a doubt about deployment in DEV and CONS buildsystems.

                Let me explain 2 scenarios
                Scenario 1:
                a- Have DEV and TST runtime systems configured
                b- In the IDE, I modify a DC project in the CONS buildspace
                c- In the IDE, activate the changes, and release the transport
                d- After that, I have the activities ready to be imported in the DEV runtime system tab through the CMS

                Scenario 2:
                – change the configuration in CMS (step a) having DEV, CONS and TST. DEV runtime system disabling the automatic deployment, CONS runtime system enabling the automatic deployment. Both DEV and CONS with the same host.
                – Do the same from step b to d as step 1.

                I want to access the changes that I made in CONS, running application in the server.
                When I access the url via “serverName:50000/webdynpro/dispatcher/vendor_name/wdName…”, I am able to see the DEV buildspace state, and not the
                CONS buildspace state with none of the 2 sacenarios.

                How do I access the CONS buildspace deployed application? is there a different URL? is this possible?

                thanks again!

                (0) 
                1. Guenter Schiele Post author
                  Hi Deborah,

                  as I understand your scenario the following happens:

                  Scenario 1: After having changed, activated and released your DCs in CONS you see them ready for import on the DEV tab.
                  This is the case because CMS has an inbuild connection between the CONS and the DEV workspaces so that you can transport your fixes back from CONS to DEV immediately and avoid double maintenance and recurring errors.

                  Scenario 2: You have configured the same runtime system for DEV and CONS – correct? When you develop in DEV you activate the automatic deployment for DEV and when you fix in CONS you change the configuration accordingly.

                  I suppose you need to consider the following: The automatic deployment is connected to the activation step in the IDE. So this means that you need to change your configuration before you activate your changes in CONS. The NW JDI also calculates if the changes you made need a rebuild of the sources. Only if the DCs are rebuild they will be deployed after the activation.
                  You can see when your DC has been last deployed in the development configuration perspective on the active DCs tab. Choose your DC you want to check and choose “Central deployment log” in the context menu.

                  You need to access of your CONS changes directly after activation! Do not import your activities into DEV because that is independent of the automatic deployment and will overwrite your CONS changes immediately.

                  I’m afraid there is no different URL, you need to monitor very closely when you deploy what state of your appliacation and be aware the deployment on import cannot be deactivated by disabling the automatic deployment after activation.

                  Good luck!

                  Regards,
                  Günter

                  (0) 
  4. Sistemi Open SAP
    Hi Guenter, yes….:-)

    Please, I need another clairifications:

    I need to maintain the version 1.0 of one SC while the ver 2.0 is in progress of develop.

    To do that I created a DEVLP track and also a MAINT track, connected to
    the first by a Repair connection.

    After forward the approved SC ver. 1.0 to the MAINT track we want to start to develop the ver. 2.0 of this SC.

    As I understood I have to develop this new version 2.0 on the same DEVLP track where I created the previous ver. 1.
    BUt that track is assigned into the CMS to SC version 1.

    1) I need to clarify if to start to develop the ver. 2 I have to define a new Product ver. 2 and a new SC ver. 2 into the SLD, and then I have to update the DEVLP track, removing the SC ver. 1 and adding the new one
    ver. 2.

    2) When the version 2 is ready, after the assempble step, the SCA for ver. 2 will be produced.
    Suppose we want to deploy the ver. 2 on the same system where the ver. 1 of the same Product is already deployed.
    What happen ? All the object of ver. 1 are overwritten or is possible to keep both the versions active on the same runtime system ?

    Regards

    (0) 
    1. Guenter Schiele Post author
      Hi Mauro,

      1) Your assumptions are correct. My only comment to this is that it is not necessary to create a new product. A new SC definition in SLD is enough.

      2) Also this assumption is correct. Since the version number of the SC is only a label for your release counting, the objects of the SC stay the same on the runtime system. This means that the deployment of a new (technical) version of the same SC will overwrite the acitve version. I don’t know of a way to keep two versions acitve on the same runtime system.

      Regards,
      Günter

      (0) 
  5. Sistemi Open SAP
    We developed an SC on our JDI, managed by a own SLD.
    We are going to pick-up the SCA file after the Assembly step and to chck-in it into another track on another JDI landscape, not connected to the previous.

    I’m asking if before to do the check-in of my SCA on the second JDI I have to do the followig actions too:

    1) to align the second SLD with the SC definition coming from the first SLD

    2) to update the track where the SCA file is supposed to be checked-in with this SC

    THe SCA we will checkin is supposed to be distributed in more systems into the target JDI landscape.
    If we do not align the target JDI and the target cms track I’m not sure we will be able to move this SCA into the target landscape using the CMS functionalities, but I’m not sure of that.

    Regards and thans in advance

    (0) 
    1. Guenter Schiele Post author
      Hi Mauro,

      you are correct: To configure a track into which you can check-in the assembled SCA you need to align the second SLD with the content of the first one and the update the second CMS with the new SLD content.

      CMS checks if the SC is configured in the track before you can check it in.

      I hope this answers your questions.

      Regards,
      Günter

      (0) 
    2. RK RK
      Hi Guenter,

        I got a query regarding the transport to multiple systems. couldnt find the solution yet.

      I created a track DEV – QA – PROD and it is working fine.

      now i have a requirement in which i got a couple of other servers (EP1 AND EP2) , where the changes should be deployed to them too.

      I have the following questions:
      1. should i create two seperate tracks, one for EP1 and another for EP2 or would one track including these two is enough

      2. whether it is two tracks or one track for these systems, EP1 AND EP2, what should i enter when creating the track for “Software Components for Development” and “Required Software Components” sections?

      Thank you

      (0) 
      1. Guenter Schiele Post author
        Hi Raj,

        You are refering to the scenario with production tracks see the online help:
        http://help.sap.com/saphelp_nw04s/helpdata/en/42/f1a03611d83ee4e10000000a1553f7/content.htm

        To answer your questions in short:
        1. Yes, create two tracks. Otherwise the systems will always get the software one after the other but not at the same time.

        2. Leave the table “software components for development” empty and add all software components you want to deploy on the systems to the table “required software components”.
        (also leave the input fields for DTR URL and CBS URL empty).

        Best regards,
        Günter

        (0) 
  6. Anonymous
    Hello,

    I am creating a webdynpro application in studio.In order to have the webdynpro component available in GP, i am expected to add caf/eu/gp/api DevelopmentComp.
    I received an online doc, which showed how to create a DevelopmentComp.
    Here, we come across development config and software components.
    We obtained NWDI, and the tracks for developer and admin were created.

    Now to be able to have caf/eu/gp/api dc added to our project we are expected to build it over the SC “SAP-EU”.

    We added this to our track in CMS-landscape config.But, still caf/eu/gp/api DC is not listed under SAP-EU.

    Can anyone give me more information on SoftwareComponents(esp SAP-EU )?
    How to configue the DC’s under this software component?

    Thanks,
    Sharath

    (0) 
    1. Guenter Schiele Post author
      Hi Sharath,

      I guess you need to take a look at the SAP component model which is documented in Component Model.

      In short: In order to develop your web dynpro you need
      1. create a software component (SC) for your development under which you will create your DCs in SLD
      2. configure usage dependencies for this software component in SLD (especially SAP-EU but also the other SCs that are required for CAF).
      3. Update CMS
      4. check-in and import all required SCs in your track
      5. download the development configuration and start developing.

      I hope this is of help for you.

      Regards,
      Günter

      (0) 
  7. David Keiser
    Hello,

    I have created a new SC in SLD for a Java web dynpro application. I’d like to know for this application, what are the prerequisite SCs for development, i.e. what will be needed to build the WD application once you import the config into NWDS, create a DC, etc.

    Thanks in advance!!
    Dave K.

    (0) 
    1. Guenter Schiele Post author
      Hi David,

      the required software components (in SLD) are
      – DI Build Tool (SAP_BUILDT)
      – SAP Java Technology Services (SAP_JTECHS)
      – SAP J2EE Engine (SAP-JEE)

      Define usage dependencies to those software components in SLD and the perform Update CMS.

      Regards,
      Günter

      (0) 
  8. Shubham Tripathi
    Hi Guenter,

    First of all, I will thank you for your blog that clarified most of my doubts about transports.

    I have one more doubt.

    We have a NWDI in our company that has only DEV and CONS system.

    We want to transport a complete track containing all our WebDynpro Developments from our company development WAS to the customer development WAS since the customer owns the source code of our WebDynpro Development.

    Can this be done? If yes how? If no any workarounds for the same.

    Thanks & Regards,
    Shubham

    (0) 
    1. Guenter Schiele Post author
      Hi Shubham,

      it depends on what you want to do.
      If you only want to deliver the source code to the customer, you could perform an assembly with a configured package type “Source” or “Source and Archive”. This would provide your customer with the sources of your SCs.

      If you want to move your DTR to the customer site and get rid of the content at your site, you would need to do a system copy.

      A system copy for NWDI is possible as of NW 04 SPS 15 or NW 2004s SPS 07. You find more information about system copy in the SAP note 870863 (for NW 04s) and SAP note 785848 (for NW 04).

      Best regards,
      Günter

      (0) 
      1. Shubham Tripathi
        Hi Günter,

        Thanks for your reply.

        Actually I have one more issue here. We are on NW04 SP12 and since we have done all the development on SP12 we cannot upgrade to SP15 at this point of time. So a system copy is not possible.

        So we need to look at the option to obtain a ‘sca’ file for our development. How to get the same? When I assemble components, does it assemble all the requests including the old ones that were assembled earlier or only the delta? If it assembles only the delta, how to get a sca for the all the requests.

        Thanks & Regards,
        Shubham

        Sorry for responding late

        (0) 
        1. Guenter Schiele Post author
          Hi Shubham,

          an assembly always assembles the whole sc. So the SCA contains the latest state of your software that is active in the consolidation system.

          You find the resulting SCA of your assmebly in the transport directory of you NWDI, but i assume that you know this.

          Regards,
          Günter

          (0) 
  9. Anandaraj Velmurugan
    Hi Günter,

    This is a great thread and for me it is very timely.

    I have a question about how this would work if we have more than 1 SLD in our landscape. We plan to have 1 SLD for production and another for DEV,QA,etc..

    1. How do you see this NWDI/Tracks would work if there are two SLDs
    2. Can we or is there a process that NWDI offers to trasport SC,Product (and other SLD) defintions between two SLDs…

    Thanks,
    Raj Velmurugan

    (0) 
  10. Jayson Xiao
    Hi Guenter

    first thank you very much for your blog, this is a very good article that clarifies my doubt about the complete dev landscape. However I still have one quesiton.

    Let’s say we have complete the dev phase and correction phase. Now it’s time for real test in the test system. Thus the SCs are imported into Test system from the consilidation system. In the test phase normally the business people come in for test from their aspect. Of course in this phase the busniess people will find isssues and bugs, those issues and bugs will be given back to dev team for correction which should be done in the consolidation system. Those changes will be available in the test system only after re-imported of the corresponding SCs containing the corrected DCs. However this re-import is NOT a small action, it takes time (up to one hour sometime). Therefore the re-import might only be done once per day or even less frequently. However for the business people, they are assinged to the test task for limited time, let’s see three weeks, once they found problems, they want to test the correction as soon as possible, they can NOT wait for one day to see the corrction. So my quesion is:
    How can we make the correction done in the consolidation system available to the test system during the MIT test?
    Be aware the business people is doing the MIT in the test system, dev team can fix the problem within two hours normally, and business people wnat to test it right away after the fix, which means we need to make hte changes done in hte consolidation test to Test system on fly, is it possible?

    Many thanks
    Jayson

    (0) 
  11. Jayson Xiao
    Hi Guenter

    first thank you very much for your blog, this is a very good article that clarifies my doubt about the complete dev landscape. However I still have one quesiton.

    Let’s say we have complete the dev phase and correction phase. Now it’s time for real test in the test system. Thus the SCs are imported into Test system from the consilidation system. In the test phase normally the business people come in for test from their aspect. Of course in this phase the busniess people will find isssues and bugs, those issues and bugs will be given back to dev team for correction which should be done in the consolidation system. Those changes will be available in the test system only after re-imported of the corresponding SCs containing the corrected DCs. However this re-import is NOT a small action, it takes time (up to one hour sometime). Therefore the re-import might only be done once per day or even less frequently. However for the business people, they are assinged to the test task for limited time, let’s see three weeks, once they found problems, they want to test the correction as soon as possible, they can NOT wait for one day to see the corrction. So my quesion is:
    How can we make the correction done in the consolidation system available to the test system during the MIT test?
    Be aware the business people is doing the MIT in the test system, dev team can fix the problem within two hours normally, and business people wnat to test it right away after the fix, which means we need to make hte changes done in hte consolidation test to Test system on fly, is it possible?

    Many thanks
    Jayson

    (0) 
    1. Guenter Schiele Post author
      Hi Jayson,

      the easiest and fastest way to test the fixes would probably be to attach a runtime system to the consolidation location and test directly in the consolidation system.
      There you would have direct deployment when your developers activate their fixes.
      The prerequisite for such a process is that you exclusively do your fixes in cons and that you are aware that continuous activation by several people can destabilize the software state.

      However, I don’t know if this is feasable for your QM process. Unfortunately there is no way to speed up the assembly process (except to invest heavily in hardware).

      I hope this helps in your task.

      Regards,
      Günter
      (0) 
  12. Rajeet Mathur
    Hi Guenter,

    Thanks so much for your blog. It was really very informative. I just needed some clarification.
    We are on JDI 7 SP12 on HPUX 11.23. We need a small clarification on our NWDI track as we are currently stuck with a requirements wrt to NWDI.

    Presently, We were having a 5 systems SAP CRM landscape. CRM Dev(CED), CRM IST (CEI), CRM U (CEU), CRM Q (CEQ) & CRM P (CEP).

    We have developers who work for Live Production system for bug fixes and other who work for the new project developement work.

    We are planning to configure our 5 System landscape in the below way to ensure that both the New Development and the bug fixes can happen simuntaneously.

    We are planning to create 3 tracks in total.
    There would be a 2 master tracks, Development track & a maintenance track.

    The Dev track would have the CRM Dev (CED), CRM IST (CEI), CRM UAT (CEU) defined in the Dev, Cons & the Test Runtime systems respectively.

    The Maintenance Track would have just one run time system. That is the CRM Q (CEQ) system defined in the Dev Runtime System.

    A Track connection (type repair) would be made from the test system of the Dev Track to the Dev system of the Maintenance track.

    Similarly a back track connection would be made from the Dev runtime system of the maintenance track to the Dev runtime system of the Dev Track.

    Then we would create a 3rd Track with only the CRM Prod (CEP) instance defined in the Prod runtime system. This track is connected to the Maintanence Track and a track connection of type transport is created between these 2 tracks. No track connection is made between the Dev Track and Production Track.

    With this approach, all the bug fixes, can be fixed with the Maintanence track & parallely the new development can happen in the Dev Track.

    We also believe that this would solve our issue during upgrade of our CRM landscape as we can use the Maintanence track for issues and parallelly the other systems in the landscape would get upgraded.
    Can you please confirm whether our understanding is correct or not. Kindly suggest
    Thanks in advance for your inputs.

    Warm Regards
    Rajeet

    (0) 
    1. Guenter Schiele Post author
      Hi Rajeet,

      so far, I think your track layout makes sense.
      The only question I have regarding your outline is the following:

      Why do want to create a connection of type “repair” from the DEV track to the MAINTENANCE track?

      The suggested connection in the above article is using the “transport” connection between DEV and MAINTENANCE to advance the latest changes in Development to the maintenance phase.

      Other than that I think you’re set.

      Best regards,
      Günter

      (0) 
  13. Sateesh Chandra
    Hi Guneter,

    This is best blog I ever found on NWDI landscape.
    I need some tips to work out for a solution.

    I am developing a custom E-commerce application I have encounterd with to problem to go ahead.

    My secnario is this

    I have three DC’s named DC1, DC2 and DC3.

    DC1 have build dependencies on DC2 and DC2 have build dependencies on DC3.

    I have created an activity to make changes in DC1 and DC2. I released the activity and it is deployed.

    Now I have to make changes in DC3 (I have to develop in this order only first DC1,DC2 and later DC3).

    I also created an activity for DC3 and released.

    Now my request is I should see the changes in DC1. Since I am not updating DC1 (changing of files in DC1) I need not to create an activity.

    If I just update (rebuild and deploy) this is enough for me.

    Here I should let you know two things.

    1)      I can only create, modify and release an activity which will auto deploy the application

    2)      I don’t have an access to local J2EE (Only I should create and release activity)

    Please advice me How I will be able to achieve this.

    Regards,
    Sateesh Chandra

    (0) 
    1. Guenter Schiele Post author
      Hi Sateesh Chandra,

      let me quickly rephrase what you wrote so that you see whether I understood your question correctly.

      You have created/developed DC1 and DC2 in one activity, activated and released both of them and they were automatically deployed on the Development System of you NWDI landscape.

      Now are developing DC3 that has a buildtime dependency on DC2. You have created an Activity for this and now you ask me what is going to happen when you check it in and activate it.

      First of all let me tell you the following: The automatic deployment takes place directly after activating an activity in the NW Developer Studio if there is a runtime system configured in the Development System of your Development Track.

      So when you check-in and activate your DC3 it will be deployed automatically on the development runtime system. Since DC1 and DC2 have been deployed already, DC3 will be added to the runtime environment and you should be able to see your changes.

      What I don’t understand is what you are expecting to see in DC1 after the deployment of DC3 if there is no change in DC1?

      What I probably need to add here is the fact that automatic deployment will only be triggered if your DC3 contains deployable content (e.g. an ear-file).
      The automatic deployment is done via CMS of NWDI. So your user is not used for system communication and deployment authorization.

      I hope this answers your questions. Let me know if there is more that you need.

      Regards,
      Günter Schiele

      I hope this answers your question

      (0) 
  14. Rajeet Mathur
    Hi Guenter,

    Thanks for your reply.

    Just another help. Right now, we have another requirement, where in apart from  the existing CRM 5.0 Systems, we need to add a separate 5 Tier Landscape of CRM 7.0 Systems (FRD, FRI, FRU, FRQ & FRP) in the same NWDI instance.

    Do we adapt the same approach for new CRM systems and make 3 separate tracks (One for Dev, one for Maint &  one for Prod). So, with the 3 systems, we would be having in total 6 tracks. This means we will have the same web applications available in different versions.

    If this is not the right approach, can you please be so kind to suggest the best practice.
    Also, is there any inter dependency here (namespace, versioning, etc.)? Is there anything we should be careful of to ensure smooth functioning of NWDI & Java Transports across all the landscape with different web applications catering to different business units?

    Thanks a lot for your support.
    Good Day.

    Warm Regards
    Rajeet

    (0) 
    1. Guenter Schiele Post author
      Hi Rajeeet,

      if you intend use a similar landscape for CRM 7.0 development as for CRM 5.0 I think this will be fine.

      As far as I can see it there are going to be no problems with regards to different web apps catering to different business units.
      By managing your development and maintenance in this kind of landscape, the NWDI takes care that there is no mixup in the versioning and namespace.

      The only thing is the runtime part where you should be careful not deploy different versions of the same web applications to the same runtime system. But I think that you also took care of this by using CRM 7.0 systems that are different from the CRM 5.0 systems.

      Best regards,
      Günter

      (0) 
    2. Srinivas Eligati
      Hi Guenter,

      This topic on NWDI is very informative with different scenarios.

      Now I am experiencing an unique problem with the NWDI after configuration of CMS and creation of tracks.

      When the users transport the ‘dc’ objects they directly getting under the ‘Consolidation’ tab of CMS-Transport Studio rather then coming under ‘Check-In’ or ‘Development’ Tab. Even after configuring the Runtime System as ‘Development’ still the import queue is shown under ‘Consodidation’ and empty under ‘Development’ tab.

      We are on NWDI – SP15 with Dual Stack.

      regards
      Srini

      Just another help. Right now, we have another requirement, where in apart from the existing CRM 5.0 Systems, we need to add a separate 5 Tier Landscape of CRM 7.0 Systems (FRD, FRI, FRU, FRQ & FRP) in the same NWDI instance.

      (0) 
      1. Guenter Schiele Post author
        Hi Srini,

        you are not experiencing a unique problem, but usual behaviour of NWDI.

        The point is that your development in the NWDS represents the “development location” of your track. Everything you develop there is deployed to the Development runtime system on activation after check-in. (If you have configured a runtime system in DEV.)

        When you release your development on the Transport View of the NWDS you have already completed the development stage and move on to the consolidation stage in your lifecycle. Therefore you see the released activities appear on the consolidation tab of the Transport Studio.

        I hope this clarifies your situation.

        As to your second question: You can add additional systems to your track landscape by connecting another track to your CRM 7.0 track.
        Either use a second development track or add a so called “production track”. For more information see the online documentation under
        Development Landscapes and Runtime Systems. There see also the link to “Automated Deployment into Multiple Production Systems”.

        Best regards,
        Günter

        (0) 
  15. Sunitha Subbarao
    Hello Guenter,

    Thank you for your weblogs. They are very informative. I have few questions regarding our landscape here. We have different kinds of developments going on here (Webdynpro development, Visual composer etc). We had NWDI running on 6.40 earlier and now we have completed the upgrade to the NWDI on 7.0. We now need to move all the SCs to the new environment. Before that, I want to get your suggestion in creating tracks for our requirement here. Could you please let me know, if it is required to have separate tracks for different type of developments – meaning one track for Visual composer, one track for Webdynpro development etc?

    could you please provide us your recommendations on this?

    Thanks.
    Sunitha.

    (0) 
  16. Bishnu Priya Sahoo
    Hi,

    I have a Track for development of a Custom web dynpro application which had three DCs.

    Now I have a new requirement of Creating a Portal DC and it requires the addition of KM SCs to the track.

    What should be the ideal approach ,creating a new track for the Portal DC or using the existing track by updating it with new KM SCs.

    Regards,
    Bishnu Priya

    (0) 
  17. Bishnu Priya Sahoo
    Hi,

    I have a Track for development of a Custom web dynpro application which had three DCs.

    Now I have a new requirement of Creating a Portal DC and it requires the addition of KM SCs to the track.

    What should be the ideal approach ,creating a new track for the Portal DC or using the existing track by updating it with new KM SCs.

    Regards,
    Bishnu Priya

    (0) 
  18. Bishnu Priya Sahoo
    Hi,

    I have a Track for development of a Custom web dynpro application which had three DCs.

    Now I have a new requirement of Creating a Portal DC and it requires the addition of KM SCs to the track.

    What should be the ideal approach ,creating a new track for the Portal DC or using the existing track by updating it with new KM SCs.

    Regards,
    Bishnu Priya

    (0) 
    1. Guenter Schiele Post author
      Hi Bishnu Priya Sahoo,

      sorry that this reply took quite long. I was on vactation and only came about the notification just now.

      Regarding your setup.
      If this new Portal DC is part of your product that you develop in the Software Component (SC) that conatains the WD DCs then I would do the following (assuming you are working in an NWDI 7.00 SP 13+ setup):

      1. In SLD: Enhance the build time dependency definiton of your SC with the new required KM SCs.
      2. Update your CMS on the domain tab.
      3. Edit your track by doing the following:
      3.1. Delete your SC from the track definition
      3.2. Add your SC to the track again. It will now contain the new dependency definitions of your SC.
      3.3. Save the new track configuration.
      4. Import the new KM SCAs in the Transport Studio.

      (The deletion of the SC from the track does not remove or delete your sources from the DTR workspaces – therefore the reconfiguration won’t harm your running implementations).

      Best regards,
      Günter

      (0) 
  19. Anonymous
    Hi Günter!
    Congratulations for your article. It is very well written!

    I’m new to NWDI, and i’m currently lost on the systems keyword. I’ve seen that i can configure systems on the following places:

    -TMS (ABAP or non-ABAP systems).
    -SLD (Technical systems, Business systems).
    -CMS (Runtime systems).
    -Solution Manager (synchronization of SLD or TMS systems).

    Now, i can’t understand what is the purpose of all these definitions. I’ve seen how to define transport routes on TMS, but i can’t understand how it is related to the tracks transport routes, and where the techincal systems enters in this game.

    Can you clear the things to me please?

    Thank you

    (0) 
  20. Neeraj Jain
    Hi Guenter..

    This is a very good blog & clears NWDI concept.However I am facing a issue and need your view on it.

    I have a question regarding the NWDI migration. Our scenario is like this..
    We have NWDI installed on host ABC & using track Track1 for phase1. We released the actvt from NWDS & deployed it on Dev & consolidation system configured in track but not on production.

    Now we moved the track from one host to another host(system copy) but after moving the track we are not seeing the SC in assembly tab. Is there any way such that we can use the Cons workspace & create a sca file and deploy it to production.

    Other way is to create a new actvt for all dc and release them again but this will take lot of time as there are 40-50 dc’s. Is there any workaround for this?

    Regards,
    Neeraj

    (0) 
  21. Felipe Forero Guzman
    Hello Guenter, good blog !!
    I read it before but now I have a question related to the “Develoment and Test” phases, and I think this is the right place to ask it !

    I always promote the use of a Local_AS, but not all developers have one installed on their machine either because their computers doesn´t acomplish technicall requirements or because some how the server one day didn´t start again.

    So, while the developer fix his Local_AS problem, they most use the ‘Development Runtime system’ to develop and test. Then the question is:

    Should I make a direct deploy on the ‘Development Runtime system’ to make a test (like making a local test), or, each time a make a test I should checkin and activate the activity am working in ?

    I would like to have a straight answer like:
    1. “yes you can but you should note that making direct deploys can lead to differente states of the app.”.
    2. “yes you can but it can bring ther server down when more than one developer makes direct deploy”.
    3. “yes you can but I sugest not to do it because……”.
    4. “Noooooo, you should never ever make a direct diploy while using NWDI because…”.
    5. “….”

    Many thanks
    Felipe

    (0) 
    1. Guenter Schiele Post author
      Hi Felipe,

      I think options 1 and 2 apply.
      You can use the central test system for direct deployment, but you need to be aware that the direct deployments can interfere with each other and might constantly change the state of the app on the test server.

      To avoid this the idea of NWDI was to provide the central deployment mechanism via check-in and activation. In this case the deployments are queued and you always have the latest check-in state of the app on the system.

      However, I agree that this slows down the development process and it might be easier to do the direct deployment to the central test system.

      Therefore I don’t want to discourage you from directly deploying but you need to be aware of the risks – as you obviously are.

      I hope that helps.

      Best regards,
      Günter

      (0) 
  22. Amanda Perez

    Hi everyone,

    I have a problem in my company exist two persons working with different DC but in the same track. The issue occurs when the activities of this two people was published in QAS but just one of this DC was ready for deployment in Production the other dont. And when the basis team did deploy there gone all the changes that was published, i mean the two activities that was published. My Answer is there is a way that can separated this activities

    Best Regards

    (0) 

Leave a Reply