1                     Themenübersicht

Für Entwicklungen und Adaptierungen in Comarch ERP Enterprise und deren Auslieferung müssen verschiedene Systeme vorgehalten werden und Transportwege zwischen diesen Systemen aufgebaut werden. Die Anforderungen dafür können sehr unterschiedlich sein. Unterschiede ergeben sich aus der Anzahl der zu versorgenden Systeme, ob nur adaptiert wird oder Erweiterungen des Standards entwickelt werden. Dieses Dokument beschreibt mögliche Szenarien von einer einfachen Systemlandschaft mit wenigen Systemen bis zur Systemlandschaft für Entwicklung von eigenständigen Erweiterungen, die wiederum für verschiedene Zwecke adaptiert werden können.

Die Reihenfolge der Systeme, in welcher Softwareaktualisierungen von einem System in ein anderes gelangen, wird durch den Transportweg festgelegt. Sie finden nachfolgend Informationen, wie Sie eine komplette Transportlandschaft, von Qualitätssicherungssystem bis hin zu einem Produktiv-System, einrichten und welche Einstellungen vorzunehmen sind. Außerdem wird beschrieben, in welcher Konstellation welche System-Parameter zu setzen sind.

2                     Zielgruppe

Verantwortliche für Support, Entwicklungsplanung, Qualitätssicherung und Auslieferung.

3                     Begriffsbestimmungen

Adaptierung

Eine Adaptierung ist eine Anpassung des Releasestands. Es werden neue Entwicklungsobjekte 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.

Entwicklungssystem

Entwicklungssysteme dienen der (Neu-)Entwicklung und Adaptierung. In Entwicklungssystemen können Entwicklungsobjekte geändert und angelegt werden. Ein Entwicklungssystem versorgt im Regelfall nur nachgelagerte Systeme mit Softwareaktualisierungen.

Internes System/Supportsystem

Das interne System/Supportsystem dient zur Koordination und Dokumentation der Entwicklung und der dazugehörigen Supportauslieferungen (und damit Softwareaktualisierungen). Auf diesem System werden Supportanfragen, Entwicklungsaufträge, Supportauslieferungen erstellt und Softwareaktualisierungen zum Download für Systeme bereitgestellt, die dem Entwicklungssystem nachgelagert sind. Das System sollte diese Aufgaben für alle Releases übernehmen. Daher wird im Allgemeinen nur ein internes System/Supportsystem benötigt.

Korrektursystem

Entspricht einem Entwicklungssystem. Allerdings werden bestimmte Änderungen an Entwicklungsobjekten in diesen Systemen gar nicht zugelassen oder sind nur nach Bestätigung einer Warnung möglich. So werden Löschungen erst nach einer Warnung möglich, da sie möglicherweise inkompatibel zu Anpassungen in nachgelagerten Entwicklungssystemen sind. Korrektursysteme versorgen wie Entwicklungssysteme nachgelagerte Systeme mit Korrekturen, können die Korrekturen aber auch an Entwicklungssysteme weitergeben.

Nachgelagertes System

Nachgelagerte Systeme sind aus der Perspektive eines Systems alle Systeme, in die aus dem System exportierte Software­aktualisierungen eingespielt werden.

Die nachgelagerten Systeme können in mehreren parallelen Zweigen einer Systemfamilie liegen. Nachgelagerte Systeme können nicht in einer anderen Systemfamilie liegen.

Partnerentwicklung

Eine nicht kundenspezifische Erweiterung oder Adaptierung des Standard-Systems. Die für Kunden nochmals adaptiert werden kann. Zum Beispiel eine Branchenlösung oder eine App.

Produktivsystem

Das Produktivsystem oder auch P-System 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 Qualitätssicherungssystem alle Softwareaktualisierungen von Comarch ERP Enterprise einspielen. Auf diesem System kann er die für ihn relevanten Anwendungen nochmals überprüfen. Tritt in Systemen, die eigene Adaptierungen enthalten, ein Fehler auf, so 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.

ERP-System-Standard

Die Menge der jeweils aktuellen Versionen aller Entwicklungsobjekte eines Releases einschließlich aller für das Release von der Comarch Software und Beratung AG freigegebenen Softwareaktualisierungen wird als der jeweilige ERP-System-Standard bezeichnet. Für alle betrachteten Entwicklungsobjekte gilt weiter, dass sämtliche jeweils auftretenden Versionsnummern höchstens zwei Stellen umfassen, wobei die erste und die zweite Stelle der Versionsnummer der Comarch Software und Beratung AG vorbehalten sind. Damit ist automatisch ausgeschlossen, dass die Entwicklungsobjekte von Dritten erstellt oder geändert wurden. Der ERP-System-Standard wird exklusiv durch die Comarch Software und Beratung AG definiert. Über die Entwicklungsobjekte hinaus umfasst der ERP-System-Standard auch Programmierkonventionen und verbindliche Richtlinien.

Standard-System

Als Standard-System wird ein Comarch-ERP-Enterprise-System bezeichnet, bei dem keine Änderungen vorgenommen wurden.

Softwareaktualisierung

Mithilfe mehrerer Softwareaktualisierungen wird ein Comarch-ERP-Enterprise-System innerhalb eines Releases aktualisiert. Eine Softwareaktualisierung enthält, auch in Kombination, neue oder veränderte Entwicklungsobjekte. Softwareaktualisierungen werden benutzt, um zum einen Fehlerkorrekturen und zum anderen Weiterentwicklungen auszuliefern. Wenn eine Softwareaktualisierung exportiert wird, entstehen zwei Dateien: Eine Datei wird als Sourcerefresh (sr) bezeichnet und enthält den Quellcode. Die andere Datei wird als Coderefresh (cr) bezeichnet und enthält den gegebenenfalls bereits kompilierten Objektcode.

Software-Transport/Software-Quer-Transport

Software-Transporte finden zwischen Systemen mit unterschiedlicher Versionierungsstufe statt. Dabei wird zwischen (normalen) Software-Transporten und Software-Quer-Transporten unterschieden. Bei einem Software-Transport ist die Versionierungsstufe des Quell-Systems kleiner als die des Ziel-Systems oder Softwareaktualisierungen wurden im Quell-System zusammengefasst. Bei einem Software-Quer-Transport ist die Versionierungsstufe des Quell-Systems größer als die des Ziel-Systems.

Systemfamilie

Eine Systemfamilie ist eine Menge von Comarch-ERP-Enterprise-Systemen, die alle denselben Release-Stand haben. Der Versorgungsweg für Softwareaktualisierungen ist innerhalb einer Familie fest definiert. Jede Softwareaktualisierung wird zu einem (späteren) Zeitpunkt auch in das nächste System gemäß Versorgungsweg eingespielt.

Produktivsystemfamilie

Eine Produktivsystemfamilie ist eine Systemfamilie, die aus mindestens einem Produktivsystem und einem oder mehreren vorgelagerten Test- oder Qualitätssicherungssystemen besteht. Idealerweise umfasst die Produktivsystemfamilie zwei Testsysteme, von den eines in regelmäßigen Abständen mit Kopien der OLTP-Daten und eventuell auch der OLAP-Daten des Produktivsystems versorgt wird. Dieses so versorgte Testsystem ist dem Produktivsystem vorgelagert und dem anderen Testsystem nachgelagert.

Systemlandschaft

Alle Systemfamilien bilden zusammen die Systemlandschaft. Die Systemfamilien innerhalb einer Systemlandschaft können verschiedene Releasestä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 Comarch-ERP-System-Installation, wie Datenbank, Semiramis Application Server, Semiramis 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.

Transportweg

Die Reihenfolge der Systeme, in welcher Softwareaktualisierungen von einem System in ein anderes gelangen, wird durch den „Transportweg“ festgelegt. Auf dem Transportweg befinden sich Entwicklungssysteme mit den möglichen Versionierungsstufen 1, 2, 3, 4 und 6, in denen Versionsnummern von Entwicklungsobjekten geändert werden und so neue Softwareaktualisierungen erzeugen. In Systemen mit Versionierungsstufe 7 können die aus einem Entwicklungssystem stammenden Softwareaktualisierungen zu größeren Einheiten zusammengefasst werden. Softwareaktualisierungen dürfen auf dem Weg bis hin zu einem Produktivsystem keines der Systeme eines Transportweges überspringen. Softwareaktualisierungen können nicht in vorgelagerte Systeme eingespielt werden. Der Transportweg ist sozusagen eine „Einbahnstraße“.

Eine umfassende Transportlandschaft besteht aus mehreren Systemen, die unterschiedliche „Transportwege“ für verschiedene Systemfamilien bilden.

Da auf einem Transportweg mehrere Semiramis Application Server (SAS) unterschiedlicher Systeme miteinander kommunizieren, wird statt des Begriffs „Transportlandschaft“ auch der Begriff Systemlandschaft verwendet.

Versionierungsstufen

Jedem System ist eine Versionierungsstufe zugeordnet. Aus dieser Stufe wird dann eine Verwendung abgeleitet. Wir unterscheiden aktuell sieben Stufen, die zum Beispiel wie folgt verwendet werden können:

• Stufe 1: Entwicklungssystem
• Stufe 2: Korrektursystem
• Stufe 3: Partner-Entwicklungssystem. Zum Beispiel eine Branchenlösung.
• Stufe 4: Partnerkorrektursystem
• Stufe 5: Entwicklungssystem zur freien Verfügung.
• Stufe 6: Adaptierungssystem
• Stufe 7: Produktiv-, Test-, Qualitätssicherungssystem

Die Versionierungsstufen 3, 4, 5, 6 und 7 stehen für Partner zur Verfügung. In den Versionierungsstufen 3, 4, 5 und 6 kann entwickelt werden in der Versionierungsstufe 7 nicht.

Wird in einem System entwickelt, geben diese Stufen vor, wie die Versionsnummern der Entwicklungsobjekte vergeben werden. Die Versionsnummern von Entwicklungsobjekten bestehen aus sechs durch Punkte getrennten Zahlen (n₁.n₂.n₃.n₄.n₅.n₆). Bei der Erzeugung einer neuer Version, wird die der Versionierungsstufe entsprechende Zahl um eins erhöht. Die nachträgliche Änderung der Versionierungsstufe eines Systems, führt daher zu Änderungen bei nicht der Versionierungsstufe entsprechenden Versionsnummern an den bis dahin veränderten Entwicklungsobjekten.

Vorgelagertes System

Vorgelagerte Systeme sind aus Sicht eines Systems alle die Comarch-ERP-Systeme, durch die eine Softwareaktualisierung (SA) notwendigerweise transportiert werden muss, bevor sie in das System eingespielt werden kann. Jedes System hat genau ein direkt vorgelagertes System, aus dem es mit SA versorgt wird. Das direkt vorgelagerte System wird über die Import-Restriktionen festgelegt.

Die vorgelagerten Systeme liegen alle in der gleichen Systemfamilie. Das vorgelagerte System ist entweder ein Entwicklungssystem oder ein Testsystem, in dem Softwareaktualisierungen zusammengefasst werden.

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                     Vorüberlegungen

4.1               Transportwege

