1 Themenübersicht
Entwicklungsaufgaben dienen zur Bearbeitung von Entwicklungsobjekten. Ein Entwicklungsobjekt, genauer eine Version eines Entwicklungsobjektes, muss einer Entwicklungsaufgabe zugeordnet werden, bevor die Arbeit mit dem Entwicklungsobjekt möglich ist. Die Zuordnung von Entwicklungsobjekten zur Entwicklungsaufgaben erfolgt dabei über die Anwendung „Entwicklungsobjekte“. Einer Entwicklungsaufgabe können mehrere Entwicklungsobjekte gleichzeitig zugeordnet werden. Die Anwendung „Entwicklungsaufgaben“ dient zur Erzeugung und zum Abschließen, dem Aktivieren, einer Entwicklungsaufgabe. Außerdem werden bei der Aktivierung einer Entwicklungsaufgabe alle Entwicklungsobjekte, die der Entwicklungsaufgabe zugeordnet sind, einer Softwarewareaktualisierung zugeordnet.
Für die Erfassung einer Entwicklungsaufgabe ist ein Entwicklungsauftrag notwendig. Die folgende Abbildung stellt den Zusammenhang zwischen Entwicklungsaufträgen, Entwicklungsaufgaben und Entwicklungsobjekte dar.
Entwicklungsauftragsbeziehungen zu Entwicklungsaufgaben und -objekten
Jeder Entwicklungsaufgabe muss ein Entwicklungsauftrag zugeordnet sein. Ein Entwicklungsauftrag kann mehrere Aufgaben umfassen. Das kann eine oder können mehrere inhaltlich zusammengehörige Entwicklungsaufgaben sein. In einer Entwicklungsaufgabe können mehrere Entwicklungsobjekte bearbeitet werden. Normalerweise werden alle Entwicklungsaufgaben, die demselben Entwicklungsauftrag zugeordnet sind, zu einer Softwareaktualisierung zusammengefasst. Dadurch werden die Entwicklungen zu einem Entwicklungsauftrag immer als eine Einheit transportiert.
2 Anwendungsbeschreibung
Mithilfe der Anwendung „Entwicklungsaufgaben“ können Sie Entwicklungsaufgaben für die Bearbeitung der Entwicklungsobjekte des ERP-Systems erfassen. Entwicklungsaufgaben werden zu einem Entwicklungsauftrag erfasst, wenn ein Entwicklungsauftragsdienst aktiviert ist. In diesem Fall wird nach dem Aktivieren einer Entwicklungsaufgabe auch eine Softwareaktualisierung zum Auftrag erzeugt, mit der die geänderten Entwicklungsobjekte zur Installation in anderen Systemen transportiert werden kann.
Die Anwendung besteht aus einem Identifikations- und einem Arbeitsbereich.
2.1 Identifikationsbereich
Die Felder im Identifikationsbereich identifizieren eine Entwicklungsaufgabe eindeutig.
Die Felder im Einzelnen:
| Feld | Erläuterung |
| Entwicklungsaufgabe | Die Entwicklungsaufgabe wird über eine im System eindeutige Nummer identifiziert. Die Nummer kann maximal fünf Stellen lang sein. Die ersten Stellen werden mit Nullen aufgefüllt.
Neue Entwicklungsaufgaben erhalten eine Aufgabennummer vom System. Dafür wird die im System höchste vergebene Aufgabennummer um eins erhöht. Die Nummer darf nicht geändert werden. Solange die Aufgabe nicht das erste Mal gespeichert ist, vergibt das System diese Aufgabennummer auch bei weiteren neuen Entwicklungsaufgaben. Beim Speichern wird geprüft, ob die vergebene Aufgabennummer bereits gespeichert ist. Ist das der Fall, wird automatisch eine neue Aufgabennummer ermittelt und gespeichert. |
| Entwicklungsauftrag | Ist in der Anwendung „Systemcockpit“ ein Entwicklungsauftrags-Server festgelegt, dann wird ein Entwicklungsauftrag zur Erstellung einer Entwicklungsaufgabe benötigt. In diesem Fall wird Folgendes überprüft:
· Ist der Entwicklungsauftrag syntaktisch korrekt. · Ist der Entwicklungsauftrag vorhanden. · Ist der Entwicklungsauftrag im Status „in Bearbeitung“. · Stimmt das im Entwicklungsauftrag angegebene Release mit dem des Entwicklungssystems überein. · Stimmt die Code-Klasse der Entwicklungsaufgabe mit der im Entwicklungsauftrag erfassten Klassifikation überein. Ist kein Entwicklungsauftragsdienst vorhanden, dann wird der Eintrag nicht geprüft. In diesem Fall kann ein freier Text erfasst werden. Entwicklungsaufgaben, die den gleichen Eintrag haben, werden soweit möglich, in einer Softwareaktualisierung zusammengefasst. Der Text darf 20 Zeichen lang sein. |
| Aufgabenstatus | Anzeige des Status, in der sich die Aufgabe befindet:
· Offen: Mit der Aufgabe kann in der Anwendung Entwicklungsobjekte gearbeitet werden. · Freigegeben: Eine Bearbeitung der Entwicklungsobjekte ist nicht mehr möglich. In diesem Status erfolgt die Aktivierung der Business Objects. · Aktiviert: Die Entwicklungsobjekte der Aufgabe sind nicht mehr gesperrt und können wieder bearbeitet werden. Die Entwicklungsobjekte sind einer Softwareaktualisierung zugeordnet. · Aktiviert ohne Softwareaktualisierung: Die Entwicklungsobjekte der Aufgabe sind nicht mehr gesperrt und können wieder bearbeitet werden. Die Entwicklungsobjekte sind keiner Softwareaktualisierung zugeordnet und werden nicht ausgeliefert. In diesem Fall ist bei der Erstellung der Softwareaktualisierung ein Fehler aufgetreten, versuchen Sie erneut zu aktivieren. Wechselt der Status anschließend nicht auf aktiviert, wenden Sie sich an das Supportcenter. · Freigabe mit Warnungen fehlgeschlagen: Bei der Freigabe trat eine Warnung auf. In diesem Zustand kann die Aufgabe erneut geöffnet werden (Nachbearbeitung) oder die Aufgabe wird erneut freigegeben. Dazu sollte die Option „Alle Warnungen bestätigen“ im Verarbeitungsdialog aktiviert werden. · In Freigabewarteschlange: Die Freigabe erfolgte in einem Hintergrundprozess. Die Entwicklungsaufgabe bleibt solange in diesem Status, bis der Hintergrundprozess mit der Freigabe der Entwicklungsaufgabe beginnt. · In Aktivierungswarteschlange: Die Aktivierung erfolgte in einem Hintergrundprozess. Die Entwicklungsaufgabe bleibt so lange in diesem Status, bis der Hintergrundprozess mit der Aktivierung der Entwicklungsaufgabe beginnt. · Wird gerade freigegeben: Die Entwicklungsaufgabe wird gerade in einem Hintergrundprozess freigegeben. · Wird gerade aktiviert: Die Entwicklungsaufgabe wird gerade in einem Hintergrundprozess aktiviert. |
2.2 Arbeitsbereich
Im Arbeitsbereich sind die Informationen zur Entwicklungsaufgabe und insbesondere die mit ihr bearbeiteten Entwicklungsaufgaben aufgeführt. Die jeweiligen Daten sind unter Karteireiter angeordnet, die in folgenden Kapiteln beschrieben sind:
- Karteireiter „Information“
- Karteireiter „Entwicklungsobjekte“
- Karteireiter „Ausgabe Checkin“
2.2.1 Karteireiter „Information“
Unter diesem Karteireiter werden bestimmte Einstellungen zu einer Entwicklungsaufgabe getroffen sowie allgemeine Informationen angezeigt.
Die Felder im Einzelnen:
| Feld | Erläuterung |
| Rubrik „Beschreibung“ | |
| Code-Klasse | Ausschließlich in einem System, in dem System-Code bearbeitet werden kann, können Sie in diesem Feld den Eintrag „System-Code“ festlegen. In allen anderen Systemen können nur Entwicklungsobjekte aus dem Anwendungsbereich bearbeitet werden. Somit wird in den entsprechenden Systemen der Eintrag „Anwendungs-Code“ angezeigt. |
| Aufgabenklasse | Anzeige, in welchem Kontext die Entwicklungsaufgabe entstanden ist:
· Entwicklung: · Fehlerbehebung Dieser Eintrag wird nicht mehr in der Softwarelogistik verwendet, ist jedoch aus Kompatibilitätsgründen weiterhin existent. · Konfliktbearbeitung Dieser Eintrag wird nicht mehr in der Softwarelogistik verwendet, ist jedoch aus Kompatibilitätsgründen weiterhin existent. · Konfliktbearbeitung nachgelagertes System: · Konfliktbearbeitung vorgelagertes System: · Konfliktbearbeitung Releasewechsel: |
| Beschreibung | In diesem Feld können Sie einen Text erfassen, um z. B. die Ziele der Aufgabe oder bestimmte Lösungsvorschläge zu beschreiben. Ist keine Beschreibung angegeben und die Aufgabe wird zum ersten Mal gespeichert, dann wird die Beschreibung und Aufgabenbeschreibung des Entwicklungsauftrages in dieses Feld übertragen, sofern ein Entwicklungsauftrag referenziert wird. Der Text darf maximal 1024 Zeichen lang sein. Ist der Text aus dem Entwicklungsauftrag länger, dann werden nur die ersten 1024 Zeichen übernommen. |
| Aufgabentyp | In diesem Feld legen Sie den Aufgabentyp fest. Entsprechend des gewählten Aufgabentyps können nur bestimmte Entwicklungsobjekte bearbeitet werden. Sind der Entwicklungsaufgabe bereits Entwicklungsobjekte zugeordnet, dann kann der Aufgabentyp nicht mehr geändert werden.
Wählen Sie zwischen folgenden Einträgen: · Entwicklung Alle Entwicklungsobjekte, die mit diesem Aufgabentyp bearbeitet werden, werden mit einer Softwareaktualisierung ausgeliefert. · Test · Redaktion |
| Softwareaktualisierungen erzeugen
(Checkbox) |
Anzeige, ob eine Softwareaktualisierung erzeugt wird. Beim Aufgabentyp „Test“ werden keine Softwareaktualisierungen erzeugt. Bei den anderen Aufgabentypen werden immer Softwareaktualisierungen erzeugt. Um Inkonsistenzen zu vermeiden, müssen verschiedene Versionen des gleichen Entwicklungsobjekts immer mit der gleichen Einstellung bearbeitet werden, auf keinen Fall darf eine Version transportiert werden und eine andere nicht. |
| Softwareaktualisierung | Nach der Aktivierung der Aufgabe wird die Softwareaktualisierung angezeigt, der die Entwicklungsobjekte zugeordnet sind. Die Erzeugung der Softwareaktualisierung ist abhängig vom Entwicklungsauftrag.
Dabei werden folgende Fälle unterschieden: · Ist dem zugehörigem Entwicklungsauftrag keine Softwareaktualisierung zugeordnet, dann wird diese bei der Aktivierung erzeugt. · Ist dem Entwicklungsauftrag bereits eine Softwareaktualisierung zugeordnet und diese ist noch nicht freigegeben, dann werden die Entwicklungsobjekte dieser Softwareaktualisierung zugeordnet. · Ist dem Entwicklungsauftrag eine Softwareaktualisierung zugeordnet und ist diese bereits freigegeben, dann wird eine neue Softwareaktualisierung erzeugt. |
| Rubrik „Status“ | |
| Erstellung | Datum und Zeitpunkt, zu dem die Aufgabe erfasst oder erzeugt wurde. |
| Bearbeiter | Information über den Benutzer, der die Entwicklungsaufgabe erfasst hat oder mit dem sie erzeugt wurde.(mit Erstellungsdatum) |
| Freigabe | Datum und Zeitpunkt, zu dem die Aufgabe freigegeben wurde. |
| Bearbeiter | Information über den Benutzer, der die Entwicklungsaufgabe freigegeben hat oder mit dem sie freigegeben wurde. |
| Aktivierung | Datum und Zeitpunkt, zu dem die Aufgabe aktiviert wurde. |
| Bearbeiter | Information über den Benutzer, der die Entwicklungsaufgabe aktiviert hat oder mit dem sie aktiviert wurde. |
Liste „Bearbeiter“
In der Liste „Bearbeiter“ können Bearbeiter der Aufgabe hinzugefügt oder entfernt werden. Mindestens ein Bearbeiter muss in der Liste aufgeführt sein. Für eine neue Aufgabe wird automatisch der aktuelle Benutzer hinzugefügt. Ein Bearbeiter kann nur aus der Aufgabe entfernt werden, wenn er keine Entwicklungsobjekte mehr in Bearbeitung hat (lokale Sperre). Wenn ein Bearbeiter zu der Aufgabe hinzugefügt wird, dann wird im Arbeitsordner der Aufgabe ein neuer Ordner „usr<Benutzer>“ für den Benutzer erstellt. Der Ordner enthält ein Projekt, um die Entwicklungsaufgabe, z. B. mit „Eclipse“, bearbeiten zu können.
In der Symbolleiste der Liste finden Sie die Buttons „Neu“ und „Löschen“ zum Bearbeiten der Einträge. Die List umfasst nur eine Spalte „Bearbeiter“, in der die Identifikation eines Benutzers aufgeführt ist.
2.2.2 Karteireiter „Entwicklungsobjekte“
Unter diesem Karteireiter werden in einer Liste alle Entwicklungsobjekte aufgeführt, die der Entwicklungsaufgabe hinzugefügt wurden. Für die reduzierte Anzeige der aufgeführten Entwicklungsobjekte stehen Abfragefelder für die Liste zur Verfügung. Damit die gewählten Abfragemerkmale sich auf die Liste auswirken, drücken Sie auf den Aktualisieren-Button in der Symbolleiste der Liste.
Abfragefelder
Die Abfragefelder im Einzelnen:
| Feld | Erläuterung |
| Typ | Wählen Sie die Entwicklungsobjekttypen, die Sie in der Liste anzeigen lassen möchten. |
| Status | Wählen Sie den Status eines Entwicklungsobjektes als Suchmerkmal:
· Neu: · Geändert: · Gelöscht: |
| Namensraum | Mithilfe dieses Abfragefeldes reduzieren Sie die Liste der Entwicklungsobjekte auf jene eines bestimmten Namensraumes. Sie können Platzhalterzeichen und mehrere Namensräume (durch Komma getrennt) erfassen. |
| Name | Mithilfe dieses Abfragefeldes reduzieren Sie die Liste auf bestimmte Entwicklungsobjektnamen. Sie können Platzhalterzeichen und mehrere Entwicklungsobjektnamen (durch Komma getrennt) erfassen. |
| Generiert | Sie können festlegen, ob in der Liste die generierten Entwicklungsobjekte angezeigt werden sollen. |
| Test-Namensraum | Sie können festlegen, ob auch solche Entwicklungsobjekte angezeigt werden sollen, die mit einem Testnamensraum erfasst wurden. |
Liste
In der Liste werden die Entwicklungsobjekte gemäß den erfassten Suchmerkmalen in den Abfragefeldern zur Liste angezeigt.
In der Symbolleiste der Liste finden Sie neben den üblichen Buttons für Listen die folgenden:
- Aktualisieren
Nachdem Sie Suchmerkmale für die Abfragefelder der Liste erfasst haben, drücken Sie auf den Aktualisieren-Button, um die Liste entsprechend zu optimieren.
- Suchen und hinzufügen
Mithilfe dieses Buttons können Sie ein Entwicklungsobjekt suchen und der Aufgabe hinzufügen. Das hinzugefügte Entwicklungsobjekt ist gleichzeitig lokal für den Benutzer gesperrt, der es hinzugefügt hat. Möchten Sie es wieder aus der Aufgabe entfernen, dann wechseln Sie dazu in die Anwendung „Entwicklungsobjekte“ und nutzen den Button „Aus Aufgabe entfernen“.
- Im Folgesystem gesperrt
Mithilfe dieses Buttons lassen Sie in der Liste nur die Entwicklungsobjekte anzeigen, die im Folgesystem gesperrt sind.
- Konflikte anzeigen
Für Entwicklungsaufgaben des Typs „Redaktion“ können Sie mithilfe dieses Buttons in der Liste nur die Entwicklungsobjekte des Typs „Text“ anzeigen, für die ein Konflikt besteht.
Die Spalten der Liste im Einzelnen:
| Spalte | Erläuterung |
| 1. Spaltenüberschriftenzeile | |
| Typ | In dieser Spalte wird Ihnen das zum Entwicklungsobjekttyp gehörende Icon mit Tooltip angezeigt. |
| Namensraum | Namensraum des Entwicklungsobjekts. |
| Bearbeiter | Benutzer, der das Entwicklungsobjekt in der Entwicklungsaufgabe zuletzt bearbeitet hat. |
| Bearbeitungsstatus | Für ein Entwicklungsobjekt können Sie einen Bearbeitungsstatus festlegen. Dies ist bei größeren Aufgaben mit mehreren Bearbeitern nützlich. Folgende Status können angezeigt werden:
· Undefiniert · Zu bearbeiten · Bearbeitet Diese Information ist nach der Aktivierung der Aufgabe nicht mehr vorhanden. |
| Status | Anzeige des aktuellen Status des Entwicklungsobjekts:
· Nicht gesperrt · Sperre durch Benutzer (lokale Sperre) · Sperre durch Aufgabe · Sperre durch Softwareaktualisierung Zusätzlich wird Folgendes angezeigt: · Löschkennzeichen gesetzt · Abgelehnt · Gelöscht Die Anzeige der Sperren bezieht sich auf den Kontext der aktuellen Aufgabe. |
| 2. Spaltenüberschriftenzeile | |
| Name | Name des Entwicklungsobjekts. |
| Version | Version, die in der Entwicklungsaufgabe erzeugt und bearbeitet wurde. |
| Letzte Änderung | Änderungsdatum der angezeigten Version. |
| Herkunft | Insbesondere bei Konfliktaufgaben ist nützlich, die Herkunft des Inhalts der Version zu kennen. In dieser Spalte wird diese Herkunft mit einem Icon angezeigt. Folgende Einträge können angezeigt werden:
· Inhalt stammt aus einem anderen System · Inhalt stammt aus diesem System · Objekt wurde manuell aufgenommen Diese Information ist nach der Aktivierung der Aufgabe nicht mehr vorhanden. |
| Aufgabe im Folgesystem | Falls das Objekt im Folgesystem gesperrt ist, dann wird in dieser Spalte die Entwicklungsaufgabe des Folgesystems angezeigt. |
2.3 Karteireiter „Ausgabe Checkin“
Unter diesem Karteireiter werden Meldungen angezeigt, die beim Checkin und damit verbundenem Kompilieren einer Java-Klasse entstehen. Unabhängig der verwendeten Checkin-Aktion wird unter anderem Folgendes beim Einchecken geprüft bzw. ausgeführt:
- Ermittlung betroffener Klassen
- Kompilierungsfehler
- Kompatibilitätsprüfungen
- Statische Code-Analyse mithilfe von „FindBugs“, wenn diese Funktion aktiv ist
- Ermittlung von Warnungen, die mit „Deprecated“ gekennzeichnet sind
- Ermittlung, ob direkt System-Code referenziert wird
System-Code darf in der Regel nicht referenziert werden. Ausnahmen für generierte Klassen werden berücksichtigt.
- Ermittlung, ob Klassen aus Apps referenziert werden dürfen
- Stabilitätsanalyse: Ermittlung, ob geschützte Klassen bzw. Methoden betroffen sind
- Mitteilung über den Erfolg der Übernahme der Java-Klasse ins Archiv
2.4 Anwendungsbezogene Aktionen
2.4.1 Work-Ordner
Werden dateibasierte Entwicklungsobjekte (Entwicklungsobjekt Bericht, Datei, Java-Klasse, Icon, Hilfe-Objekt) in einer Entwicklungsaufgabe bearbeitet, werden die zugehörigen Dateien im Work-Ordner abgelegt. In diesem Ordner erfolgt die Bearbeitung der Dateien. Der Ordner befindet sich im System-Serverordner und hat folgende Struktur:
work
job<id>
common
classes
help
helpdoc
reports
source
www
usr<Benutzer>
classes
help
helpdoc
reports
source
www
| Ordnerebene | Erläuterung |
| work | Work-Ordner im System-Serverpfad. |
| job<Aufgabennummer> | Ordner der Aufgabe, in dem die Dateien abgelegt werden. |
| common | Im common-Ordner befinden sich alle Dateien der gesperrten Entwicklungsobjekte einer Entwicklungsaufgabe. Die Dateien sind immer schreibgeschützt. Wird ein Entwicklungsobjekt lokal gesperrt, dann werden die zugehörigen Dateien im Ordner des Bearbeiters zur Bearbeitung abgelegt. Im common-Ordner befindet sich immer der letzte Stand des Archivs. Somit ist anderen Bearbeitern der Entwicklungsaufgabe möglich mit diesem Stand weiterzuarbeiten. Ein Vorteil dieser Struktur ist zum Beispiel die einfachere Bearbeitung von Java-Klassen. Dies ist z. B. der Fall, wenn ein Kompilieren des common-Ordners nicht möglich ist. Dadurch kann eine Entwicklungsaufgabe in kleinen Schritten überarbeitet werden. Um die Bearbeitung von Java-Klassen zu vereinfachen, ist ein Projekt im „common“-Ordner abgelegt, das z. B. in „Eclipse“ importiert werden kann. Dieses Projekt bindet alle Java-Sourcen und -Klassen aus dem Ordner „common/source“ bzw. „common/classes“ ein. Wird die lokale Sperre wieder aufgehoben (Speichern und Freigeben, Checkin), dann wird der common-Ordner aktualisiert und die Dateien werden aus dem Ordner des Bearbeiters entfernt. |
| usr<Benutzer> | Ordner des Benutzers. In diesem Ordner befinden sich nur die Dateien der Entwicklungsobjekte, die durch den Benutzer lokal gesperrt sind. Wird die lokale Sperre aufgehoben (Speichern und Freigeben, checkin), wird der common-Ordner aktualisiert und die Dateien im Ordner des Benutzers gelöscht. Um die Bearbeitung von Java-Klassen zu vereinfachen, ist ein Projekt im „usr<Benutzer>“-Ordner abgelegt, das z. B. in „Eclipse“ importiert werden kann. Dieses Projekt ist von dem Projekt im „common“-Ordner abhängig. Hierdurch wird erreicht, dass die Versionen der Java-Sourcen im „usr<Benutzer>“-Ordner beim Kompilieren die Java-Sourcen im „common“-Ordner überdecken. |
| source | In diesem Ordner werden alle Java-Source-Dateien abgelegt. |
| classes | In diesem Ordner werden alle Java-Class-Dateien abgelegt. |
| help | In diesem Ordner werden alle Ziel-Dateien der Hilfe-Objekte abgelegt. |
| helpdoc | In diesem Ordner werden alle Quell-Dateien der Hilfe-Objekte abgelegt. |
| reports | In diesem Ordner werden alle Berichts-Dateien abgelegt. |
| www | In diesem Ordner werden alle Icons abgelegt. |
| com\cisag\… | Der Pfad entspricht dem Namensraum des Entwicklungsobjekts. Datei-Objekte werden direkt im „usr“-Ordner mit dem im Entwicklungsobjekt erfassten Pfad abgelegt. |
| Dateityp | Die Datei, die aus dem Archiv im Dateisystem abgelegt wurde. |
2.4.2 Aktionen zum Kompilieren und Einchecken von Java-Klassen
Für das Kompilieren und Einchecken von Java-Klassen beachten Sie bitte die Informationen zur Stabilitätsprüfung und die verschiedenen Aktionen, die in folgenden Kapiteln beschrieben sind:
- Stabilitätsprüfung beim Einchecken von Java-Klassen
- Java-Klassen kompilieren und einchecken
- Java-Klassen kompilieren und einchecken (Ergebnis der Kompatibilitätsprüfung ignorieren)
- Java-Klassen kompilieren und einchecken (Kompatibilitätsprüfung nicht ausführen)
2.4.2.1 Stabilitätsprüfung beim Einchecken von Java-Klassen
In Java-Klassen können „Provider“- und „Client“-Schnittstellen deklariert werden. Dies geschieht per @Stable-Annotation. Wird die Annotation auf Klassenebene gesetzt, dann ist eine Provider-Schnittstelle deklariert. Wird ein Konstruktor, eine Methode oder auch ein Attribut so ausgezeichnet, dann ist eine Client-Schnittstelle deklariert.
Eine Client-Schnittstelle stellt eine Methode zum Aufruf durch Verwender bereit. Eine Provider-Schnittstelle ermöglicht dem Verwender, Methodenparameter selbst zu spezifizieren.
Beispiel:
Java.utils.Collections.sort(List list, Comparator c);
In diesem Beispiel ist die Methode „sort“ der Klasse „Collections“ eine Client-Schnittstelle. Ein Verwender/Client kann diese Methode aufrufen. Der Comparator ist in diesem Beispiel eine Provider-Schnittstelle. Eine verwendende Klasse liefert in diesem Fall, wie die Elemente der „List“ verglichen werden sollen.
Client-Schnittstelle
Eine Client-Schnittstelle darf nicht entfernt werden. Würde man eine Client-Schnittstelle entfernen, dann wären alle verwendenden Klassen ungültig und die Folge wäre beim Versuch des Aufrufs diese Ausnahme:
NoSuchMethodException
In einer Java-Klasse darf also eine Methode zusätzlich als Client-Schnittstelle deklariert werden, aber eine existierende Client-Schnittstelle darf nicht entfernt oder verändert werden.
Eine entsprechende Prüfung wird beim Einchecken der Java-Klassen vorgenommen.
Provider-Schnittstelle
Eine Provider-Schnittstelle darf nicht erweitert werden. Eine neue Methode an der Schnittstelle würde bedeuten, dass Klassen, die diese Schnittstelle bereits implementieren, ungültig würden, da so eine Klasse natürlich diese neue Methode nicht kennt und damit nicht implementiert.
Eine entsprechende Prüfung wird beim Einchecken der Java-Klassen vorgenommen.
2.4.2.2 Java-Klassen kompilieren und einchecken
Die Java-Klassen, die in der Entwicklungsaufgabe gesperrt sind, werden in Bezug zum System-Klassenstand kompiliert. Anschließend erfolgt die Kompatibilitätsprüfung. Geprüft wird, ob eine inkompatible Änderung zur Vorgängerversion durchgeführt wurde (z. B. eine Änderung der Signatur oder einer public-Methode). Danach wird der Inhalt der Java-Quelle und der Java-Klasse in die Archive geschrieben. Die lokalen Sperren der Java-Klassen werden aufgehoben.
Diese Aktion darf nur in einer Laufzeitumgebung ohne lokale Klassen ausgeführt werden.
In der Anwendung „Customizing“ besteht die Möglichkeit, die Kompatibilitätsprüfung einzuschränken (Funktion „Software-Entwicklung“, Kompatibilitätsprüfung einschränken). Wird diese Funktion aktiviert, dann werden die Java-Klassen, die in dem aktuellen System erfasst wurden, bei der Kompatibilitätsprüfung ignoriert.
Die Java-Sourcen werden abhängig von den Festlegungen in der Anwendung „Customizing“ beim Einchecken mit einem Source-Code-Formatierer formatiert. Damit wird garantiert, dass alle Java-Sourcen nach den gleichen Regeln formatiert werden. Weitere Informationen zum Einbinden eines Source-Code-Formatierers finden Sie in dieser Dokumentation: Entwicklungssystem einrichten
2.4.2.3 Java-Klassen kompilieren und einchecken (Ergebnis der Kompatibilitätsprüfung ignorieren)
Diese Aktion entspricht der Aktion „Java-Klassen kompilieren und einchecken“ (siehe dieses Kapitel: Java-Klassen kompilieren und einchecken) mit der Änderung, dass lediglich die Ergebnisse der Kompatibilitätsprüfung ignoriert werden.
2.4.2.4 Java-Klassen kompilieren und einchecken (Kompatibilitätsprüfung nicht ausführen)
Diese Aktion entspricht der Aktion „Java-Klassen kompilieren und einchecken“ (siehe dieses Kapitel: Java-Klassen kompilieren und einchecken) mit der Änderung, dass die Kompatibilitätsprüfung nicht ausgeführt wird.
2.4.3 Entwicklungsobjekte speichern
Alle in der Entwicklungsaufgabe enthaltenen und durch den Benutzer lokal gesperrten Entwicklungsobjekte werden gespeichert. Somit werden für die gewählte Entwicklungsaufgabe alle lokalen Sperren des Benutzers aufgehoben, der die Aktion ausführt.
2.4.4 Aufgabe freigeben
Die Freigabe einer Aufgabe verhindert, dass weitere Entwicklungsobjekte zu der Aufgabe hinzugefügt werden können. Die bereits enthaltenen Entwicklungsobjekte können nicht mehr bearbeitet werden, weder in dieser Entwicklungsaufgabe noch in einer anderen, bis die Entwicklungsaufgabe aktiviert wurde.
Vor der Freigabe werden alle Entwicklungsobjekte der Entwicklungsaufgabe erneut geprüft. Kein Entwicklungsobjekt in der Aufgabe darf lokal gesperrt sein. Warnungen können bestätigt oder ihnen nachgegangen und die Objekte entsprechend nachbearbeitet werden. Bei Fehlermeldungen muss das betroffene Entwicklungsobjekt nochmals bearbeitet und korrigiert werden. Erst dann ist eine Freigabe der Aufgabe möglich. Einige Entwicklungsobjekte müssen besondere Voraussetzungen erfüllen, bevor die Entwicklungsaufgabe freigegeben werden kann:
| Entwicklungsobjekt | Status |
| Business Object, Extension | Die Konvertierung muss erfolgreich durchgeführt sein.
Weitere Informationen finden Sie in dieser Dokumentation: Datenbankänderungen |
| Part, OQL-View | Die Generierung muss erfolgreich durchgeführt sein.
Weitere Informationen finden Sie in dieser Dokumentation: Datenbankänderungen |
| Text | Wurde ein übersetzbarer Text gelöscht, dann werden alle zugehörigen Übersetzungen gelöscht. Durch eine Warnung wird darauf aufmerksam gemacht. |
Für die Freigabe wird ein Dialogfenster geöffnet, in dem Sie entscheiden können, ob die Freigabe im Hintergrund oder sofort erfolgen soll. Die Hintergrundverarbeitung sollte vor allem bei größeren Entwicklungsaufgaben verwendet werden. Tritt bei der Freigabe eine Warnung auf, dann wechselt der Status der Entwicklungsaufgabe auf „Freigabe mit Warnungen fehlgeschlagen“. In diesem Status ist nicht mehr möglich, Entwicklungsobjekte zu bearbeiten. Sie können die Entwicklungsaufgabe wieder öffnen, um eventuelle Nacharbeiten durchzuführen. Wenn die Entwicklungsaufgabe trotz der Warnungen freigegeben werden soll, dann können Sie die Entwicklungsaufgabe erneut freigeben. Im sich dazu öffnenden Dialogfenster aktivieren Sie die Funktion „Warnungen automatisch bestätigen“ und führen die Aktion aus.
Für die Hintergrundverarbeitung muss in der Anwendung „Customizing“ unter der Funktion „Software-Entwicklung“ eine Verarbeitungs-Warteschlange für die Freigabe festgelegt werden. Diese Verarbeitungs-Warteschlange sollte ausschließlich für die Freigabe verwendet werden. Nachdem die Entwicklungsaufgabe freigeben wurde, kann sie aktiviert werden.
Hinweis:
Wenn eine Aufgabe nicht freigegeben werden konnte, weil Warnungen entstanden sind, dann kann eventuell beim erneuten Freigeben die Fehlermeldung „Verarbeitungsauftrag kann nicht gelöscht werden“ auftreten. Diese Meldung tritt auf, weil der erste Verarbeitungsauftrag, der aufgrund der Warnungen abgebrochen wurde, nicht gelöscht werden konnte und der neue Verarbeitungsauftrag den gleichen generierten Namen erhält.
Obwohl die Fehlermeldung erscheint, wird der Verarbeitungsauftrag dennoch abgearbeitet und die Aufgabe freigegeben.
2.4.5 Aufgabe aktivieren
Die Aktivierung erfolgt nach der Freigabe der Entwicklungsaufgabe. In einem System kann zu einem Zeitpunkt immer nur eine Aufgabe aktiviert werden. Wird bereits eine Aufgabe aktiviert, kann die Aktivierung erst durchgeführt werden, wenn die laufende Aktivierung abgeschlossen ist.
Da eine Aktivierung durchaus sehr lange andauern kann, ist auch möglich, eine Aktivierung im Hintergrund abarbeiten zu lassen. Alle anstehenden Aktivierungen werden nacheinander abgearbeitet. Für die Hintergrundverarbeitung muss in der Anwendung „Customizing“, Funktion „Software-Entwicklung“ eine Verarbeitungs-Warteschlange für die Aktivierung festgelegt sein. Diese Verarbeitungs-Warteschlange sollte ausschließlich für die Aktivierung verwendet werden. Da immer nur eine Aktivierung im System erfolgen kann, benötigt diese Verarbeitungs-Warteschlange nur einen Thread.
Beim Aktivieren der Entwicklungsaufgabe wird Folgendes ausgeführt:
- Alle globalen Sperren werden aufgehoben.
- Die durch die Entwicklungsaufgabe gesperrte Version eines Entwicklungsobjekts wird die aktive Version.
- Die Versionen der Entwicklungsobjekte werden der Softwareaktualisierung zugeordnet.
- Die bestehenden Java-Klassen, Java-Quellen, Icons, Datei-Objekte und die Hilfe-Ziel-Dateien werden im „semiramis“-Ordner durch die aktiven Versionen ersetzt. Dazu benötigt der Application-Server, auf dem die Aktivierung erfolgt, Schreibrechte für den „semiramis“-Ordner.
2.4.6 Aufgabe wieder öffnen
Ist die Entwicklungsaufgabe mit dem Status „Freigabe mit Warnungen fehlgeschlagen“ gekennzeichnet, dann kann die Entwicklungsaufgabe zur Bearbeitung mithilfe dieser Aktion wieder geöffnet werden.
2.4.7 Entwicklungsobjekte der Entwicklungsaufgabe exportieren
Mit dieser Aktion können alle Entwicklungsobjekte exportiert werden, die in der aktuellen Entwicklungsaufgabe gesperrt sind. Der Export ist nur möglich, wenn die Entwicklungsaufgabe offen oder aktiviert ist.
Sie können beim Export zwischen folgenden Exportarten wählen:
- Die Entwicklungsobjekte werden in eine Datei exportiert.
- Pro Entwicklungsobjekt wird eine Datei exportiert.
- Pro Entwicklungsobjekt wird eine Datei exportiert. Zusätzlich werden Versionen in separaten Ordnern zum Vergleich abgelegt. Die Java-Sourcen werden abhängig von den Einstellungen in der Anwendung „Customizing“ beim Export mit einem Source-Code-Formatierer formatiert. Damit wird garantiert, dass alle Java-Sourcen für den Vergleich nach den gleichen Regeln formatiert werden. Weitere Informationen zum Einbinden eines Source-Code-Formatierers finden Sie in dieser Dokumentation: Entwicklungssystem einrichten
Weitere Informationen zum Export aus der Anwendung „Entwicklungsaufgaben“ heraus finden Sie in dieser Dokumentation: Entwicklungsobjekte exportieren und importieren
2.4.8 Entwicklungsobjekte aus einer Datei importieren
Mit dieser Aktion können Entwicklungsobjekte wieder importieren, die zuvor exportiert wurden.
Weitere Informationen zum Export aus der Anwendung „Entwicklungsaufgaben“ heraus finden Sie in dieser Dokumentation: Entwicklungsobjekte exportieren und importieren