Development Landscapes and Runtime Systems 

Use

One of the most important features of the SAP NetWeaver Development Infrastructure (NWDI) is that it can handle many development projects in one central system; furthermore, NWDI works independently of the release under which the software is being developed.

But to develop software, you need runtime systems for testing purposes and for the productive system. These systems are not part of an NWDI (usage type Development Infrastructure (DI)) installation. Runtime systems for runtime objects to be deployed to can be chosen freely in the NWDI track configuration.

Prerequisites

The SAP NetWeaver Application Server on which the NWDI is deployed and the NWDI software itself are on the same SPS level.

Activities

In an NWDI track you can name runtime systems for the following phases:

●      Development

Deployment takes place on a DC-level based on activities that developers activate. This is used for early integration test by developers. Deployment can be defined to take place automatically when sources are successfully activated.

The advantage of having a central runtime system for this phase is that all developers deploy to one system immediately at activation: every single developer finds all other parts of the application deployed by his or her colleagues and does not need to worry about it.

Bear in mind two things: if more than one developer works on the same DC the deployed version will be overwritten by the latest deployment. The system state in respect of the deployed versions changes constantly.

●      Consolidation

Here, deployment takes place on a development component (DC)-level based on activities that developers release. Integration tests for the consolidation system are possible here also. You can choose to allow fixes in the consolidation system.

This runtime system may be used so you have a system that is independent of the runtime system Development, so that development and consolidation also go on independently.

Deployment can be defined to occur automatically when sources are successfully activated. (Activation is triggered automatically when change requests are imported.)

The advantage of a runtime system in this phase is that deployment can be controlled by the administrator who steers the import of released objects – therefore, the system state remains stable as long as needed.

●      Test

Here deployment of software component archives (SCAs) is done in exactly the same way as in a productive system.

Deployment works at the import step.

●      Production

Here the software is used productively, so it may be omitted by software vendors who do not use it productively. In case you need more than one productive system, see Automated Deployment into Multiple Production Systems.

Deployment works at the import step.

Even though the NWDI can host many different releases of software projects, the release is important for the development environment (defined in a track).

These are some rules for using runtime systems:

●      You use one NWDI for different releases. The NWDI should not be older than the newest platform you develop for. We recommend that you use the latest NWDI release available.

●      Tracks are release-specific. Developer Studio, used archives and the runtime must be the same release.

●      Runtime systems can be the J2EE Engine’s instances on one physical server or on several servers.

●      If you want to reuse the NWDI runtime, see SAP Note 737368.

●      You can deploy software components (SCs) from different tracks into one runtime system if all used SCs are of the same version.

If these rules are fulfilled, you may also put all SCs for development that are based on the same release of used SCs into one track (so that you get one track for each release).

Example

The runtime systems you need depends on your situation: for example, your development team may use the SAP NetWeaver Developer Studio with a local J2EE Engine (as a Developer Workplace) or without one.