1              Themenübersicht

Semiramis Anwendungen und Logik werden in Entwicklungssystemen entwickelt. Die dabei entstehenden Softwareaktualisierungen können in ein nachfolgendes Entwicklungssystem eingespielt werden. Dieses Aneinanderreihen von Entwicklungssystemen ermöglicht es, die vorrangegangene Entwicklung durch Adaptierung zu spezialisieren.

Eine übliche Kette von Entwicklungssystemen besteht aus Standard-, Branchen- und Kundenentwicklungssystem. Aus dem Standardentwicklungssystem werden mehrere Branchenentwicklungssysteme mit Softwareaktualisierungen versorgt.

Jedes Branchenentwicklungssystem versorgt in der Regel mehrere Kundenentwicklungssysteme. Normalerweise gibt es für jeden Kunden ein eigenes Entwicklungssystem. Die Versorgungskette hat vom Standardentwicklungssystem aus gesehen eine baumartige Struktur. Vom Kundenentwicklungssystem gesehen, gibt es nur einen Pfad bis hinauf zum Standardentwicklungssystem.

Wenn nun in zwei Kundenentwicklungssystemen die gleiche Erweiterung benötigen wird, so kann diese Erweiterung entweder im vorgelagerten Branchenentwicklungssystem oder in den einzelnen Kundenentwicklungssystemen erfolgen. Bei der Entwicklung im Branchenentwicklungssystem würde die Erweiterung auch in allen anderen zugehörigen Kundenentwicklungssystemen zur Verfügung stehen, was ggf. nicht gewünscht ist. Wird in den einzelnen Kundenentwicklungssystemen die Erweiterung vorgenommen, so muss die Erweiterung doppelt implementiert und gepflegt werden, was zu Fehlern und unterschiedlichen Entwicklungsständen führen kann. Im ungünstigsten Fall haben die beiden Kundenentwicklungssysteme nicht das gleiche vorgelagerte Branchenentwicklungssystem, sodass die Entwicklung theoretisch im Standardentwicklungssystem erfolgen müsste.

Die App-Technologie kann hier mit neuen Konzepten zur Softwarelogistik helfen. Apps werden in einem eigenen Entwicklungssystem entwickelt und können in Kundenentwicklungssysteme eingespielt werden. Dort stehen diese Apps als Erweiterung zur Verfügung und werden über den normalen Transportweg zum Produktivsystem transportiert.

Eine App kann einzelne Anwendungen und deren Logik oder aber auch komplette Frameworks mit zahlreichen Anwendungen und Logik umfassen. Wenn passende Schnittstellen bereitstehen, kann eine App in die bestehenden Prozesse integriert werden. Viele Entwicklungen, die bis jetzt nur in den „normalen“ Entwicklungssystemen durchgeführt werden konnten, können nun alternativ auch in einem App-Entwicklungssystem erfolgen.

Dieses Dokument soll Ihnen helfen, die Möglichkeiten, aber auch die Einschränkungen, von Apps zu verstehen, um diese richtig und gezielt in der Entwicklung einzusetzen.

2              Zielgruppe

• Entwickler
• Technische Berater

3              Was ist eine App?

Eine App ist eine Sammlung von Entwicklungsobjekten und deren Versionen, die in ein Kundenentwicklungssystem als Erweiterung eingespielt werden können. Der Umfang einer App kann dabei von einzelnen Entwicklungsobjekten bis hin zu kompletten Frameworks gehen. Eine App ist aber auch anders als eine normale Entwicklung in Semiramis. Durch die App-Technologie wird es erstmals möglich, die normalen Transportwege zu verlassen. Im Folgenden werden diese Unterschiede genauer beschrieben.

3.1        Situationsbeschreibung ohne Apps

Der Entwicklungsablauf stellt sich in Semiramis wie folgt dar. In der Standardentwicklung werden Entwicklungsobjekte erstellt und ausgeliefert. Diese werden mittels Softwareaktualisierung in ein Branchenentwicklungssystem transportiert und dort ggf. an die speziellen Anforderungen einer Branche angepasst. Zusammen mit den Anpassungen gelangen die Entwicklungsobjekte schließlich in ein Kundenentwicklungssystem. Dort können weitere Anpassungen und Erweiterungen speziell für einen Kunden erfolgen. Der erreichte Stand wird in das Produktivsystem des Kunden eingespielt.

Die Entscheidung, in welchem Entwicklungssystem welche Anpassung erfolgt, ist unter anderem davon abhängig, wie groß der Kreis derer ist, die die Anpassung benötigen. Ist die Anpassung nur für einen Kunden interessant, so wird die Anpassung in der Regel in dessen Kundenentwicklungssystem erfolgen. Wenn die Anpassung für alle Kunden genutzt werden kann, so wird sie im Branchenentwicklungssystem erfolgen. Die Entscheidung kann zwischen einem Kunden oder allen Kunden bzw. der Branche getroffen werden.

