1 Kurzbeschreibung
Ein System kann auf vielfältige Weise angepasst werden. Über die Anwendung „Entwicklungsobjekte“ kann sehr tiefgreifend Einfluss auf die Funktionen genommen werden. Diese Änderungen bzw. Erweiterungen können nur für einzelne oder eine Gruppe von Kunden vorgenommen werden, je nachdem, auf welchem Entwicklungssystem die Eingriffe erfolgen.
Die im System integrierte Softwarelogistik wird verwendet, um Erweiterungen und Korrekturen von einem System in nachfolgende Systeme zu transportieren. Als Transportmedium werden Softwareaktualisierungen verwendet.
In dieser Dokumentation wird beschrieben, welche Möglichkeiten die Softwarelogistik bietet. Es wird beschrieben, wie die Systeme zueinander stehen und wie die Softwareaktualisierungen von einem System zum anderen gelangen.
2 Voraussetzungen
Zum Verständnis dieser Dokumentation werden grundlegende Kenntnisse über Entwicklungsobjekte und deren Versionierung sowie Entwicklungsaufgaben benötigt.
3 Begriffsbestimmung
Adaptierung
Eine Adaptierung ist eine Anpassung des vorhandenen Systemstandes. Neue Entwicklungsobjekte werden hinzugefügt oder bestehende Entwicklungsobjekte verändert. Dabei werden Funktionalitäten aus dem Standard erweitert oder verändert.
Branchenlösung
Eine Partnerentwicklung, die Erweiterungen zur Anpassung an eine spezielle Branche enthält. Technisch gesehen unterscheiden sich Partnerentwicklung und Branchenlösung nicht.
Code-Refresh
Die Code-Refreshes enthalten alle Metadaten zu den transportierten Entwicklungsobjekten sowie die kompilierten Java-Klassen. Ein Code-Refresh enthält keine Java-Sourcen, Texte oder Hilfe-Sourcen.
Entwicklungssystem
Entwicklungssysteme dienen der (Neu-)Entwicklung und Adaptierung. In Entwicklungssystemen können Entwicklungsobjekte geändert und angelegt werden. Ein Entwicklungssystem versorgt nachgelagerte Systeme mit Softwareaktualisierungen.
Export-Ordner
Im Ordner /refreshes/export im „semiramis“-Verzeichnis schreibt das System die exportierten Softwareaktualisierungen.
Help-Refresh
Ein Help-Refresh enthält die in einer Softwareaktualisierung geänderten Hilfe-Sourcen. Zu jedem Code-Refresh kann es für jede Sprache ein Help-Refresh geben. Im Allgemeinen werden Hilfe-Sourcen nicht an nachgelagerte Systeme ausgeliefert.
Import-Ordner
Im Ordner /refreshes/import im „semiramis“-Verzeichnis werden die zu einer Softwareaktualisierung gehörenden Dateien vor dem Import abgelegt.
Internes System/Supportsystem
Das Comarch-ERP-Enterprise-System, auf dem der zentrale Entwicklungsauftrags-Service aktiv ist, wird auch als internes System bezeichnet. Das interne System/Supportsystem dient zur Koordination und Dokumentation der Entwicklung und der dazugehörigen Supportauslieferungen (Softwareaktualisierungen). Auf diesem System werden Supportanfragen, Entwicklungsaufträge und Supportauslieferungen erstellt sowie Softwareaktualisierungen zum Download für nachgelagerte Systeme bereitgestellt. Das System sollte diese Aufgaben für alle Systeme übernehmen. Daher wird im Allgemeinen nur ein internes System/Supportsystem benötigt.
Partnerentwicklung
Eine nicht kundenspezifische Erweiterung oder Adaptierung des Comarch-ERP-Enterprise-Standard-Systems, die nochmals adaptiert werden kann, z. B. eine Branchenlösung oder eine App.
Produktivsystem
Das Produktivsystem ist das beim Kunden befindliche System für den Echtbetrieb. Dieses System enthält die Echtdaten des Kunden und ist auf dem Transportweg das letzte System, das eine Softwareaktualisierung erhält.
Qualitätssicherungssystem
Ein Qualitätssicherungssystem ist ein spezielles Testsystem. In dieses System werden alle Softwareaktualisierungen aus der vorgelagerten Entwicklung eingespielt und getestet. Das System sollte immer den aktuellsten Stand an Softwareaktualisierungen enthalten.
So sollte zum Beispiel ein Partner in sein QS-System alle Softwareaktualisierungen aus der Standardentwicklung einspielen. Auf diesem System kann er die für Ihn relevanten Anwendungen überprüfen. Wenn in Systemen, die eigene Adaptierungen enthalten, ein Fehler auftritt, dann kann auf diesem System überprüft werden, ob der Fehler schon im Standard enthalten ist. Dafür ist ein aktueller Stand an Softwareaktualisierungen nötig, da sonst nicht erkannt wird, ob der Fehler schon beseitigt wurde.
Release
Release hat zwei Bedeutungen:
1. Ein Release ist eine Softwareauslieferung, die alle notwendigen Entwicklungsobjekte, bestimmte Softwarekomponenten und Informationen enthält, um ein neues ERP-System mit einem freigegebenen, definierten Entwicklungsstand installieren zu können. Darüber hinaus enthält ein Release die notwendigen Werkzeuge und Informationen, um ein vorhandenes System zu aktualisieren und auf den Entwicklungsstand des neuen Release zu bringen.
2. Ein von der Comarch Software und Beratung AG freigegebener, definierter Entwicklungsstand wird als Release bezeichnet. Jedes Release wird durch eine eindeutige Bezeichnung identifiziert.
Softwareaktualisierung
Logische Einheit, die Versionen von Entwicklungsobjekten zwischen Systemen transportiert. Zu jeder Softwareaktualisierung können mehrere Dateien entstehen, das Code-Refresh (Endung „.cr“), das Source-Refresh (.sr) sowie pro Sprache ein Help-Refresh (.hr) und ein Text-Refresh (.tr).
Jede Softwareaktualisierung lässt sich durch Release, ID und Ursprungs-Repository (Exportpräfix, z. B. „babel“) eindeutig identifizieren. Partner können Softwareaktualisierungen erzeugen, um kundenspezifische Änderungen und eigene Standard-Erweiterungen ausliefern.
Softwareaktualisierungen enthalten Fehlerkorrekturen bzw. Erweiterungen, die für ein bestimmtes Release ausgeliefert werden. Pro Release können beliebig viele Softwareaktualisierungen erzeugt werden.
Zwei Klassen von Softwareaktualisierungen werden unterschieden: System-Code (SYS-Softwareaktualisierungen) und Anwendungs-Code (APP-Softwareaktualisierungen). SYS-Softwareaktualisierungen umfassen die Entwicklungsobjekte aus den Namensräumen unterhalb von „com.cisag.pgm“ und „com.cisag.sys“, sowie unterhalb der zugehörigen Unternamensräume aus „com.cisag.archive“ und „com.cisag.nls“. Alle anderen Entwicklungsobjekte werden mit APP-Softwareaktualisierungen transportiert. Im Speziellen sind das alle Entwicklungsobjekte, die nicht von Comarch angelegt wurden. Im Gegensatz zu APP-Softwareaktualisierungen enthalten SYS-Softwareaktualisierungen keine Entwicklungsobjekte vom Typ „Java-Klasse“. Diese sind für den System-Code in der System-Engine enthalten.
Source-Refresh
Ein Source-Refresh enthält die in einer Softwareaktualisierung geänderten Java-Sourcen. Zu jedem Code-Refresh gibt es maximal ein Source-Refresh. Die Lizenz bestimmt, ob auf einem System Source-Refreshes installiert werden können.
Sprachaktualisierung
Eine Sprachaktualisierung ist eine spezielle Softwareaktualisierung, die alle aktiven Texte zu einer Sprache enthält.
Standard-System
Als Standard-System wird ein von Comarch ausgeliefertes System oder ein aus einer Partnerentwicklung stammendes System bezeichnet, an dem noch keine Adaptierungen vorgenommen wurden.
Systemfamilie
Eine Systemfamilie ist eine Menge von Comarch-ERP-Enterprise-Systemen, die alle denselben Release-Stand haben. Der Transportweg für Softwareaktualisierungen ist innerhalb einer Familie fest definiert.
Systemlandschaft
Alle Systemfamilien bilden zusammen die Systemlandschaft. Die Systemfamilien innerhalb einer Systemlandschaft können verschiedene Release-Stände haben. Innerhalb einer Systemlandschaft sollte genau ein internes System existieren, das von allen zu dieser Systemlandschaft gehörenden Systemen benutzt wird. Darüber hinaus wird auch die Aufteilung der verschiedenen Komponenten einer Installation, wie Datenbank, ERP-System-Application-Server, ERP-System-Output-Manager etc. als Systemlandschaft bezeichnet.
Testsystem
In einem Testsystem kann nicht entwickelt werden, das heißt, Entwicklungsobjekte können nicht verändert oder angelegt werden. In einem Testsystem erfolgt ausschließlich der Test von eingespielten Softwareaktualisierungen und den damit verbundenen Entwicklungen oder Korrekturen. Des Weiteren können die eingespielten Softwareaktualisierungen an nachgelagerte Systeme weiter gegeben werden.
Text-Refresh
Ein Text-Refresh enthält die in einer Softwareaktualisierung geänderten Texte Zu jedem Code-Refresh kann es für jede Sprache ein Text-Refresh geben. Die Lizenz bestimmt, ob zu welchen Sprachen ein System Text-Refreshes importieren kann.
Vorgelagertes/nachgelagertes System
Ein System „b“ ist einem System „a“ nachgelagert, wenn es Softwareaktualisierungen von „a“ erhält und die Versionierungsstufe von „b“ größer ist, als die Versionierungsstufe von „a“. Umgekehrt ist „a“ damit „b“ vorgelagert. Werden in einem vorgelagerten System Softwareaktualisierungen zusammengefasst, ist die Versionierungsstufe dieses Systems 7 und als ein Testsystem einzurichten.
4 Beschreibung
4.1 Entwicklungslandschaft
Eine Entwicklungslandschaft besteht aus einer Menge von Entwicklungs- und Testsystemen. Die Entwicklungssysteme haben ein aufsteigende Versionierungsstufe. Testsysteme werden in der Regel aus Entwicklungssystemen mit Softwareaktualisierungen versorgt und haben immer die Versionierungsstufe 7.
Je größer die Versionierungsstufe eines Entwicklungssystemes ist, desto spezieller ist dessen Verwendungszweck. Ein Entwicklungssystem der Versionierungsstufe 6 enthält speziell für einen Kunden angepasste Entwicklungen. Diese Systeme werden deshalb auch als Kundenentwickungssysteme bezeichnet. Als Branchenentwicklungssysteme werden Systeme der Versionierungsstufe 3 bezeichnet, da diese Entwicklungen beinhalten, die für mehr als einen Kunden genutzt werden soll. Die Versionierungstufen 4 und 5 lassen sich zur weiteren strukturellen Abbildungen nutzen, z.B. kann auf Stufe 3 ein übergeordnetes System eingerichtet werden, welches allgemeine Funktionalitäten bereitstellt, während die konkrekte Branchenausrichtung erst in Stufe 4 oder 5 erfolgt. Genauso ist es möglich die Kundenentwicklung in Stufe 5 zu erstellen und dem Kunden ein eigenes Entwicklungssystem auf Stufe 6 bereitzustellen. Der Verwendungszweck und die Bezeichung des Systems ist von untergeordneter Rolle. Wichtig ist ausschließlich, dass die Entwicklungssysteme in aufsteigender Reihenfolge angeordnet sind.
Jedem Entwicklungssystem können ein oder mehrere Testsysteme folgen. Von diesen kann maximal eines in der Auslieferungskette liegen, d. h. alle Softwareaktualisierungen des Entwicklungssystems müssen, damit diese in das dem Testsystem nachgelagerte System gelangen können, in das Testsystem eingespielt und exportiert werden. Neben der Möglichkeit in einem Testsystem Tests unabhängig vom aktuellen Stand des Entwicklungssystem durchzuführen, lassen sich auf diesen Systemen Softwareaktualisierungen zusammenfassen. Dies bedeutet, dass die Möglichkeit besteht, mehrere importierte Softwareaktualisierungen in eine exportierte Softwareaktualisierung umzuwandeln. In das nachfolgende System braucht dann nur eine, bzw. eine kleinere Anzahl von Softwareaktualisierungen eingespielt zu werden.
App-Entwicklungssysteme haben immer die Versionierungsstufe 2. Im Gegensatz zu den anderen Entwicklungssystemen können in ein App-Entwicklungssystem auch Softwareaktualisierungen aus höheren Versionierungsstufen (bis einschließlich Versionierungsstufe 5) eingespielt werden. Die aus diesem System erstellen Apps lassen sich anschließen nur in Kundenentwicklungssysteme (Versionierungstufe 6) einspielen, die mindestens den gleichen Softwarestand haben, wie das App-Entwicklungssystem. Dadurch ist es möglich, z. B. ein App basierend auf einer Branchenentwicklung zu realisieren. Die App kann nur in Kundenentwicklungsysteme eingespielt werden, die von diesem Branchenentwicklungssystem versorgt wurden.
Hinweis:
Beachten Sie bitte die Hinweise zu parallelen Entwicklungssystemen und Apps.
Versionierungsstufe | Verwendung | Bezeichnung |
1 | Standard-Entwicklung | Entwicklungssystem |
2 | App-Entwicklung | App-Entwicklungssystem |
3 | Partner | Branchenentwicklung-Entwicklungssystem |
4 | Reserviert | |
5 | Partner-Entwicklungssystem oder Kundenadaptierungssystem. Für die Kaskadierung von Entwicklungen. | |
6 | Partner, Kunde | Kunden-Adaptierungssystem |
7 | Standard-Entwicklung, Partner, Kunde | Produktivsystem/Testsystem |
Klassifizierung der Systeme
Die Systeme innerhalb der Hierarchie lassen sich in verschiedene Klassen unterscheiden:
- Entwicklungssystem
In einem Entwicklungssystem können Entwicklungsobjekte geändert und angelegt werden. Ein Entwicklungssystem versorgt nachgelagerte Systeme mit Entwicklungen.
- App-Entwicklungssystem
In einem App-Entwicklungssystem können Apps geändert und angelegt werden. Ein App-Entwicklungssystem versorgt ein nachgelagertes App-Testsystem.
- Testsystem- bzw. Produktivsystem
Mit diesen Systemen kann keine Entwicklung betrieben werden, d. h., Entwicklungsobjekte können nicht verändert oder angelegt werden.
In einem Testsystem erfolgt ausschließlich der Test von eingespielten Softwareaktualisierungen und den damit verbundenen Entwicklungen oder Korrekturen. Des Weiteren können die eingespielten Softwareaktualisierungen an nachgelagerte Systeme weitergegeben werden.
In einem Produktivsystem erfolgt der Echtbetrieb.
4.2 Softwareaktualisierungen
4.2.1 Anlage einer Softwareaktualisierung
Eine neu angelegte Softwareaktualisierung befindet sich im Status „Offen“. Normalerweise durchläuft sie danach die Status „Freigegeben“ und „Exportiert“. Solange die Softwareaktualisierungen offen ist, können weitere Entwicklungsobjekte hinzugefügt werden. Wenn eine Entwicklungsaufgabe aktiviert wird, dann wird automatisch eine neue Softwareaktualisierungen erzeugt, falls keine Softwareaktualisierung existiert, die:
- offen ist und
- aus einer Entwicklungsaufgabe zum selben Entwicklungsauftrag entstanden ist.
Alle Versionen von Entwicklungsobjekt in der Entwicklungsaufgabe werden dieser neuen Softwareaktualisierung oder der gefunden Softwareaktualisierung zugeordnet. Im Allgemeinen werden alle Entwicklungsaufgaben und die darin enthaltenen Entwicklungsobjekte, die sich auf einen Entwicklungsauftrag beziehen, zu einer Softwareaktualisierung zusammengefasst. Wenn die Softwareaktualisierung zu einem Entwicklungsauftrag bereits freigegeben ist, dann wird eine neue Softwareaktualisierung zu diesem Entwicklungsauftrag erzeugt.
Alle Entwicklungsaufgaben erhalten eine Referenz auf die zugeordnete Softwareaktualisierung. Somit ist es nicht möglich, einer Entwicklungsaufgabe zwei verschiedene Softwareaktualisierungen zuzuordnen.
Nach der Erzeugung der Softwareaktualisierung kann diese freigegeben werden. In diesem Zustand können keine weiteren Entwicklungsobjekte der Softwareaktualisierung durch Entwicklungsaufgaben zugeordnet werden.
Nach der Freigabe erfolgt der Export der Softwareaktualisierung. Bei diesem Vorgang werden das Code-Refresh, Source-Refresh, das Text-Refresh und das Hilfe-Refresh erzeugt (siehe Abschnitt „Softwareaktualisierungs-Dateien“).
Hinweis:
Dieser Vorgang kann beliebig wiederholt werden, solange nicht mit dem Tool rgzrep Metadaten gelöscht wurden.
4.2.2 Installations-Reihenfolge von Softwareaktualisierungen
Bei der Installation von Softwareaktualisierungen in andere Systeme muss die Konsistenz der Metadaten gewährleistet werden. Das heißt, es dürfen keine Entwicklungsobjekte eingespielt werden, die abhängig von Entwicklungsobjekten sind, die noch nicht im System vorhanden sind bzw. nicht mit eingespielt werden. Bei einigen Entwicklungsobjekttypen sind auch die Vorgängerversionen beim Einspielen zwingend notwendig.
Der Aufbau der Abhängigkeiten zwischen Softwareaktualisierungen erfolgt in Entwicklungssystemen über den Verwendungsnachweis. Wenn ein Entwicklungsobjekt andere Entwicklungsobjekte verwendet, dann wird geprüft, welchen Softwareaktualisierungen die Entwicklungsobjekte zugeordnet sind. Zu diesen Softwareaktualisierungen wird eine Abhängigkeit aufgebaut.
Beispiel:
Entwicklungsobjekt A Version 2.0 verwendet Entwicklungsobjekt B Version 3.0. Somit ist die Softwareaktualisierung, in der sich Entwicklungsobjekt A Version 2.0 befindet, abhängig von der Softwareaktualisierung, in der sich Entwicklungsobjekt B Version 3.0 befindet.
In System der Versionierungsstufe 7 werden die Abhängigkeiten zwischen den importierten Softwareaktualisierungen auf die exportierten Softwareaktualisierungen übertragen.
Bei einigen Entwicklungsobjekten werden auch die Vorgängerversionen im System benötigt. Die Softwareaktualisierungen bauen somit eine Abhängigkeit zu den Softwareaktualisierungen auf, in der sich die Vorgängerversionen befinden.
Der Aufbau der technischen Abhängigkeiten erfolgt automatisch bei der Aktivierung der Entwicklungsaufgabe.
Zusätzlich können noch manuell Abhängigkeiten hinzugefügt werden. Diese begründen sich meist auf fachliche Zusammenhänge. Das Hinzufügen und Löschen von fachlichen Abhängigkeiten ist nur möglich, solange die Softwareaktualisierung nicht freigegeben ist. Beim Installieren der Softwareaktualisierungen wird geprüft, ob alle direkt abhängigen Softwareaktualisierungen bereits im System sind. Ist das nicht der Fall, dann müssen die abhängigen Softwareaktualisierungen ebenfalls importiert werden. Die Prüfung der Abhängigkeiten erfolgt nicht rekursiv. Das heißt, werden abhängige Softwareaktualisierungen hinzugenommen, werden auch dafür die Abhängigkeiten ermittelt. Dies kann dazu führen, dass die hinzugekommenen Softwareaktualisierungen neue Fehlermeldungen wegen Abhängigkeiten erzeugen.
Die Prüfung der Abhängigkeiten erfolgt auch bei der Freigabe einer Softwareaktualisierung. Diese ist nur möglich, wenn die abhängigen Softwareaktualisierungen ebenfalls freigegeben wurden.
Zusätzlich zu den Abhängigkeiten kann aus technischen Gründen für System-Softwareaktualisierungen eine feste Installationsreihenfolge erzwungen werden. Softwareaktualisierungen mit fester Installationsreihenfolge werden immer einzeln, in der vorgegebenen Reihenfolge, installiert.
Eine feste Installationsreihenfolge wird nur für Änderungen am System-Code von Comarch ERP Enterprise verwendet. Für Adaptierungen wird das Erzwingen einer festen Installationsreihenfolge nicht benötigt.
4.2.3 Änderung von Java-Klassen
Mittels Softwareaktualisierung werden geänderte Java-Klassen in kompilierter Form an Partner bzw. Kunden weitergegeben und, falls möglich (Partner hat keine Änderungen vorgenommen), ohne Neukompilierung im Ziel-System aktiviert. Dies funktioniert nur dann, wenn die geänderten Klassen kompatibel sind. Folgende Konventionen sind daher von den Programmierern einzuhalten:
- Das Löschen oder Umbenennen von Konstanten, Methoden, Instanz- und Klassenvariablen, welche public oder protected sind, ist nicht zulässig.
- Das Ändern von Interfaces ist nicht erlaubt; auch das Löschen einer Methode darf nicht vorgenommen werden.
- Das Ändern von Signaturen bei Methoden, die public oder protected sind, ist verboten.
- Bei Konstanten, die public oder protected sind, dürfen die Werte nicht geändert werden.
- Klassen und Methoden, die public oder protected sind, dürfen nicht nachträglich als final deklariert werden.
4.2.4 Export und Historie von Softwareaktualisierungen
Werden die Softwareaktualisierungen in ein System eingespielt, können diese nach der Installation wieder exportiert werden. Die exportierten Softwareaktualisierungen können dann in die nachgelagerten Systeme eingespielt werden.
In Systemen der Stufe 7 werden Softwareaktualisierungen nicht automatisch erzeugt. In diesen Systemen können abhängig vom Verwendungszweck Softwareaktualisierungen zu neuen Softwareaktualisierungen zusammengefasst werden, oder die importierten Softwareaktualisierungen werden an weitere Systeme verteilt.
Bei dem Export und der Zusammenfassung von Softwareaktualisierungen wird eine Historie geschrieben. Über diese kann nachvollzogen werden, aus welchen Softwareaktualisierungen, die aktuelle Softwareaktualisierung entstanden ist. Die Historie wird mit ausgeliefert und ist dann auch im Ziel-System verfügbar.
4.2.5 Konflikte beim Einspielen von Softwareaktualisierungen
Einige Entwicklungsobjekttypen lassen sich in einem Entwicklungssystem ändern, auch wenn sie in einem vorgelagertem System angelegt wurden, dabei entstehen Branches. Die Notwendigkeit von Branches ergibt sich durch folgende Fälle: Behebung von Fehlern sowie Anpassung des Standard-Systems durch Partner. Wird ein Entwicklungsobjekt eingespielt, zu dem ein Branch in diesem System existiert, entsteht ein Konflikt. Die Entwicklungsaufgabe zu Bearbeitung der Konflikte wird automatisch erzeugt, siehe unten.
Folgendes Beispiel zeigt die Änderungshistorie eines Entwicklungsobjekts, das in der Comarch-ERP-Enterprise-Standard-Entwicklung angelegt wurde, in einem Partner-System für eine Branche:
Standard-Entwicklung | Entwicklung Partner |
1.0:5.3.0: (Neuanlage) | |
1.0.1:5.3.0 (Modifikation) | |
1.0.2:5.3.0 (Fehlerbehebung) | |
1.0.3:5.3.0 (Erweiterung) | |
2.0:5.3.0 (Erweiterung/Korrektur) | |
2.0.1:5.3.0 (Merge: 2.0:5.3.0 und 1.0.3:5.3.0) |
Alle Softwareaktualsierungen, die Entwicklungsobjekte enthalten, die einen Konflikt auslösen, werden zusammen mit den Konfliktversionen als eine Softwareaktualsierung aus dem Entwicklungssystem ausgeliefert. Nur so kann sichergestellt werden, dass die Anpassungen zusammen mit dem importierten Softwareaktualisierungen in die nachfolgenden Systeme eingespielt werden.
Beispiel:
Vier Softwareaktualisierungen werden in ein Entwicklungssystem eingespielt. In dreien von ihnen befinden sie Entwicklungsobjekte, die auf dem System angepasst wurden. Es wird eine Konfliktaufgabe erzeugt, in der für jedes der betroffenen Entwicklungsobjekten eine Branchversion enthalten ist. Zu der Entwicklungsaufgabe gibt es genau eine Softwareaktualisierung, die alle Versionen der Entwicklungsobjekte der drei importierten Softwareaktualisierungen und die in der Aufgabe enthaltenen Versionen enthält. Die vierte Softwareaktualsierung wird mit dem gleichen Inhalt exportiert, mit dem sie importiert wurde.
4.2.6 Softwareaktualisierungs-Dateien
Eine Softwareaktualisierung wird in Form einer Zip-Datei gespeichert. Darin enthalten sind ein Code-Refresh, ein Source-Refresh, Text-Refreshes und ggf. Help-Refreshes. Voraussetzung für die Erzeugung der Datei ist, dass die Softwareaktualisierung freigegeben ist. Die Erzeugung der Datei kann beliebig oft wiederholt werden. Auch zu einem späteren Zeitpunkt ist das noch möglich, sofern keine Metadaten durch eine Reorganisation des Archivs gelöscht wurden, die für die Erstellung erforderlich sind.
Die Dateinamen leiten sich aus der Softwareaktualisierung ab:
Format: <exportpräfix>-<release>-<codeClass>-<id>.zip
z. B. babel-5.1.0-app-RFR-123456
exportpräfix | Exportpräfix des exportierenden Systems, z. B. „babel“ |
release | Release, z. B. 5.1.0 |
codeClass | Klasse: „sys“ für System-Code oder „app“ für Anwendungscode-Code |
id | ID der Softwareaktualisierung (10 Stellen, besteht nicht zwingend nur aus Zahl, kann auch der Name einer Supportauslieferung sein, z. B. RFR-123456.). Bei automatischen erzeugten Softwareaktualisierungen ist die id eine fortlaufende Nummer. |
Die Endungen der darin enthaltenen Dateien lauten wie folgt:
.cr | Code-Refresh |
.sr | Source-Refresh |
.<xy>.tr | Text-Refresh für die Sprache <xy> |
.<xy>.hr | Help-Refresh für die Sprache <xy> |
Eine Code-Refresh-Datei enthält die Beschreibung des Softwareaktualisierung (Code-Refresh-Definition), die Information zu welchem Release sie gehört, eine Liste der Versionen von Entwicklungsobjekte (ObjectDirEntry und Version) und zugehörige Metadaten aus den Archiv-Tabellen. Zudem kann eine Liste von Abhängigkeiten zu anderen Code-Refreshes enthalten sein, die vor bzw. zusammen mit diesem Code-Refresh installiert werden müssen. Diese Abhängigkeiten gelten nur für die Code-Refresh-Datei und nicht für die komplette Softwareaktualisierung. Die Source-Refresh-, Text-Refresh und Help-Refresh-Dateien sind nur von der zugehörigen Code-Refresh-Datei abhängig.
Softwareaktualisierungen können neben den Abhängigkeiten weitere Informationen für die Installation enthalten:
- Softwareaktualisierungen können unabhängig von deren Inhalt einen Neustart des Systems erzwingen, in dem sie installiert werden.
- Softwareaktualisierungen können eine feste Installationsreihenfolge erzwingen. Unterschiedliche Softwareaktualisierungen mit fester Installationsreihenfolge werden nicht gemeinsam installiert.
- Softwareaktualisierungen können manuelle Aufgaben umfassen, die nach der Installation durchzuführen sind.
Bei Entwicklungsobjekten des Typs Java-Klasse enthält die Code-Refresh-Datei nur kompilierte Class-Dateien. Die Sourcen sind in der Source-Refresh-Datei enthalten. Die Texte der in der Softwareaktualisierung enthaltenen Entwicklungsobjekte und Hilfedokumente (ohne die Hilfe-Sourcen) sind in den sprachspezifischen Text-Refresh-Dateien enthalten. Die Hilfe-Sourcen werden gesondert in den Help-Refresh-Dateien gespeichert. Ein System kann Source bzw. sprachspezifische Texte nur dann installieren, wenn das System eine Source-Code-Lizenz bzw. die Sprache lizenziert hat.
Enthalten die Business Objects Benutzer-GUIDs, dann werden diese nicht durch eine Zero-GUID ersetzt. Ist ein Benutzer im Ziel-System nicht bekannt (z. B. Benutzer aus der Comarch-ERP-Enterprise-Standard-Entwicklung beim Partner), dann wird dort ein Leer-String auf der Oberfläche ausgegeben. Wenn die Softwareaktualisierung jedoch in einem eigenen System (verteiltes Entwicklungssystem) installiert wird, dann geht diese Information nicht verloren.
4.2.7 Zusammenfassen von Softwareaktualisierungen
In Stufe 7 Systemen ist es möglich, mehrere installierte Softwareaktualisierungen nach bestimmten inhaltlichen Gesichtspunkten zu einer Softwareaktualisierung zusammenzufassen. Dadurch wird verhindert, dass viele kleine Softwareaktualisierungen an die nachfolgenden Systeme ausgeliefert werden, sondern mehrere große Softwareaktualisierungen zu einem bestimmten Kontext. Auf diese Weise kann sichergestellt, dass Softwareaktualisierungen die inhaltlich zusammengehören, eine Einheit bilden. Im Rahmen der Auslieferung werden die Softwareaktualisierungen mit Supportauslieferungen verbunden. Weitere Informationen erhalten Sie in der Dokumentation „Supportauslieferungen“.
Bei der Zusammenfassung werden auch die auch die Abhängigkeiten zwischen den Softwareaktualisierungen neu aufgebaut.
Das folgende Beispiel erklärt den Abhängigkeitsaufbau:
Die Softwareaktualisierung A ist abhängig von Softwareaktualisierung B und Softwareaktualisierung B ist abhängig von Softwareaktualisierung C. Wenn Softwareaktualisierung A und Softwareaktualisierung B zu Softwareaktualisierung A’ zusammengefasst werden, muss Softwareaktualisierung C entweder ebenfalls in Softwareaktualisierung A’ aufgenommen oder zu einer anderen Softwareaktualisierung zusammengefasst werden. Wenn eine Softwareaktualisierung C in die Softwareaktualisierung C’ zusammengefasst wird, dann ist die Softwareaktualisierung A’ abhängig von der Softwareaktualisierung C’.
4.2.8 Deaktivieren von Softwareaktualisierungen
Softwareaktualisierungen vom Typ Import können unter bestimmten Umständen deaktiviert oder vollständig aus dem System gelöscht werden. Jede importierte Softwareaktualisierung wird entweder temporär oder permanent im System gespeichert. Temporäre Softwareaktualisierungen können deaktiviert und gelöscht werden, während permanente Softwareaktualisierungen nicht mehr deaktiviert oder gelöscht werden können. Enthält eine deaktivierte Softwareaktualisierungen Versionen von Entwicklungsobjekten, die vor der Deaktivierung im System aktiv waren, so wird die die Version, die vorher aktiv war, wieder aktiviert. Nach dem Deaktivieren der Softwareaktualisierung verhält sich das System so, als ob die Softwareaktualisierung nicht installiert worden ist.
Die in einer Softwareaktualisierung enthaltenen Entwicklungsobjekte entscheiden darüber, ob eine Softwareaktualisierung temporär gespeichert werden kann. Softwareaktualisierungen, die Business Objects, Views, Datenaktualisierungen oder bestimmte Dateiaktualisierungen enthalten, werden sofort nach der Installation permanent.
Temporäre Softwareaktualisierungen werden unter bestimmten Umständen automatisch permanent:
- Wenn eine permanente von einer temporären Softwareaktualisierung abhängig ist.
- Wenn ein in einer temporären Softwareaktualisierung enthaltenes Entwicklungsobjekts in eine Entwicklungsaufgabe aufgenommen wird.
- Wenn die Versionsinformationen der temporären Softwareaktualisierung reorganisiert werden.
- Wenn ein in einer temporären Softwareaktualisierung enthaltenes Entwicklungsobjekt in eine Entwicklungsaufgabe aufgenommen wird.
Deaktivierte Softwareaktualisierungen bleiben im System und werden bei der Installation der nächsten Softwareaktualisierung erneut aktiviert.
4.2.9 Sprachaktualisierungen
Sprachaktualisierungen enthalten alle Texte einer Sprache zu allen Entwicklungsobjekten des Systems, auf dem die Sprachaktualisierungen erstellt wurden. Mithilfe von Sprachaktualisierungen können Sie eine Anzeigesprache in einem System nachträglich installieren. Bei der Installation einer Sprachaktualisierung treten keine Konflikte oder Abhängigkeiten auf. Wenn eine Sprachaktualisierung in einem System mit einem neueren Versionsstand erzeugt worden ist, dann werden die Texte, bei denen das zugehörige Entwicklungsobjekts noch nicht auf dem System verfügbar ist, nicht auf dem System installiert. Wenn eine Sprachaktualisierung in einem System mit einem älteren Versionsstand erzeugt wird, dann fehlen nach dem Einspielen ggf. die neusten Texte. Die fehlenden Texte können Sie durch das Installieren einer neueren vollständigen Sprachaktualisierung jederzeit nachinstallieren.
Sprachaktualisierungen erzeugen bei der Installation keine importiere Softwareaktualisierung, somit können Sprachaktualisierungen auch nicht deaktiviert werden.
Wenn in einem Partner –oder Kundenentwicklungssystemen angepasste Texte in der zu exportierenden Sprache existieren, dann werden neben den aktiven Texten auch die angepassten Texte mit der Sprachaktualisierung exportiert. Dadurch wird gewährleistet, dass alle Texte des Quellsystems auch im Folgesystem verfügbar sind. Die angepassten Texte werden im Folgesystem als angepasste Texte importiert.
4.3 Releasewechsel und paralleler Betrieb mehrerer Releases
Für die Standardentwicklung werden die Softwareaktualisierungen nicht nur für das aktuelle Release, sondern auch für gewartete Vorgängerreleases ausgeliefert. Für jedes Release gibt es in der Standardentwicklung ein eigenes Auslieferungssystem.
Um einen Releasewechsel durchführen zu können, muss ein System einen Mindeststand erreicht haben. Informationen hierzu werden in den Auslieferungsbegleitschreiben bereitgestellt.
Der Releasewechsel auf das Folgerelease wird durch die Installation von Softwareaktualisierungen, die zu dem Folgerelease gehören, durchgeführt. Mit der Installation der ersten Softwareaktualisierung, die zum Folgerelease gehört, wird der Releasewechsel begonnen. Abgeschlossen ist der Releasewechsel mit dem Einspielen der letzten Softwareaktualisierung, die zur der entsprechenden Auslieferung gehört. Nachdem mit dem Releasewechsel begonnen wurde können keine Softwareaktualisierungen aus dem alten Release mehr installiert werden.
Hinweis:
Ein begonnener Releasewechsel kann nur durch ein Backup des Systems wieder rückgängig gemacht werden.
Hinweis:
Das Releases einer Softwareaktualisierung ist auch im Dateinamen enthalten. Der Dateiname beginnt mit <exportpräfix>-<release>, z. B. ist „babel-5.0.0-…“ eine Auslieferung aus dem Standard des Release 5.0.
Hinweis:
Bevor Sie ein System auf einen neues Release heben, müssen Sie eine neue Folgelizenz für das System installieren. Dieses Lizenz schaltet das neue Release frei. Ist diese Lizenz nicht installiert, können die Softwareaktualisierungen, die zum neuen Release gehören, nicht installiert werden. Wenn Sie ein System nacheinander über mehrere Releases heben möchten, benötigen Sie nicht für jedes einzelne Release eine gesonderte Lizenz. Es reicht in diesem Fall eine Lizenz mit dem höchsten benötigten Release zu installieren.
4.3.1 Wann ist ein Releasewechsel möglich?
Ein Releasewechsel ist mit dem Erreichen des Mindeststandes möglich, dabei ist zu beachten, dass das Folgerelease mindestens über die gleichen Korrekturen und Erweiterungen verfügt. Wird eine Korrektur in einem Release ausgeliefert, so wird diese Korrektur, wenn nötig, auch in den Folgereleases eingebaut und ausgeliefert. Durch die zeitlichen Abläufe und versetzten Auslieferungstermine, steht eine Korrektur deshalb nicht zeitgleich in allen Releases zur Verfügung. Als Regel gilt, dass der Fixstand des Folgereleases mindestens zwei Fixstände neuer sein muss, bezogen auf den Auslieferungszeitpunkt der Korrektur.
Beispiel: Im Release 5.0 wird eine Korrektur ausgeliefert und im Kundenentwicklungssystem installiert. Zu dem Zeitpunkt der Korrekturauslieferung ist im Release 5.1 der Fixstand 5.1 PD Fix02 der aktuellbereitgestellt. Wenn das Kundenentwicklungssystem auf das Release 5.1 gehoben werden soll, so muss mindestens für der Fixstand 5.1 PD Fix04 installiert werden.
Das bedeutet für ein System, dass vor einen Releasewechsel nicht der neueste Stand des aktuellen Systems eingespielt werden darf, da sonst die Gefahr besteht, dass der Releasewechsel nicht durchgeführt werden kann. Dies ist ins besonders beim Wechsel über mehrere Releases zu beachten. Hier addieren sich die Zeiträume.
4.3.2 Aus dem Standard versorgtes System
Grundsätzlich stehen Ihnen zwei Vorgehensweisen zur Verfügung.
4.3.2.1 Variante 1: Systemtopologie beibehalten
Sie können ihre Systemtopologie so belassen wie sie ist:
Releasewechsel ohne Änderung der Systemtopologie
In diesem Fall ändert sich für Sie wenig. Sie müssen lediglich die Importrestriktionen ändern und die Folgelizenz installieren. Dies ist für alle Systeme relevant auf denen Sie wenig adaptiert haben und Sie einfach auf eine neues Releases wechseln können.
4.3.2.2 Variante 2: Paralleles System einrichten
Bei der zweiten Variante duplizieren Sie Ihr vorhandenes System. Anschließend betreiben Sie beide Systeme parallel weiter.
Diese Variante bietet sich in zwei Fällen an:
- Bei dem System handelt es sich z. B. um eine Branchenentwicklung, die mehrere Kundensysteme versorgt. Sie können aber nicht alle nachfolgenden Produktivsysteme auf das neue Release heben.
- Sie haben viele Adaptierungen. In diesem Fall setzen Sie das zweite System auf und heben dieses System auf das neue Release. Anschließend führen Sie im neuen Release die Nacharbeiten durch (Konfliktaufgabe, Tests). Wenn diese Arbeiten abgeschlossen sind, können Sie den Transportweg für die Zielsysteme, die das Release wechseln sollen, umschalten, siehe dazu auch die Abbildung im Abschnitt „Branchenentwicklung mit nachgelagerter Kundenadaptierung“.
Paralleler Betrieb eines Entwicklungssystems in zwei Releases
4.3.3 Vorgängersystem und Zielsystem wurden kopiert
Szenario 2. Das Vorgängersystem wurde kopiert. Es existieren zwei Vorgängersysteme, eines auf Releasestand n und eines auf Releasestand n+1.
Dieses Szenario ermöglicht Ihnen die größtmögliche Flexibilität. Sie haben die Möglichkeit, über mehrere Stufen zu entscheiden, wann Sie welches Release ablösen. Branchenentwicklung (auch zweistufig) und Kundenadaptierung werden parallel in mehreren Releases gewartet. Sie können die Kundenadaptierung gleichzeitig warten und im zweiten System an das neue Release anpassen.
Branchenentwicklung mit nachgelagerter Kundenadaptierung
Vollständiges Szenario bis zum Produktivsystem
Sobald Sie die Kundenadaptierung vollständig auf das neue Release gehoben haben und alle Nacharbeiten und Tests beendet sind (Zeitpunkt T3), kann die Versorgung des Produktivsystems über das neue Release erfolgen. Ab diesem Zeitpunkt wird das Kundenadaptierungssystem auf dem alten Release nicht benötigt und kann entfernt werden.
4.3.4 Keine Änderung der Topologie
Das Vorgängersystem wechselt das Release
Der einfachste Fall ist, wenn das Vorgängersystem sein Release ändert, also kein neues System aufgesetzt wird. Sie müssen nichts an Ihrer System-Topologie ändern. Nur das Release der Softwareaktualisierungen, die das Vorgängersystem exportiert, ändert sich. Dieser Fall ist relevant für:
- Kundenadaptierungen hinter einem Partnerentwicklungssystem, das auf ein neues Releases gehoben wurde.
- Produktivsysteme hinter einer Kundenadaptierung oder hinter einem Branchenentwicklungssystem, wenn dies auf ein neue Release gehoben wurde.
Für Systeme, die direkt aus dem Standard versorgt werden, trifft dieses Szenario nie zu. In diesem Fall wechselt immer das Vorgängersystem.
Sie müssen im Zielsystem nur eine entsprechende Lizenz installieren und ggf. die Importrestriktionen anpassen. Ansonsten verhält sich alles wie in früheren Releases.
4.3.5 Nur eine Änderung in der Topologie
Das Vorgängersystem wechselt das Release
Dies ist das Szenario für Branchenentwicklungen mit nachgelagertem Kundenadaptierungen. Die Branchenentwicklung wird in zwei parallele Entwicklungssysteme aufgeteilt. Die nachgelagerten Kundenadaptierungssysteme werden zu einem beliebigen Zeitpunkt auf das neue Release umgestellt. Dabei kann dieser Zeitpunkt (T) für jedes Kundenadaptierungssystem frei gewählt werden. Dadurch ist es möglich
- den Releasewechsel auf dem Branchenentwicklungssystem durchzuführen und gleichzeitig Kundensystem weiterhin mit Korrekturen und Entwicklungen aus dem alten Release zu versorgen, und
- für jeden Kunden einen eigenen Termin für den Releasewechsel zu bestimmen.
Das alte Branchenentwicklungssystem kann entfernt werden, sobald alle nachgelagerten Produktivsysteme auf das neue Release gehoben wurden.
4.3.6 Das geht nicht
Ein Szenario, das nicht funktioniert.
Zu jedem System muss ein Vorgängersystem existieren, das das gleiche Release hat. Sie können nicht ihre Kundenadaptierungssysteme parallel betreiben, aber ihre Branchenentwicklung nicht. Das gleiche gilt für ihre Branchenentwicklungssysteme. Wenn Sie diese parallel betreiben wollen, müssen Sie ebenfalls das vorgelagerte QA-System, aus dem diese Systeme versorgt werden, parallel betreiben.
4.3.7 Aufsetzen eines Systems aus einer Kopie
Das Duplizieren eines (Entwicklungs-) Systems beinhaltet immer die Kopie des Entwicklungssystems und des zugehörigen Testsystems. In den Abbildungen wird zur Vereinfachung nur das (Gesamt-) System dargestellt. Wenn Sie das erste Entwicklungssystem duplizieren, müssen Sie ebenfalls Ihr QAS-System duplizieren.
Beim Aufsetzen eines Systems aus einer Kopie sind einige Voraussetzungen zu beachten. Dies betrifft den Zustand des Systems das kopiert wird, sowie einige Regeln für das System, das aufgesetzt wird.
Für das System, das kopiert wird gilt:
- Alle Entwicklungsaufgaben müssen aktiviert sein.
- Alle Softwareaktualisierungen müssen exportiert sein.
- Alle Installationsvorgänge müssen erfolgreich abgeschlossen sein.
Für die Kopie gilt:
- Die Identitätsliste muss gelöscht werden (wrkidysrv –delIdyLst) .
- Das System muss die gleiche Identitätsliste benutzen, wie das System aus dem es entstanden ist.
- Nach der Installation des neuen Releases kann die Identitätsliste mit cpyIdyLst auf das neue System kopiert werden.
Soll das neue System
- Entwicklungsobjekte mit dem alten System austauschen,
- OLTP-Datenbanken des alten Systems lesen können
- oder später das gleiche Folgesystem versorgen,
so müssen die Systeme dieselbe Identitätsliste benutzen.
Wenn mehrere Releases desselben Systems in Wartung sind („parallele Entwicklung“), dann müssen diese Systeme unbedingt dieselbe Identitätsliste verwenden. Das gilt auch, wenn drei oder mehr Releases des gleichen Systems gewartet werden. Die Systeme müssen alle auf dieselbe Identitätsliste zugreifen.
Hinweis:
Beim Starten eines Messageservers eines Entwicklungsystems wird geprüft, ob es weitere Systeme gibt, die dasselbe Entwicklungspräfix benutzen. Benutzen diese Systeme nicht die gleiche Identitätsliste wird der Start mit einer Fehlermeldung abgebrochen. Sie können mit Hilfe einer Property dieses Verhalten übersteuern. Beachten Sie in diesem Fall, dass Fehler beim Aufsetzen der Identitätsliste erst spät bemerkt werden, z. B. beim Umstellen des Folgesystems auf das neue Release, und ggf. nicht zu beheben sind.
4.3.8 Parallele Wartung
Mit der Möglichkeit zwei Releases oder mehrere Apps parallel zu betreiben bzw. zu warten, entsteht auch die Notwendigkeit Korrekturen oder Entwicklungen auf beiden Systemen zu synchronisieren. In den meisten Fällen, werden Sie dabei Korrekturen vom alten Release (Release n) in das neue Release (n + 1) übernehmen. Dies geschieht über den Entwicklungsdient, der Dienst sperrt auf dem Folgesystem beim Aktivieren der Aufgabe die in der Aufgabe befindlichen Entwicklungsobjekte und überträgt deren Inhalte, wenn ein Entwicklungsobjekt im Zielsystem noch nicht verändert wurde. Der Entwicklungsdienst ist in der parallelen Wartung zwingend erforderlich. Er überträgt z. B. die für einen Releasewechsel notwendigen Informationen über die Schemata der Business Objekte.
Inhaltlicher Vergleich im Entwicklungsdienst
Bei der Übertragung, eines Entwicklungsobjekts von einem System in das nächste, wird überprüft, ob das Entwicklungsobjekt im Zielsystem verändert wurde. Dazu wird die wird die aktive Version im Quellsystem mit der gesperrten oder, falls keine gesperrte Version existiert, mit der aktiven Version im Zielsystem verglichen. Wurde die Version im Zielsystem gegenüber dem Quellsystem nicht verändert, werden die Inhalte der Version ebenfalls übertragen. Der inhaltliche Vergleich stellt sicher, dass die Inhalte eines Entwicklungsobjekt, das mehrmals im Quellsystem geändert wurde, jedes Mal in das Zielsystem übertragen werden, wenn im Zielsystem lediglich die Änderungen aus dem Quellsystem übernommen wurden.
Dieser inhaltliche Vergleich vergleicht die technischen Eigenschaften des Entwicklungsobjekts. Entwicklungsobjekte, die optisch gleich aussehen, können trotzdem unterschiedlich sein. Zum Beispiel kann ein Bericht, der nur geöffnet und ohne Änderung gespeichert wird, als geändert erkannt werden, da Crystal Reports dabei das Dokument verändern kann. Bei Java-Klassen werden nur die Sourcen verglichen. Formatierungen und Revision-Information werden vorher so weit möglich entfernt. Trotzdem kann es vorkommen, dass zwei nur unterschiedlich formatierte Sourcen als verändert erkannt werden.
In der Anwendung Entwicklungsobjekte, auf dem Reiter Information, wird angezeigt aus welcher Version die gesperrte Version entstanden ist, wenn Sie durch die parallele Wartung gesperrt wurde.
4.3.9 Parallele Wartung in der App-Entwicklung
Grundsätzlich arbeitet die parallele Wartung in der App-Entwicklung wie in den vorangegangenen Kapiteln beschrieben. Im Gegensatz zu der Entwicklung auf Branchen- und Kundenadaptierungssytemen können mehrere Folgesysteme beteiligt sein. Jede App, die auf einem System entwickelt wird, kann ein anderes Folgesystem haben. Dies wird über das Systemcockpit durch die Zuordnung der Module zu Systemgruppen festgelegt. In diesem Fall muss der Codestand des Entwicklungsauftragssystems mindestens 5.1 sein, da mehrere Folgeaufträge in unterschiedlichen Releases verwaltet werden müssen.
Hinweis:
App-Entwicklungssysteme werden nicht als Kopie eines existierenden App-Entwicklungssystems aufgesetzt. Sie werden aus einer Standardauslieferung bzw. aus der Kopie einer Branchenentwicklung aufgesetzt. Anschließend werden die Apps über die Anwendung „Cockpit: Apps übertragen“ in das neue System übertragen.
4.3.10 Entwicklungsdienst
Der Entwicklungsdienst dient zum Abgleich der Korrekturen zwischen Entwicklungssystemen. Der Entwicklungsdienst wird beim Aktivieren einer Aufgabe angestoßen. Ist ein Folgesystem definiert, werden folgende zusätzliche Aufgaben durchgeführt:
- Anlegen eines Folgeentwicklungsauftrags. Dies ist eine Kopie des ursprünglichen Auftrags für das Release des Folgesystems.
- Anlegen einer Entwicklungsaufgabe auf dem Folgesystem. Diese ist dem Bearbeiter, der gerade die Entwicklungsaufgabe aktiviert, zugeordnet.
- Ermitteln welche Entwicklungsobjekte, die in dieser zu aktivierenden Aufgabe gesperrt sind, auf dem Folgesystem nicht gesperrt sind.
- Diese Entwicklungsobjekte in der Folgeentwicklungsaufgabe sperren und als nicht entfernbar kennzeichnen.
- Entwicklungsobjekte, die schon in anderen Aufgaben gesperrt sind, als nicht entfernbar aus diesen Aufgaben markieren.
- Rückmeldung an das aktivierende System, welche Versionen gesperrt wurden.
- Schreiben dieser Abhängigkeiten in die zur Entwicklungsaufgabe gehörenden Softwareaktualisierung.
Ist für das Folgesystem wieder ein Folgesystem definiert, setzt sich der Vorgang fort, sobald die Folgeentwicklungsaufgabe aktiviert wird.
Um den Entwicklungsauftragsdienst zu aktivieren muss auf dem Folgesystem der Verarbeitungsauftrag Entwicklungsdienst gestartet werden. Das Folgesystem wird über das Systemcockpit angegeben, siehe Systemgruppen und Entwicklungsgruppen.
4.3.11 Entwicklungsdienst auf App-Entwicklungssystemen
Der Entwicklungsdienst funktioniert in der App-Entwicklung grundsätzlich wie in obigen Abschnitt beschrieben. Unterschiede ergeben sich, da ein System mehrere Folgesysteme haben kann, pro App kann es ein Folgesystem geben. Wird eine Aufgabe aktiviert, werden die oben beschriebene Vorgehensweise für alle Entwicklungsobjekte in der Aufgabe, gruppiert nach Apps durchgeführt. Die Aufgabe kann erst aktiviert werden, wenn die parallele Wartung, für alle in der Aufgabe enthaltenen Entwicklungsobjekte, erfolgreich durchgelaufen ist.
4.3.12 Konfiguration der parallelen Wartung
4.3.12.1 Systemgruppen
Eine Systemgruppe beschreibt die Topologie eines Entwicklungssystem und zugehöriger Test, bzw. weiterer Entwicklungssysteme.
Möglicher Aufbau einer Systemgruppe
In einer Systemgruppe für Entwicklungssysteme gibt es immer ein Entwicklungssystem (DV). Ein Testsystem (DT) wird empfohlen, ist aber nicht zwingend erforderlich. Es kann festgelegt werden, ob die Auslieferung aus dem DV-System direkt erfolgt, ober ob über das DT-System ausgeliefert wird. Nur auf dem DT-System können Softwareaktualisierungen zusammengefasst werden.
Werden weitere Testsysteme benötigt, so können diese ebenfalls in einer Systemgruppe erfasst werden. Von diesen Testsystem können keine Softwareaktualisierungen ausgeliefert werden.
Alle Testsysteme werden per Softwareaktualisierungen vom DV-System versorgt.
Bei Bedarf können sogenannte weitere Entwicklungssysteme (DV 1..n) angelegt werden. Dies ist z. B. hilfreich, wenn eine größere Entwicklung in einem Kundenentwicklungssystem umgesetzt werden soll, die aber die Versorgung des Produktivsystems mit Korrekturen aus dem Standard, Branchensystem oder dem Kundenentwicklungssystem nicht behindern darf. Die weiteren Entwicklungssysteme werden als Kopie vom DV-System erstellt. Beim Aktivieren von Entwicklungsaufgaben im DV-System werden über den Entwicklungsdienst, ähnlich zur parallelen Wartung, Entwicklungsaufgaben auf den weiteren Entwicklungssystemen angelegt. Diese Aufgaben enthalten die gleichen Entwicklungsobjekte, wie die Entwicklungsaufgabe im DV-System. Über den Inhalt der Entwicklungsobjekte wird mithilfe des Versionsvergleiches entschieden. Allerdings werden keine Informationen über die angelegten Versionen an das aktivierende System übermittelt.
Die Übernahme von Änderungen aus dem weiteren Entwicklungssystemen (DV 1..n) zurück in das DV-System erfolgt nicht automatisch. Verwendet wird hierfür der XML-Import/Export. Auf dem DV-System entsteht eine Entwicklungsaufgabe mit allen Entwicklungsobjekten, die über diesen Weg in das System übertragen werden. Alle weiteren Informationen, z.B. Historie, Entwicklungsaufgaben, Bearbeiter usw. werden von den weiteren DV-Sytemen nicht mit übernommen! Nach der Rückübernahme in das DV-System sollten die entsprechenden weiteren DV-Systeme gelöscht und bei Bedarf, nach dem Aktivieren der Entwicklungsaufgabe, neu erstellt werden.
Alle DV-Systeme einer Systemgruppe haben das gleiche Entwicklungspräfix und die gleiche Versionierungsstufe. Softwareaktualisierungen, die in das DV-System einer Systemgruppe eingespielt werden, sollten auch in die weiteren Entwicklungssysteme der Systemgruppe eingespielt werden. Alle Systeme innerhalb einer Systemgruppe haben das gleiche Release.
4.3.12.2 Entwicklungsgruppen
Entwicklungsgruppen fassen mehrere Systemgruppen zusammen. In einer Entwicklungsgruppe werden Definition getroffen, die für alle Systemgruppen gelten. Dies sind z. B. die Versionierungsstufe, das Entwicklungsprafix, das Exportpräfix der Softwareaktualisierungen, den Identitätsserver und den Entwicklungsauftragsserver.
Eine Entwicklungsgruppe definiert eine unveränderliche Reihenfolge der Systemgruppen. Dadurch wird festgelegt, welches Entwicklungssystem in der parallelen Wartung benachrichtigt werden muss.
Beispiel: In der nachfolgenden Grafik sind die Systemgruppen 1, 2 und 3 in genannter Reihenfolge aufsteigend angeordent, d.h. die parallele Wartung erfolgt von DVS1 über DVS2 nach DVS3.
Entwicklungssysteme in einer Entwicklungsgruppe haben immer das gleiche Entwicklungspräfix. Damit es zu eindeutigen Identitäten in den Entwicklungsobjekten kommt, verwenden alle Entwicklungssysteme denselben Identitätsdienst.
Für die parallele Wartung ist es notwendig einen Entwicklungsauftragsserver zu verwenden. Dieser muss nicht zwingend ein System innerhalb der Entwicklungsgruppe sein. Üblicherweise wird ein Entwicklungsauftragsserver für alle Entwicklungssysteme verwendet. Über den Entwicklungsauftragsserver wird der organisatorische Teil der parallelen Entwicklung verwaltet. Über die Anwendungen Entwicklungsaufträge, Supportanfragen und Supportauslieferungen wird die Organisation der Anfrage des Kunden, der Ablauf der Entwicklung bis hin zur Auslieferung vorgenommen.
Entwicklungsgruppe mit drei Systemgruppen
In der Standardentwicklung, bzw. der Branchenentwicklung haben die einzelnen Systemgruppen unterschiedliche, aber direkt aufeinander folgende aufsteigende Releases.
Beispiel: Das DVS1 hat das Release 5.1 und das DVS2 das Release 5.2.
In einer Entwicklungsgruppe für App-Entwicklung können mehrere aufeinanderfolgende Systemgruppen das gleiche Release haben.
Beispiel: Das DVS1 und DVS2 haben das Release 5.1 und das DVS3 hat das Release 5.2.
Um eine Reihenfolge in den Systemen definieren zu können, gibt es eine fortlaufende Nummer, das Infix, an den Systemgruppen. Diese Nummer wird in den App-Entwicklungssystemen als führender Teil in der Versionnummer der Entwicklungsobjekte verwendet. In den ausliefernden Testsystemen der Gruppen, wird die Nummer auch als Teil in der Bezeichnung der Softwareaktualisierungen verwendet. So kann sichergestellt werden, dass es bei Systemen gleichen Releases und gleichem Exportpräfix nicht zu namensgleichen Softwareaktualisierungen kommt.
Beispiel: Das DTS1 und DTVS2 haben das Release 5.1 und das Exportpräfix ist für die gesamte Entwicklungsgruppe „abcde“. Die Namen der Softwareaktualisierungen aus dem S1-System fangen alle mit „abcde-5.1.0-app-001-…“ an, die aus dem S2-System mit „abcde-app-002-…“. Die drei Punkte sind stellvertretend für eine sechsstellige aufsteigende Nummer, die mit führenden Nullen aufgefüllt wird, z.B. „000001“.
4.3.12.3 Module
Eine Systemgruppe beschreibt, in welcher Beziehung einzelne Systeme zueinander stehen und welche Rolle sie dabei einnehmen. Eine Entwicklungsgruppe beschreibt die Reihenfolge der Systemgruppen zueinander. Was fehlt ist die Definition, was wo entwickelt wird. Diese Festlegung erfolgt in sogenannten Modulen.
Ein Modul beschreibt was entwickelt wird und in welchen Systemgruppen. Es wird unterschieden zwischen Modulen vom Typ „Standard“ und vom Typ „App“.
Module vom Typ „Standard“ werden in Entwicklungsgruppen eingesetzt, die für die Standard-, Branchen- oder Kundenentwicklung bestimmt sind. In der Regel werden alle Systemgruppen dem Modul zugeordnet. Die parallele Wartung dieses Moduls erfolgt somit über die dadurch referenzierten Entwicklungssysteme.
Module vom Typ „App“ kommen in der App-Entwicklung zum Einsatz. Im Unterschied zur „Standard“-Entwicklung, kann eine App auf einer Untermenge der vorhandenen Systemgruppen entwickelt und gewartet werden. Mit der Zuordnung einer Entwicklungsgruppe zu einem Modul beginnt die parallele Wartung. Die genaue Vorgehensweise entnehmen Sie bitte der Dokumention „Einführung: Apps“
Bei Modulen vom Typ „App“ kann zusätzlich festgelegt werden, von welchen anderen „App-Modulen“ diese abhängig sind, bzw. welche verwendet werden dürfen. Diese Festlegung wird für Referenzprüfungen in den Entwicklungsobjekten verwendet und schützt davor, Abhängigkeiten zu nicht erlaubten Apps zu erzeugen. Die benötigen Module werden auch bei der späteren Installation der Apps vorrausgesetzt.
4.4 Entwicklung bei Partnern
Beim Partner werden zwei Fälle unterschieden:
- Der Partner liefert das Standard-System aus und adaptiert es für jeden seiner Kunden.
- Der Partner nimmt Erweiterungen am System vor, die für mehrere oder alle Kunden (Branchenlösung) bestimmt sind und nimmt anschließend noch kundenspezifische Adaptierungen für einige oder alle Kunden vor.
4.4.1 Standard-System
Für jeden Kunden wird eine Kopie des Kunden-Produktiv-Systems, das Kundentestsystem benötigt. Falls für den Kunden adaptiert wird, wird zusätzlich ein Kunden-Adaptierungssystem benötigt. Dort werden Anpassungen des Standard-Systems für den Kunden-Systeme vorgenommen. Wenn aus der Comarch-ERP-Enterprise-Standard-Entwicklung eine Softwareaktualisierung bereitgestellt wird, dann wird diese zunächst in das Standard-System des Partners eingespielt und getestet.
Falls die Softwareaktualisierung für einen Kunden relevant ist oder die Übernahme durch Abhängigkeiten zu anderen Softwareaktualisierungen notwendig ist, wird die Softwareaktualisierung in das Kunden-Adaptierungssystem bzw. in das Kundentestsystem eingespielt. Im Kunden-Adaptierungssystem kommt es beim Installieren zu Konflikten, wenn in der Softwareaktualisierung Entwicklungsobjekte enthalten sind, die der Partner für den Kunden angepasst hat.
Diese Konflikte müssen dann im Kunden-Adaptierungssystem gelöst werden. Danach wird eine weitere Softwareaktualisierung erstellt, die zusammen mit den Inhalten der installierten Softwareaktualisierung an den Kunden ausgeliefert wird. Zu jeder Softwareaktualisierung, die nicht zu Konflikten führt, wird vom Kunden-Adaptierungssystem beim Installieren automatisch eine neue Softwareaktualisierung mit gleichem Inhalt erzeugt. Die zugehörige Datei muss manuell in das Dateisystem exportiert werden.
4.4.2 Partner entwickelt eigenes Standard-System
Falls der Partner eigene Erweiterungen am Comarch-ERP-Enterprise-Standard-System vornimmt, muss die Installation der Softwareaktualisierungen zweistufig erfolgen.
Zunächst werden diese in das Entwicklungssystem bzw. Korrektursystem vom Partner eingespielt und die Konflikte werden bearbeitet, anschließend dann in das Kunden-Adaptierungssystem übernommen. Dort führen die Änderungen u. U. nochmals zu Konflikten, die bearbeitet werden müssen. Anschließend werden die Softwareaktualisierungen an den Kunden ausgeliefert.
4.5 Transportwege der Softwareaktualisierungen
4.5.1 Transportwege beim Partner
Die Softwareaktualisierungen aus der Comarch-ERP-Enterprise-Standard-Entwicklung werden in das Qualitätssicherungssystem (Standard-System) des Partners eingespielt. Von hier aus gibt es verschiedene Möglichkeiten, welche Systeme mit den Softwareaktualisierungen aus dem Qualitätssicherungssystem aktualisiert werden.
Verwendet der Partner das im Abschnitt „Standard-System“ beschriebene Standard-System, wird in zwei Fälle unterschieden:
- Die Produktivsysteme (inkl. zugehörigem Testsystem) werden direkt mit den Softwareaktualisierungen aktualisiert. Diese Variante der Auslieferung ist nur empfehlenswert, wenn in nächster Zeit keine Adaptierungen für den Kunden anstehen. Muss für den Kunden doch eine Anpassung vorgenommen werden, muss nachträglich ein Kunden-Adaptierungssystem in den Transportweg aufgenommen werden. Der zusätzliche Aufwand ist nur gerechtfertigt, wenn dadurch über einen längeren Zeitraum die Pflege des Systems eingespart wurde.
- Hat der Partner Anpassungen für den Kunden vorgenommen, müssen die Softwareaktualisierungen in das Kunden-Adaptierungssystem eingespielt werden. Von da aus wird das Kundensystem aktualisiert.
Wenn ein Partner eine eigene Branchenlösung entwickelt (siehe Abschnitt „Partner entwickelt eigenes Standard-System“), dann werden ebenfalls zwei Fälle unterschieden:
- Wenn der Partner eine Branchenlösung entwickelt und diese gerade in der Entwicklungsphase ist, wird nur das Entwicklungssystem mit Softwareaktualisierungen aktualisiert.
- Ist die Branchenlösung bereits in der Wartungsphase werden die Softwareaktualisierungen in das Partner-Korrektursystem eingespielt. Über das Partner-Korrektursystem werden nun die Entwicklungsobjekte des Partners und aus der Comarch-ERP-Enterprise-Standard-Entwicklung in das Partnertestsystem eingespielt. Es können aber auch einzelne Softwareaktualisierungen in das Partner-Entwicklungssystem, des nächsten Releases eingespielt werden (z. B.: Fehlerkorrekturen). Im Kundentestsystem werden die Softwareaktualisierungen nach inhaltlichen Gesichtspunkten zusammengefasst. Aus dem Testsystem werden die zusammengefassten Softwareaktualisierungen nun direkt oder über ein Kunden-Adaptierungssystem ins Kundensystem eingespielt (siehe oben).
4.5.2 Transportwege in der Produktivumgebung
In der Produktivumgebung werden die Softwareaktualisierung aus dem Qualitätssicherungssystem, dem Adaptierungssystem oder dem Partnertestsystem in das Kundentestsystem eingespielt. Aus dem Testsystem kann nun das Produktivsystem aktualisiert werden.
4.5.3 Mögliche Transportwege
Die nachfolgende Abbildung beschreibt die möglichen Transportwege von Softwareaktualisierungen.
4.6 Ziel-System aktualisieren
Beim Aktualisieren eines Ziel-Systems wird ein Ziel-System aus einem Quell-System mit Softwareaktualisierungen versorgt. Das Quell-System ermittelt die im Ziel-System importierten Softwareaktualisierungen. Diese müssen nicht mehr eingespielt werden. Die Softwareaktualisierungen, die im Ziel-System noch nicht installiert worden sind, werden automatisch in das Ziel-System übertragen und im Import-Ordner des Ziel-Systems abgelegt. Erst wenn sich Code-Refresh-Dateien, die Source-Refresh-Dateien usw. im Import-Ordner befinden kann der Installationsvorgang begonnen werden. Die Softwareaktualisierungen können im Ziel-System automatisch installiert werden. Die Softwareaktualisierungen müssen exportiert werden bevor sie übertragen werden können. In Testsystemen müssen die Softwareaktualisierungen erst zusammengefasst werden, bevor sie mit Zielsystem aktualisieren übertragen werden können.
Automatische Installation
Softwareaktualisierung können und sollten auf einem System automatisch installiert werden. Bei der automatischen Installation führt das System selbstständig die notwendigen Installationsschritte durch. Am Ende der automatischen Installation wird das Installationsprotokoll erstellt. Wenn bei einer automatischen Installation Fehler auftreten, dann bricht die automatische Installation ab, damit Sie die Fehler ggf. manuell beheben können. Danach können Sie die automatische Installation fortsetzen und die übrigen Installationsschritte werden ausgeführt. Die automatische Installation erkennt manuell durchgeführte Installationsschritte und führt diese nicht erneut aus.
Die automatische Installation installiert System- und Anwendungssoftware-Aktualisierungen sequenziell, d. h. erst SYS dann APP, Die Installation von Softwareaktualisierungen teilt sich in eine Vorbereitungs- und in eine Aktivierungsphase. Die Vorbereitungsphase wird im laufenden Betrieb des Systems durchgeführt. Während der Aktivierungsphase kann abhängig von den installierten Softwareaktualisierungen das System nicht verwendet werden.
Die automatische Installation umfasst im Wesentlichen die folgenden Installationsschritte:
- Vorbereitung der Installation:
Eine XML-Datei wird im Import-Ordner erzeugt. Diese Datei enthält alle Informationen über den aktuellen Status der Installation. Des Weiteren wird ein Verzeichnis angelegt in dem die Ausgaben der Installation in Dateien protokolliert werden.
Der Name des Verzeichnisses ist wie folgt aufgebaut: AI-JJJJMMTTHHMMSS (JJJJ – Jahr, MM – Monat, TT – Tag, HH – Stunde, MM – Minute, SS – Sekunde an dem das Verzeichnis erstellt wurde). Auch die XML-Datei wird zur Sicherheit in diesem Verzeichnis abgelegt.
- SYS-Import:
Alle Softwareaktualisierungen die Systementwicklungsobjekte enthalten werden importiert (Toolaufruf: imprfr –all –codeClass:sys). Der Import wird in der Datei SYS_IMPORT.log protokolliert.
- SYS-Dateiauslieferung Neustart:
Enthalten die Softwareaktualisierungen Dateiauslieferungen (siehe nächster Abschnitt), wird ein Neustart durchgeführt um die entsprechenden Dateien auszutauschen.
- SYS-Vorbereiten:
Vorbereitung der Installation der importierten Softwareaktualisierungen (Toolaufruf: upgaps –prepare –codeClass:sys). Die Vorbereitung wird in der Datei SYS_PREPARE.log protokolliert.
- SYS-Vorbereitung abschließen:
Die zu installierenden Entwicklungsobjekte werden aus dem Archiv in die Systemtabellen übernommen. (Toolaufruf: upgaps –upgrade –codeClass:sys). Die Information wird in der Datei SYS_UPGRADE.log protokolliert.
- SYS-Vorbereitung abschließen Neustart:
Neustart nach Abschluss der Vorbereitung der System-Softwareaktualisierungen.
- SYS-Aktivieren:
Aktivierung der Entwicklungsobjekte (Toolaufruf: upgaps –activate –codeClass:sys). Die Information wird in der Datei SYS_ACTIVATE.log protokolliert.
- SYS-Aktivieren Neustart:
Neustart nach der Aktivierung der System-Softwareaktualisierungen.
- SYS-Freigeben:
Ausführen der Datenaktualisierung (Toolaufruf: upgaps –release –codeClass:sys). Die Information wird in der Datei SYS_RELEASE.log protokolliert.
- APP-Import:
Es werden alle Softwareaktualisierungen die Anwendungsentwicklungsobjekte enthalten importiert (Toolaufruf: imprfr –all –codeClass:app). Der Import wird in der Datei APP_IMPORT.log protokolliert.
- APP-Dateiauslieferung Neustart:
Enthalten die Softwareaktualisierungen Dateiauslieferungen (siehe nächster Abschnitt), wird ein Neustart durchgeführt um die entsprechenden Dateien auszutauschen.
- APP-Vorbereiten:
Vorbereitung der Installation der importierten Softwareaktualisierungen (Toolaufruf: upgaps –prepare –codeClass:app). Die Vorbereitung wird in der Datei APP_PREPARE.log protokolliert.
- APP-Vorbereitung abschließen:
Die zu installierenden Entwicklungsobjekte werden aus dem Archiv in die Systemtabellen übernommen. (Toolaufruf: upgaps –upgrade –codeClass:sys). Die Information wird in der Datei APP_UPGRADE.log protokolliert.
- APP-Vorbereitung abschließen Neustart:
Neustart nach Abschluss der Vorbereitung der Softwareaktualisierungen.
- APP-Aktivieren:
Aktivierung der Entwicklungsobjekte (Toolaufruf: upgaps –activate –codeClass:sys). Die Information wird in der Datei APP_ACTIVATE.log protokolliert.
- APP-Aktivieren Neustart:
Neustart nach der Aktivierung der System-Softwareaktualisierungen.
- APP-Freigeben:
Ausführen der Datenaktualisierung (Toolaufruf: upgaps –release –codeClass:app). Die Information wird in der Datei APP_RELEASE.log protokolliert.
- Abschluss:
Die XML-Datei wird aus dem Import-Ordner entfernt. Somit kann das System wieder automatisch aktualisiert werden. Solange die XML-Datei in dem Import-Ordner vorhanden ist, ist eine Aktualisierung vom Quell-System aus nicht möglich.
4.7 Dateiauslieferungen
Dateiauslieferungen sind spezielle Entwicklungsobjekte vom Typ „Datei“, mit denen größere Dateien an Softwareaktualisierungen angehangen werden können und somit in andere Systeme ausgeliefert werden. Folgende Gründe stehen für diese Auslieferungsvariante, in der die Dateien nicht als Dateiobjekte verwendet werden können:
- Die Dateien sind zu groß, als dass sie im Repository verwaltet werden sollten.
- Die Lizenzbestimmungen verhindern, dass diese Datei ausgeliefert wird.
- Die Datei kann nicht ausgetauscht werden, solange ein SAS diese Datei benutzt.
Zu jeder Dateiauslieferung wird ein Dateiobjekt in der Anwendung „Entwicklungsobjekte“ angelegt. Dieses Dateiobjekt darf nur im Namensraum com.cisag.sys.delivery oder com.xxx.app liegen. Bei der Datei handelt es sich um eine XML-Datei, die die Auslieferung beschreibt:
- Ausgabedatum der Version
- Typ der Dateiauslieferung:
FILE, CHECKSUM
- Neustartart:
NONE, SERVER, SHELL
- Versionsinformation
- Für alle zugeordneten Dateien:
Dateiname mit relativem Pfad zum „semiramis“-Verzeichnis
Eine Dateiauslieferung vom Typ FILE liefert die Inhalte der zugeordneten Dateien aus. FILE-Dateiauslieferungen werden für alle Dateigruppen verwendet, die auf jedem System verfügbar sein sollen.
Eine Dateiauslieferung vom Typ CHECKSUM liefert die Inhalte der Dateien nicht aus sondern nur die Prüfsummen der Dateien. Die Auslieferung der Prüfsummen wird benötigt, wenn die Lizenzbestimmungen eine Auslieferung der Inhalte verbieten oder wenn die Installation dieser Dateien optional ist.
Wenn eine Softwareaktualisierung exportiert wird, dann wird überprüft, ob diese Dateiauslieferungen enthält. Für jede Dateiauslieferung müssen in dem Verzeichnis „<Name der Dateiauslieferung>+<Versionsnummer>“ die anzuhängenden Dateien hinterlegt sein. Dieses Verzeichnis wird beim Import der Dateiauslieferung angelegt und muss vor dem Export gefüllt werden. Wenn die Dateiauslieferung vom Typ FILE ist, dann enthält die Softwareaktualisierung, die in der Dateiauslieferung beschriebenen Dateien und inklusive deren Prüfsummen. Wenn die Dateiauslieferung vom Typ CHECKSUM ist, dann enthält die Softwareaktualisierung nur die Prüfsummen der beschriebenen Dateien.
Beim Exportieren einer Softwareaktualisierung mit einer Dateiauslieferung werden die Prüfsummen der ausgelieferten Dateien in eine gesonderte Datei abgelegt. Mithilfe dieser Prüfsummen kann sichergestellt werden, dass die Metadaten der Dateiauslieferung zu den realen Daten passen. Die Prüfsummendatei enthält für jede Datei in einer Dateiauslieferung die folgenden Daten:
- relativer Dateiname
- Prüfsumme
- Dateigröße
- Dateidatum
Beim Import der Softwareaktualisierungen werden die Dateiauslieferungsdateien in das der Dateiauslieferung mit dieser Version zugeordnete Verzeichnis entpackt (z. B.: <„semiramis“-Verzeichnis/file-deliveries/object_0X1).
Beim Aktivieren der Softwareaktualisierungen werden die Dateiauslieferungsdateien mit der Option Neustartart NONE direkt in das „semiramis“-Verzeichnis kopiert. Dateiauslieferungsdateien mit der Option Neustartart SERVER oder SHELL werden in das Verzeichnis fileupdate kopiert. Wenn bei der Menge der importierten Softwareaktualisierungen eine Dateiauslieferung mit der Neustartart SERVER oder SHELL enthalten ist, dann wird nach dem Import der Softwareaktualisierungen der Server beendet. Nach dem Beenden des SAS werden die Dateien aus Verzeichnis fileupdate in das Serververzeichnis kopiert. Wenn die Option Neustartart SERVER ist, dann wird nur der SAS neu gestartet. Wenn die Neustartart SHELL ist, dann wird der SAS beendet und der Benutzer wird aufgefordert, die Shell zu beenden, die Dateien zu kopieren (per bereitgestellten Skript) und die Shell mit dem Server neu zu starten. Nach jeder Übernahme der Dateien in das Serververzeichnis wird das Verzeichnis fileupdate gelöscht.
Beim Import einer Softwareaktualisierung werden die enthaltenen Dateiauslieferungen in das Verzeichnis „<Name der Dateiauslieferung> + <Versionsnummer>“ geschrieben. In einem Produktivsystem können diese Dateiauslieferungsverzeichnisse gelöscht werden. In anderen Systemen sollte davon abgesehen werden. Mit dem Tool chkfd kann man die aktuelle Datei mit der Datei im Dateiauslieferungsverzeichnis vergleichen, um festzustellen, ob die benutzte Datei nicht zwischenzeitlich geändert wurde.
4.8 Installationsprotokoll
Für jede automatische Installation von Softwareaktualisierungen wird ein Installationsprotokoll erstellt. Das Installationsprotokoll enthält folgende Informationen:
- eine Übersicht über alle in dem Installationsvorgang installierten Softwareaktualisierungen,
- eine Übersicht über alle in dem Installationsvorgang installierten Datenaktualisierungen,
- falls notwendig die Nummer der Konfliktaufgabe,
- die Liste aller Aufgaben, die Sie nach der Installation durchführen müssen, und
- falls vorhanden die Liste aller Fehler, die bei der Installation aufgetreten sind.
Das Installationsprotokoll umfasst somit alle Informationen, die nach dem Einspielen von Softwareaktualisierungen relevant sind. Das Installationsprotokoll wird nach Abschluss des Installationsvorgangs erzeugt. Das Installationsprotokoll wird in dem Verzeichnis mit dem Namen AI-JJJJMMTTHHMMSS (JJJJ – Jahr, MM – Monat, TT – Tag, HH – Stunde, MM – Minute, SS – Sekunde an dem das Verzeichnis erstellt wurde) im Import-Ordner gespeichert.
Sie können das Installationsprotokoll im Systemcockpit auf dem Karteireiter Installationsvorgänge einsehen.
Im Customizing kann in der Hauptfunktion „Softwareaktualisierungen“ festgelegt werden, wie die Benachrichtigung nach Abschluss der Installation von Softwareaktualisierungen erfolgt. Sie können zwischen einer Benachrichtigung durch den Workflow oder durch eine E-Mail wählen.
Workflow
Der Bearbeiter der erzeugten Workflowaktivitäten ist die Workflowrolle „cis.SysAdmin“, wenn dieser Rolle keine Personen zugeordnet wurden, dann wird der Verantwortliche für das System verwendet.
Für jede Aufgabe, einer im Installationsvorgang installierten Softwareaktualisierung, werden Aktivitäten angelegt. Die Aktivitäten enthalten die bei der Aufgabe erfasste Beschreibung und Anwendung.
Wenn in dem Installationsvorgang Dialog-Datenaktualisierungen oder noch nicht ausgeführte Hintergrund-Datenaktualisierungen enthalten sind, wird eine Aktivität zum Ausführen dieser Datenaktualisierungen erzeugt.
Wenn das Installationsprotokoll per E-Mail versendet wird, kann der Absender und Empfänger der E-Mail im Customizing erfasst werden. Wenn kein Absender erfasst wird, der Administrator als Absender verwendet und wenn kein Empfänger erfasst ist, wird dem System-Verantwortlichen die E-Mail zugesendet. Die E-Mail enthält das Installationsprotokoll.