NWDI Overview and Guidelines

[Former Member]

NetWeaver Development Infrastructure (NWDI)

If you are working with a single, local Web AS Java, you can immediately deploy and test your newly developed applications on this server, and it is also possible to control this server directly from the Studio. However, you can also easily integrate your work into a larger setting, be it a team of developers you cooperate with or a network of systems along a delivery track. This is because all the tools in the SAP NetWeaver Developer Studio are linked to the components of NetWeaver Development Infrastructure (NWDI), which supports development in arbitrarily large projects. No matter what type of entity you are building, you can:

• Organize your development items in Software Components (SCs) and Development Components (DCs)
• Exchange DCs with the Design-time Repository (DTR), which is responsible for source-code management
• Delegate the build process to the Component Build Service (CBS) that runs a central build, automatically using all the latest library versions, and
• Trigger the transport of completed DCs to the next level of system, e.g. from development to test, and from test to release systems (CMS).

The NWDI in its full version will contain: a source repository (Design Time Repository, DTR), a deployment tool (Software Deployment Manger, SDM), a service to guarantee uniqueness of names (Name Service), the Component Build Service (CBS) for a central build, and the Change Management Service (CMS) to set up development landscapes and handle all steps in the software life-cycle. The Java Dictionary supports the global definition of tables and data types.

Using a central infrastructure reduces development time and completeness by providing a consistent environment for the whole software life-cycle.

Development Scenarios

The development in the NWDI provides for several scenarios.

• 1.Team-Oriented Development - Development in smaller teams. Here the DTR is used as a source repository to synchronize the work of the developers. In this scenario Java and J2EE based applications can be developed.
• 2.Development with Components - Development according to the component model. Again the DTR is used. In this scenario development configurations are used. Using a Name Service is recommended. CMS and CBS may or may not used in this scenario. In case no CMS and CBS are used, simpler utilities are available to cover their functions. Besides Java and J2EE, Web Dynpro applications can also be developed.
• 3.Layered Development - is meant for big development teams with full-scale administration in the CMS. This eases simultaneous development of more than one software component that depends on each other. Synchronization of the team work is also done on archive level by use of the build support by the CBS. The full software logistics are in place.

The SAP NetWeaver Developer Studio not only provides toolsets for various requirements in Java development based on appropriate SAP project types; its really special feature is its full integration within a robust SAP development structure.  The combination of both aspects makes the Developer Studio a highly productive and comprehensive development environment that covers the entire development cycle of Java projects. The advantages of this solution become particularly evident during the creation of extensive, server-based business applications that require large developer teams.

Restriction: The combination of Web Dynpros and portal objects in the same package is possible only if the Web Dynpros are executed on the portal’s J2EE cluster.

!!!!

The current NWDI implementation doesn't have an incremental build. This basically means that if an activity is activated the CBS will build all DCs affected by the activity and all other DCs that depend directly or indirectly on these DCs. If the change affected a "popular" DC this could well mean that the CBS will rebuild the whole build space.

From a more theoretical viewpoint this is also an indication for a sub-optimal design. If you have single components that can affect the whole product you also have a very obvious point of failure, which means that these component must either be carefully developed and heavily tested or it could easily cause a breakdown of the whole thing.

What you need in order to start working with NWDI

• Installed a complete NWDI (CMS, DTR, and CBS) on a J2EE Engine.
• The recommendation is to use three J2EE Engines: for integration tests, for quality assurance, and for production use of the application BUT if your project is in the initial phase and you do not have QA and production environment, one J2EE Engines is enough.
• NetWeaver Developer Studio in each developer desktop. It is also recommended to install local SAPJ2EE on each developer desktop for local test purposes
• You have write authorization in the System Landscape Directory (SLD) and configure the URL of the System Landscape Directory (SLD) in NetWeaver Developer Studio

Design recommendations

You should:

• Separate implementation from API, ideally putting these into two separate DCs.
  an API should hopefully be rather stable, at least more stable than its implementation. Thus bug fixes to the implementation won't force a rebuild of DCs that use the API.