Soll nur eine Teilmenge der Kunden die Erweiterungen bekommen, so muss in den einzelnen Kundenentwicklungssystemen die Entwicklung erfolgen. Soll dieser Stand erweitert werden, oder müssen Fehler behoben werden, so müssen in mehreren Systemen parallel die Arbeiten ausgeführt werden. Der dabei entstehende Wartungsaufwand erhöht sich, wenn die einzelnen Kundenentwicklungssysteme einen unterschiedlichen Entwicklungsstand besitzen.

Wenn stattdessen die Erweiterungen im Branchenentwicklungssystem erfolgen, entfällt zwar die parallele Entwicklung in den Kundenentwicklungssystemen, dafür wird aber das Branchenentwicklungssystem mit kundenspezifischen Erweiterungen durchsetzt. Diese Erweiterungen können in den anderen Kundenentwicklungen stören und erhöhen dort ggf. die Anpassungs- und Wartungskosten.

Es gibt auch Fälle, in denen eine Erweiterung benötigt wird, diese aber nur unter erhöhtem Aufwand selbst erstellt werden kann. Sei es, dass hierfür erst das erforderliche Know-how aufgebaut werden muss, oder aber sich die Entwicklung für einen einzelnen Kunden nicht lohnt. Hier möchte man die entsprechenden Teile von einem externen Anbieter zukaufen oder aber, bei einer Eigenentwicklung, anderen Partnern anbieten können. In der Systemlandschaft ohne Apps kann die Auslieferung z. B. über XML-Import/Export erfolgen. Der Einspielvorgang incl. Anpassungen, Konfliktbearbeitung etc. ist aber mit erheblichem manuellem Aufwand verbunden. Der Aufwand erhöht sich, wenn die Systeme, in die die Erweiterungen eingespielt werden, unterschiedliche System- und Anpassungsstände haben. Ein weiteres Konfliktpotenzial haben Adaptierungen. Wenn sowohl Partner als auch externer Anbieter die gleichen Entwicklungsobjekte adaptieren möchten, muss geklärt sein, wer was ändern darf und wie man sich im Fehlerfall verhält. Noch schwieriger ist die Frage zu beantworten, wenn beide Entwicklungsobjekte inkompatibel zueinander ändern möchten. Die Wartung der Entwicklung per XML-Import/Export erzeugt einen hohen manuellen Aufwand.

3.2        Anforderungen an eine App

Die Situationsbeschreibung zeigt, dass in einigen Bereichen die normalen Entwicklungsmöglichkeiten zwar eine Lösung bieten, diese aber mit Einschränkungen verbunden und nicht immer wirtschaftlich ist. Aus der Beschreibung lassen sich Wünsche und Anforderungen an eine App formulieren:

Releasefest

Die Entwicklung und auch das spätere Einspielen einer App in die Systeme sollte möglichst wenig vom Stand des Systems, in dem die Entwicklung eingespielt wird, abhängen. Bestenfalls sollte es sogar unabhängig vom Release sein.

Konfliktfrei

Der Einspielvorgang sollte möglichst ohne Konflikte ablaufen, um den Wartungsaufwand gering zu halten. Die Erweiterungen der App dürfen die eigene Entwicklung nicht gefährden, d. h., die eigene Entwicklung sollte unberührt von den eingespielten Entwicklungsobjekten bleiben.

Um die Anforderungen zu erfüllen, müssen einige Regeln beachtet werden und die Entwicklungssysteme entsprechend eingestellt werden. Nachfolgend wird nun auf diese Details eingegangen.

3.2.1    Releasefest

Wo kann eine App entwickelt werden?

Eine App sollte sich in eine möglichst große Menge von Systemen einspielen lassen. Dabei sollten an den Systemstand des Zielsystems möglichst geringe Anforderungen gestellt werden. Eine Anforderung an ein System ist der installierte Stand an Entwicklungsobjekten und deren Versionen.

In einem Semiramis-Entwicklungssystem werden zu den anderen Softwareaktualisierungen Abhängigkeiten aufgebaut. Diese Abhängigkeiten bilden die Basis dafür, dass eine Softwareaktualisierung nur in ein System eingespielt werden kann, wenn die abhängigen Aktualisierungen bereits installiert sind, oder im gleichen Vorgang mit installiert werden.

Betrachtet man die verschiedenen Systeme in Semiramis, so wird man feststellen, dass es viele unterschiedliche Entwicklungsstände gibt. Werden Korrekturen auf einem System benötigt, so werden diese über Softwareaktualisierungen bis zum entsprechenden System transportiert. Es kann allerdings auch Systeme geben, die diese Korrekturen nicht benötigen und deshalb einen älteren Stand aufweisen.