Während der Entwicklung erfolgen im Allgemeinen (normale) Software-Transporte. Software-Quer-Transporte finden in der Regel nur bei der Über­nahme von Korrekturen aus einem Korrektursystem in das zugeordnete Ent­wicklungssystem des nachfolgenden Releases statt.

Die Versionierungsstufe des Quell-Systems wird in der Softwareaktualisierung hinterlegt, siehe dazu auch Abschnitt Systeme mit der Versionierungsstufe 7. Beim Einspielen im Ziel-System wird überprüft, welche (Quell-) Versionierungs­stufe in der Softwareaktualisierung hinterlegt ist. Anhand dieser Information wird entschieden, ob ein Software-Quer-Transport vorliegt.

In der normalen Softwarelogistik hat ein System genau ein Quell-System. Dies ist durch die Abhängigkeiten zwischen den Softwareaktualisierungen nötig. Jedes System kann das Quell-System für mehrere andere Systeme sein. Dadurch ergibt sich immer eine Baumstruktur.

4.2               Abhängigkeiten zwischen Softwareaktualisierungen

Zwischen den Softwareaktualisierungen, die aus einem System exportiert wurden, bestehen unvermeidliche Abhängigkeiten. Eine Softwareaktualisierung kann erst im Ziel-System installiert werden, wenn alle Software­aktuali­sier­ungen von denen sie abhängig ist, in dieses System importiert wurden. Dadurch wird sichergestellt, dass sich auf einem System immer ein technisch konsistenter Stand an aktiven Entwicklungsobjekten befindet.

4.3               Identitätswechsel von Softwareaktualisierungen

Beim Einspielen von Softwareaktualisierungen in ein System der Stufe 3, 4, 5
oder 6 werden automatisch neue Softwareaktualisierungen erzeugt. Die zugehörigen Dateien (*.cr, *.tr, *.hr, *.sr) werden nicht automatisch exportiert. Diese Softwareaktualisierungen enthalten die eingespielten Entwicklungsobjekte. Die Versionierungsstufe dieser Softwareaktualisierungen entspricht der des Systems, das sie erzeugt. Nur in Systemen mit Versionierungsstufe 7 wird eine andere Versionierungsstufe in die exportierten Softwareaktualisierungen geschrieben, siehe unten. Die Softwareaktualisierungen enthalten die gleichen Entwicklungsobjekte, haben aber andere Identitäten. Die Abhängigkeiten zwischen den Softwareaktualisierungen werden entsprechend umgerechnet.

Mapping der Abhängigkeiten von Softwareaktualisierungen beim Identitätswechsel

4.4               Systeme mit der Versionierungsstufe 7

Systeme der Versionierungsstufe 7 nehmen in der Softwarelogistik eine Sonderstellung ein. Da in diesen Systemen nicht entwickelt wird, erzeugen sie nicht automatisch Softwareaktualisierungen. Wenn in diesen Systemen Softwareaktualisierungen über die Anwendung Softwareaktualisierungscockpit erzeugt werden, dann enthalten diese nur Entwicklungsobjekte, die in einem anderen System erzeugt wurden. Daher wird in diesen Software­aktualisier­ungen die Versionierungsstufe des vorgelagerten Entwicklungs- bzw. Korrektur­systems hinterlegt. Diese Systeme sind für den Transportweg nicht wichtig, können aber erhebliche Vorteile in der Qualitätssicherung und in der Softwarelogistik bringen. Ein System der Stufe 7 ist immer optional. Wenn das System allerdings erst einmal im Transportweg benutzt wurde, dann kann es nicht ohne weiteres aus diesem entfernt werden.

Beispiel:
Ein Kunden-Adaptierungssystem (6) DV erzeugt Softwareaktualisierungen, die in ein Testsystem (7) DT eingespielt werden. In diesem System werden die Softwareaktualisierungen zusammengefasst. Diese Softwareaktualisierungen werden mit der Versionierungsstufe 6 versehen, da die Entwicklung im DV System stattgefunden hat. Anschließend wird die Softwareaktualisierung an das Kunden-Testsystem und später an das Kunden-Produktivsystem weiter­ge­geben. Das ist ein (normaler) Software-Transport von Versionierungsstufe 6 nach 7.

4.5               Ziel-System aktualisieren und Stufe 7 Systeme

Die Funktionalität „Zielsystem aktualisieren“ im Softwareaktualisierungscockpit erzeugt keine neuen Softwareaktualisierungen. Sie verwendet nur Software­aktualisierungen, die schon auf dem System vorhanden sind. Wenn in einem Stufe 7 System nicht gleichzeitig Softwareaktualisierungen erzeugt werden (Supportauslieferung erstellen / Softwareaktualisierungen zusammenfassen), kann das System jederzeit aus dem Transportweg entfernt oder dazu hinzugefügt werden, da die Softwareaktualisierungen nicht ihre Identität wechseln, sondern nur durchgereicht werden. Anders ausgedrückt, ein System der Versionierungsstufe 7, in dem nur „Zielsystem aktualisieren“ benutzt wird, ist kein Quell-System. Im Allgemeinen betrifft das die folgenden Systeme:

• Internes System.
• Alle Testsysteme, die keine Supportauslieferungen erstellen. Hauptsächlich das dem Produktivsystem vorgelagerte Testsystem.

4.6               Entwicklungspräfix

Jedem System, in dem entwickelt wird, ist ein Entwicklungspräfix zugeordnet. Neue Entwicklungsobjekte können in diesem System nur in Namensräumen unterhalb von com.<Entwicklungspräfix> angelegt werden. Außerdem können nur diese Entwicklungsobjekte ohne Einschränkungen verändert werden.

Beispiel:
Das Entwicklungspräfix von Comarch ERP Enterprise ist „cisag“. Die Entwicklungsobjekte befinden sich alle unterhalb von com.cisag.

Wenn ein Entwicklungsobjekt einmal angelegt ist, dann kann sein Name inkl. Namensraum nicht mehr geändert werden. Daher macht die nachträgliche Änderung des Entwicklungspräfixes meistens keinen Sinn. Vorher angelegte Entwicklungsobjekte können nach einer Änderung des Entwicklungspräfixes nur noch sehr eingeschränkt bearbeitet werden, siehe dazu die Dokumentation Entwicklungsobjekte.

5                     Systemlandschaften

Bevor eine Systemlandschaft aufgesetzt wird, müssen insbesondere folgende Fragen geklärt werden.

• Ist ganz sicher keine Partnerentwicklung beabsichtigt? Im Zweifel sollte lieber eine Partnerentwicklung aufgesetzt werden.
• Wie viele Kunden müssen wann versorgt werden?

5.1               Partnerentwicklung oder Adaptierung?

Partnerentwicklung oder Adaptierung unterscheiden sich in folgenden Punkten:

• Versionierungsstufe
• Entwicklungspräfix

Partnerentwicklungen haben ein dem Partner zugeordnetes Entwicklungspräfix, während Adaptierungen ein dem Kunden zugeordnetes Entwicklungspräfix haben.

Wie oben beschrieben ist die nachträgliche Änderung einer dieser Einstellungen auf einem bestehenden System wenig sinnvoll. In diesem Fall muss ein neues System aufgesetzt werden und die relevanten Entwicklungsobjekte müssen mithilfe des Business Integration Service, also mit den Anwendungen „Daten importieren“ und „Daten exportieren“ (siehe dazu die Dokumentation Einführung: Datenaustausch), oder manuell in das neue System übertragen werden. Dies erzeugt zusätzlichen Aufwand und bringt Einschränkungen mit sich. Daher sollte eine Partnerentwicklung von Anfang an als System mit der Versionierungsstufe 3 oder 4 aufgesetzt werden. Das gilt, auch wenn zunächst nur ein Kunde versorgt wird. In diesem Fall kann zunächst auf das Aufsetzen eines Kunden-Adaptierungssystems verzichtet werden, siehe dazu auch die Erläuterungen weiter unten im Text.

Für die eigentliche Entwicklung macht es keinen Unterschied, ob in einem Partner-Entwicklungssystem oder in einem Adaptierungssystem entwickelt wird. Für die Systemlandschaft und zukünftige Änderungen ergeben sich allerdings größere Unterschiede.

Daher sollte zuerst überlegt werden, ob die beabsichtigten Entwicklungen nur für einen Kunden relevant sind oder auch für eine eventuelle Branchenlösung. In diesem Fall ist immer das Partner-Entwicklungssystem vorzuziehen. Gerade am Anfang wird dadurch kein zusätzlicher Aufwand generiert.

Wenn nur kundenspezifische Adaptierungen vorgenommen werden, sollte das auf jedem Fall in einem Adaptierungssystem mit dem Entwicklungspräfix des Kunden vorgenommen werden. Sonst wird zusätzlicher Aufwand bei der nachträglichen Einführung eines Partner-Entwicklungssystems generiert, da das Entwicklungspräfix schon vergeben ist.

Versionierungsstufe 3 oder 4?

Solange man nur für ein Release entwickelt und keine Adaptierungssysteme versorgt, ist die Versionierungsstufe 3 vorzuziehen. In dieser Stufe existieren beim Entwickeln erheblich weniger Restriktionen (Warnungen), was die Veränderungen an Entwicklungsobjekten betrifft. Werden Adaptierungssysteme versorgt, sollen die Restriktionen in Stufe 4 Systemen verhindern, dass Änderungen vorgenommen werden, die zu möglichen Anpassungen in Adaptierungssystemen inkompatibel sind.

Beispiel:
Das Löschen eines Business Objects in der Partnerentwicklung kann zu Datenverlusten in der Adaptierung führen, falls eine Extension existiert. Für Löschungen existiert keine Konfliktbehandlung!

Werden nur Produktivsysteme, in denen nicht entwickelt wird, versorgt. Kann man auch die Stufe 3 wählen.

Sobald eine Partnerentwicklung für ein älteres Release existiert und die Partnerentwicklung eines neuen Release begonnen wurde, sollte die alte Partnerentwicklung Stufe 4 und die neue Stufe 3 haben. Dadurch sind Software-Quer-Transporte mit den Korrekturen aus dem alten Release möglich. Normalerweise werden die Entwicklungen und Adaptierungen im neuen Release während des Releasewechsels aus dem alten Release hervorgehen, daher enthält das neue Release auch die Fehler, die im alten noch vorhanden waren. Korrigiert man diese Fehler im alten Release und spielt die daraus entstandenen Softwareaktualisierungen auch in das Entwicklungssystem für das neue Release, wird der Aufwand (Doppelpflege) erheblich minimiert. Wenn die Korrekturen Schemaänderungen umfassen (Änderung von Business Objects) ist dieses Vorgehen sogar nötig, eine Doppelpflege würde einen späteren Releasewechsel deutlich erschweren. Das neue System kennt bei Doppelpflege die Versionen der Business Objects aus dem alten System nicht, daher kann der Persistenzdienst nicht auf die Daten im alten System zugreifen.

5.2               Paralleles Entwicklungssystem (XML-Transport)

Die Entwicklung größerer Pakete in einem Partneradaptierungssystem und die Versorgung der Folgesysteme mit Bugfixes ist häufig in einem System nicht zu bewerkstelligen. Dabei treten hauptsächlich zwei Probleme auf:

