Tools for analyzing, designing and encoding software are required to develop applications and maintain them throughout their lifecycle. It is also essential to have an infrastructure for managing program codes and supplying specified versions of generated programs in development, test and production landscapes. An easy-to-use system for transporting programs from Java to ABAP was already integrated in SAP solutions. Now, with the launch of the SAP NetWeaver Development Infrastructure (NWDI), ABAP applications can also be developed in Java environments.
Component model instead of object model
With its SAP NetWeaver Development Infrastructure, SAP is offering its customers a complete solution. It comprises both local components to be installed on the developer’s PC and central infrastructure services. All the components were developed in Java. The services can be hosted by multiple SAP NetWeaver Application Servers (SAP NetWeaver AS). Several servers can also be combined into clusters to improve scalability. To help the developer, all the development tools have been integrated in the SAP NetWeaver Developer Studio.
The basis for developments with NWDI is a component model which divides the software to be developed into different levels. The component model represents an extension of the previous object model. An ‘object’ is a software-mapped logical unit from the real world with all its attributes, methods and functions – for example, an order, invoice or confirmation. The components combine several related objects into a logical software package. An example of such a package is a mask in the HR department employed as a user interface, the link between this interface and the HR solution, and the functionality of this mask. The component model supports the IT processes required to develop and modify software quickly and without errors.
The SAP development landscape is divided into three areas, namely development, test and production. This prevents protected corporate or personal data from being transferred from production into the development system. The objects are initially created in a development and consolidation landscape in which developers use demo data. This data is then transferred to the test landscape. This gives the employees who will later be using the applications in practice the opportunity to test the functions from a business management perspective. Following successful test runs and approval, the objects are ready for live operation.
Because the source code had to be converted for each object, the software logistics process of moving from one development cycle to the other – from the development landscape to the test landscape and finally to the live landscape – previously required a lot of time and effort. SAP’s component model speeds up and simplifies these tasks. NWDI supplies developers with appropriate tools in the development environment to assist them in their work. The procedure is based on the Eclipse open source development project. While Eclipse requires the tools to be manually compiled on each PC, the SAP development environment considerably simplifies this process. Depending on the development project – for example, a portal or a J2EE project – the developer is provided with a preconfigured and defined set of tools required in the development environment. He can therefore start work immediately. The tools incorporate individual development objects such as Java classes and Web Dynpro components. They also define the build environment to enable the source code to be compiled for each type, such as for Enterprise Java Beans (EJB), Web or Web Dynpro, and to be saved in an orderly fashion in libraries.
Creating software components
NWDI-based development can be divided into several steps to be carried out by people with different roles. In addition to the developer, these include software architects, landscape administrators to maintain the application landscape, and transport and quality managers. Within the SAP development environment, it is also possible for one person to combine several roles.
Each development begins with a new product or a new version of an existing product. These are maintained in a directory service for hardware and software, the System Landscape Directory (SLD), in which namespaces can also be reserved. The administration of the installed software components and their dependencies improves the transparency within the system landscape including hardware and software. This makes it easy to determine which products and components are installed in which versions and on which servers. The administration of namespaces relates to the prefixes for database tables and development components which the developers create during programming. Names for Java packages are assigned according to Java conventions. Depending on the product definition, either completely new or existing software components must be created and assigned.
Once all the necessary software components have been created, a development track can be created in a second step using the Change Management Service (CMS). A variety of software components are assigned to this ‘development track’. These include the components created during implementation and those required as a library. Developers incorporate the development components in the software components to be developed, which are later used as the project and build environment for the actual programming. This marks the end of the preliminary work on a development.
The process of implementing the actual functionality now begins. To do this, the developers log onto the NWDI and connect to the development track. This means that they have a standardized work area with references to the source code and the necessary libraries. This information is used to create a local copy of the work area on the developer’s PC.
During the programming process, the developers create development components and fill these with development objects such as Java classes and Web Dynpros. The latter enable the creation of dynamic HTML in Java. The required functions are created in iterative programming, local build, compilation and test processes. Once development has reached a certain stage, the development objects are transported into a version management system known as the Design Time Repository (DTR).
Version-specific source code and other resources such as text files and images are stored in the DTR. Typical version control tasks, such as checking in and out, updating local versions and identifying and solving version conflicts are combined into activities in the DTR. This makes it easy for the developer to see which changes belong together. One special feature of the DTR is its ability to manage changes in several repositories. If the DTR is used, the NWDI always sets up two areas – one active and the other inactive. Only after a successful server side build are the resources transferred from the inactive to the active area.
Due to the fact that the Design Time Repository, like a transport assignment, combines a number of changes into a single activity, several objects are usually checked in at the same time. Up until the point of activation, all the objects remain inactive and can only be explicitly accessed by the developers using the development tools. To enable access to all checked-in components on the development, consolidation, test and production systems, they must first be compiled. This is done to prevent incompatible source code from being checked in and to avoid the resultant inconsistency. Compiling can be carried out separately by activating the objects.
Preventing compiling errors
In a further step in the activation process, the newly checked-in development objects are compiled on the server together with the activated development objects already stored there and the libraries assigned to the project. The Component Build Service (CBS) is used to carry out this step. This ensures that the changes of all the developers can be compiled without any errors. This process prevents changes which result in compile errors in other components. It also ensures that a change to one module is consistent with the other modules. Moreover, parallel changes are made in a serial fashion since they are processed in the sequence in which they were checked in.
If the compilation is successful, the changes must be added to the activated program code. The activation process can begin immediately after check-in so there is no need for the normal nightly builds. Following a successful build, the checked-in code is transferred to the enabled area, which can be used by all the developers, and installed on the development server.
The development can be completed step-by-step via local development and consolidation processes using CBS. Developers then transfer the built software from their local PC to the shared development system. The automatic transport system integrated into the Change Management System is used to install the software components on the other systems. Like the development system, the consolidation system contains source code and provides patches to rapidly correct programming errors. Binary fragments are created for transport to the test and live systems and are packaged in the Software Deployment Archive (SCA/SDA). Manual transport via Software Deployment Manager (SDM) is possible.