Wenn eine App in möglichst viele Kundenentwicklungssysteme einspielbar sein soll, so muss sichergestellt werden, dass über die App nur Entwicklungsobjekte und Versionen referenziert werden, die im Zielsystem bereits vorhanden sind oder mit installiert werden.

Das System, auf dem eine App entwickelt wird, gibt mit seinen installierten Softwareaktualisierungen den Stand vor, den das System, in das die App eingespielt werden soll, mindestens haben muss. Apps lassen sich wegen Abhängigkeiten zu den Softwareaktualisierungen nur in Systeme einspielen, die mindestens den gleichen Stand haben wie das App-System. Um eine App in möglichst viele Systeme einspielen zu können, muss ein App-System einen möglichst „alten“ Stand besitzen.

Systemstand APP-Entwicklungssystem und Kundenentwicklungssysteme

Beispiel: In der Grafik ist das APP-Entwicklungssystem APP1 auf dem Stand 500 PC. Die entwickelte APP kann in die Kundenentwicklungssysteme CDV1 und CDV3 eingespielt werden, da diese Systeme einen neueren oder den gleichen Stand haben. In das System CDV2 kann die App nicht eingespielt werden, da der Systemstand niedriger ist als im APP-Entwicklungssystem.

Hinweis:

Da die Abhängigkeiten über die Softwareaktualisierungen aufgebaut werden, kann es möglich sein, dass die App sich trotzdem in das CDV2 einspielen lässt, wenn keine der Softwareaktualisierungen von 500 PC referenziert wird.

Für die Entwicklungssysteme in der normalen Versorgungskette gilt folgende Regel: Das versorgende System hat mindestens den gleichen Stand wie das aktuellste versorgte System.

Beispiel:

Werden die Kundenentwicklungssysteme aus der vorherigen Grafik aus dem gleichen Branchenentwicklungssystem versorgt, so hat das Branchenentwicklungssystem mindestens den Stand 500 PE wie das CDV1. Das Standardentwicklungssystem vor dem Branchenentwicklungssystem muss demzufolge auch mindestens auf 500 PE sein.

Eine App kann deshalb nicht in einem der Systeme des normalen Transportweges entwickelt werden. Wäre dies möglich, so müsste vor dem Einspielen der App das entsprechende System auf den Stand des Systems angehoben werden, auf dem die App entwickelt wurde.

Apps werden im eigenen Entwicklungssystem erstellt. Dieses System wird in der Regel aus dem Standartentwicklungssystem versorgt. Alternativ könnte dieses System auch aus einem Branchenentwicklungssystem versorgt werden. Dies würde allerdings bedeuten, dass die Apps nur in Kundensysteme eingespielt werden könnten, die vom gleichen Branchensystem versorgt werden. Dem Entwicklungssystem muss ein Testsystem folgen, auf dem der Test erfolgt und auf dem die Auslieferung erstellt wird.

APP-Entwicklungssystem und APP-Testsystem

Hinweis:

In der Grafik sind APP-DV und APP-DT als einzelne Systeme eingetragen. Bei den anderen Systemen sind die Testsysteme nicht dargestellt, aber implizit vorhanden. In allen anderen Grafiken gilt dies auch für die Angabe bei APP-DV.

Hinweis:

Mit dem Einspielen von Softwareaktualisierungen kann ein App-System einen neueren Stand erreichen als die Systeme, in die die App bereits eingespielt wurde. Wenn nun eine neue Version einer App ausgeliefert werden soll, kann diese nur dann in die Kundenentwicklungssysteme eingespielt werden, wenn diese mindestens auf den gleichen Stand wie das App-System gehoben wurden. Hierbei kann es zu Konfliktaufgaben kommen, die gelöst werden müssen, bevor die App eingespielt werden kann. Kritische Korrekturen erreichen die Kunden dann ggf. erst mit erheblicher Verzögerung. Es gibt zwar die Möglichkeit, diese Abhängigkeiten zu verändern, dies kann aber negative Auswirkungen auf die Lauffähigkeit einer App haben.

Welche Entwicklungsobjekte können in Referenzen verwendet werden?

Ein Entwicklungsobjekt kann sich im Laufe der Zeit ändern. In der Regel sind die Änderungen derart, dass das Entwicklungsobjekt kompatibel zu seinen Vorgängerversionen bleibt. Es kann aber vorkommen, dass das Entwicklungsobjekt nicht mehr kompatibel bleiben kann.

In einer App können Entwicklungsobjekte außerhalb der App referenziert werden. Ändert sich ein referenziertes Entwicklungsobjekt inkompatibel, so kann das dazu führen, dass eine App nicht mehr funktioniert.