• Die Bugfixes können nicht installiert werden, da enthaltene Entwicklungsobjekte gesperrt sind.
• Die Bugfixes können aufgrund von Abhängigkeiten nur aus dem Partnerentwicklungssystem exportiert werden, wenn Teile der Neuentwicklungen mitexportiert werden. Diese Neuentwicklungen sind eventuell noch nicht vollständig implementiert oder getestet und können daher nicht exportiert werden. Damit können auch die Bugfixes nicht exportiert werden.

Abhilfe schafft hier das Aufsetzen eines parallelen Entwicklungssystems. Dieses System wird vom gleichen System mit Softwareaktualisierungen versorgt, wie das System für die Bugfixes. Allerdings versorgt es, außer einem Testsystem für die Neuentwicklungen, keine Folgesysteme. In diesem System findet die komplette Neuentwicklung statt.

Sobald die Neuentwicklungen ausgeliefert werden sollen, können diese mit „Daten exportieren“ (BIS) exportiert werden und in das System im Transportweg eingespielt werden. Die dabei entstehende Entwicklungsaufgabe lässt sich einfach bearbeiten, da in diesem System keine „unbekannten“ Softwareaktualisierungen und Änderungen existieren. Korrekturen im System für die Bugfixes werden entweder manuell im Entwicklungssystem nachgezogen oder ebenfalls per Ex- und Import transportiert.

 

Am Besten Sie setzen das parallele Entwicklungssystem als Kopie ihres Partnerentwicklungssystems auf. Dadurch stellen Sie sicher, dass sich beide Systeme auf dem gleichen Code-Stand befinden. In „INF-000337: Kopieren und Bereinigen eines Semiramis Systems“ finden Sie hierbei nützliche Informationen, um das Entwicklungssystem zu kopieren. Bevor Sie die Kopie machen, muss sich das Entwicklungssystem vorher im folgenden Zustand befinden:

• Alle Entwicklungsaufgaben müssen aktiviert sein.
• Alle importierten Softwareaktualisierungen müssen installiert sein. D. h., es darf keine Installationsvorgänge geben, die nicht beendet wurden.

Im Entwicklungssystem und dem dazugehörigen parallelen Entwicklungssystem müssen die gleiche Versionierungsstufe und das gleiche Entwicklungspräfix eingestellt sein.

Beide Entwicklungssysteme müssen vom gleichen Vorgängersystem mit Supportauslieferungen versorgt werden. Wann Sie allerdings die Supportauslieferungen, in welches System spielen, ist abhängig vom jeweiligen Entwicklungsstand. In das Entwicklungssystem zum Bugfixing werden Sie wahrscheinlich zeitnah alle benötigten Supportauslieferungen übernehmen. In das parallele Entwicklungssystem übernehmen Sie neue Supportauslieferungen abhängig von dem Entwicklungsstand des Systems.

Zwischen den beiden Entwicklungssystemen können Sie jederzeit mit Hilfe des BIS Entwicklungen transportieren. Weichen die Code-Stände in der Standardentwicklung stark voneinander ab, so führt das im Zielsystem zu einem erhöhten Anpassungsaufwand. Sie sollten daher, wenn die Übernahme einer größeren Entwicklung aus dem parallelen Entwicklungssystem in das Bugfixing-System ansteht, wie folgt vorgehen.

1. Beenden Sie die entsprechenden Entwicklungen.
2. Bringen Sie das parallele Entwicklungssystem mit Supportauslieferungen auf den gleichen Code-Stand im Standard, den das Bugfixing-System hat, soweit das noch nicht geschehen ist.
3. Passen Sie Ihre Entwicklungen auf diesen Stand an.
4. Testen Sie diese Entwicklungen.
5. Aktivieren Sie alle Entwicklungsaufgaben im Bugfixing-System.
6. Übernehmen Sie die Entwicklungen auf das Bugfixing-System
7. Im Bugfixing-System müssen Sie noch die Update-Programme, für die geänderten Business Objekte, ändern.
8. Testen Sie die Entwicklungen im Bugfixing-System.

Diese Vorgehensweise hält die Durchlaufzeiten im Bugfixing-System gering, da die Schritte im Bugfixing-System schnell bearbeitet werden können.

Falls Sie alle Entwicklungen aus dem parallelen Entwicklungssystem in das Testsystem übernommen haben, haben Sie zwei Möglichkeiten für das weitere Vorgehen bzgl. der parallelen Entwicklung.

1. Sie arbeiten mit dem vorhanden parallelen Entwicklungssystem weiter.
2. Sie ersetzen das parallele Entwicklungssystem durch eine Kopie des Bugfixing-Systems.

Die erste Alternative hat den Vorteil, dass Sie sofort weiter entwickeln können und nicht erst auf die Bearbeitung der (Übernahme-) Entwicklungsaufgabe im Bugfixing-System warten müssen. Bei der zweiten Alternative können Sie die OLTP- und OLAP-Mandanten des Bugfixing-Systems mitkopieren. So erhalten Sie Testdaten im parallelen Entwicklungssystem. Ein Austausch der OLTP- und OLAP-Mandanten, zwischen den beiden Entwicklungssystemen ist im Allgemeinen nicht möglich.

Hinweis: Natürlich können Sie die hier beschriebene Vorgehensweise auch für ein paralleles Kundenadaptierungssystem durchführen.

5.3               Parallele Releases

Ab Semiramis 4.4 besteht die Möglichkeit verschiedene Releases des gleichen (Entwicklungs-) Systems zu betreiben. Eine genaue Beschreibung über das Vorgehen und die Versorgung dieser Systeme mit Softwareaktualisierungen finden Sie im Dokument Einführung: Softwarelogistik im Kapitel „Parallele Wartung“.

5.4               Nachträgliche Änderung von Transportwegen

Transportwege können nachträglich geändert werden. Dies stellt jedoch keine Standardoperation dar und erfordert die Unterstützung des Supports. Die folgenden Punkte sind beim Ändern des Transportweges problematisch:

• Die inhaltliche Konsistenz:

Wenn einem System ein neues Quell-System zugewiesen wird, muss dies exakt dieselben aktiven Entwicklungsobjekte enthalten, wie das alte Quell-System. Das gilt vor allem für die Anpassung auf Entwicklungsobjekten. Daher kann eine Kundenadaptierung nicht aus zwei Partnerentwicklungen versorgt werden. In beiden Partnerentwicklungen können verschiedene Anpassungen am gleichen Entwicklungsobjekt vorgenommen worden sein. Das führt im Kunden-Adaptierungssystem zu prinzipiell nicht auflösbaren Inkonsistenzen.

• Wie oben beschrieben existieren zwischen Softwareaktualisierungen Abhängigkeiten und die Softwareaktualisierungen wechseln in fast jedem System ihre Identität. Die Softwareaktualisierungen, die ursprünglich von kommen, müssen daher auf genau einem Weg ein Ziel-System erreichen. Sonst können die Abhängigkeiten nicht mehr aufgelöst werden, und die Installation der Softwareaktualisierungen schlägt fehl.

Das nachträgliche „Einschieben“ eines neuen Systems ist möglich. Dies wird am Beispiel einer Partnerentwicklung erklärt.

Beim Entwicklungsstart wird häufig nur ein Kunde versorgt. Für diesen Kunden sind zuerst keine Adaptierungen vorgesehen. Daher wird vorerst auf ein eigenes Adaptierungssystem verzichtet. Später kommen weitere Kunden hinzu und Adaptierungen sollen vorgenommen werden. In diesem Fall wird ein Adaptierungssystem (6) aufgesetzt. Die Partnerentwicklung wird zum Quell-System für die Adaptierung und die Adaptierung wird zum Quell-System für die Systeme beim Kunden. Dafür sind bestimmte Reorganisationsschritte an den Softwareaktualisierungen nötig, die hier nicht weiter beschrieben werden.

Hinweis:
Treten Sie in Kontakt mit dem Support, um solche Operationen durchzuführen.

Sie können die Stufe eines Systems nicht kleiner machen. Beispielsweise können Sie aus einem Kunden-Adaptierungssystem (Stufe 6) kein Partner-Entwicklungssystem (Stufe 3) machen.

Ein (Quell-) System aus dem Transportweg entfernen, ist nur unter ganz bestimmten Bedingungen möglich von diesem Schritt ist dringend abzuraten.

Ersetzen oder Verlust eines Systems auf dem Transportweg

Sobald aus einem System Softwareaktualisierungen exportiert und in ein nachgelagertes System eingespielt wurden, darf das Quellsystem der Softwareaktualisierungen nicht gelöscht werden oder z.B. durch eine Neuinstallation basierend auf einem neueren Installationssystem ersetzt werden.

Dies betrifft insbesondere Entwicklungssysteme.

Sollte ein solches System dennoch verloren gehen, weil sich  z.B. nach einem Desaster auch die Sicherungen nicht wieder einspielen lassen, informieren Sie sofort das Support-Center, das Sie bei der Rekonstruktion der Entwicklungsdaten unterstützen kann.

Eine verlustfreie Wiederherstellung ist bei einem solchen Totalverlust eines Systems normalerweise nicht garantiert.

Stellen Sie daher eine funktionierende Backup- und Recovery-Routine sicher.

5.5               Supportauslieferung erstellen/Software­aktualisierungen zusammenfassen

Das System bietet einige Komfortfunktionen für die Softwarelogistik zur Unterstützung großer Systemlandschaften. Gerade am Anfang, wenn nur ein Entwicklungssystem und nur Ziel-Systeme für einen Kunden existieren, erzeugt die Benutzung dieser Funktionen zusätzlichen Aufwand, der sich eventuell nicht amortisiert. Daher können Sie zuerst auf diese Funktionalitäten verzichten und zu einem späteren Zeitpunkt darauf umsteigen. Dieser Vorgang ist im Dokument „Supportumstellung“ beschrieben.

Interne Systeme/Supportsysteme zum Verteilen der Softwareaktualisierungen können beliebig in den Transportweg eingebaut werden, siehe dazu Dokumentation Supportauslieferungen. Zum Beispiel kann ein Partner über dieses System Kunden neue Softwareaktualisierungen (Supportauslieferungen, siehe unten) zum Download zur Verfügung stellen.

Diese Komfortfunktionen bringen folgende Vorteile, für eine genauere Beschreibung siehe auch Dokumentation Supportauslieferungen.

• Zusammenfassen von Softwareaktualisierungen:

Softwareaktualisierungen sollten zusammengefasst werden, wenn

• diese technisch voneinander abhängig sind. In diesem Fall können sie nur zusammen installiert werden. Dann ist die Verwendung nur einer Datei einfacher.
• diese inhaltlich aber nicht technisch voneinander abhängig sind. Das ist zum Beispiel der Fall, wenn die Behandlung von Daten in einer Anwendung verändert wurde und vorher eine Datenaktualisierung ausgeführt werden muss. Die Anwendung ist technisch nicht zwingend von der Datenaktualisierung abhängig, aber inhaltlich. In diesem Fall können Sie zwar einzeln installiert werden, aber die Anwendung wird nicht ordnungsgemäß arbeiten. Das Zusammenfassen verhindert in diesem Fall, dass die Anwendung ohne die Datenaktualisierung installiert wird.
• Erstellung von Supportauslieferungen:

