Let’s Do Java (Part 2)

Feature Article | November 14, 2005 by admin

Part 1

Development projects are often carried out with a large number of groups spread over several sites. The programming language Java, which involves the developer working on his PC with copied development objects and local environments, requires a much more complex development landscape than a server-based environment for ABAP development. When performing their work, developers must select tools which support the process of building and distributing a Java application from the initial design right through to implementation in the live system and maintenance in the subsequent IT lifecycle. SAP NetWeaver Development Infrastructure (NWDI) combines several of these tools and helps to address this problem. Among other things, it offers a version management system and central functionalities for error-free and automated build and transport of software. SAP’s development infrastructure goes beyond the functionalities of the tools previously available for Java such as Concurrent Versions System (CVS) for version management and ANT for script processing. It supports a central configuration system, offers good scalability, features a rights management system and helps to prevent conflicts when distributing software.

Tools in the development environment

SAP NetWeaver Developer Studio is used as an integrated development environment (IDE) which incorporates NWDI. The SAP solution is designed so that the developer can perform almost all his tasks within the development environment. Access to separate interfaces and the relevant services is only required in exceptional cases such as when having to adhere to a role concept with a manager for transporting applications. SAP NetWeaver Developer Studio is based on the platform of the Eclipse open-source development project. Using its plug-in mechanism, it supports a variety of development tasks and perspectives of the individual development objects.
Current development environments contain a sometimes bewildering array of available tools. In contrast, SAP NetWeaver Developer Studio makes the developer’s life easier because he is given predefined access only to the tools he requires for the development segment he is currently working on, for example, a predefined perspective for technologies such as J2SE applications, J2EE Beans, web services and others. Perspectives for general tasks such as managing configurations or the source code are also preconfigured. However, customizations can also be made or special perspectives created in order to facilitate future development work.
Thanks to its integration into the development environment, NWDI facilitates ease-of-use and offers advantages in terms of productivity too. SAP NetWeaver Development Infrastructure offers good scalability both in terms of requirements and the number of developers. This is due to the fact that, in the broadest sense, NWDI is an independent application on the SAP NetWeaver Application Server. Software and hardware scaling can be achieved by means of a cluster architecture consisting of interconnected servers. This enables queries to be processed faster and the system to be protected against possible failure.

Central configuration

The central configuration supported in NWDI makes the day-to-day work of the developer a lot easier. It automatically provides him with the correct source code and the correct libraries. Central configuration also comes into its own when a developer is working on several projects which use the same libraries but in different versions. For example, when a developer is working on two projects at the same time, one for WebAS 6.40 and the other for WebAS 7.0, he is automatically provided with the relevant SAP_JTECHS libraries in versions 6.40 and 7.0 in the relevant projects.
Early integration of the code for all developers on a central platform helps to prevent the problems of simultaneous changes in a joint project. The components of NWDI support this task through various stages. If several developers are working on the same objects at the same time, the intelligent Design Time Repository (DTR) identifies this fact and informs the developers. The NWDI Change Management Service (CMS) component, which covers the entire transport system of the software, identifies conflicts in the distribution of the created software. The transport system is reflected in a track definition in the CMS. Such a track describes a project at a specific stage, for example, during development or consolidation.
One of the further tasks of CMS is the management of development configurations. In addition to the necessary project libraries, a development configuration also incorporates the build environments specified by the development components. This procedure makes it possible to manage the build environments centrally. It is no longer necessary to manually create build scripts either for development within the development environment or for builds on the server side..
NWDI makes it possible after check-in to activate source code created locally on the developer’s PC and to consolidate it automatically. This method is faster and more stable than the nightly build consolidation process popular in the past. This procedure, which is controlled with the help of the Change Management Service (separate check-in, activation and consolidation), prevents errors which can easily occur during the nightly build. This is the case, for example, when two developers check in conflicting source code in the course of a single working day so that a version which cannot be converted is active on the server. This results in an inconsistency that is only discovered the next night during the nightly build, but which the developers will only learn about the following morning when they sit down to work.
The Component Build Service (CBS) is responsible for integrating the changes made by the developers into the central version. As soon as a developer checks program code into the Design Time Repository, he is able to convert the changed program code together with the existing active program modules. If this conversion is successful, the changes are added to the active program code. This process ensures that a change to one module matches the other modules. Moreover, CBS processes parallel changes in the sequence in which they were checked in. All the tasks in the CBS are continuously recorded in a database and the developer can return to them at any time, even after a system failure.