Um Sicherheit für die Entwicklung von Apps zu schaffen, sind einige Entwicklungsobjekte in Semiramis als „stabil“ gekennzeichnet. Diese Entwicklungsobjekte lassen sich nicht mehr ändern und sind auch über Releasegrenzen hinweg konstant. Baut ein App ausschließlich auf diese Entwicklungsobjekte auf, kann das App auch in einem zukünftigen Release mit hoher Wahrscheinlichkeit ohne Anpassung verwendet werden. Die App wird dadurch releasefest.

3.2.2    Konfliktfrei

Eine Anforderung an ein App ist es, den Einspielvorgang in ein System möglichst ohne Konflikte durchführen zu können. Ein Konflikt entsteht in Semiramis immer dann, wenn ein geändertes Entwicklungsobjekt aus einem vorgelagerten Entwicklungssystem in einer neuen Version eingespielt wird. In dieser Aussage sind einige wichtige Informationen enthalten. Einen Konflikt kann es nur auf Entwicklungsobjekten geben, die ursprünglich nicht von diesem System stammen. Sie müssen folglich aus einem der vorgelagerten Entwicklungssysteme kommen, z. B. aus dem Standardentwicklungssystem oder dem Branchenentwicklungssystem. Die zweite Bedingung ist, dass dieses Entwicklungsobjekt in dem Entwicklungssystem verändert wurde, also eine neue Version des Entwicklungsobjektes angelegt wurde. Wenn nun eine neue Version aus dem vorgelagerten Entwicklungssystem eingespielt wird, kommt es zum Konflikt, da die Inhalte der eingespielten und der angepassten Version vermutlich voneinander abweichen.

Beispiel:

Eine Java-Klasse wird im Kundenentwicklungssystem angepasst. Wenn nun eine neue Version dieser Java-Klasse aus dem Branchenentwicklungssystem eingespielt wird, so kommt es zu einem Konflikt. Der Entwickler muss nun manuell den Inhalt der beiden Versionen derart zusammenführen, dass die Korrekturen aus dem Branchensystem und die Anpassungen aus dem Kundensystem berücksichtigt werden.

Wie an dem Beispiel ersichtlich, ist der Entwickler dafür zuständig den Abgleich der beiden Versionen vorzunehmen. Er ist es, der entscheiden muss, welche Inhalte wie berücksichtigt werden müssen. Diese Entscheidung kann aber mitunter schwierig sein. Vor allem, wenn in beiden Systemen das Entwicklungsobjekt an der gleichen Stelle geändert wurde, z. B. unterschiedliche Implementierungen der gleichen Methode einer Java-Klasse. Kann der Entwickler diese Aufgabe noch lösen, z. B. weil er auch für die Entwicklung in der Branchenlösung zuständig war, so sieht die Welt bei Änderungen, die von außerhalb kommen schon schwieriger aus.

Wie bereits beschrieben, entsteht ein Konflikt immer dann, wenn ein Entwicklungsobjekt aus einem anderen Entwicklungssystem, bzw. aus einem fremden Entwicklungsnamensraum geändert wird. Ein Konflikt kann auf einfache Art und Weise vermieden werden: Es werden nur Entwicklungsobjekte aus dem eigenen Entwicklungsnamensraum geändert.

Wenn eine App konfliktfrei eingespielt werden soll, darf die App nur Entwicklungsobjekte aus dem eigenen Namensraum mitbringen. Würde die App Entwicklungsobjekte aus einem fremden Namensraum mitbringen, so könnte es auf diesen Entwicklungsobjekten zu Konflikten kommen.

Hinweis:

Eine App kann in einem Kundenentwicklungssystem adaptiert werden. Wenn dies der Fall ist, kommt es natürlich auch beim Einspielen einer App zu einem Konflikt. Es kommt auch zu einem Konflikt, wenn eine App eine Erweiterung zu einem „fremden“ Business Objekt mitbringt. Hier muss ein Konflikt entstehen, um die Schemaänderungen koordinieren zu können.

3.3        Erweiterungen

Wenn die Entwicklungsobjekte einer App in einem separaten Namensraum liegen und keine anderen Entwicklungsobjekte verändert werden dürfen, kann keine so tiefgreifende Integration erreicht werden, wie sie bei einer Adaptierung der Fall wäre. Wenn keine „fremden“ Entwicklungsobjekte geändert werden dürfen, wer ruft dann die App auf? Wie wird sie eingebunden? Wie kommen neue Felder in bestehende Anwendungen auf die Oberfläche?

Diese Problemstellungen werden durch Erweiterungen gelöst. Eine Änderung, bzw. Adaptierung, hat zur Folge, dass mehrere Parteien die gleiche Ressource zueinander inkompatibel ändern können. Erweiterungen erlauben es, eine Ressource um zusätzliche Informationen anzureichern, ohne, dass die anderen Parteien davon betroffen sind. Ein mögliches Beispiel sind zusätzliche Attribute an Business Objects. Solange diese einen eindeutigen Namen haben, stören die neuen Attribute die Anderen nicht.