Jede Supportauslieferung enthält Texte, die in der Supportauslieferung die enthaltene Problemlösung beschreiben bzw. erklären. Einer Support­aus­lieferung ist eine zusammengefasste Softwareaktualisierung zugeordnet. Vorteile:

• Zu jeder Supportauslieferung gehört eine Beschreibung, was die Supportauslieferung ändert / korrigiert.
• Download von Supportauslieferungen, vereinfachte Softwarelogistik. Die Supportauslieferungen können über die Beschreibung gesucht und dann heruntergeladen werden. Das Supportsystem protokolliert diesen Vorgang, somit kann jederzeit überprüft werden, welche Supportauslieferung von wem heruntergeladen wurde.
• Dokumentation der Auslieferung
• Supportanfragen, Dokumentation von Fehlern und Wünschen:

Mitarbeiter, Partner oder Kunden können auf diesem System Supportanfragen erstellen. Eine Supportanfrage ist alles, was als Anfrage, Fehlermeldung, Wunsch usw. eingeht.

• Statuskontrolle von Supportanfragen
• Ist die Supportanfrage in Bearbeitung, erledigt?
• Kontrolle, ob die zu einer Supportanfrage gehörenden Supportauslieferungen ausgeliefert worden.

5.6               Minimale Systemlandschaften

5.6.1          Partnerentwicklung ohne Adaptierung

Die Partnerentwicklung selbst sollte aus mindestens zwei Systemen bestehen.

1. Dem Partner-Entwicklungssystem (3 oder 4) (Entwicklungspräfix des Partners)
2. Dem zugeordneten Testsystem (7)

Zusätzlich werden für jeden Kunden folgende Systeme benötigt:

1. Ein Testsystem DT (7) beim Partner, wenn möglich sollte dieses System zumindest teilweise echte Daten des Kunden enthalten. Solange wirklich nur ein Kunde unterstützt wird, kann entweder auf 2. oder 3. verzichtet werden.
2. Ein Kundentestsystem T (7) beim Kunden.
3. Das Kundenproduktivsystem P (7).

Mögliche Transportwege:

Direkte Versorgung aus der Partnerentwicklung

Die direkte Versorgung eignet sich nur für kleine Installationen. Schon bei ein paar Kundensystemen wird sich das Zusammenfassen im Partnerentwicklungstestsystem lohnen. Außerdem wird dadurch automatisch sichergestellt, dass nur getestete Softwareaktualisierungen weitergegeben werden. Mit steigender Anzahl von Ziel-Systemen steigt bei der direkten Versorgung die Wahrscheinlichkeit, dass der Überblick über die Transporte verloren geht.

Zusammenfassen der Softwareaktualisierung im Partnerentwicklungs-Testsystem

Zusammenfassung im Partner Kunden-Testsystem

Diese Möglichkeit bietet sich vor allem an, wenn der Kunde selbst die Softwareaktualisierungen installiert und die Menge der Dateien (Software­aktualisierungen) reduziert werden soll, siehe dazu auch Abschnitt Supportauslieferung erstellen/Softwareaktualisierungen zusammenfassen.

Beim Vergleich der obigen Darstellungen erkennt man zwei verschiedene Konzepte in der Verteilung:

1. Von einem Quell-System sternförmig an alle möglichen Ziel-Systeme zur verteilen oder
2. Jedes System reicht die Softwareaktualisierungen an genau ein weiteres System weiter.

Für die Qualitätssicherung ist der zweite Ansatz besser, so wird sichergestellt, dass keine Softwareaktualisierung im Produktivsystem ankommt, bevor sie nicht im zugehörigen Testsystem eingespielt wurde. Der erste Ansatz erzeugt bei kleinen Installationen weniger zusätzlichen Aufwand. So können zum Beispiel alle Softwareaktualisierungen, die zusammen weitergeben werden sollen, gesammelt werden, um dann auf eine CD gebrannt zu werden. Diese CD kann dann dafür benutzt werden alle Ziel-Systeme zu aktualisieren. Dafür müssen die Zeitpunkte, zu denen die Softwareaktualisierungen eingespielt werden, manuell abgestimmt werden.

5.6.2          Partnerentwicklung mit Adaptierung

Die Partnerentwicklung selbst sollte aus mindestens zwei Systemen bestehen.

1. Dem Partner-Entwicklungssystem (3 oder 4) (Entwicklungspräfix des Partners)
2. Dem zugeordneten Testsystem (7)
3. Ein QS-System, das immer den letzten ausgelieferten Stand enthält. In diesem System können Fehler nachvollzogen werden. Dadurch kann eingegrenzt werden, ob die Fehler erst im Adaptierungssystem entstanden sind.

Für jeden Kunden, für den adaptiert wird, werden folgende Systeme benötigt:

1. Ein Adaptierungssystem DV (6). (Entwicklungspräfix des Kunden)
2. Ein Testsystem DT (7), wenn möglich sollte dieses System zumindest teilweise echte Daten des Kunden enthalten.
3. Ein Kundentestsystem T (7) beim Kunden.
4. Das Kundenproduktivsystem P (7).

Auch für diese Lösung existieren mehrere mögliche Transportwege. Die Softwareaktualisierungen aus den Entwicklungssystemen werden direkt in die nachgelagerten Systeme gespielt, oder erst im zugehörigen Testsystem zusammengefasst.

Eine Systemlandschaft kann eine Mischung aus Branchenlösung ohne Kundenadaptierung und mit Kundenadaptierung sein. Nur für Kunden die Adaptierungen benötigen, muss ein Kunden-Adaptierungssystem existieren.

Mögliche Transportwege

5.6.3          Adaptierungen (keine Partnerentwicklung)

Ohne Partnerentwicklung sind mindestens folgende Systeme nötig.

1. Ein Kunden-Adaptierungssystem DV (6) beim Partner. (Entwicklungspräfix des Kunden)
2. Ein Testsystem DT (7) beim Partner, wenn möglich sollte dieses System echte Daten des Kunden enthalten.
3. Ein Testsystem T (7) beim Kunden.
4. Das Produktivsystem P (7).

Auch für diese Lösung existieren mehrere mögliche Transportwege. Die Softwareaktualisierungen aus dem Kunden-Adaptierungssystem werden direkt in die nachgelagerten Systeme gespielt, oder erst im zugehörigen Testsystem DT zusammengefasst und das an die Systeme T und P weitergegeben.

5.6.4          Produktivsysteme ohne Adaptierung und ohne Partnerentwicklung

1. Ein Testsystem DT (7) beim Partner, wenn möglich sollte dieses System zumindest teilweise echte Daten des Kunden enthalten.
2. Ein Testsystem T (7) beim Kunden.
3. Das Produktivsystem P (7).

Die Software der kann entweder im DT-System noch einmal zusammengefasst werden oder direkt in die Systeme T und P gespielt werden.

Mögliche Transportwege:

5.7               Schematische Darstellung einer komplexen Systemlandschaft

Die folgende Darstellung zeigt eine „große Landschaft“ mit optimalen Transportwegen. Auf diese Weise werden die Softwareaktualisierungen auf keinen Fall „zu früh“ in Produktivsysteme eingespielt. Wie oben beschrieben kann der Abschnitt „Partnerentwicklung“ oder der Abschnitt „Kundenadaptierung“ komplett entfallen.

6              Transportlandschaft einrichten

Comarch-ERP-Enterprise-Systeme bilden eine Transportlandschaft, in der es Abhängigkeiten zwischen den einzelnen Systemen geben kann. Diese Abhängigkeiten definieren den von einer Softwareaktualisierung (SA) zu durchlaufenden Transportweg bis hin in ein Produktivsystem.

In diesem Kapitel werden mögliche Transportlandschaften, die Transport-Beziehungen von Systemen untereinander und die im Systemcockpit vorzunehmenden notwendigen Einstellungen von Systemen beschrieben.

6.1        Konventionen

• Entwicklungssysteme werden in den Abbildungen blau dargestellt
• Systeme mit Level 7 werden in den Abbildungen grün dargestellt
• Optionale (logische) Transportwege werden mit einem gestrichelten Pfeil dargestellt. Sie werden auch als sichere Transportwege bezeichnet.
• Obligatorische (physikalische bzw. notwendige) Transportwege werden mit durchgezogenen Pfeilen dargestellt. Sie werden auch als unsichere Transportwege bezeichnet.

6.2        Empfohlene Transportlandschaft

Die empfohlene Transportlandschaft nutzt konsequent alle gebotenen Funktionen zur Unterstützung des Entwicklungsprozesses, der Qualitätssicherung und der Softwarelogistik.

In der empfohlenen Transportlandschaft werden folgende Systeme bei einem Partner verwendet:

• Quality Assurance System (QAS) zur Verteilung der ausgelieferten Softwareaktualisierungen (SA). Ein QAS kann an mehreren Stellen in der Transportlandschaft eingebaut werden.
• Internes System (INT) zur Verwendung des Entwicklungsauftragsdiensts und zur Verwaltung von Supportauslieferungen
• Entwicklungssysteme (Partnerentwicklung oder Adaptierungssysteme)
• Testsysteme
• Demosysteme

Bei einem Kunden schließlich sind ein Produktiv-Testsystem und das Produktivsystem angesiedelt.

6.3        Welches System wird wann installiert?

Vom Zeitpunkt des Vertragsabschlusses über die mögliche Entwicklungs- und Adaptierungsphase bis zur Produktivsetzung eines Systems können mehrere Monate vergehen. Die jeweils an den unterschiedlichen Projektphasen beteiligten Systeme werden typischerweise dabei zu unterschiedlichen Zeitpunkten installiert. Dafür gibt es mehrere Möglichkeiten, aber es gilt auch diverse Voraussetzungen zu erfüllen.

Zunächst wird ein Auslieferungssystem (Wartungsrelease) installiert. Basierend auf diesem System können das QAS, das interne System, das Partnerentwicklungs- und Partnertestsystem und Adaptierungssysteme (Entwicklung und Test) aufgesetzt werden.

Als Faustregel gilt, dass Entwicklungs- und Testsystem basierend auf dem gleichen Codestand aufgesetzt werden müssen und alle aus dem Entwicklungssystem exportierten Softwareaktualisierungen in das Testsystem eingespielt werden müssen. Daneben gibt es die Möglichkeit Systeme als bereinigte Kopie zu installieren, siehe dazu „INF-000337:  Kopieren und Bereinigen eines Semiramis Systems“.

In einem Entwicklungssystem des Partners auf Versionierungsstufe 3 oder 4 können sehr umfangreiche Erweiterungen und Neuanlagen vorgenommen werden, so dass sehr viele Softwareaktualisierungen (SA) entstehen. Die entstandenen SA müssen alle in das Testsystem eingespielt werden. Wird das Testsystem zu einem späteren Zeitpunkt als das Entwicklungssystem installiert wird es – im Vergleich zur ständigen Aktualisierung mit SA – mit der fortschreitenden Entwicklung immer weniger aufwendig das Testsystem als bereinigte Kopie des Entwicklungssystems aufzusetzen. Dies gilt insbesondere sobald die Entwicklung einen definierten Stand erreicht hat und im Wesentlichen nur noch Korrekturen zu erwarten sind.

