Aber bitte mit Java (Teil 1)

Feature | 31. Oktober 2005 von admin 0

Werkzeuge zu Analyse, Design und Kodierung von Software sind erforderlich, um Anwendungen zu entwickeln und über den Lebenszyklus zu warten. Zudem bedarf es einer Infrastruktur, mit der sich Programmcodes verwalten und generierte Programme nach festgelegten Versionen jeweils in Entwicklungs-, Test- und Produktionslandschaften ausliefern lassen. Hierfür diese stand Anwendern aus dem ABAP-Umfeld ein komfortables Transportwesen zur Verfügung, das in SAP-Lösungen integriert ist. Das Gegenstück dazu, um Anwendungen in Java-Umgebungen zu entwickeln, bildet nun die SAP NetWeaver Development Infrastructure (NWDI).

Komponenten- statt Objektmodell

Dienste und Elemente der NWDI

Dienste und Elemente der NWDI

Mit der SAP NetWeaver Development Infrastructure bietet SAP ihren Kunden eine komplette Lösung. Sie besteht zum Einen aus lokalen Komponenten, die auf dem PC des Entwicklers zu installieren sind, zum Anderen auch aus zentralen Infrastruktur-Diensten. Alle Bestandteile sind in Java realisiert. Die Dienste werden von einem oder mehreren SAP NetWeaver Application Servern (SAP NetWeaver AS) gehostet. Mehrere Server lassen sich darüber hinaus zu Clustern zusammenfassen, um eine bessere Skalierbarkeit zu ermöglichen. Für den Entwickler sind alle Werkzeuge, um entwicklungsbezogene Aufgaben zu erledigen, im SAP NetWeaver Developer Studio integriert.

Komponentenmodell

Komponentenmodell

Die Grundlage für Entwicklungen mit NWDI bildet ein Komponentenmodell, das die zu entwickelnde Software auf unterschiedlichen Ebenen zergliedert. Das Komponentenmodell erweitert das bisherige Objektmodell. Als Objekt wird dabei eine in Software abgebildete logische Einheit aus der realen Welt samt ihren Eigenschaften, Methoden oder Funktionalitäten verstanden, zum Beispiel ein Auftrag, eine Berechnung oder eine Bestätigung. In den Komponenten sind mehrere Objekte, die in Beziehung zueinander stehen, zu einem logischen Softwarepaket zusammengefasst. Ein derartiges Paket ist zum Beispiel eine Maske im Personalwesen als Benutzerschnittstelle, die Anbindung dieser Schnittstelle an die HR-Lösung und die Funktionalität dieser Maske. Das Modell unterstützt die Prozesse, die auf der IT-Seite notwendig sind, um zügig und ohne Fehler Software zu entwickeln und zu ändern.
Dabei ist eine Dreiteilung zu berücksichtigen. Die Trennung der SAP-Entwicklungslandschaft in die Bereiche Entwicklung, Test und Produktion soll verhindern, dass geschützte Unternehmens- oder Persönlichkeitsdaten aus der Produktion ins Entwicklungssystem gelangen. Zunächst entstehen die Objekte in einer Entwicklungs- und Konsolidierungslandschaft, in denen Entwickler mit Demo-Daten operieren. Danach sind sie in eine Testlandschaft zu transportieren. Hier haben auch die Mitarbeiter, die später in der Praxis mit den Anwendungen arbeiten sollen, die Möglichkeit, aus betriebswirtschaftlicher Sicht die Funktionalität zu prüfen. Nach erfolgreichen Testläufen und der Freigabe werden die Objekte in den produktiven Betrieb überführt.
Diese Softwarelogistik von einem Entwicklungszyklus in den anderen – von der Entwicklungs- in die Test- und schließlich in die Produktivlandschaft – war bisher mit viel Zeit und Aufwand verbunden, um den Quellcode je nach Objekt zu übersetzen. Das Komponentenmodell von SAP beschleunigt und vereinfacht diese Aufgaben. Der Vorteil der NWDI besteht darin, dass den Entwicklern während ihrer Arbeit bedarfsgerecht Hilfsmittel in der Entwicklungsumgebung bereit gestellt werden. Die Vorgehensweise orientiert sich am Open-Source-Entwicklungsprojekt Eclipse. Während bei Eclipse die Hilfsmittel auf jedem PC manuell zusammengestellt werden müssen, lässt sich in der SAP-Entwicklungsumgebung wesentlich komfortabler arbeiten. Je nach Entwicklungsprojekt beispielsweise im Rahmen eines Portal- oder ein J2EE-Projekts erhält der Entwickler bereits vorkonfiguriert einen definierten Satz der notwendigen Hilfsmittel in der Entwicklungsumgebung geöffnet. Er ist daraufhin sofort in der Lage, mit der Arbeit zu beginnen. Die Hilfsmittel beinhalten die einzelnen Entwicklungsobjekte, wie Java-Klassen und Web-Dynpro-Komponenten. Ebenso definieren sie die Build-Umgebung, um Sourcecode je nach Typ etwa für Enterprise Java Beans (EJB), Web oder Web Dynpro zu kompilieren und dann den Sourcecode in Bibliotheken geordnet zu speichern.