Erweiterbar sind somit potentiell alle Entwicklungsobjekte in Semiramis die über 1 zu n Dependents verfügen und wenn zusätzliche Instanzen der Dependents konfliktfrei hinzugenommen werden können.

Einige Entwicklungsobjekte erfüllen diese Bedingung nicht, sodass sie nicht erweiterbar sind. Hierunter fallen z. B. Java-Klassen, Logische Datentypen, Actions usw.

Bei den erweiterbaren Entwicklungsobjekten sind nicht alle Erweiterungen sinnvoll, bzw. technisch realisierbar. Stringtables müssen nicht erweiterbar sein, da problemlos eine eigene Stringtable im Namensraum der App angelegt werden kann. ValueSet-Erweiterungen sind derzeit technisch nicht realisierbar. Hier kann zum einen nicht sichergestellt werden, dass mehrere Apps den gleichen Zahlwert für ein ValueSet-Element verwenden. Zum anderen kann nicht sichergestellt werden, dass vorhandene Logik mit neuen Einträgen zurechtkommt. Dies kann bis zu inkonsistenten Datenbeständen führen.

Für die Apps wurden deshalb in erster Linie die Erweiterungen umgesetzt, die eine möglichst tiefe Integration der Apps in ein bestehendes System ermöglichen.

Extensions

Wenn an einem Business Object neue Attribute benötigt werden, so können diese an einer Extension erfasst werden. Die neuen Attribute werden zu einem Bestandteil der Tabelle des Business Objects auf der Datenbank. Dies hat den Vorteil, dass die Attribute bei allen Logikoperationen, z. B. Laden, Speichern etc. automatisch berücksichtigt werden.

Objektsicht-Erweiterungen

Betriebswirtschaftliche Entitys werden in Semiramis in komplexen Containern, sogenannten APP-Entitys, verwaltet. Neben den lesenden und schreibenden Zugriff auf die Daten enthalten die Container auch komplexe Operationen, wie z. B. das Hinzufügen oder Löschen von Dependents. Mit den Objektsichten kann eine releasefeste Schnittstelle für ein APP-Entity definiert werden. Über eine Objektsicht-Erweiterung können zusätzliche Eigenschaften zu einer bestehenden Objektsicht hingenommen werden.

Anwendungserweiterungen

Die anpassbaren Oberflächen ermöglichen die Anordnung der Oberflächenelemente einer Anwendung. Das dabei entstandene Layout wird in einer Anwendungserweiterung gespeichert. Werden im Rahmen einer App neue Felder für eine Anwendung bereitgestellt, so kann das Layout in einer zusätzlichen Anwendungserweiterung gespeichert werden.

3.4        Erweiterungen für Java-Klassen

Um eine Integration der Apps in Semiramis zu ermöglichen, müssen die Apps auch im Programmablauf berücksichtigt werden. Java-Klassen können aus beschrieben Gründen nicht erweitert werden. Deshalb müssen Apps schon bei der Entwicklung der Standard-Java-Klassen berücksichtigt werden. An bestimmten Stellen im Source-Code sind Aufrufe vorgesehen. Damit eine App von diesen Stellen aufgerufen wird, muss sie sich hierfür registrieren.

Umgesetzt ist dies mit dem Entwicklungsobjekt „Hook Contract“.

Hook Contracts werden in den Entwicklungssystemen des normalen Transportweges bereitgestellt, d. h. im Standardentwicklungssystem, im Branchenentwicklungssystem. Eine App kann nur über die in diesen Systemen erstellen Hooks aufgerufen werden. Hierfür muss das App-Entwicklungssystem auf dem System basieren, welches die benötigten Hooks bereitstellt.

Eine App kann auch eigene Hook Contracts bereitstellen. Diese können von den Systemen verwendet werden, in die die App eingespielt wird. So kann die Technologie auch dazu genutzt werden, ohne Adaptierung eine App zu erweitern.

3.5        App-Replacements

An einer Java-Klasse kann eingetragen werden, welche Klasse sie ersetzt. Dieses funktioniert auch bei Java-Klassen aus einer App. Bei der Verwendung von Replacements kann das Problem auftreten, dass mehrere Java-Klassen aus verschiedenen Quellen die gleiche Klasse ersetzten wollen. Ein konfliktfreies Einspielen ist dann nicht mehr gewährleistet. Apps sollten daher keine Replacements verwenden.

3.6        Registrierungen

In früheren Versionen von Semiramis waren für Registrierungen, z. B. Import/Export, zentrale Klassen im fachlichen Bereich zu adaptieren. Mit Semiramis 5 sind diese Registrierungen in das Entwicklungsobjekt „Business-Object-Registry“ verlagert worden. Für die eigenen Business Objects können dadurch die entsprechenden Registrierungen konfliktfrei vorgenommen werden.