Für Adaptierungssysteme gilt Ähnliches. Falls lediglich wenige Änderungen vorgenommen werden müssen, sollte das Testsystem zeitnah basierend auf dem gleichen Wartungsrelease aufgesetzt werden. Wird das Adaptierungs-Testsystem zu einem späteren Zeitpunkt aufgesetzt, muss für die Installation entweder der gleiche Systemstand wie für das Adaptierungssystem verwendet und alle erstellten Softwareaktualisierungen nachgeführt werden oder es wird eine bereinigte Kopie des Adaptierungssystems verwendet, siehe dazu „INF-000337: Kopieren und Bereinigen eines Semiramis Systems“.

Basiert ein Adaptierungssystem auf einer Partnerentwicklung, muss es entsprechend entweder

• mit dem gleichen Wartungsrelease wie das Partner-Entwicklungssystem aufgesetzt und alle erstellten SA eingespielt werden.
• oder das System wird als bereinigte Kopie des Partner-Entwicklungssystems installiert, falls im Partnerentwicklungs-Testsystem die SA nicht zusammengefasst werden.
• oder das System wird als bereinigte Kopie des Partnerentwicklungs-Testsystems installiert, falls im Partnerentwicklungs-Testsystem die SA zusammengefasst werden.

Die in der Produktivumgebung aufgesetzten Systeme müssen entweder mit dem gleichen Codestand wie das davor liegende Entwicklungssystem basierend auf einem Wartungsrelease aufgesetzt werden oder als bereinigte Kopie des vorgelagerten Testsystems, in dem Softwareaktualisierungen zusammengefasst werden.

6.4        Transportwege und Systemfamilien

Ein Transportweg beschreibt den Weg, den eine Änderung eines Entwicklungsobjekts in Form einer Softwareaktualisierung durch die beteiligten Systeme nimmt, ehe sie letztendlich in einem Produktivsystem eingespielt wird.

Die durch einen Transportweg zusammenhängenden Systeme stammen normalerweise immer vom gleichen Major Release VxRy.

Die in einem Transportweg zusammenhängenden Systeme bilden eine Systemfamilie.

6.4.1    Beispiele für Systemfamilien

Aus Sicht des Partners beginnt eine Systemfamilie mit dem ersten von ihm verwalteten Entwicklungssystem. Dies kann das System der Partnerentwicklung oder ein Adaptierungssystem sein. Die vorgelagerten Systeme gehören als Ursprung aller Systemfamilien auch zu der jeweiligen Systemfamilie, sie werden hier aber nicht weiter betrachtet.

Hier werden lediglich anschauliche Beispiele der Transportwege gegeben.

6.4.1.1      Systemfamilie bei Partnerentwicklung

 

Alle Änderungen, die in einem System der Partnerentwicklung entstehen und in ein Produktivsystem übernommen werden, müssen durch alle dem Produktivsystem vorgelagerten Systeme des Transportwegs transportiert werden, in denen Softwareaktualisierungen zusammengefasst werden oder die Entwicklungssysteme sind.

Änderungen, die in einem Adaptierungssystem anfallen, werden nur durch die zu diesem Adaptierungssystem gehörenden nachgelagerten Systeme transportiert.

Quertransporte zwischen den einzelnen Zweigen der Systemfamilien sind nur einmalig zu Beginn der Entwicklung eines der Zweige möglich.

Jedes System hat nur ein direkt vorgelagertes System, dass durch die Angabe der Import-Restriktionen festgelegt wird. Das Ändern des Vorgängersystems ist nicht mehr möglich, sobald die ersten Softwareaktualisierungen aus dem Vorgängersystem eingespielt wurden.

6.4.1.2      Systemfamilie bei Adaptierung

Wird kein System zur Partnerentwicklung eingesetzt, bilden die einzelnen auf Adaptierungssystemen beruhenden Systeme eigenständige Systemfamilien.

Quertransporte zwischen den einzelnen Zweigen der Systemfamilien sind nur einmalig zu Beginn der Entwicklung eines der Zweige möglich.

 

In diesem Szenario werden die Adaptierungssysteme als Kopie von einem Wartungsrelease aufgesetzt.

6.4.2    Beispiele für Transportwege

6.4.2.1      Gesicherter Transportweg

Eine in ein System via Softwareaktualisierung (SA) eingespielte Änderung oder Korrektur kann einem System mit anderen SA zu einer neuen SA zusammengefasst werden. In den folgenden Abbildungen sind die Verbindungen zwischen Systemen mit einer gestrichelten Linie versehen, falls das Vorgängersystem zusammengefasste SA ausliefert.

Gesichert ist ein Transportweg, wenn alle beteiligten Systeme auf dem Transportweg in genau dieser Reihenfolge mit der SA versorgt werden. Insbesondere wird durch Testsysteme sichergestellt, dass das Einspielen der SA funktioniert und alle notwendigen SA eingespielt werden. Es existieren also keine nicht aufgelösten Abhängigkeiten. Die Verwendung von Testsystemen stellt neben der technischen Konsistenz der SA auch sicher, dass die betriebswirtschaftliche Korrektheit der eingespielten SA mit dem Codestand getestet werden kann, der in einem nachgelagerten System vorhanden ist.

In der Darstellung sind Entwicklungssysteme (Versionierungslevel 1, 2, 3, 4, 6) blau hinterlegt und Produktiv-, Test- und Demosysteme (Versionierungslevel 7) grün hinterlegt.

Das interne System, das zur Verwaltung von Entwicklungsaufträgen und Softwareauslieferungen genutzt wird, ist ein Level 7 System und hier in einer anderen Farbe von den anderen Systemen abgesetzt, da es Release-übergreifend verwendet wird. Es wird aber nur mit SA aus einem Release versorgt.

Die Softwareaktualisierungen des Korrektursystems werden auf dem Korrektur-Testsystem zusammengefasst.

Die aus diesem Level 2-System exportierten Softwareaktualisierungen werden als „babel-*“ Dateien auf dem Support Center bereitgestellt.

In das QAS werden die vom Support Center bereitgestellten SA eingespielt. Das QAS wird nicht zur Zusammenfassung von SA genutzt, sondern stellt einen Verteiler auf die anderen Systeme dar.

Vom QAS werden die SA via „Zielsystem aktualisieren“ an

• das interne System,
• Standard Demosysteme (Demonotebooks)
• das Partner-Entwicklungssystem und
• Adaptierungssysteme

weitergegeben und in den Ziel-Systemen eingespielt.

Im Partnerentwicklungs- bzw. Partnerentwicklungs-Korrektur-System werden durch Erweiterungen und Konfliktbearbeitungen neue SA mit einem neuen Exportpräfix erzeugt.

Die SA der Partnerentwicklung/-Korrektur werden in das Partnerentwicklungs-Testsystem eingespielt und dort optional zusammengefasst.

Die zusammengefassten SA werden in die auf der Partnerentwicklung basierenden Adaptierungssysteme eingespielt.

Die in einem Adaptierungssystem (basierend auf der Standardentwicklung bzw. auf der Partnerentwicklung) erstellten SA werden in das jeweilige Adaptierungs-Testsystem eingespielt und dort zusammengefasst.

Die in einem Adaptierungs-Testsystem zusammengefassten SA werden zunächst in das Produktiv-Testsystem eingespielt und können dort wiederum zusammengefasst werden.

Zuletzt werden die bereitgestellten SA in das Produktivsystem eingespielt.

In jedem System, in das die Softwareaktualisierungen eingespielt werden, werden diese umbenannt und mit neuem Exportpräfix exportiert bzw. kann mit anderen zu einer neuen SA zusammengefasst werden.

Dabei kann man sich das Zusammenfassen von Softwareaktualisierungen als eine andere Verpackung oder Zusammenstellung in einem neuen Paket der SA unter einem neuen Namen vorstellen. Die Informationen über die in dem neuen Paket enthaltenen SA bleiben dabei erhalten und können über die Anwendung „Softwareaktualisierungen“ eingesehen werden.

Werden die Testsysteme zum Zusammenfassen genutzt, gilt folgende Regel für die Import-Restriktion eines direkt nachgelagerten Systems:

1. Die Versionierungsstufe des Vorgängersystems ist immer eine Stufe eines Entwicklungssystems.
2. Das Exportpräfix ist das Exportpräfix des Entwicklungs-Testsystems.

6.4.2.2      Ungesicherter Transportweg

Änderungen an Entwicklungsobjekten entstehen nur in Entwicklungssystemen. Werden die resultierenden Softwareaktualisierungen nicht weiter zusammengefasst, können diese SA in direkt nachgelagerte Systeme parallel eingespielt werden. Systeme auf dem Transportweg können und dürfen nicht übersprungen werden. In diesem Szenario können und dürfen in ein System nur die SA des unmittelbar vorhergehenden Entwicklungssystems eingespielt werden.

Ungesichert ist ein Transportweg, wenn die in einem Entwicklungssystem entstandenen SA ohne in einem Testsystem zusammengefasst oder getestet zu werden in ein nachgelagertes System eingespielt werden können.

Ausgehend von dem Entwicklungssystem, in dem eine Änderung vorgenommen wird, muss eine SA auf dem Weg in das Produktivsystem auch alle auf dem Transportweg nachfolgenden Entwicklungssysteme durchlaufen, bevor sie in ein System mit Level 7 eingespielt werden darf.

 

In der Darstellung sind Entwicklungssysteme (Versionierungslevel 1, 2, 3, 4 oder 6) blau hinterlegt und Produktiv-, Test- und Demosysteme (Versionierungsstufe 7) grün hinterlegt. Das interne System, das zur Verwaltung von Entwicklungsaufträgen und Softwareauslieferungen genutzt wird, ist ein Level 7 System und hier in einer anderen Farbe von den anderen Systemen abgesetzt, da es Release-übergreifend verwendet wird. Es wird aber nur mit SA aus einem Release versorgt.

An einem ungesicherten Transportweg sind nur Systeme beteiligt, in denen sich die Version von Entwicklungsobjekten ändert, also Entwicklungs- und Korrektursysteme Level 1, 2, 3, 4 oder 6. Produktivsysteme werden direkt aus dem vorgelagerten Entwicklungssystem versorgt.

In diesem Szenario werden die SA in keinem der Systeme zusammengefasst.

Ausgelieferte SA sind immer zusammengefasste Softwareaktualisierungen, die in einem Level 1 System entstanden und in einem Stufe 7 System zusammengefasst wurden. Diese mit dem Präfix „babel-*“ versehenen SA „enthalten“ wiederum die eigentlichen Änderungen in „cisag-*“ Softwareaktualisierungen.

Die bereitgestellten SA können vom Support Center dazu verwendet werden, um folgende Systeme zu aktualisieren:

