Szenario „Entwicklung von Komponenten
mit der NWDI“ 
Einsatzmöglichkeiten
Sie entwickeln Geschäftsanwendungen für die SAP NetWeaver-Technologieplattform unter Verwendung der vollständigen SAP NetWeaver Development Infrastructure (NWDI).
Dieses Szenario baut auf dem Szenario „Java-Projekte mit zentraler Quelldateienablage“ auf. Das heißt, dass Entwickler in einem Team arbeiten, Quellcode mit Hilfe des Design Time Repository (DTR) gemeinsam genutzt wird, die Software in Komponenten unterteilt wird und Development-Configurations verwendet werden, um die Sicht des Entwicklers auf die Entwicklungsinfrastruktur zu definieren.
Der zentrale Build-Prozess basiert nun nicht länger auf Kommandozeilen-Werkzeugen und einzelnen Make-Skripts, sondern setzt den Component Build Service (CBS) ein, der Teil der JDI ist. Der CBS baut Komponenten und ihre Abhängigkeiten bei Bedarf und stellt benutzungsfreundliche Bibliotheken und Deploy-Werkzeuge für Entwickler und Laufzeitsysteme zur Verfügung.
Darüber hinaus läuft der Prozess der Softwareänderungsverwaltung nun automatisch. Der Change Management Service (CMS) ist zuständig für den Transport von Software innerhalb der Landschaft, einschließlich Quellcode und Bibliotheken. Auch unterstützt der CMS das automatische Deployment von ausführbarem Code in zentrale Test-Server und Produktivsysteme.
Einführungshinweise
Sie verwenden dieses Szenario, wenn Sie Software entsprechend dem Komponentenmodell entwickeln und alle Projekt-Typen der SAP ohne Einschränkungen nutzen wollen. Sie benötigen dieses Szenario außerdem, wenn Sie Komponenten-basierte Anwendungen modifizieren wollen, für die SAP Quelldateien ausliefert.
Phasen der Softwareentwicklung
Definition der Entwicklungslandschaft
In diesem Szenario erlangen Development-Configurations eine zentrale Bedeutung für den gesamten Prozess. Development-Configurations definieren die Sicht des Entwicklers auf die JDI-Landschaft. Die Konfiguration identifiziert die für den Entwickler wichtigen Komponenten, Quellen, Bibliotheken und Services, wählt die für Übersetzung und Aufbau der Komponenten erforderlichen Build-Plug-Ins aus, konfiguriert den Build-Service und definiert den übergeordneten Deployment-Prozess für ein bestimmtes Stück Software.
Wenn ein Entwicklungsprojekt gestartet wird, verwendet der Landscape Administrator zunächst den CMS zur Definition eines neuen Tracks. Ein Track ist eine separate Produktionslinie für ein bestimmtes Release einer Softwarekomponente. Ein Track besteht aus zwei logischen Systemen, die durch Änderungspropagierung verbunden sind. Das erste System wird für die Entwicklung verwendet, das zweite zum Testen. Jedes logische System wird durch eine Development-Configuration beschrieben und besteht aus DTR-Workspaces, einer eigenen CBS-Build-Umgebung (Buildspace) und einer SAP NetWeaver J2EE Engine. Der CMS legt automatisch die erforderlichen Work- und Buildspaces an und fügt zuletzt die Development-Configuration zu einem Bestandsverzeichnis im SAP System Landscape Directory (SLD) hinzu.
Entwicklung
Ein Entwickler importiert eine Development-Configuration in das SAP NetWeaver Developer Studio. Das Studio offeriert eine Liste der verfügbaren Development-Configurations, die es aus dem System Landscape Directory beschafft.
Dann beginnt der Entwickler mit den Änderungen an dem sogenannten inaktiven Zustand der Software. Dieser Zustand wird durch einen bestimmten Workspace im DTR repräsentiert. Das SAP NetWeaver Developer Studio beschafft automatisch die Bibliotheken der verwendeten Komponenten, die benötigt werden, um die Software auf dem Build-Server zu kompilieren. Wie in Szenario 2 garantiert der Namensservice die eindeutige Namensvergabe.
Nachdem die Änderungen eingecheckt und getestet wurden, aktiviert sie der Entwickler. Die Aktivierung wird ausgelöst durch das Senden einer Build-Anforderung vom SAP NetWeaver Developer Studio an den CBS. Der CBS versucht dann, die geänderten Komponenten zu bauen. Ist er erfolgreich, dann werden die Änderungen in einen anderen Workspace integriert, der den aktiven Zustand der Software enthält. Nach diesem Prozess enthält der aktive Workspace immer die Quellen, die vom CBS erfolgreich gebaut wurden.
Gleichzeitig kann ein automatisches Deployment der vom Build-Server angelegten neuen Archive in die SAP NetWeaver J2EE Engine stattfinden, die dem lokalen Testsystem zugeordnet ist. Sind die Tests erfolgreich, gibt der Entwickler die Änderungen zum Transport frei.
Konsolidierung
Der CMS verarbeitet Freigabeanforderungen, indem er die Änderungen zur Import-Queue des Konsolidierungssystems des Tracks hinzufügt. Zu einem bestimmten Zeitpunkt (z.B. jeden Abend, jede Woche oder jede Stunde) verwendet ein Mitglied des Systemverwaltungsteams die CMS-Web-Benutzungsoberfläche, um die Änderungen aus der Queue in das Konsolidierungssystem zu importieren. Während dieses Schrittes werden die geänderten Quellen in den DTR-Workspace des Konsolidierungssystems integriert und der Build-Server kompiliert die geänderten Komponenten. Nach erfolgtem Import in das Konsolidierungssystem werden die vom Build-Server angelegten Archive zu einer neuen Version der Software zusammengebaut (Assembly), die dann auf das Deployment in die SAP J2EE Engine wartet, die als Testsystem fungiert.
Freigabe
Nach Deployment und Test gibt ein Mitglied des Qualitätsmanagementteams die neue Softwareversion für den produktiven Einsatz frei. Nun kann das Deployment der neuen Version in das Produktivsystem stattfinden.
Überblick über die Prozesse in einem Track des CMS
Überblick über die einzelnen Bestandteile eines vollständigen JDI-orientierten Entwicklungsszenarios und ihre Interaktionen.
Konfiguration
Hier führen Sie Schritte aus, wie für Szenario „Java-Projekte mit zentraler Quelldateienablage“ beschrieben. Die Definition der Entwicklungslandschaft erfolgt nun wie beschrieben in SLD und im Landscape Configurator des CMS. Der Build-Prozess erfolgt nun zentral im CBS. An die Stelle des manuellen oder automatisierten Prozesse der Änderungsverwaltung tritt das Transportstudio des CMS.