Security and rights management

The transport system in the SAP development infrastructure features an easy-to-use user interface which enables automatic installation of new versions on target systems. There is no need for manual copying of data and developers no longer require full access to the target systems. This ensures that live systems containing critical and sensitive company and personal data remain protected from access during the development processes. The additional security measures of the CMS include rights which can be defined very precisely for access to applications in the development, consolidation, test or live systems. Each transport process into a system is only possible if permission for such has been granted.
Like the Change Management Service, the Design Time Repository also features a rights management system. Access can be defined at a project or object level. The DTR makes it easy to avoid work with competing check-outs and restrictions. If two developers are working on one object, the DTR registers the relevant accesses and notifies the developers of this. It is also possible to assign an object exclusively to a developer. It cannot then be accessed by other developers until it is released again.
The codes and other resources are stored by version in the DTR. The typical functions of a version check such as check-in and check-out, updating local versions and identifying and solving version conflicts are grouped together as activities in the DTR. This makes it easier for the developer to see which changes belong together. One special feature of the DTR is its ability to manage changes across several repositories. This is made possible by an identification system that is unique worldwide. The process also forms the basis for modifying code supplied to customers and quickly identifying version conflicts in the case of changes which have been made by the customer. This is made possible through the use of software component archives which can be transported via NWDI or loaded directly onto the target system using the Software Deployment Manager (SDM), a standard add-on of the SAP NetWeaver Application Server. In addition to the integrated transport system, the DTR also supports early detection of errors or inconsistencies.

Preventing collisions, troubleshooting

NWDI offers a directory service in the form of the System Landscape Directory (SLD). Its key tasks include reserving namespaces and providing a directory for hardware and software. The namespace reservation function, which is already standard in Java packages, prevents collisions in database tables and development objects. This is especially helpful when it comes to SAP partner product developments relating to SAP NetWeaver.
All the necessary services such as Design Time Repository, Component Build Service, Change Management Service and the creation of development components from the SAP NetWeaver Developer Studio can be accessed by the developer and are fully integrated. This reduces the time required for familiarization and administration. The developer is able to concentrate fully on the core tasks of design and implementation. Easy-to-use web interfaces which enable consistent and self-explanatory operation are provided by NWDI for additional tasks such as creating products, software components and transport.
NWDI saves all the data in a database. This facilitates day-to-day administrative activities such as computer backups. Such a solution offers the advantage of improved security and consistency, since backup solutions for production databases are generally available. A database is also easier and faster to back up than an entire computer. This means that NWDI can be used on a variety of platforms such as Windows or Unix and thus satisfies the IT landscape requirements of almost any company.
Moreover, NWDI supports the entire development process by largely automating initial development and transport and supporting tasks such as extensions and troubleshooting in the same consistent manner. NWDI offers patch version control for this purpose. This means that it is always possible to find out the release status or the patch level of the relevant software component. This facilitates troubleshooting and constructing the reference system.
The installation and configuration of NWDI requires specialist expertise but is more practical than manually constructing a complete development infrastructure. The advantages of NWDI become particularly evident where there are a number of projects running in parallel and involving several groups of developers working at different sites. Build scripts developed in-house tend to become increasingly complex as a project progresses and are thus increasingly difficult to maintain. In contrast, NWDI uses a structured and largely automated procedure and can be used for any project, large or small. The available NWDI deployment scenarios can be selected according to company philosophy or the complexity of the project. These scenarios support both effortless startup – only via SAP NetWeaver Developer Studio and DTR – and comprehensive use of all NWDI components.

Jewgeni Kravets

Jewgeni Kravets

Marco Lommatzsch

Marco Lommatzsch

Tags: , ,

Leave a Reply