• QAS,
• internes System,
• Standard-Demosysteme,
• Partner-Entwicklungs- bzw. Partner-Korrektursystem und
• auf dem Standard basierende Adaptierungssysteme

Die in einem Partner-Entwicklungs- bzw. Partner-Korrektursystem entstehenden SA können direkt in folgende nachgelagerte Systeme eingespielt werden:

• das Partner-Testsystem,
• Partner-Demosysteme,
• auf der Partnerentwicklung basierende Adaptierungssysteme

Die in einem Adaptierungssystem entstehenden SA können direkt in folgende nachgelagerte Systeme eingespielt werden:

• das zugehörige Adaptierungs-Testsystem,
• Produktiv-Testsystem und das
• Produktiv-System

Falls auf dem Transportweg von der Funktionalität „Softwareaktualisierungen zusammenfassen“ kein Gebrauch gemacht wird, ergibt sich somit für nachgelagerte Systeme, dass die Import-Restriktionen (Versionierungsstufe und Muster) auf das Vorgänger-Entwicklungssystem (Level und Export-Präfix) eingestellt werden müssen.

Wenn die Testsysteme nicht zum Zusammenfassen genutzt werden, dann gelten folgende Regeln für die Import-Restriktionen eines direkt nachgelagerten Systems:

• Die Versionierungsstufe des Vorgängersystems ist immer eine Stufe eines Entwicklungssystems.
• Das Exportpräfix ist das Exportpräfix des vorgelagerten Entwicklungssystems.

Am Transportweg (die beteiligten Systeme, in die SA eingespielt werden) ändert sich auch nichts, wenn die Funktion SA zusammenfassen nicht genutzt wird, sondern lediglich durch organisatorische Maßnahmen sichergestellt wird, dass die SA in der beschriebenen Abfolge die Systeme durchlaufen.

Werden die Softwareaktualisierungen zum Testen in die Testsysteme eingespielt, aber dort nicht zusammengefasst, bevor sie in nachgelagerte Systeme eingespielt werden, ändern sich die Import-Restriktionen der Systeme gegenüber dem Fall, dass keine Testsysteme zum Einsatz kommen, nicht.

Es gilt für die Import-Restriktionen:

• Die Versionierungsstufe des Vorgängersystems ist immer eine Stufe eines Entwicklungssystems.
• Das Exportpräfix ist das Exportpräfix des vorgelagerten Entwicklungssystems.

Diese Regeln greifen auch, wenn kein Entwicklungs-Testsystem eingesetzt wird und das Entwicklungs-System direkt nachgelagerte Systeme versorgt.

7              Systemeinstellungen

Im folgenden Kapitel werden für die einzelnen Systeme die notwendigen Einstellungen aufgeführt, die für den jeweiligen beschriebenen Einsatzzweck notwendig sind.

Jedes System benötigt ein eigenes installiertes ERP-Enterprise-System, das aus den ausgelieferten Dateien und Datenbankimporten eines Wartungsreleases her­vor­geht bzw. durch einen Partner als Wartungsrelease einer Partnerentwicklung bereitgestellt wurde.

Die Einstellungen werden in der Anwendung „Systemcockpit“ vorgenommen. Viele Einstellungen ergeben sich durch die System-Lizenz, die jedes System benötigt (siehe dazu die Dokumentation Lizenzierung). Die für den Betrieb eines Systems weiteren notwendigen Einstellungen entnehmen Sie den Dokumentationen zur Installation eines neuen Semiramis-Systems.

Im Folgenden werden die Einstellungen für folgende Systeme aufgeführt:

• Demosystem
  Ein Demosytem basierend auf einem Standard-Wartungsrelease
• QAS450PAR
  QAS des Release Semiramis 4.5 des Partners mit Kürzel PAR
• INT450PAR
  Internes System des Release Semiramis 4.5 des Partners mit Kürzel PAR
• PAR450DV
  Partner-Entwicklungssystem (DV für Development) des Release Semiramis 4.5 des Partners mit Kürzel PAR
• PAR450DT
  Partnerentwicklungs-Testsystem (DT für Development Test) des Release Semiramis 4.5 des Partners mit Kürzel PAR
• CUS450DV
  Adaptierungssystem (DV für Development) aufgesetzt mit Release Semiramis 4.5 für Kunde mit Kürzel CUS (Customer)
• CUS450DT
  Adaptierungs-Testsystem (DT für Development Test) aufgesetzt mit Release Semiramis 4.5 für Kunde mit Kürzel CUS (Customer)
• CUS450T
  Produktions-Testsystem (T für Test) aufgesetzt mit Release Semiramis 4.5 für Kunde mit Kürzel CUS (Customer)
• CUS450P
  Produktions-System (P für Productive System) aufgesetzt mit Release Semiramis 4.5 für Kunde mit Kürzel CUS (Customer)

Ersetzen Sie die verwendeten Kürzel PAR (das Partnerkürzel) und CUS (das Kundenkürzel) durch die konkreten Abkürzungen.

7.1        Demosysteme

Ein installiertes Wartungsrelease (z. B. CIS450PBOR) kann zunächst nur als Demosystem verwendet werden. Die notwendigen Systemeinstellungen sind für den Einsatz als Demosystem schon getroffen.

7.2        Quality Assurance System

Ein Quality Assurance System (QAS) wird basierend auf den Installationsdateien für ein Demosystem erstellt. Es benötigt für den Einsatz keine Java-Sourcen. Es wird aber genutzt um das Einspielen von Klassen und Java-Sourcen zu testen.

Von einem QAS aus können logisch nachgelagerte Systeme wie Demosysteme, Partner-Entwicklungssystem oder Adaptierungssysteme über „Zielsystem aktualisieren“ auf den gewünschten Stand gebracht werden.

Feldname	Feldinhalt
Release	Semiramis 4.5
Versionierungsstufe	7
Exportpräfix	qas
Entwicklungspräfix	Nicht eingabebereit
Verwendung	Qualitätssicherungssystem
Identitätsmodus	Lokal
Identitäts-Serversystem	Nicht eingabebereit
Identitäts-Server	Nicht eingabebereit
Entwicklungsauftrags-Server-Modus	Verwenden
Entwicklungsauftrags-Server-System	INT450<PAR>
Entwicklungsauftrags-Server	INT450<PAR>MS – Message Server
Entwicklungsauftrags-Serverdatenbank	INT450<PAR>00

Import-Restriktionen:

Feldname	Feldinhalt
Versionierungsstufe	1 – Korrektursystem
Muster	babel-*

Hinweis:
Beachten Sie, dass Sie einige der Felder erst füllen können, wenn die referenzierten Objekte bereits angelegt wurden. Beispielsweise können Sie die Angaben zum Entwicklungsauftrags-Server-System erst dann machen, wenn das System in der Konfigurationsdatenbank erfasst wurde.

7.3        Entwicklungsauftragssystem – internes System

Das interne System wird basierend auf den Installationsdateien für ein Demosystem erstellt. Es benötigt für den Einsatz keine Java-Sourcen. Es wird genutzt um die Entwicklungsaufträge Entwicklungssystem-übergreifend und Release-übergreifend zu verwalten. Darüber hinaus verwaltet es Informationen zu Supportauslieferungen.

Feldname	Feldinhalt
Release	Semiramis 4.5
Versionierungsstufe	7
Exportpräfix	int
Entwicklungspräfix	Nicht eingabebereit
Verwendung	Produktivsystem
Identitätsmodus	Lokal
Identitäts-Serversystem	Nicht eingabebereit
Identitäts-Server	Nicht eingabebereit
Entwicklungsauftrags-Server-Modus	Verwenden
Entwicklungsauftrags-Server-System	INT450<PAR>
Entwicklungsauftrags-Server	INT450<PAR>MS – Message Server
Entwicklungsauftrags-Serverdatenbank	INT450<PAR>00

Import-Restriktionen:

Feldname	Feldinhalt
Versionierungsstufe	1 – Korrektursystem
Muster	babel-*

Das interne System muss mit den Entwicklungssystemen, für die es Entwicklungsaufträge verwaltet, synchron gehalten werden, damit die notwendigen Informationen zu Entwicklungsaufgaben erhalten bleiben.

7.4        Partnerentwicklung

Möchte ein Partner z. B. eine Branchenlösung entwickeln oder möchte er Funktionalität, die in mehreren Adaptierungssystemen bereitgestellt werden soll, in einem System entwickeln, bietet sich der Einsatz eines Partner-Entwicklungssystems an.

Mit den beiden Versionierungsstufen „3 – Entwicklungssystem des Partners“  und „4 – Korrektursystem des Partners“ bietet sich auch die Einteilung des Entwicklungszyklus in eine Entwicklungsphase, in der die API und das Datenmodell noch nicht festgeschrieben sind, und eine Korrekturphase an, in der lediglich Fehler behoben werden.

Als Konsequenz ergibt sich, dass der Transportweg einer Fehlerbehebung im Standard bis hin zu einem Produktivsystem bei einem Kunden länger wird, falls die Produktivsysteme auf dem Partner-Entwicklungssystem aufbauen.

Der Transportweg verlängert sich weiter, falls nach dem Partner-Entwicklungs­system noch ein kundenindividuelles Adaptierungssystem auf dem Transport­weg liegt.

Eine SA muss durch alle beteiligten Systeme transportiert werden und kann in den Entwicklungssystemen zu Konfliktaufgaben führen. Die Konfliktaufgaben müssen bearbeitet werden, bevor die entstehenden SA weiter transportiert werden können. Die entstehenden SA können wiederum untereinander Abhängigkeiten aufbauen, die den Transport in das nächste System verzögern.

Für das Aufsetzen der Systeme entlang des Transportwegs müssen einige Voraussetzungen beachtet werden. Es kann nicht jedes System mit einem beliebigen Wartungsrelease aufgesetzt werden.

Daher sollte der Einsatz eines Partner-Entwicklungssystems eng mit dem Support Center abgestimmt werden.

Partner-Entwicklungssystem und Partnerentwicklungs-Testsystem werden zeitgleich basierend auf einem Wartungsrelease aufgesetzt. Wird das Partnerentwicklungs-Testsystem zu einem späteren Zeitpunkt aufgesetzt, wird es als bereinigte Kopie des Partner-Entwicklungssystems aufgesetzt, siehe dazu auch „INF-000337: Kopieren und Bereinigen eines Semiramis Systems“.

7.4.1    Anzeigesprachen und Sprachaktualisierungen

Im Allgemeinen sollten Sie im Partner-Entwicklungssystem und im Partnerentwicklungs-Testsystem alle Sprachen als Anzeigesprachen eingerichtet haben, die die nachfolgenden Kundensysteme benötigen. Nur so können Sie ihre Anpassungen im Rahmen der Partnerentwicklung übersetzen.

Ob Sie Sprachaktualisierungen oder Softwareaktualisierungen für die Auslieferung von Übersetzungen der Partnerentwicklung nutzen, hängt von folgenden Faktoren ab:

• Umfang der Anpassungen
• Anzahl der nachgelagerten Entwicklungssysteme