4              Erstellen eines App-Systems

Wie bereits im Kapitel Releasefest beschrieben, wird für die Entwicklung von Apps ein eigenes Entwicklungssystem benötigt. Dieses System besteht aus einem Entwicklungssystem und einem Entwicklungstestsystem.

Die Systeme werden in der Regel als Kopie eines bestehenden Entwicklungssystems oder von einer Auslieferungs-DVD aufgesetzt. Hierbei sind die gleichen Regeln zu beachten, wie sie für nachgelagerte Entwicklungssysteme gelten.

Für die beiden Systeme sind spezielle Lizenzen erforderlich. Das Entwicklungssystem muss in der Verwendung der Lizenz „App-Entwicklungssystem“ und das Testsystem „App-Entwicklungstestsystem“ eingetragen haben.

Das System, aus dem das App-System erstellt wurde, wird im Folgenden als Basissystem bezeichnet und ist zugleich auch das System, aus dem das App-System im Bedarfsfall mit Softwareaktualisierungen versorgt wird.

4.1        Auswahl des Basissystems

Die Wahl des Basissystems ist im Wesentlichen davon abhängig, in welche Systeme die Apps eingespielt werden sollen. Werden Funktionalitäten benötigt, die erst ab einem bestimmten Entwicklungssystem zur Verfügung stehen, so muss dies bei der Entscheidung ebenfalls berücksichtigt werden.

Als Basis für ein App-System kann entweder das Standardentwicklungssystem oder ein Branchenentwicklungssystem verwendet werden. Ein Kundenentwicklungssystem der Entwicklungsstufe 6 kann nicht verwendet werden.

Standardentwicklungssystem (Entwicklungsstufe 1)

Das App-System kann auf Basis einer Auslieferungs-DVD von Semiramis aufgesetzt werden. Apps aus diesem System können in alle Kundenentwicklungssysteme eingespielt werden.

Branchenentwicklungssystem (Entwicklungsstufe 3, 4 oder 5)

Wird die App auf Basis eines Branchenentwicklungssystems erstellt, können die erstellten Apps nur in die nachfolgenden Kundenentwicklungssysteme eingespielt werden.

Diese Basis sollte nur gewählt werden, wenn die App branchenspezifische Entwicklungsobjekte bzw. branchenspezifische Logik verwenden soll.

5              Entwickeln von Apps

Ein App-Entwicklungssystem kann für die Entwicklung von einer oder mehrerer Apps verwendet werden. Jede App besitzt einen in diesem System eindeutigen Namen. In Kombination mit dem Entwicklungspräfix des Systems wird daraus ein eindeutiger Name über alle Semiramis-Systeme hinweg.

Apps können und dürfen Abhängigkeiten zu Entwicklungsobjekten aus anderen Namensräumen haben. Apps sollten keine Abhängigkeiten zueinander haben. Wird ein Entwicklungsobjekt einer App von einer anderen App referenziert, so wird eine Fehlermeldung ausgegeben.

Über eine Property kann allerdings festgelegt werden, welche Apps eine andere App referenzieren dürfen. Nähere Informationen hierzu finden Sie in der Dokumentation „Semiramis Properties“.

5.1        Vorbereiten des Entwicklungssystems

In einem neuen App-Entwicklungssystem müssen als Erstes folgende Namensräume angelegt werden:

com.<Entwicklungspräfix>

com.<Entwicklungspräfix>.ext

com.<Entwicklungspräfix>.ext.app

Diese Entwicklungsobjekte sollten in einer eigenen Aufgabe erstellt und freigegeben werden.

5.2        Anlegen von Apps

Apps werden in einem speziellen Namensraum angelegt:

com.<Entwicklungspräfix>.ext.app

In diesem Namensraum muss als Erstes eine App erstellt werden. Eine App darf als Namen maximal acht Buchstaben haben.

Nachdem die App angelegt ist, muss als Nächstes ein Namensraum mit dem gleichen Namen wie die App, allerdings in Kleinbuchstaben, angelegt werden.

Beispiel: Wenn das Entwicklungspräfix xyz ist und die App MyApp heißt, müssen in dem Entwicklungssystem folgende Objekte angelegt werden:

Unterhalb des Namensraumes können dann die Entwicklungsobjekte der App angelegt werden.

Das Entwicklungsobjekt App, der zugehörige Namensraum und alle Entwicklungsobjekte unterhalb des Namensraums bilden zusammen eine App.

Hinweis: Zu einer App gehören auch die Entwicklungsobjekte im upd- und nls-Namensraum.

5.3        Referenzen

Entwicklungsobjekte können andere Entwicklungsobjekte referenzieren. Für eine App gibt es dabei drei Kategorien von Referenzen.

Referenzen auf Entwicklungsobjekte aus der gleichen App