Softwarekomponenten anlegen

Schritte für NWDI-Entwicklung

Schritte für NWDI-Entwicklung

Eine auf NWDI basierte Entwicklung lässt sich in mehrere Schritte einteilen, die zum Teil von unterschiedlichen Rollen durchgeführt werden. Neben der spezifischen Rolle des Entwicklers gibt es die des Software-Architekten, des Landscape-Administrators zur Pflege der Anwendungslandschaft, sowie des Transport- und Quality-Managers. Es ist in der SAP-Entwicklungsumgebung auch möglich, dass eine Person mehrere Rollen auf sich vereint. Startpunkt einer Entwicklung ist ein neues Produkt oder eine neue Version eines bestehenden Produkts. Beides wird in einem Verzeichnisdienst für Hard- und Software, dem System Landscape Directory (SLD), gepflegt, in dem sich auch Namensräume reservieren lassen. Durch die Verwaltung der installierten Software-Komponenten und ihrer Abhängigkeiten erhöht sich die Transparenz innerhalb der Systemlandschaft einschließlich Hard- und Software. So kann beispielsweise leicht festgestellt werden, welche Produkte und Komponenten in welchen Versionen auf welchen Servern installiert sind. Die Verwaltung von Namensräumen bezieht sich auf Präfixe für Datenbanktabellen und Entwicklungskomponenten, die die Entwickler während der Programmierung anlegen. Namen für Java-Pakete werden nach Java-Konventionen vergeben. Nach der Produktdefinition müssen entweder neu zu erstellende oder bereits vorhandene Softwarekomponenten angelegt und zugeordnet werden.
Sobald alle benoetigten Softwarekomponenten angelegt sind, lässt sich in einem zweiten Schritt mit dem Change Management Service (CMS) ein Entwicklungspfad anlegen. Einem solchen so genannten Entwicklungstrack werden dabei verschiedene Softwarekomponenten zugeordnet. Hierzu zählen sowohl diejenigen Komponenten, die während der Implementierung realisiert, als auch solche, die als Bibliothek benötigt werden. Entwickler nehmen die Entwicklungskomponenten in die zu entwickelnden Softwarekomponenten auf, die dann als Projekt- und Build-Umgebung für die eigentliche Programmierung zu verwenden sind. Damit sind die Vorarbeiten für eine Entwicklung abgeschlossen.

Implementierung der Funktionalität