Wenn Sie feststellen können, dass in nachgelagerten Entwicklungssystemen wenige Konflikte entstehen werden, dann empfehlen wir Software­aktuali­sierungen zu nutzen. Das erspart Ihnen das Erstellen neuer Sprach­aktualisierungen.

Installieren Sie in Ihrem Partner-Entwicklungssystem und in Ihrem Partnerentwicklungs-Testsystem die Sprachaktualisierungen jener Sprachen, die in einem nachgelagerten System benötigt werden. Nutzen Sie für den Export Ihrer Übersetzungen aus dem Partner-Entwicklungssystem die Softwareaktualisierungen, nicht die Sprachaktualisierungen. Importieren Sie die Softwareaktualisierungen in Ihr Partnerentwicklungs-Testsystem.

Wägen Sie ab:

• Wenn Sie in einem Partner-Entwicklungssystem geringe Anpassungen haben, dann können Sie für den Transport der Anpassungen aus dem Partnerentwicklungs-Testsystem die Softwareaktualisierungen nutzen. Auf allen nachgelagerten Systemen ist unsere Sprachaktualisierung zu installieren.
• Wenn Sie in einem Partner-Entwicklungssystem umfangreiche Anpassungen haben, die zu vielen Konflikten auf nachgelagerten Systemen führen können, dann empfehlen wir, die Sprachaktualisierung zu nutzen. Dazu exportieren Sie aus dem Testsystem die jeweilige Sprache als Sprach Konflikte in nachgelagerten Entwicklungssystemen, beispielsweise in einem Kunden-Adaptierungssystem, werden vermieden.

In der Anwendung „Customizing“ unter der Rubrik „Softwareaktualisierungen“ können Sie in dem Feld „Exportierbare Sprachen“ angeben, zu welchen Sprachen Textrefreshes erstellt werden sollen.

Wenn Sie keine Sprachaktualisierungen verwenden wollen, das heißt, wenn zu jeder auf dem System verfügbaren Sprache ein Textrefresh erstellt werden soll, geben Sie „*“ auf dem Partnerentwicklungs-Testsystem in das Feld „Exportierbare Sprachen“ ein.

Wenn Sie Übersetzungen mit Sprachaktualisierungen ausliefern wollen, dann tragen Sie ihre Entwicklungssprache auf dem Partnerentwicklungs-Testsystem in das Feld „Exportierbare Sprachen“ ein. Alle anderen Sprachen werden damit nicht als Textrefeshes exportiert.

7.4.2    Partner-Entwicklungssystem

Als Grundlage für ein Partner-Entwicklungssystem dient das Partnersystem einer Wartungsrelease-Auslieferung. Es enthält die zur Entwicklung notwendigen Java-Sourcen. Es benötigt einen eigenen Entwicklungs- und Exportpräfix, die Sie über das Support Center erhalten.

Sie können die Partnerentwicklung auf einem System der Stufe 3 oder 4 beginnen. Auf Stufe 4 werden erweiterte Prüfungen in der Entwicklungs­um­gebung durchgeführt, dann können auf Stufe 4 z. B. keine Entwicklungsobjekte mehr direkt gelöscht werden.

Hinweis:
Bitte wenden Sie sich für genauere Informationen und zur Beratung, welche Stufe für Sie geeignet ist, an das Support Center.

Feldname	Feldinhalt
Release	Semiramis 4.5
Versionierungsstufe	3,4
Exportpräfix	<PAR>dv
Entwicklungspräfix	<PAR>dv
Verwendung	Partner-Entwicklungssystem
Identitätsmodus	Lokal
Identitäts-Serversystem	Nicht eingabebereit
Identitäts-Server	Nicht eingabebereit
Entwicklungsauftrags-Server-Modus	Verwenden
Entwicklungsauftrags-Server-System	INT450<PAR>
Entwicklungsauftrags-Server	INT450<PAR>MS – Message Server
Entwicklungsauftrags-Serverdatenbank	INT450<PAR>00

Import-Restriktionen:

Feldname	Feldinhalt
Versionierungsstufe	1 – Korrektursystem
Muster	babel-*

Customizing „Softwareaktualisierungen“:

Feldname	Feldinhalt
Exportierbare Sprachen	*

7.4.3    Partnerentwicklungs-Testsystem

Ein Partnerentwicklungs-Testsystem sollte parallel zum Partner-Entwicklungssystem und mit dem gleichen Wartungsrelease aufgesetzt werden, damit alle jemals in das Entwicklungssystem eingespielten Softwareaktualisierungen auch in das Testsystem eingespielt werden können. Das Aufsetzen mit einem späteren Wartungsrelease ist nicht möglich. Die im Entwicklungssystem entstandenen SA lassen sich u. U. nicht in das neuere Wartungsrelease einspielen.

Da das Partnerentwicklungs-Testsystem evtl. noch nachgelagerte Adaptierungs­­systeme mit SA versorgt, muss es wie auch das Partner-Entwicklungs­system mit dem in einer Wartungsrelease-Auslieferung gelieferten Partnersystem aufgesetzt werden, das die Java-Sourcen enthält.

Wenn das Testsystem zu einem späteren Zeitpunkt als das Partner-Entwicklungssystem aufgesetzt wird, dann wird dazu eine bereinigte Kopie des Entwicklungssystems verwendet, siehe dazu auch „INF-000337: Kopieren und Bereinigen eines Semiramis Systems“. Wird ein bereinigtes Partner-Entwicklungs­system als Installationsvorlage eingesetzt, dann sind die kopierten Sourcen des Partner-Entwicklungssystems zu verwenden. Das Vorgehen zur Bereinigung eines Systems wird im Systemhandbuch beschrieben.

Feldname	Feldinhalt
Release	Semiramis 4.5
Versionierungsstufe	7
Exportpräfix	<PAR>dt
Entwicklungspräfix	Nicht eingabebereit
Verwendung	Entwicklungs-Testsystem
Identitätsmodus	Lokal
Identitäts-Serversystem	Nicht eingabebereit
Identitäts-Server	Nicht eingabebereit
Entwicklungsauftrags-Server-Modus	Verwenden
Entwicklungsauftrags-Server-System	INT450<PAR>
Entwicklungsauftrags-Server	INT450<PAR>MS – Message Server
Entwicklungsauftrags-Serverdatenbank	INT450<PAR>00

Import-Restriktionen:

Feldname	Feldinhalt
Versionierungsstufe	3 – Entwicklungssystem des Partners oder 4 – Korrektursystem des Partners
Muster	<PAR>dv-*

Die Festlegung, ob das Partnerentwicklungs-Testsystem zur Zusammenfassung von SA verwendet wird, kann nicht über die Systemeinstellungen getroffen werden.

Customizing „Softwareaktualisierungen“:

Feldname	Feldinhalt
Exportierbare Sprachen	* wenn keine Sprachaktualisierungen verwendet werden oder Entwicklungssprache wenn Sprachaktualisierungen verwendet werden.

7.5        Adaptierungssysteme

Die in einem Adaptierungssystem gemachten Änderungen sind kunden­individuell und lassen sich meist nicht direkt in anderen Projekten einsetzen.

Ein Adaptierungssystem kann auf einer Partnerentwicklung aufbauen oder auf dem Standardsystem.

Adaptierungssysteme (Test und Entwicklung) werden zeitgleich aufgesetzt:

• aus einem Wartungsrelease, falls Sie auf dem Standardsystem basieren oder
• aus einem bereinigten Partner-Entwicklungssystem, falls kein Testsystem eingesetzt wird oder SA im Testsystem nicht zusammengefasst werden oder
• aus einem bereinigten Partnerentwicklungs-Testsystem, falls in dem Testsystem die SA des Partner-Entwicklungssystems zusammengefasst werden.

Wenn das Adaptierungs-Testsystem zu einem späteren Zeitpunkt als das Adaptierungssystem aufgesetzt wird, dann wird es als bereinigte Kopie des Adaptierungssystems aufgesetzt.

7.5.1    Adaptierung basierend auf Partner-Entwicklungssystem

Adaptierungssysteme, die auf einem Partner-Entwicklungssystem aufbauen,  werden zu einem wesentlich späteren Zeitpunkt als das Partner-Entwicklungs­system selbst installiert. Für Adaptierungssysteme, die auf einer Partner­entwicklung beruhen, kann nicht das aktuellste Standard-Wartungs­release verwendet werden.

Verwenden Sie eine bereinigte Kopie des Partnerentwicklungs-Testsystems, falls dort SA zusammengefasst werden. Verwenden Sie eine bereinigte Kopie des Partner-Entwicklungssystems, falls die SA nicht im Testsystem zusammengefasst werden. Die Vorgehensweise zur Bereinigung eines Systems wird im Systemhandbuch beschrieben. Weitere Informationen zum Kopieren und Bereinigen von Systemen finden Sie auch in „INF-000337: Kopieren und Bereinigen eines Semiramis Systems“.

Feldname	Feldinhalt
Release	Semiramis 4.5
Versionierungsstufe	6
Exportpräfix	<CUS>dv
Entwicklungspräfix	<CUS>dv
Verwendung	Kunden-Adaptierungssystem
Identitätsmodus	Lokal
Identitäts-Serversystem	Nicht eingabebereit
Identitäts-Server	Nicht eingabebereit
Entwicklungsauftrags-Server-Modus	Verwenden
Entwicklungsauftrags-Server-System	INT450PAR
Entwicklungsauftrags-Server	INT450PARMS – Message Server
Entwicklungsauftrags-Serverdatenbank	INT450PAR00

Import-Restriktionen, falls im Partnerentwicklungs-Testsystem die SA zusammengefasst werden:

Feldname	Feldinhalt
Versionierungsstufe	3 – Entwicklungssystem des Partners oder 4 – Korrektursystem des Partners
Muster	<PAR>dt-*

Import-Restriktionen, falls keine SA zusammengefasst werden:

Feldname	Feldinhalt
Versionierungsstufe	3 – Entwicklungssystem des Partners oder 4 – Korrektursystem des Partners
Muster	<PAR>dv-*

7.5.2    Adaptierung basierend auf Standardentwicklung

Verwenden Sie zum Aufsetzen eines Adaptierungssystems basierend auf der Standardentwicklung das jeweils neueste Wartungsrelease. Verwenden Sie das ausgelieferte Partnersystem, das die Java-Sourcen enthält.

Feldname	Feldinhalt
Release	Semiramis 4.5
Versionierungsstufe	6
Exportpräfix	<CUS>dv
Entwicklungspräfix	<CUS>dv
Verwendung	Kunden-Adaptierungssystem
Identitätsmodus	Lokal
Identitäts-Serversystem	Nicht eingabebereit
Identitäts-Server	Nicht eingabebereit
Entwicklungsauftrags-Server-Modus	Verwenden
Entwicklungsauftrags-Server-System	INT450<PAR>
Entwicklungsauftrags-Server	INT450<PAR>MS – Message Server
Entwicklungsauftrags-Serverdatenbank	INT450<PAR>00

Import-Restriktionen:

Feldname	Feldinhalt
Versionierungsstufe	1 – Korrektursystem
Muster	babel-*

7.5.3    Adaptierungs-Testsystem

Ein Adaptierungs-Testsystem wird zeitgleich mit dem Adaptierungssystem und mit dem gleichen Ausgangssystem installiert.