Diese Referenzen sind ohne Einschränkung erlaubt, da alle Objekte einer App zusammen ausgeliefert werden. Es kann somit keine Referenz geben, die auf dem Zielsystem nicht aufgelöst werden kann.

Referenzen auf Entwicklungsobjekte einer anderen App des gleichen Systems

Diese Beziehungen sind erst einmal nicht erlaubt. Wenn solche Beziehungen aufgebaut werden, so wird beim Einspielen der App das referenzierte App vorausgesetzt. Mithilfe einer Systemproperty kann festgelegt werden, welche App welche anderen Apps referenzieren darf. Diese Property darf nachträglich nur erweitert werden.

Referenzen auf andere Entwicklungsobjekte

Entwicklungsobjekte aus anderen Entwicklungssystemen können, bzw. sollten in der Regel nicht referenziert werden. Entwicklungsobjekte können sich von Version zu Version ändern. In der Regel sind die Änderungen kompatibel zur Vorgängerversion. Es ist allerdings auch möglich, dass inkompatible Änderungen erfolgen müssen. Baut eine App auf diesen Entwicklungsobjekten auf, so kann es passieren, dass nach dem Einspielen der App, diese nicht lauffähig ist. Im Bereich der Datenmodelländerungen kann es im schlimmsten Fall dazu kommen, dass das ganze System in einem irreparablen Zustand gerät.

Um aus einer App heraus dennoch gefahrlos Entwicklungsobjekte aus einem anderen System referenzieren zu können, wurden die stabilen Entwicklungsobjekte eingeführt. Diese Entwicklungsobjekte können auch in Ihrem Entwicklungssystem nicht mehr geändert werden. Sie sind, wie der Name schon umschreibt, stabil und können gefahrlos in einer App referenziert werden.

Werden darüber hinaus andere Entwicklungsobjekte referenziert, so wird abhängig von der Verwendung eine Fehlermeldung oder eine Warnung ausgegeben. Immer wenn potenziell eine Gefahr für das System besteht, in das die App eingespielt wird, wird eine Fehlermeldung ausgegeben. In allen anderen Fällen kann es bei Bestätigung der Warnung auf dem System zu Laufzeitfehlern kommen.

6              Ausliefern von Apps

Eine App wird in einem App-Entwicklungssystem entwickelt. Zwecks Test und späterer Auslieferung werden die Entwicklungsobjekte und deren Versionen in das nachgelagerte App-Entwicklungstestsystem eingespielt. Bis hierhin verhält sich die Softwarelogistik wie in einem normalen Entwicklungssystem mit nachgelagertem Testsystem.

Die Auslieferung eines Apps aus dem Entwicklungstestsystem heraus geschieht per Softwareaktualisierung. Im Gegensatz zu den üblichen Auslieferungen in Semiramis umfasst die Auslieferung einer App immer die vollständige App. Um eine bestimmte Version einer App zu installieren, müssen nicht inkrementell alle vorherigen Versionen eingespielt werden.

Dies hat den Vorteil, dass z. B. direkt die Version 4 einer App eingespielt werden kann. Es kann auch direkt von Version 1 auf die Version 5 gesprungen werden. Die vereinfachte Art und Weise für die Auslieferung hat den Nachteil, dass bei Korrekturen ebenfalls die komplette App ausgeliefert werden muss.

Für die Auslieferung einer App gibt es die Anwendung „Apps exportieren“. Eine Auslieferung über die Anwendung „Softwareaktualisierungscockpit“ ist nicht möglich.

6.1        Apps exportieren

Sie können ein App mit der Anwendung „Apps exportieren“ auf dem App-Entwicklungstestsystem exportieren. In der Anwendung können Sie die auf dem zugehörigen App-Entwicklungssystem entwickelten Apps auswählen. Der Ablauf ist üblicherweise wie folgt.

1. Neue Version des Apps im App-Entwicklungssystem erstellen und in das App-Entwicklungstestsystem übernehmen.
2. Softwareaktualisierung im App-Entwicklungstestsystem erstellen
3. Abhänigkeiten übernehmen (nur in Ausnahmefällen)
4. Softwareaktualisierung exportieren.

6.1.1    Neue Version des Apps erstellen

Legen Sie im App-Entwicklungssystem eine neue Version des App-Entwicklungsobjekts an, das Sie exportieren wollen. Übernehmen Sie die Softwareaktualisierung mit dieser Version in das App-Entwicklungstestsystem.

6.1.2    Softwareaktualisierung erstellen

Um das App auszuliefern, muss wird im App-Entwicklungstestsystem eine Softwareaktualisierung zu der aktiven Version des Entwicklungsobjekts App erstellt. Diese Version des Entwicklungsobjekts App darf noch keiner anderen Softwareaktualisierung zugeordnet sein. Die Version des Entwicklungsobjektes ist zugleich auch die Version des exportieren Apps.