Nun beginnt die Implementierung der eigentlichen Funktionalität. Hierzu melden sich die Entwickler bei der NWDI an und verbinden sich mit dem Entwicklungstrack. Auf diese Weise erhalten sie einen einheitlichen Arbeitsbereich mit Verweisen auf den Quellcode und die benötigten Bibliotheken. Anhand dieser Informationen wird eine lokale Kopie des Arbeitsbereichs auf dem Entwickler-PC aufgebaut.
Während der Programmierung legen die Entwickler Entwicklungskomponenten an und füllen diese mit den Entwicklungsobjekten, etwa mit Java-Klassen und Web Dynpro. Letztere erlauben, dynamisches HTML in Java zu erstellen. In mehrfach sich wiederholenden Prozessen aus Programmierung, lokalem Build, Kompilieren und Testen lässt sich die eigentliche Funktionalität in der gewünschten Form erzielen. Wenn die Entwicklung einen bestimmten Stand erreicht hat, werden die Entwicklungsobjekte in die Versionsverwaltung, das Design Time Repository (DTR), eingecheckt.
Im DTR sind versionierter Sourcecode und andere Ressourcen beispielsweise Textdateien oder Bilder abzulegen. Die typischen Funktionen einer Versionskontrolle, wie Ein- und Auschecken, Update der lokalen Versionen, Erkennung und Lösen von Versionskonflikten werden im DTR in Aktivitäten zusammengefasst. So lässt sich vom Entwickler leicht erkennen, welche Änderungen zusammengehören. Als Besonderheit bietet das DTR die Möglichkeit, Veränderungen über mehrere Repositories zu verwalten. Wird das DTR angewendet, dann richtet die NWDI immer zwei Bereiche – je einen aktiven und einen inaktiven – ein. Erst nach einem erfolgreichen Build gehen die Ressourcen aus dem inaktiven in den aktiven Bereich über.
Da das Design Time Repository eine Menge von Änderungen zu einer Aktivität – ähnlich einem Transportauftrag – zusammenfasst, werden in der Regel mehrere Objekte auf einmal eingecheckt. Bis zur Aktivierung befinden sich alle Objekte in dem inaktiven Bereich und sind nur explizit über die Entwicklungswerkzeuge den Entwicklern zugänglich. Um alle eingecheckten Komponenten auf den Entwicklungs-, Konsolidierungs- sowie auf Test- oder Produktionssystemen zugänglich zu machen, sind sie erst zu übersetzen. Das soll vermeiden, das nicht zusammenpassender Sourcecode eingecheckt und somit ein inkonsistenter Stand erzeugt wird, Die Übersetzung lässt sich separat durch die so genannte Aktivierung der Objekte anstoßen.

Übersetzungsfehler ausschließen

Bei der Aktivierung werden in einem weiteren Schritt die neu eingecheckten Entwicklungsobjekte auf dem Server zusammen mit den dort bereits vorhandenen, aktiven Entwicklungsobjekten und dem Projekt zugeordneten Bibliotheken übersetzt. Diesen Vorgang übernimmt der Component Build Service (CBS). Dieser stellt sicher, dass die Änderungen aller Entwickler fehlerfrei übersetzbar sind. Änderungen, die Übersetzungsfehler in anderen Komponenten erzeugen, werden nach dieser Vorgehensweise nicht zugelassen. Diese Arbeitsweise gewährleistet, dass eine Veränderung eines Moduls zu den anderen Modulen passt. Außerdem erfolgen parallele Änderungen serialisiert, da sie in der Reihenfolge des Eincheckens abgearbeitet werden.
Ist die Übersetzung erfolgreich, sind die Änderungen auch zum aktiven Programmcode hinzuzufügen. Diese Aktivierung lässt sich unmittelbar nach dem Einchecken anstoßen, damit entfallen die typischen Nightly-Builds. Nach einem erfolgreichen Build wird der eingecheckte Code in den aktiven – und gemeinsam für alle Entwickler nutzbaren – Zweig übernommen und auf dem Entwicklungsserver installiert.
Durch Prozesse aus lokaler Entwicklung und der Konsolidierung mittels CBS lässt sich Schritt für Schritt die Entwicklung fertig stellen. Der Entwickler überträgt dann die gebaute Software von seinem lokalen PC auf das gemeinsame Entwicklungssystem. Im Change Management System ist ein automatisches Transportwesen integriert, mit dessen Hilfe die Softwarekomponenten auf den weiteren Systemen zu installieren. Wie das Entwicklungssystem enthält das Konsolidierungssystem Quellcode und bietet Patches, um rasch Programmierfehler zu korrigieren. Für einen Transport zum Test- und Produktivsystem werden binäre Fragmente erzeugt und im Software-Deployment-Archive (SCA/SDA) verpackt. Ein manueller Transport über Software Deployment Manager (SDM) ist möglich.
Teil 2 des Artikels

Jewgeni Kravets

Jewgeni Kravets

Marco Lommatzsch

Marco Lommatzsch

Leave a Reply