• Try to keep things down to the bare minimum. This also means that you should be as specific as possible. E.g. if you add a Used DC to your DC you should specify exactly which public part you require and when you require it (design time, build time, deploy time, runtime)
• Create own DCs for reusable parts, e.g. Java libraries that are used in two different deployment scenarios: create a Java DC that contains the actual implementation. Then you can create a J2EE Server Component that includes the library for deployment and you can also create a Eclipse plugin that uses the same Java code, etc.

As a more drastic approach you could split up a project into different tracks, thus isolating the interfaces between the components even more.

Development Process

1. Create Projects and Download Development Components

• open the Inactive DCs View in the Configuration Perspective
• select the DCs you want to modify
• choose Create Project from the context menu
• this action
  • downloads the sources of the selected DCs from DTR in the inactive (modifiable) state
  • downloads the archives of used DCs from CBS (if these DCs are available in active state)
  • downloads the sources of used DCs from DTR if the used DC exists in inactive state only
  • creates an Eclipse Project for the selected DCs
  • triggers an initial local build of all DCs that were downloaded from DTR as source code

2. Make Your Changes

• Modify sources to apply a change e.g. fixing a bug or implementing new functionality
• check out all files you want to modify
• when checking out you have to specify a DTR activity
• DTR activities group your changes and isolate them from other developer's work until you check it in
• modify the checked out files using SAP Net Weaver Developer Studio.

3. Build and Test

• do a local component build by clicking the menu entry Development Component /Build
• test your change locally (e.g. deploy your modified application on your local J2EE engine using the deploy action on the ear file from the J2EE DC explorer)
• test your application locally

4. Check In Inactive Changes

• if the tests are ok, you may check in the activity
• select the activity in the Open Activities view and choose "check in" from the context menu
• the change is now visible in the inactive workspace
• it is now available for all developers who want to use the inactive state of your DCs
• normally the inactive state would only be shared with developers who work closely together in the same team
• if different developers make changes that depend on each other, both developers can iteratively change and synchronize from inactive state until the change is complete.

5. Activate Your Changes

• select the activity in the Activation View and choose "activate" from activation view
• a activation request is created on the CBS
• you can monitor the progress of your request in the activation requests view
• during activation the CBS tries to centrally build your modified DCs
• If the build is successful (no build errors) your changes are integrated into the active workspace
• Your changes are now visible for all developers who use the active state of your DC. (By convention all developers who work on other components should always use the active state of your component)
• if a central test J2EE engine is defined for your development system, the new version of your successfully activated components will be automatically deployed onto this test server.
• after the new version was deployed, you can start with integration tests on the central test server

6. Release Your Changes for Propagation

• if these tests are passed successfully, you may consolidate your change from the development system to the consolidation system
• opening the Transport View (via Window / Show View / CMS / Transport View) select your activities and choose Release on your activity
• your activity is now queued for consolidation
• your activity will be imported into the consolidation system by a transport administrator
• in the consolidation system your activity will be automatically activated and deployed on the connected central test J2EE engine.

7. Testing,Debugging and Patching the Consolidated State

• In the consolidation test server, quality assurance testing is done
• you may also do further integration tests on the central test server of the consolidation system
• for debugging the consolidated state you need to import the development configuration for the consolidation system into the Developer Studio
• if necessary you may patch severe bugs in the consolidation system. This might require additional privileges. Ask your QM or system administrator how to get them.

8. Acceptance Test and Assembly

• when integration tests have been completed successfully in the consolidation system the transport administrator will create a shippable assembly of the current version of all SCs currently contained in the consolidation system
• this assembly may then be optionally deployed on another central test J2EE engine for acceptance testing
• if acceptance testing on the assembly is ok as well and the responsible QM agrees the assembly is formally approved and depending on your development landscape it is ready for propagation into another track using your SCs (e.g. an application using technology) or for shipment to customers

Appendix

http://help.sap.com/saphelp_nw04/helpdata/en/01/9c4940d1ba6913e10000000a1550b0/frameset.htm