Beim Export wird eine Softwareaktualisierung erstellt. Dieser werden alle aktiven Versionen der Entwicklungsobjekte aus dem Namensraum der App und die App selbst zugeordnet. Bei einigen Entwicklungsobjekten werden auch historische Versionen mit aufgenommen. Zusätzlich sind auch die übergeordneten Namensräume enthalten, damit diese bei der ersten Installation ebenfalls mit den richtigen Identitäten erstellt werden. Zu einer App gehören auch Entwicklungsobjekte im UPD und NLS Namensraum. Diese werden ebenfalls in die Softwareaktualisierung aufgenommen.

6.1.3    Abhängigkeiten übernehmen

Die Entwicklungsobjekte einer App können andere Entwicklungsobjekte referenzieren. Diese Referenzen werden benutzt um die Softwareaktualisierungen zu ermitteln, die die referenzierten Objekte beinhalten. Diese Softwareaktualisierungen werden vorausgesetzt, wenn die App in einem Zielsystem installiert wird.

In der Regel sind diese Anforderungen recht niedrig, da ein App-System einen möglichst alten Stand haben sollte. In einigen Fällen ist es aber erforderlich, in das App-System Softwareaktualisierungen für Korrekturen einzuspielen. Diese Korrekturen können die Mindestvoraussetzungen an ein System, in dem die App eingespielt, wird anheben. Im ungünstigsten Fall muss das Zielsystem erst auf diesen Stand angehoben werden, bevor die App eingespielt werden kann. In einigen Fällen ist das nicht möglich, da z. B. das vorgelagerte System die entsprechenden Softwareaktualisierungen noch nicht freigegeben hat.

Für den Fall, dass die in das App-System eingespielten Korrekturen keinen Einfluss auf die Lauffähigkeit des Apps haben, besteht die Möglichkeit die ermittelten Abhängigkeiten zu verwerfen und statt deren die Abhängigkeiten der vorherigen App Version zu übernehmen. Dieser Vorgang kann nicht rückgängig gemacht werden und sollte nicht leichtfertig angewendet werden.

Mit der Übernahme der Abhängigkeiten lassen sich allerdings auch Softwareaktualisierungen erstellen, die im Zielsystem möglicherweise nicht lauffähig sind, da benötigte Entwicklungsobjekte fehlen. Diese Prüfung, die diesen Fehler verhindern soll, wird mit der Übernahme der Abhängigkeiten zum Teil ausgehebelt.

Daraus resultierende Supportleistungen sind auf jeden Fall kostenpflichtig.

6.1.4    Softwareaktualisierung exportieren

Im letzten Schritt wird die Softwareaktualisierung exportiert. Bei diesem Vorgang wird die Softwareaktualisierung in Form von Dateien abgelegt. Der Vorgang kann beliebig oft wiederholt werden.

Wenn Abhängigkeiten nachträglich übernommen werden, so muss die Softwareaktualisierung erneut exportiert werden.

7              Testen von Apps

Auf dem App-Entwicklungstestsystem kann die Funktion einer App getestet werden. Zusätzlich zu diesen Tests wird empfohlen, die Installation der exportierten App zu testen. Hierfür wird ein Kundenentwicklungssystem benötigt (Entwicklungsstufe 6). Erst nachdem dieser Test erfolgreich abgeschlossen ist, sollte die App für die Auslieferung freigegeben werden.

8              Sonstiges

8.1        Lizenzierung

An einer App kann ein Lizenzschlüssel eingetragen werden. Über die Lizensierung kann eine App ein- und ausgeschaltet werden.

Wenn die App nicht lizensiert ist, so ist die App für den Anwender quasi nicht sichtbar. Die Logik der App wird in diesem Fall nicht automatisch aufgerufen.

Die Lizenzierung erfolgt zentral beim Semiramis-Support. Eigene Lizenzschlüssel können in einem App-System nicht erfasst werden. Werden Lizenzschlüssel benötigt, so können diese über den Semiramis-Support bestellt werden.

8.2        Deinstallation

Eine Deinstallation von Apps ist derzeit nicht möglich. Soll ein App abgeschaltet werden, so ist dies nur über die Lizenz machbar.

8.3        Wartung von älteren App-Versionen

Die parallele Wartung von Apps innerhalb des gleichen Releases ist möglich. Die parallele Wartung von Apps wird in der Dokumentation Einführung: Softwarelogistik beschrieben.

8.4        Releasezyklus

Ein App-Entwicklungssystem ist an den normalen Transportweg von Semiramis angeschlossen. Ändert das versorgende System sein Release, so wird bei Aktualisierungen des App-Systems dieses auch auf das neue Release angehoben.

Ein App-Entwicklungssystem ist an den Standard-Release-Zyklus von Semiramis gebunden. Allerdings kann es mehrere parallele Apps Systeme geben, auch mehrere pro Release.