Für ein Adaptierungssystem basierend auf einer Partnerlösung wird die bereinigte Kopie des Partnerentwicklungs-Testsystems verwendet.

Für ein Adaptierungs-Testsystem basierend auf der Standardentwicklung wird das gleiche Wartungsrelease wie für das Adaptierungssystem verwendet. Sie können die Demoversion ohne Java-Sourcen eines Wartungsreleases verwenden, da das Adaptierungs-Testsystem keine nachgelagerten Systeme versorgen muss, die zur Entwicklung eingesetzt werden.

Alternativ können Sie das Adaptierungssystem kopieren und bereinigen.

Das Testsystem dient zum Testen und Zusammenfassen der im Adaptierungs­system angefallenen Änderungen.

Feldname	Feldinhalt
Release	Semiramis 4.5
Versionierungsstufe	7
Exportpräfix	<CUS>dt
Entwicklungspräfix	Nicht eingabebereit
Verwendung	Kundenadaptierungs-Testsystem
Identitätsmodus	Lokal
Identitäts-Serversystem	Nicht eingabebereit
Identitäts-Server	Nicht eingabebereit
Entwicklungsauftrags-Server-Modus	Verwenden
Entwicklungsauftrags-Server-System	INT450<PAR>
Entwicklungsauftrags-Server	INT450<PAR>MS – Message Server
Entwicklungsauftrags-Serverdatenbank	INT450<PAR>00

Import-Restriktionen:

Feldname	Feldinhalt
Versionierungsstufe	6 – Adaptierungssystem
Muster	<CUS>dv-*

7.6        Produktivsysteme

Bei einem Kunden muss es ein Testsystem geben, in das die ausgelieferten SA eingespielt werden. Das Testsystem dient auch dazu die gemachten Änderungen auf realen Kundendaten zu testen und zusammenzufassen, bevor sie in das Produktivsystem eingespielt werden.

Produktivsysteme (Produktiv-Testsystem und Produktivsystem) werden zeitgleich aufgesetzt aus

• einem Wartungsrelease, falls keinerlei Adaptierungen vorgenommen werden sollen, oder
• aus einer bereinigten Kopie des Adaptierungs-Testsystems, falls im Adaptierungs-Testsystem SA zusammengefasst werden und die Produktivsysteme wesentlich später als die Adaptierungssysteme aufgesetzt werden, oder
• dem gleichen Wartungsrelease wie die vorgelagerten Adaptierungssysteme, falls im Adaptierungs-Testsystem die SA nicht zusammengefasst werden und alle dort erstellten SA werden in die Produktivsysteme eingespielt, oder
• als bereinigte Kopie eines Adaptierungs-Testsystems, in dem keine SA zusammengefasst werden, aber alle SA des Adaptierungssystems eingespielt wurden.

7.6.1    Produktiv-Testsystem

Produktivsysteme werden in der Regel zeitlich wesentlich später als Partner-Entwicklungssysteme aufgesetzt. Der zeitliche Abstand zwischen der Installation eines Adaptierungssystems und Produktivsystemen ist dagegen in der Regel gering.

Basieren die Produktivsysteme direkt auf einer Partnerentwicklung muss das Produktivsystem als bereinigte Kopie des Partnerentwicklungs-Testsystems aufgesetzt werden. Es ist nicht möglich ein aktuelles Wartungsrelease zu verwenden.

Basiert die Entwicklung auf einer Adaptierung muss das Produktivsystem mit dem gleichen System wie das Adaptierungs- und Adaptierungs-Testsystem aufgesetzt werden. Alle aus dem Adaptierungs-Testsystem (falls SA zusammengefasst werden) oder Adaptierungssystem (falls keine SA zusammengefasst werden) exportierten SA müssen installiert werden. Alternativ kann auch eine bereinigte Kopie des Adaptierungs-Testsystems verwendet werden.

Wenn die Entwicklung auf dem Standard basiert, dann verwenden Sie zur Installation der Produktivsysteme die Demosystem-Edition eines aktuellen Wartungsreleases. Dieses System enthält keine Java-Sourcen.

In das Produktivsystem werden keine Java-Sourcen (.sr Refreshes) eingespielt, wenn das Framework „Softwareentwicklung“ nicht lizenziert ist.

Feldname	Feldinhalt
Release	Semiramis 4.5
Versionierungsstufe	7 – Produktivsystem
Exportpräfix	<CUS>pt
Entwicklungspräfix	Nicht eingabebereit
Verwendung	Produktiv-Testsystem
Identitätsmodus	Lokal
Identitäts-Serversystem	Nicht eingabebereit
Identitäts-Server	Nicht eingabebereit
Entwicklungsauftrags-Server-Modus	Nicht Verwenden
Entwicklungsauftrags-Server-System	Nicht eingabebereit
Entwicklungsauftrags-Server	Nicht eingabebereit
Entwicklungsauftrags-Serverdatenbank	Nicht eingabebereit

Import-Restriktionen, falls in Adaptierungs-Testsystem SA zusammengefasst werden:

Feldname	Feldinhalt
Versionierungsstufe	6 – Adaptierungssystem
Muster	<CUS>dt-*

Import-Restriktionen, falls in den Adaptierungssystemen keine SA zusammengefasst werden:

Feldname	Feldinhalt
Versionierungsstufe	6 – Adaptierungssystem
Muster	<CUS>dv-*

Import-Restriktionen, falls das System auf einem Partner-Entwicklungssystem basiert und keine SA zusammengefasst werden:

Feldname	Feldinhalt
Versionierungsstufe	3 – Partnerentwicklung oder 4 – Partnerkorrektur
Muster	<PAR>dv-*

Import-Restriktionen, falls das System auf einem Partnerentwicklungs-Testsystem basiert, in dem SA zusammengefasst werden:

Feldname	Feldinhalt
Versionierungsstufe	3 – Partnerentwicklung oder 4 – Partnerkorrektur
Muster	<PAR>dt-*

Import-Restriktionen, falls das System auf dem Standard basiert:

Feldname	Feldinhalt
Versionierungsstufe	1 – Korrektursystem
Muster	babel-*

7.6.2    Produktivsystem

Direkt basierend auf einer Partnerentwicklung muss das Produktivsystem als bereinigte Kopie des Partnerentwicklungs-Testsystems aufgesetzt werden. Es ist nicht möglich ein aktuelleres Wartungsrelease zu verwenden.

Wenn die Entwicklung auf einer Adaptierung basiert, dann muss das Produktivsystem mit dem gleichen System aufgesetzt werden wie das Adaptierungs- und Adaptierungs-Testsystem. Alle SA müssen nachgezogen werden. Alternativ kann auch eine bereinigte Kopie des Adaptierungs-Testsystems verwendet werden.

Wenn die Entwicklung auf dem Standard basiert, dann verwenden Sie die Demosystem-Edition eines aktuellen Wartungsreleases, die keine Sourcen enthält.

In das Produktivsystem werden keine Java-Sourcen (.sr Refreshes) eingespielt.

Feldname	Feldinhalt
Release	Semiramis 4.5
Versionierungsstufe	7
Exportpräfix	<CUS>
Entwicklungspräfix	Nicht eingabebereit
Verwendung	Produktivsystem
Identitätsmodus	Lokal
Identitäts-Serversystem	Nicht eingabebereit
Identitäts-Server	Nicht eingabebereit
Entwicklungsauftrags-Server-Modus	Nicht Verwenden
Entwicklungsauftrags-Server-System	Nicht eingabebereit
Entwicklungsauftrags-Server	Nicht eingabebereit
Entwicklungsauftrags-Serverdatenbank	Nicht eingabebereit

Import-Restriktionen, falls in Produktiv-Testsystem SA zusammengefasst werden:

Feldname	Feldinhalt
Versionierungsstufe	6 – Adaptierungssystem
Muster	<CUS>pt-*

Import-Restriktionen, falls in Adaptierungs-Testsystem SA zusammengefasst werden, im Produktivtestsystem aber nicht:

Feldname	Feldinhalt
Versionierungsstufe	6 – Adaptierungssystem
Muster	<CUS>dt-*

Import-Restriktionen, falls es ein Adaptierungssystem gibt, aber keine SA zusammengefasst werden:

Feldname	Feldinhalt
Versionierungsstufe	6 – Adaptierungssystem
Muster	Cusdv-*

Import-Restriktionen, falls das System auf einem Partner-Entwicklungssystem basiert und keine SA zusammengefasst werden:

Feldname	Feldinhalt
Versionierungsstufe	3 – Partnerentwicklung oder 4 – Partnerkorrektur
Muster	<PAR>dv-*

Import-Restriktionen, falls das System auf einem Partnerentwicklungs-Testystem basiert in dem SA zusammengefasst werden:

Feldname	Feldinhalt
Versionierungsstufe	3 – Partnerentwicklung oder 4 – Partnerkorrektur
Muster	<PAR>dt-*

Import-Restriktionen, falls das Produktivsystem auf dem Standard beruht:

Feldname	Feldinhalt
Versionierungsstufe	1 – Korrektursystem
Muster	babel-*

8              Weitere Transportlandschaften – Beispiele

Auf die Darstellung des einfachsten Falls, dass ein Produktivsystem direkt auf der Standardentwicklung aufbaut, wird verzichtet.

Unsichere minimale Transportlandschaft

In einer minimalen Transportlandschaft werden SA direkt in Partner-Entwicklungs- oder Adaptierungssysteme eingespielt und die resultierenden SA ohne weitere Tests in die Produktivsysteme eingespielt.

In der dargestellten Konstellation muss zumindest das Einspielen der SA in Produktiv-Testsystem und Produktiv-Systemen zu unterschiedlichen Zeitpunkten erfolgen, um einen minimalen Test zu ermöglichen.

Diese Transportlandschaft ist möglich, es wird aber aufgrund mangelnder Möglichkeiten zur Qualitätssicherung dringend von einer solchen Konstellation abgeraten.

Das nachträgliche Einfügen von weiteren Systemen in den Transportweg ist nicht automatisch möglich.

Gemischte Transportlandschaft

In einer gemischten Transportlandschaft wird für einige Systeme die Funktionalität „Softwareaktualisierungen zusammenfassen“ genutzt, bei einfachen Systemen kann aber gegebenenfalls auf diese qualitätssichernde Maßnahme verzichtet werden. Es existieren also sichere und unsichere Transportwege in den Systemfamilien.

Vor dem Produktivsystem muss es immer mindestens ein Testsystem geben.

Eine nachträgliche Änderung des Transportwegs von direkter Versorgung durch ein Entwicklungssystem auf die Versorgung durch ein Testsystem das Softwareaktualisierungen zusammenfasst ist nicht automatisch möglich.

Zwischen einem Entwicklungssystem (Partnerentwicklung, Adaptierung) sollte mindestens ein Testsystem in der Transportlandschaft vorhanden sein.

Das Produktivsystem sollte über die Importrestriktionen so konfiguriert werden, dass es die Softwareaktualisierungen immer aus einem Testsystem erhält, welches Softwareaktualisierungen zusammenfasst.