1 Themenübersicht
Die Anwendung „Entwicklungsobjekte“ dient der Erfassung und Ansicht von Entwicklungsobjekten verschiedenster Typen. Sie bietet eine Aufgabenverwaltung zur Zugriffskontrolle durch einen zweistufigen Sperrmechanismus sowie eine Versionsverwaltung.
Dieses Dokument beschreibt die Anwendung mit den für alle Entwicklungsobjekte gültigen Elementen sowie das Verhalten der Anwendung. Pro Entwicklungsobjekt finden Sie eine eigene Dokumentation.
2 Begriffsbestimmung
Archiv- und System-Business-Objects
Die zur Verwaltung der Entwicklungsobjekte benutzten Business Objects werden in zwei Gruppen unterteilt:
- Die Archiv-Business-Objects speichern die versionisierten Daten. In diesen Business Objects werden archivierte Versionen, aktive und aktuelle Version gespeichert. Die Inhalte dieser Business Objects werden in der Anwendung „Entwicklungsobjekte“ angezeigt (je nach ausgewählter Version) und bearbeitet.
- Die System-Business-Objects sind in der Regel identisch zu den Archiv-Business-Objects, bis auf die Versionierung. Über diese Business Objects greift das System im Betrieb auf die Metadaten zu (z. B. Anzeige der Data-Description, Anzeige von Icons). Die aktive oder die aktuelle Version wird während der Bearbeitung aus dem Archiv in die System-Business-Objects geschrieben. Welche Version zu welchem Zeitpunkt in den Systemtabellen steht, ist im Programmablauf beschrieben.
Entwicklungsnamensraum
Jedem Entwicklungssystem ist genau ein Namensraum (Entwicklungsnamensraum) mit Unternamensräumen zugeteilt. In diesem Namensraum wird in diesem System entwickelt. Neue Entwicklungsobjekte können nur in diesem Namensraum angelegt werden. Änderungen an Entwicklungsobjekten in anderen Namensräumen sind nur eingeschränkt möglich.
Diese Entwicklungsnamensräume befinden sich im Namensraum com, der die Wurzel aller Namensräume bildet. Im Namensraum com befinden sich keine anderen Namensräume.
Baumstruktur in den Namensräumen, die durch ein Entwicklungspräfix entstehen.
Beispiel:
com.cisag
Entwicklungsnamensraum der Standardentwicklung
com.<Partnerkürzel>
Entwicklung für eine Branchenlösung oder ein App-Entwicklungssystem
com.<Kundenkürzel>
Entwicklung für einen Kunden
Die Kürzel müssen über alle System eindeutig sein. Sie werden daher zentral vergeben.
Entwicklungsobjekt
Ein Entwicklungsobjekt ist ein in Comarch ERP Enterprise definiertes Objekt, mit welchem Anwendungsentwickler andere Objekte entwickeln. Alle Entwicklungsobjekte werden in der Repository-Datenbank archiviert. Sie können mit der Anwendung „Entwicklungsobjekte” angelegt, geändert und gelöscht werden.
Entwicklungsobjektname
Namen von Entwicklungsobjekten beginnen, außer bei Icons, mit einem Großbuchstaben. Bei Icons beginnt der Name mit einem kleinen Buchstaben. Danach sind beliebige Buchstaben und arabische Ziffern erlaubt.
Hinweis:
Buchstaben beziehen sich immer auf das englische Alphabet (d. h. keine Sonderzeichen).
Original-Repository
Jedes Entwicklungsobjekt wird gekennzeichnet, ob es original im aktuellen Repository erfasst oder durch eine Softwareaktualisierung in dieses System eingespielt wurde.
Sperrstatus
Wenn ein Entwicklungsobjekt in einer Entwicklungsaufgabe bearbeitet wird, dann ist das Entwicklungsobjekt gesperrt. Dabei wird unterscheiden:
- Globale Sperre
Bei der globalen Sperre handelt es sich um eine Aufgabensperre. Ein Entwicklungsobjekt ist einer offenen oder freigegebenen Aufgabe zugeordnet. Dadurch kann es keiner anderen Aufgabe zugeordnet werden. Diese Sperre kann nicht explizit gesetzt werden. Ein global gesperrtes Entwicklungsobjekt kann nicht von einem Benutzer bearbeitet werden, bevor eine lokale Sperre gesetzt wurde.
- Lokale Sperre
Bei der lokalen Sperre handelt es sich um eine Benutzersperre. Diese Sperre wird gesetzt, wenn ein Entwicklungsobjekt von einem Benutzer bearbeitet wird. Die lokale Sperre schließt die globale Sperre automatisch mit ein.
Sprachen
Comarch ERP Enterprise verfügt über mehrere Möglichkeiten, Sprachen und sprachabängige Daten zu verwenden. Je Datenbank werden eine Primärsprache und eventuelle Nebensprachen festgelegt, die bestimmen, in welchen Sprachen lokalisierbare Attribute bearbeitet werden können. Mit welcher davon der Benutzer arbeitet, wird in den Benutzereinstellungen festgelegt. In der Anwendung „Sprachen” können darüber hinaus die Sprachen erfasst werden, die als Korrespondenzsprachen zur Verfügung stehen sollen.
In der Anwendung „Entwicklungsobjekte“ wird zwischen zwei Sprachen unterschieden:
- Anzeigesprache
Das ist die Sprache, in der die Oberflächentexte angezeigt werden. Analog den anderen Anwendungen.
- Entwicklungssprache
Alle übersetzbaren Texte in den Entwicklungsobjekten werden in der angegebenen Entwicklungssprache erfasst. Gibt es zu einem übersetzbaren Text keinen Text in der angegebenen Entwicklungssprache, wird kein Text angezeigt.
Die Entwicklungssprache am rechten oberen Rand es Icons des Entwicklungsobjekttyps dargestellt.
Hinweis:
Die Entwicklungssprache sollte bei der Bearbeitung von Entwicklungsobjekten nicht umgeschaltet werden, da dies dazu führen kann, dass Texte in der falschen Sprache gespeichert werden.
Versionierung
Zu einem Entwicklungsobjekt können mehrere Versionen gespeichert werden. Diese Versionierung dient der Archivierung von Änderungen an Entwicklungsobjekten und zur Erkennung von Änderungen durch Partner. Die Konflikterkennung beim Einspielen von Supportauslieferungen erfolgt über die Versionierung.
Bei einer Neuanlage eines Entwicklungsobjektes wird die erste Version erzeugt. Erst bei Aktivierung der Entwicklungsaufgabe wird diese Version aktiv. Wenn ein existierendes Entwicklungsobjekt in Bearbeitung genommen wird, also zu einer Entwicklungsaufgabe hinzugefügt, dann wird eine neue Version erzeugt. Die Versionsnummer erhöht sich um eins.
- Aktive Version
Die zuletzt aktivierte Version. Wenn das Entwicklungsobjekt nicht bearbeitet wird, dann wird diese Version im laufenden Betrieb benutzt. Diese Version ist nicht änderbar.
- Aktuelle Version
Ist das Entwicklungsobjekt nicht in Bearbeitung, entspricht die aktuelle Version der aktiven Version. Die Bearbeitung erfolgt in der aktuellen Version, die in der Entwicklungsaufgabe gesperrt ist. Das System greift aber in der Regel schon auf die aktuelle Version zu (siehe System– und Archivtabellen). Nach dem Bearbeiten wird die aktuelle Version zur aktiven Version. Wenn die aktuelle Version gelöscht wird (aus der Entwicklungsaufgabe entfernt), dann wird die aktive Version zurück in die Systemtabellen kopiert. In Produktivsystemen ist die aktuelle Version immer gleich der aktiven Version.
- Archivierte Version
Alle anderen Versionen. Diese Versionen können nur gelesen werden, sie sind nicht veränderbar.
Die Versionsnummer besteht aus sechs Teilen. In Abhängigkeit vom eingestellten Typ (Versionisierungsstufe) des Systems wird der entsprechende Teil der Versionsnummer erhöht. Bei der Schreibweise der Versionsnummer werden rechtsseitige Nullen weggelassen.
Folgende Typen von Systemen sind definiert:
Stufe | Typ | Erläuterung | Versionsnummer |
1 | Standardentwicklungssystem | Standardentwicklung des nächsten Releases. | x.0 |
2 | App-Entwicklungssystem | App Entwicklungssystem haben die Versionierungsstufe 2. Alle Versionsnummer bekommen in der ersten Stelle eines festen Wert n, dieser wird im Systemcockpit vorgeben. | n.x |
3 | Branchenentwicklungssystem | Nicht kundenspezifische Erweiterung eines ausgelieferten Standardsystems durch den Partner. | 0.0.x |
4 | reserviert | 0.0.0.x | |
5 | Zur freien Verfügung | 0.0.0.0.x | |
6 | Kundenentwicklungssystem | Adaptierung eines ausgelieferten Standardsystems oder eines Branchensystems für einen konkreten Anwendungsfall | 0.0.0.0.0.x |
7 | Produktivsystem,
Testsystem, QAS |
System für die Produktion und zur Qualitätssicherung inkl. Test neuer Entwicklungen, Korrekturen und Übersetzungen |
Keine Entwicklung in diesen Systemen |
Vollständiger Name eines Entwicklungsobjekts
Der vollständige Name wird durch Aneinanderreihung der Namen der übergeordneten Namensräume und dem Namen des Entwicklungsobjekts gebildet. Die einzelnen Bestandteile werden durch einen Punkt getrennt. Das geschieht analog zu Java-Klassen und Packages.
Innerhalb eines Entwicklungsobjekttyps ist der vollständige Name eindeutig. Namen, die sich nur in Groß- und Kleinschreibung unterscheiden, sind nicht erlaubt.
XML-Entwicklungsobjekt
Ein Entwicklungsobjekt, das mithilfe der Auszeichnungssprache XML definiert ist. Die Erfassung erfolgt in einer XML-Datei mit einem separaten Programm, das kein Bestandteil des ERP-Systems ist. Eine solche XML-Datei besteht aus einem Kopf, wo die allgemeinen Informationen angegeben sind (Z.B. XML-Kodierung, Name des XML-Schema etc.) und den hierarchisch aufgebauten Elementen, die das XML-Entwicklungsobjekt beschreiben. Die XML-Entwicklungsobjekt-Typen sind:
- Hook Contract
- Business-Object-Registry
- Objektsicht
- Objektsicht-Erweiterung
3 Versionierung
Die Version eines Entwicklungsobjekts spiegelt die Hierarchie der Entwicklungslandschaft wieder. Sie setzt sich aus 6 Zahlen zusammen, die durch Punkte getrennt sind. Aus der Position der Nummer lässt sich die Ebene in der Hierarchie und damit auch das System bestimmen.
Zusätzlich wird noch der Name des Systems, in dem die Version entstanden ist an die Versionsnummer angefügt (durch ein Doppelpunkt getrennt). Dadurch ist eine Unterscheidung gleicher Versionsnummern möglich. Dies ist bei Softwarequertransporten auf gleicher Versionierungsstufe notwendig.
Wenn ein Entwicklungsobjekt verändert wird, dann wird eine neue Version dieses Entwicklungsobjekts erzeugt. Dabei wird abhängig von der Versionierungsstufe des Systems, d. h. von der Position des Systems innerhalb der Hierarchie die entsprechende Nummer der Version erhöht.
Beispiele:
Bei Neuanlagen von Entwicklungsobjekten im Standardentwicklungssystem wird die Version 1.0:4.4.0 erstellt, im Korrektursystem wird die Version 0.1: 4.4.0 angelegt. Das gilt auch, wenn der Partner ein Entwicklungsobjekt im eigenen Namensraum anlegt: 0.0.0.0.0.1:4.4.0 (hier: Kundenadaptierung).
Bei einer Änderung des Entwicklungsobjektes im selben System wird die Version hochgezählt: aus 2.0:4.4.0 wird die Version 3.0:4.4.0.
Wenn ein Entwicklungsobjekt aus einem vorgelagerten System geändert wird, dann entsteht ein Branch. Wird die Version 3.0:4.4.0 der Standardentwicklung im Branchenentwicklungssystem verändert, so wird ein Branch angelegt, in dem die 3. Stelle um eins erhöht wird. Daraus ergibt sich der Branch 3.0.1:4.4.0. Bei einer Änderung dieser neuen Version im Kundenadaptierungssystem wird der Sub-Branch 3.0.1.0.0.1:4.4.0 anlegt. Generell sprechen wir von Hauptversion, wenn nur eine der Zahlen ungleich 0 ist, ansonsten sprechen wir von Branch.
Hinweis:
In Comarch ERP Enterprise wird immer mit einer Version eines Entwicklungsobjektes gearbeitet. Wenn davon gesprochen wird, dass ein Entwicklungsobjekt bearbeitet oder transportiert wird, müsste eigentlich von der Version eines Entwicklungsobjekts gesprochen werden. Im Allgemeinen wird zur Vereinfachung nur vom Entwicklungsobjekt gesprochen.
4 Anwendungsbeschreibung
Die Anwendung besteht aus einem Identifikations- und einem Arbeitsbereich.
4.1 Identifikationsbereich
Die Felder im Identifikationsbereich identifizieren eine Version eines Entwicklungsobjekts eindeutig.
Die Felder im Einzelnen:
Feld | Erläuterung |
Typ | Im Feld „Typ“ erfolgt die Auswahl des Entwicklungsobjekttyps. Nach der Auswahl des Typs wird automatisch der zugehörige Editor im Arbeitsbereich geöffnet.
Zwischen folgenden Entwicklungsobjekten kann ausgewählt werden: · Action · Aktivitätsdefinitions-Vorlage · Anwendung · Anwendungserweiterung · Berechtigungsrollen-Vorlage · Bericht · Business-Entity-Gruppe · Business Object · Business-Object-Registry · Data-Description-Column · Data-Description-LDT · Datei · Ereignis · Extension · Fähigkeit · Framework · Funktion · Hilfe-Objekt · Hook Contract · Icon · Java-Klasse · Lizenzschlüssel · Logischer Datentyp (LDT) · Logischer Datentyp, Erweiterung · Meldung · Meldungsklasse · Namensraum · Objektsicht · Objektsicht-Erweiterung · OQL-Suche · OQL-View · Part · Prozessdefinitions-Vorlage · Skript · Stringtable · Suche · Sucherweiterung · Terminus · Testlauf · Text · Valueset · Workflowrollen-Vorlage |
Version | Dieses Feld zeigt die Versionsnummer der geöffneten Version an. Ist kein Entwicklungsobjekt geöffnet, dann ist die Anzeige leer. Die Wertehilfe zeigt alle Versionen zu einem Entwicklungsobjekt an. Über die Auswahl wird eine bestimmte Version aus dem Archiv geöffnet. |
Name | In diesem Feld wird der vollständige Entwicklungsobjektname angegeben.
Dieser Entwicklungsobjektname ist zusammengesetzt aus dem vollständigen Namen des Namensraumes und dem Namen des Entwicklungsobjektes. Der vollständige Name ist auf 200 Zeichen beschränkt. Namensraum und Entwicklungsobjektname werden durch einen Punkt getrennt. Die Syntax lautet: <Namensraum>.<Entwicklungsobjektname>. Beispiel: com.cisag.app.Name Die benutzte Wertehilfe ist vom ausgewählten Entwicklungsobjekt abhängig. |
Die Buttons im Identifikationsbereich haben folgende Funktionen:
Funktion | Erläuterung |
Aktive Version zeigen | Über diesen Button wechseln Sie zwischen aktueller (lokale oder globale Sperre durch eine Entwicklungsaufgabe) und aktiver Version eines Entwicklungsobjekts.
Ist eine ältere Version geöffnet, wird die aktuelle Version geöffnet, wenn das Entwicklungsobjekt gesperrt ist, andernfalls die aktive Version. |
Bearbeitungsstatus ändern | Mit diesem Button ändern Sie den Bearbeitungsstatus des Entwicklungsobjekts. Der Bearbeitungsstatus hat keine technischen Auswirkungen. Entwickler können damit markieren, welche Objekte sie schon bearbeitet haben. Dies ist beispielsweise hilfreich bei der Bearbeitung von Entwicklungsaufgaben durch mehrere Bearbeiter. |
Zugehöriges Textobjekt öffnen | Dieser Button öffnet das zugehörige Textobjekt.
Die Zuordnung zwischen einem Entwicklungsobjekt und einem Textobjekt wird in der Dokumentation „Entwicklungsobjekt: Text“ erläutert. |
4.2 Arbeitsbereich
Der Arbeitsbereich besteht aus mehreren Karteireitern. Abhängig vom aktuellen Entwicklungsobjekttyp stehen verschiedene Karteireiter zur Verfügung.
4.2.1 Karteireiter „Editor“
Unter dem Karteireiter „Editor“ erfolgt die eigentliche Erfassung der Metadaten zu einem Entwicklungsobjekt. Der Aufbau des Editors unterscheidet sich im Allgemeinen je nach Entwicklungsobjekttyp und ist in vielen Fällen in mehrere Karteireiter unterteilt. Diese Karteireiter sind am unteren Bildschirmrand angeordnet. Der Aufbau des Editors ist für alle XML-Entwicklungsobjekttypen identisch und die Erfassung der Metadaten erfolgt in einer XML-Datei mithilfe eines separaten Programms, das nicht der Bestandteil von einem Comarch-ERP-Enterprise-System ist. Der Aufbau des Editors je nach Entwicklungsobjekttyp wird in weiteren Dokumenten beschrieben. Die identischen Felder des Editors für einen XML-Entwicklungsobjekttyp werden in diesem Kapitel beschrieben:
Feld | Erläuterung |
Beschreibung | Beschreibung des XML-Entwicklungsobjekttyps: Wofür wird das Entwicklungsobjekt benutzt. |
Größe in Bytes | Anzeige der Dateigröße in Bytes. |
Sie finden die Beschreibungen pro Entwicklungsobjekttyp in folgenden Dokumentationen:
- Entwicklungsobjekt: Action
- Entwicklungsobjekt: Aktivitätsdefinitions-Vorlage
- Entwicklungsobjekt: Anwendung
- Entwicklungsobjekt: Anwendungserweiterung
- Entwicklungsobjekt: App
- Entwicklungsobjekt: Berechtigungsrollen-Vorlage
- Entwicklungsobjekt: Bericht
- Entwicklungsobjekt: Business-Entity-Gruppe
- Entwicklungsobjekt: Business Object
- Entwicklungsobjekt: Business-Object-Registry
- Entwicklungsobjekt: Data-Description
- Entwicklungsobjekt: Datei
- Entwicklungsobjekt: Ereignis
- Entwicklungsobjekt: Extension
- Entwicklungsobjekt: Fähigkeit
- Entwicklungsobjekt: Framework
- Entwicklungsobjekt: Funktion
- Entwicklungsobjekt: Hilfe-Objekt
- Entwicklungsobjekt: Hook Contract
- Entwicklungsobjekt: Icon
- Entwicklungsobjekt: Java-Klasse
- Entwicklungsobjekt: Lizenzschlüssel
- Entwicklungsobjekt: Logischer Datentyp
- Entwicklungsobjekt: Logischer Datentyp, Erweiterung
- Entwicklungsobjekt: Meldung
- Entwicklungsobjekt: Meldungsklasse
- Entwicklungsobjekt: Namensraum
- Entwicklungsobjekt: Objektsicht
- Entwicklungsobjekt: Objektsicht-Erweiterung
- Entwicklungsobjekt: OQL-Suche
- Entwicklungsobjekt: OQL-View
- Entwicklungsobjekt: Part
- Entwicklungsobjekt: Prozessdefinitions-Vorlage
- Entwicklungsobjekt: Stringtable
- Entwicklungsobjekt: Suche
- Entwicklungsobjekt: Terminus
- Entwicklungsobjekt: Testlauf
- Entwicklungsobjekt: Text
- Entwicklungsobjekt: Valueset
- Entwicklungsobjekt: View
- Entwicklungsobjekt: Workflowrollen-Vorlage
4.2.2 Karteireiter „Information“
Dieser Karteireiter steht für alle Entwicklungsobjekte zur Verfügung und liefert aktuelle Statusinformationen zu einem Entwicklungsobjekt. Die Felder sind Anzeigefelder und nicht editierbar.
Rubrik „Verlauf“
Die Felder im Einzelnen:
Feld | Erläuterung |
Erfasst von | Information, welcher Benutzer das Entwicklungsobjekt erstellt hat (mit Erstellungsdatum). |
Geändert von | Information, welcher Benutzer das Entwicklungsobjekt zuletzt geändert hat (mit Änderungsdatum). |
Gelöscht von | Information, welcher Benutzer das Entwicklungsobjekt gelöscht hat (mit Löschdatum). |
Rubrik „Sperre“
Die Felder im Einzelnen:
Feld | Erläuterung |
Sperr-Status | Information über den aktuellen Sperrstatus:
· keine Sperre · Sperre durch Benutzer (lokal) · Sperre durch Aufgabe (global) · Sperre durch Softwareaktualisierung (das Entwicklungsobjekt wird gerade durch eine Softwareaktualisierung installiert) |
Entwicklungsaufgabe | Entwicklungsaufgabe, der das Entwicklungsobjekt aktuell zugeordnet ist. Weitere Informationen finden Sie im Dokument „Entwicklungsaufgaben“. |
Gesperrt von | Information, welcher Benutzer das Entwicklungsobjekt gesperrt hat. |
Sperrdatum | Information, welcher Benutzer das Entwicklungsobjekt gesperrt hat. Diese Information wird nur bei einer lokalen Sperre angezeigt (mit Sperrdatum). |
Rubrik „Generierung“
Diese Information ist nur bei Entwicklungsobjekten, die generiert werden, sichtbar (Business Object, Part, OQL-View, Valueset).
Die Felder im Einzelnen:
Feld | Erläuterung |
Generiert von | Information, welcher Benutzer das Entwicklungsobjekt generiert hat (mit Generierungsdatum). |
Status | Status der Generierung:
· Generierung erfolgreich abgeschlossen. · Tabellen werden angelegt. · Tabellen wurden erfolgreich angelegt. · Konvertierung läuft. · Konvertierung erfolgreich abgeschlossen. · Aktivierung läuft. · Aktivierung erfolgreich abgeschlossen. · Wiederherstellung läuft. · Wiederherstellung abgeschlossen. |
Rubrik „Angezeigte Version“
Die Felder im Einzelnen:
Feld | Erläuterung |
Version | Version des geöffneten Entwicklungsobjektes. |
Entwicklungsaufgabe | Version der Entwicklungsaufgabe. |
Geändert von | Information, welcher Benutzer diese Version erzeugt hat (mit Änderungsdatum). |
Rubrik „Aktive Version“
Die Felder im Einzelnen:
Feld | Erläuterung |
Aktive Version | Im System aktive Version |
Entwicklungsaufgabe | Entwicklungsaufgabe, in der diese Version aktiviert wurde. |
Geändert von | Information, welcher Benutzer diese Version erzeugt hat (mit Änderungsdatum). |
Rubrik „Aktuelle Version“
Die Felder im Einzelnen:
Feld | Erläuterung |
Aktive Version | Version der aktuellen Version im System.
Wenn das Entwicklungsobjekt in keiner Entwicklungsaufgabe gesperrt ist, entspricht die aktuelle Version der aktiven Version. |
Entwicklungsaufgabe | Entwicklungsaufgabe, in der die aktuelle Version aktiviert wurde bzw. gesperrt ist. |
Geändert von | Information, welcher Benutzer diese Version erzeugt hat (mit Änderungsdatum). |
Rubrik „Vorgängerversion“
Die Felder im Einzelnen:
Feld | Erläuterung |
Vorgänger | Version der Vorgängerversion der geöffneten Version. |
Vorgänger-Branch | Versionsnummer des Branch, aus dem die geöffnete Version entstanden ist. |
Art der Kopie | Zeigt an aus welcher Version die gesperrte Version entstanden ist. |
Entstanden aus | Versionsnummer der Version, aus dem der Inhalt der gesperrten Version entstanden ist, wenn sie durch die parallele Wartung erzeugt wurde. |
Rubrik „Abgelehnt ab“
Das Setzen der Ablehnung wird im Kapitel „Status am Entwicklungsobjekt setzen“ beschrieben.
Die Felder im Einzelnen:
Feld | Erläuterung |
Version | Version, in der das Entwicklungsobjekt abgelehnt wurde. |
Entwicklungsaufgabe | Entwicklungsaufgabe, der diese Version zugeordnet ist. |
Geändert von | Information, welcher Benutzer diese Version erzeugt hat (mit Änderungsdatum). |
Rubrik „Löschkennzeichen“
Das Setzen des Löschkennzeichens wird im Kapitel „Löschen“ beschrieben.
Die Felder im Einzelnen:
Feld | Erläuterung |
Version | Version, in der das Entwicklungsobjekt als gelöscht markiert wurde. |
Entwicklungsaufgabe | Entwicklungsaufgabe, der diese Version zugeordnet ist. |
Geändert von | Information, welcher Benutzer diese Version erzeugt hat (mit Änderungsdatum). |
Rubrik „Eigenschaften“
Die Felder im Einzelnen:
Feld | Erläuterung |
Erfasst durch | Information, wie das Entwicklungsobjekt entstanden ist:
· Benutzer: Entwicklungsobjekt wurde durch einen Benutzer erfasst. · Generierung (Mehrsprachigkeit): Generierte Entwicklungsobjekte zur Unterstützung der Mehrsprachigkeit. · Generierung (OQL-View): Generierte Mapper für OQL-Views. · Generierung (Business Object): Generierte Mapper für Business Objects. · Generierung (Valueset): Generierte Java-Klassen für Valuesets. · Generierung (Part): Generierte Mapper für Parts. · Generierung (DB-Update): Generierte versionisierte DBU-Mapper. |
Name | Entwicklungsobjekt, bei dessen Generierung dieses Entwicklungsobjekt entstanden ist. |
Originalsprache | Die aktive Entwicklungssprache bei Erstellung der ersten Version des Entwicklungsobjekts. |
Rubrik „Eigenschaften des Namensraumes“
Die Felder im Einzelnen:
Feld | Erläuterung |
Verantwortlicher | Verantwortlicher Benutzer des Namensraums. |
Test-Namensraum/Interner Namensraum | Anzeige, ob es sich um einen Test– oder internen Namensraum handelt. |
4.2.3 Karteireiter „Labels“
Ein Label verknüpft ein Release oder eine Softwareaktualisierung mit einer Version.
Die Felder im Einzelnen:
Feld | Erläuterung |
Label | Name der Softwareaktualisierung oder des Releases. Weitere Informationen finden Sie in der Dokumentation „Labels“. |
Version | Versionsnummer, der die Release-Definition oder der die Softwareaktualisierung zugeordnet ist. |
Typ | Art des Labels:
· Release · Import (Typ der Softwareaktualisierung) · Export (Typ der Softwareaktualisierung) |
Erfasst durch Benutzer | Name des Benutzers, durch den das Release definiert oder die Softwareaktualisierung erzeugt wurde. |
Erzeugt am | Erzeugungsdatum der Release-Definition oder der Softwareaktualisierung. |
4.2.4 Karteireiter „Verwendungsnachweis“
Der Verwendungsnachweis ist für alle Entwicklungsobjekte verfügbar. In einer Baumstruktur werden alle Entwicklungsobjekte aufgeführt, die dies Entwicklungsobjekt verwenden. Durch Erweiterung des Baums, werden die Verwendungen der aufgeführten Entwicklungsobjekte rekursiv angezeigt. Dadurch kann abgeschätzt werden, welche Auswirkungen eine Änderung auf andere Entwicklungsobjekte hat.
Der Verwendungsnachweis wird in der Löschprüfung verwendet. Die Löschung eines Entwicklungsobjektes ist nur möglich, wenn das Entwicklungsobjekt durch kein anderes referenziert wird.
Der Verwendungsnachweis wird auch für das automatische Hinzufügen von Entwicklungsobjekten in die Entwicklungsaufgabe verwendet (siehe Kapitel „Automatisches Hinzufügen/Löschen von Entwicklungsobjekten“).
Funktionen | Erläuterung |
Entwicklungsobjekte in die Aufgabe aufnehmen | Entwicklungsobjekte werden in der aktuellen Aufgabe gesperrt.
Dazu muss im Aufgabenfeld eine gültige Entwicklungsaufgabe ausgewählt sein. Entwicklungsobjekte, die bereits in einer anderen Aufgabe gesperrt sind, können nicht übernommen werden. |
Attribute | Darstellung der Verwendung von Attributen (z. B. in Beziehungen (Business Object, Part, Extension), OQL-Suchen).
Diese Funktionalität steht nur für Business Objects, Extensions und OQL-Views zur Verfügung. |
4.2.5 Karteireiter „Direkthilfe“
Dieser Karteireiter dient der Erfassung von Hilfetexten zu einem Entwicklungsobjekt. Nur für ausgewählte Entwicklungsobjekttypen kann eine Direkthilfe erfasst werden, wie z. B. für die Typen Action, Anwendung oder Data-Description-LDT. Der Direkthilfetext kann zu den Oberflächenelementen, die das Entwicklungsobjekt verwenden, aufgerufen und angezeigt werden.
Die Felder im Einzelnen:
Feld | Erläuterung |
Überschrift | Überschrift der Direkthilfe. |
Text | Beliebiger Text, der inkl. Überschrift 2000 Zeichen nicht überschreiten darf. Der Text ist übersetzbar. |
4.3 Andockbares Fenster „Entwicklungsobjekte der aktuellen Aufgabe“
Im andockbaren Fenster „Entwicklungsobjekte der aktuellen Aufgabe“ werden die gesperrten Entwicklungsobjekte der Entwicklungsaufgabe (siehe Kapitel „Aufgabenfeld“) angezeigt, die im Aufgabenfeld eingegeben ist.
Folgende Funktionen stehen in der Symbolleiste zur Verfügung:
Buttons | Erläuterung |
Aufklapp-Button | Drücken Sie auf den Aufklappbutton, dann werden daraufhin Abfragefelder angezeigt, mit denen Sie nach Objekten suchen können, die mit der relevanten Entwicklungsaufgabe gesperrt sind. Erfassen Sie Suchmerkmale in die Abfragefelder und drücken Sie danach auf den Start-Button. In der Ergebnisliste werden jene Objekte angezeigt, die mit den Suchmerkmalen übereinstimmen. |
Neu-Button | Haben Sie Suchmerkmale in den Abfragefeldern erfasst, die unter dem Aufklapp-Button angezeigt werden, dann können Sie diese mithilfe des Neu-Buttons entfernen. Daraufhin werden die Vorschlagswerte eingefügt und die Liste der gesperrten Objekte automatisch aktualisiert.
Hinweis: Der Button „Neu“ bezieht sich nur auf die Abfragefelder im Aufklappbereich. Die anderen Anzeigekriterien, die Sie mithilfe der Buttons in der Symbolleiste ausgewählt haben (Bearbeitungsstatus, gesperrte Objekte, generierte Objekte), werden durch Drücken des Buttons „Neu“ nicht zurückgesetzt. Betroffen ist allein der Button zur Herkunft eines Entwicklungsobjektes. |
Bearbeitungsstatus | Sie können die Anzeige gemäß des Bearbeitungsstatus eines Entwicklungsobjekts beeinflussen. Die möglichen Werte sind:
· Alle anzeigen, Bearbeitungsstatus ignorieren · Objekte mit unbekanntem Bearbeitungsstatus anzeigen Der Status „Unbekannt“ bedeutet, dass das Objekt entweder nicht mehr in einer Aufgabe gesperrt ist und damit auch die Information über den Bearbeitungsstatus nicht mehr vorhanden ist, oder dass der Bearbeitungsstatus noch nicht gesetzt wurde. · Bearbeitete Objekte anzeigen · Zu bearbeitende Objekte anzeigen · Objekte mit Bearbeitungsstatus „Undefiniert“ anzeigen |
Herkunft | Sie können die Anzeige gemäß der Herkunft des Inhalts eines Entwicklungsobjekts beeinflussen. Insbesondere bei Konfliktaufgaben ist nützlich, die Herkunft des Inhalts der Version zu kennen.
Mögliche Werte sind: · Alle Objekte anzeigen, Herkunft ignorieren · Objekte mit Inhalt unbekannter Herkunft anzeigen · Manuell aufgenommene Objekte anzeigen · Objekte mit Inhalt aus diesem System anzeigen · Objekte mit Inhalt aus anderem System anzeigen Nach der Aktivierung der Entwicklungsaufgabe ist die Information über die Herkunft des Objektinhalts nicht mehr vorhanden. |
Nur gesperrte Objekte anzeigen/Alle Objekte anzeigen | Blendet alle Entwicklungsobjekte ein bzw. aus, die eine globale Sperre besitzen. |
Generierte Objekte einblenden/ausblenden | Entwicklungsobjekte, die durch das System erzeugt wurden (z. B. generierte Java-Klassen) werden über diesen Button ein- bzw. ausgeblendet. |
Start | Mit diesem Button aktualisieren Sie die Anzeige der Objekte. Das ist beispielsweise dann notwendig, wenn Sie eine andere Aufgabennummer in das Aufgabenfeld eingeben. |
4.4 Anwendungsbezogene Aktionen
4.4.1 Restriktionen
In der nachfolgenden Tabelle wird aufgeführt, in welchen Systemen Neuanlagen, Änderungen und Löschungen von Entwicklungsobjekten durchgeführt werden können.
Standardentwicklung | Partner | Kunde | |||||
Entwicklung | Korrektur | Entwicklung | Korrektur | Kunden-adaptierung | Kunden-adaptierung | Test/ Produktiv |
|
Stufe 1 | Stufe 2 | Stufe 3 | Stufe 4 | Stufe 5 | Stufe 6 | Stufe 7 | |
Standardentwicklung Systemcode | |||||||
EO neu erfassen |
Ja | Ja | Nein | Nein | Nein | Nein | Nein |
EO ändern | Ja | Ja | Nein | Nein | Nein | Nein | Nein |
EO löschen | Ja | Ja | Nein | Nein | Nein | Nein | Nein |
Standardentwicklung Anwendungscode | |||||||
EO neu erfassen |
Ja | Ja | Nein | Nein | Nein | Nein | Nein |
EO ändern | Ja | Ja | Ja | Ja | Ja | Ja | Nein |
EO löschen | Ja | Ja | Nein | Nein | Nein | Nein | Nein |
Logischen Datentyp ändern | Ja | Ja | Nein | Nein | Nein | Nein | Nein |
Business Object ändern |
Ja | Ja | Nein | Nein | Nein | Nein | Nein |
Part ändern | Ja | Ja | Nein | Nein | Nein | Nein | Nein |
Partner/Kunden Anwendungscode | |||||||
EO neu erfassen |
Nein | Nein | Ja | Ja | Ja | Ja | Nein |
EO ändern | – | – | Ja | Ja | Ja | Ja | Nein |
EO löschen | – | – | Ja | Ja | Ja | Ja | Nein |
EO = Entwicklungsobjekt
Hinweis:
Entwicklungsobjekte, die in der jeweiligen Stufe nicht bearbeitet werden können, werden nur angezeigt. Die Bearbeitung der Entwicklungsobjekte ist nicht möglich.
4.4.2 Besonderheiten bei der Bearbeitung von Entwicklungsobjekten
Eine Ausnahme stellt das Textobjekt dar. Das Textobjekt ist abhängig von einem anderen Entwicklungsobjekt und kann nicht erfasst, dupliziert, wieder angelegt, geprüft oder gelöscht werden. Das Textobjekt wird durch das dazugehörige Entwicklungsobjekt in die Aufgabe aufgenommen und kann nur mit diesem aus der Aufgabe entfernt werden. Auch die Sperren werden analog zum Entwicklungsobjekt gesetzt. Ein Textobjekt kann explizit in einer Aufgabe vom Typ Redaktion gesperrt und bearbeitet werden. In diesem Aufgabentyp können nur Textobjekte gesperrt werden.
4.4.3 Neu
Mit dieser Funktion legen Sie ein Entwicklungsobjekt neu an. Die Neuanlage erfolgt für den ausgewählten Entwicklungsobjekttyp. Ist bereits Entwicklungsobjekt geöffnet, erhalten Sie eine Warnung, falls Änderungen noch nicht gespeichert wurden.
Ist im Identifikationsbereich bereits ein Namensraum und ein Entwicklungsobjektname eingetragen, wird der Entwicklungsobjektname nur entfernt, wenn das Entwicklungsobjekt bereits existiert. Ist nichts angegeben, wird automatisch com.<Partnerkürzel>.app. gesetzt.
Bei der Neuanlage wird automatisch die erste Version erzeugt. Diese wird erst im Versionsfeld sichtbar, nachdem Sie das Entwicklungsobjekt das erste Mal gesperrt oder gespeichert haben.
Wenn ein Entwicklungsobjekt neu angelegt wird, dann werden anhand des vorherigen geöffneten Entwicklungsobjekts bestimmte Standardwerte gesetzt.
Vorheriges Entwicklungsobjekt |
Neuanlage | Standardwerte in den Feldern |
Valueset | Logischer Datentyp | · Typ: primitiver Typ
· Primitiver Typ: Valueset · Valueset: das vorherige Valueset |
Part | Logischer Datentyp | · Typ: komplexer Typ
· Part: der vorher geöffnete Part |
Logischer Datentyp | Logischer Datentyp | · Typ: Logischer Typ
· Abgeleitet von: der vorher geöffnete Logische Datentyp |
Logischer Datentyp | Data-Description-LDT | Log. Datentyp: der vorher geöffnete Logische Datentyp. |
Meldungsklasse | Meldung | Meldungsklasse: die vorher geöffnete Meldungsklasse |
Framework | Anwendung | Framework: das vorher geöffnete Framework |
4.4.4 Duplizieren
Sie können jede beliebige Version eines Entwicklungsobjekts duplizieren. Der Inhalt einer Version kann in ein neues Entwicklungsobjekt des gleichen Entwicklungsobjekttyps, in ein bestehendes Entwicklungsobjekt des gleichen Entwicklungsobjekttyps oder in das gleiche Entwicklungsobjekt dupliziert werden. Hierzu geben Sie im Dialogfenster, das nach dem Ausführen der Aktion geöffnet wird, den Namen des Entwicklungsobjekts an, in das dupliziert werden soll. Zusätzlich müssen Sie noch angeben, ob Sie in ein bestehendes Entwicklungsobjekt oder in ein neues Entwicklungsobjekt duplizieren möchten. Dadurch wird verhindert, dass Sie unbewusst den Inhalt eines bestehenden Entwicklungsobjekts überschreiben.
Das Duplizieren in ein bestehendes Entwicklungsobjekt unterscheidet sich vom Duplizieren in eine Neuanlage. In diesem Fall wird das Ziel-Entwicklungsobjekt zuerst geöffnet und alle seine Elemente (z. B. Attribute von Business Objects) werden mit einem Löschkennzeichen gekennzeichnet. Anschließend werden die Elemente des Quell-Entwicklungsobjekts zu diesem Entwicklungsobjekt hinzugefügt. Dadurch verhält sich das Duplizieren, als ob Sie den Vorgang manuell über die Oberfläche durchführen.
Hinweis:
Um eine beliebige Version eines Entwicklungsobjekts wieder herzustellen, müssen Sie nur die gewünschte Version öffnen, duplizieren und den Entwicklungsobjektnamen nicht ändern. Diese Vorgehensweise empfiehlt sich in Konfliktaufgaben, um die Adaptierung in die gesperrte Version zu kopieren und dadurch wieder herzustellen. Dabei können Sie nur Änderungen durchführen, die auch über die Oberfläche erlaubt sind. Beispiel: Sie haben ein Valueset adaptiert, zu dem eine neue Version ausgeliefert wird. Enthält diese neue Version ein neues Element, so können Sie dies nicht löschen. Duplizieren Sie Ihre Adaptierung in die Version in der Konflikt-Entwicklungsaufgabe, dann ist das neu ausgelieferte Element mit einem Löschkennzeichen gekennzeichnet. Beim Prüfen führt das zu einem Fehler. Sie müssen die Löschkennzeichnung aufheben, bevor Sie speichern können.
4.4.5 Objektnamen wiederverwenden
Die Funktion steht Ihnen zur Verfügung, wenn Sie den Objektnamen eines gelöschten Entwicklungsobjekts wieder verwenden möchten. Dabei wird nur der Entwicklungsobjektname wieder hergestellt, die Metadaten des gelöschten Entwicklungsobjekts werden nicht wieder hergestellt. Dies ist technisch nicht möglich, da referenzierte Entwicklungsobjekte gelöscht sein können. Diese müssten ebenfalls wieder hergestellt werden. Diese Verfahrensweise hätte einen nicht abschätzbaren manuellen Arbeitsaufwand zur Folge. Auch eine automatisierte Lösung ist nicht gewünscht, da nicht beeinflusst werden kann, welche Entwicklungsobjekte wieder herstellt werden würden.
Bei dieser Aktion wird eine Entwicklungsaufgabe benötigt. In dieser wird das Entwicklungsobjekt lokal gesperrt. Die Versionierung wird weiter hochgezählt.
4.4.6 Sperren
Mit dieser Aktion können Sie das Entwicklungsobjekt lokal sperren. Das zu sperrende Entwicklungsobjekt darf nicht lokal durch einen anderen Benutzer oder durch die Installation einer Softwareaktualisierung gesperrt sein.
Ist das Entwicklungsobjekt beim Sperren noch nicht global gesperrt (gilt auch für Neuanlagen) müssen Sie eine Entwicklungsaufgabe angeben, der das Entwicklungsobjekt zugeordnet werden kann. Nach dem erfolgreichen Setzen der globalen Sperre wird die lokale Sperre gesetzt. Ist das Entwicklungsobjekt bereits global gesperrt, wird die lokale Sperre gesetzt.
Beim Sperren werden bereits vorgenommene Änderungen gemerkt (siehe Kapitel „Merken“). Bei Dateiobjekten (wie z. B. Icon, Java-Klasse, Datei, Hilfe-Objekt, Bericht) werden existierende Dateien in einem Work-Ordner abgelegt. Bei einer Neuanlage werden vom System entsprechende Vorlage-Dateien im Work-Ordner erzeugt. Bei einem bereits existieren Entwicklungsobjekt werden die Dateien aus dem Archiv im Dateisystem abgelegt. Die Struktur der Work-Verzeichnisse ist im Dokument „Entwicklungsaufgaben“ beschrieben.
4.4.7 Abhängige Entwicklungsobjekte mit sperren
Diese Aktion steht Ihnen bei Java-Klassen zur Verfügung. Diese ermöglicht, beim Sperren einer Java-Klasse, alle Java-Klassen automatisch mit zu sperren, welche die geöffnete Java-Klasse verwenden. Dabei werden nur Java-Klassen gesperrt, die in der gleichen Entwicklungsaufgabe global gesperrt sind.
Hinweis:
Aufgenommen werden nur Java-Klassen, die direkt benutzt werden.
Diese Funktion ist vor allem bei umfangreichen Konfliktaufgaben behilflich. Dadurch erhält man eine Abgrenzung, welche Java-Klassen überarbeitet werden müssen. Die Abgrenzung ist nicht unbedingt inhaltlich korrekt.
4.4.8 Speichern und Freigeben
Mit dieser Aktion speichern Sie die geänderten Daten eines Entwicklungsobjekts in den Archiv-Business-Objects und aktualisieren die System-Business-Objects, vorausgesetzt, das Entwicklungsobjekt konnte erfolgreich geprüft werden.
Hinweis:
Das Entwicklungsobjekt darf nicht lokal durch einen anderen Benutzer oder durch die Installation einer Softwareaktualisierung gesperrt sein.
Ist das Entwicklungsobjekt noch nicht gesperrt, dann erfolgt die Sperrung automatisch. Dazu müssen Sie eine Entwicklungsaufgabe angeben. Ist das Entwicklungsobjekt bereits global gesperrt, wird automatisch eine lokale Sperre gesetzt. Erst wenn das Entwicklungsobjekt lokal gesperrt ist und erfolgreich geprüft wurde, werden die Änderungen gespeichert. Danach wird die lokale Sperre aufgehoben und die globale Sperre gesetzt. Andernfalls bleibt das Entwicklungsobjekt lokal gesperrt.
Der Verwendungsnachweis des Entwicklungsobjekts wird ebenfalls aktualisiert. Referenzierte Entwicklungsobjekte werden in den Verwendungsnachweis eingetragen. Entwicklungsobjekte, die nicht mehr verwendet werden, werden aus dem Verwendungsnachweis entfernt.
Hinweis:
Beim Speichern werden die Daten in die System-Business-Objects geschrieben. Da das System auf diese zugreift, heißt das, dass die Änderungen nach dem Speichern und Freigeben im System sichtbar sind. Beispiel: Wenn das Label einer Data-Description geändert wird, dann ist die Änderung nach dem Speichern und Freigeben in der Oberfläche sichtbar.
Die Änderung eines Entwicklungsobjekts sollte immer mit einer lokalen Sperre erfolgen. Wird das Entwicklungsobjekt zwischenzeitlich durch einen anderen Benutzer geändert, dann können die geänderten Daten nicht gespeichert werden. Das Entwicklungsobjekt muss neu geöffnet werden, wodurch nicht gespeicherte Änderungen verworfen werden.
Verhalten bei dateibasierten Entwicklungsobjekten
Beim Speichern und Freigeben wird der Inhalt der zugehörigen Dateien aus dem Work-Ordner des aktuellen Bearbeiters in die Archiv-Business-Objects zurückgeschrieben. Danach werden die Dateien aus dem Work-Ordner des aktuellen Bearbeiters entfernt und der „Common“-Ordner wird aktualisiert.
Hinweis:
Beim Entwicklungsobjekt „Java-Klasse“ werden die Class-Dateien im Archiv gelöscht. Dadurch wird gewährleistet, dass die Entwicklungsaufgabe in diesem Zustand nicht freigegeben werden kann, bevor das zentrale Checkin ausgeführt wurde. Nach dem Checkin sind die Archive aktualisiert.
4.4.9 Löschen
Mit der Aktion „Löschen“ löschen Sie ein Entwicklungsobjekt. Diese Aktion erzeugt eine weitere Version des Entwicklungsobjekts, die mit einem „+“ gekennzeichnet ist. Zu der Löschversion existieren keine Einträge in den Archiv-Business-Objects und den System-Business-Objects. Ist das zu löschende Entwicklungsobjekt noch nicht gesperrt, müssen Sie eine Entwicklungsaufgabe angeben. Nach der Löschung ist das Entwicklungsobjekt nicht mehr bearbeitbar und global gesperrt.
Hinweis:
Das Entwicklungsobjekt darf nicht lokal durch einen anderen Benutzer oder durch die Installation einer Softwareaktualisierung gesperrt sein.
Ein Entwicklungsobjekt kann nur gelöscht werden, wenn es von keinem anderen Entwicklungsobjekt referenziert wird. Diese Referenzen müssen Sie entfernen, bevor das Entwicklungsobjekt gelöscht werden kann. Dazu können Sie den Verwendungsnachweis zu Hilfe nehmen, um die referenzierten Entwicklungsobjekte zu ermitteln.
Hinweis:
Wenn Sie den Inhalt eines gelöschten Entwicklungsobjekts betrachten möchten, müssen Sie die entsprechende Vorgängerversion öffnen.
4.4.10 Prüfen
Mit der Aktion „Prüfen“ wird der Inhalt des Entwicklungsobjekts auf Korrektheit geprüft. Hierbei wird die gleiche Prüfung ausgeführt, die auch beim Speichern und Freigeben verwendet wird. Die Prüfung kann nur auf der aktuellen Version durchgeführt werden.
Hinweis:
Das Entwicklungsobjekt darf nicht lokal durch einen anderen Benutzer oder durch die Installation einer Softwareaktualisierung gesperrt sein.
4.4.11 Aktive Version wiederherstellen
Mit dieser Aktion können Sie die globale oder lokale Sperre eines Entwicklungsobjekts aufheben. Die gesperrte Version und deren Archiv-Business-Objects werden gelöscht und die Daten der aktiven Version werden wieder in die System-Business-Objects kopiert.
Hinweis:
Das Entwicklungsobjekt darf nicht lokal durch einen anderen Benutzer oder durch die Installation einer Softwareaktualisierung gesperrt sein.
Bei einer Neuanlage wird das Entwicklungsobjekt vollständig (Version, Archiv-Business-Objects und System-Business-Objects) entfernt. Bei einer Wiederanlage wird die Löschversion wieder hergestellt.
Entwicklungsobjekte aus Konfliktaufgabe entfernen
Eine Beschreibung der Konfliktaufgaben finden Sie im Dokument „Einführung: Softwarelogistik“.
Diese Aktion steht Ihnen bei Konfliktaufgaben zur Verfügung, die durch Software-Quertransporte oder durch den Release-Wechsel entstanden sind. Für Konfliktaufgaben des Standard-Transportwegs steht Ihnen die Aktion „Konflikt entfernen“ zur Verfügung.
Entfernen Sie in diesen Entwicklungsaufgaben ein Entwicklungsobjekt, so werden alle Versionen des Entwicklungsobjekts automatisch entfernt, die größer als die aktive Version sind. Dabei handelt es sich um die gesperrte Version und um einen Teil der importierten Versionen. Wurde das Entwicklungsobjekt bereits in dem System bearbeitet oder sind importierte Versionen kleiner als die aktive Version, dann bleiben diese Versionen erhalten.
Warnung:
Wird ein Entwicklungsobjekt aus der Aufgabe entfernt, so können Sie die gelöschten Versionen nicht wieder herstellen.
Generierte Java-Klassen (z.B. Mapper von Business Objects) können nicht einzeln aus der Entwicklungsaufgabe entfernt werden. Diese werden automatisch aus der Entwicklungsaufgabe entfernt, wenn das zugehörige Entwicklungsobjekt entfernt wird. Befinden sich die generierten Java-Klassen ohne das zugehörige Entwicklungsobjekt in der Konfliktaufgabe, können diese einzeln entfernt werden.
Die importierten dbu-Mapper von Business Objects können nicht aus der Entwicklungsaufgabe entfernt werden. Diese müssen aktiviert werden, da sie in den Methoden der aktiven Mapper der Business Objects verwendet werden.
4.4.12 Konflikt entfernen
Eine Beschreibung der Konfliktaufgaben finden Sie im Dokument „Einführung: Softwarelogistik“.
Diese Aktion steht Ihnen in Konfliktaufgaben zur Verfügung, die beim Einspielen von Softwareaktualisierungen auf dem Standard-Transportweg entstehen. Damit können Sie Branches wieder entfernen, die durch die Adaptierung von Entwicklungsobjekten entstanden sind.
Hinweis:
Das Entwicklungsobjekt darf nicht lokal durch einen anderen Benutzer oder durch die Installation einer Softwareaktualisierung gesperrt sein.
Beim Entfernen der gesperrten Version wird die importierte Version automatisch in die Konfliktaufgabe aufgenommen. Dies ist technisch notwendig, damit die Version korrekt aktiviert wird. Eine Bearbeitung dieser Version ist nicht möglich, da diese Version in einem anderen System entstanden ist.
Diese Aktion ist bei Business Objects, Parts und Extensions aus technischen Gründen nicht verfügbar.
Hinweise:
Befindet sich ein Textobjekt mit dem zugehörigen Entwicklungsobjekt in der Konfliktaufgabe, so kann das Textobjekt nicht einzeln entfernt werden. Es wird automatisch entfernt, wenn das zugehörige Entwicklungsobjekt entfernt wird.
Befindet sich ein Textobjekt ohne das zugehörige Entwicklungsobjekt in der Konfliktaufgabe, kann das Textobjekt wie jedes andere Entwicklungsobjekt einzeln entfernt werden.
Befindet sich ein Entwicklungsobjekt in der Konfliktaufgabe und das zugehörige Textobjekt wurde ebenfalls angepasst, befindet sich aber nicht in dieser Konfliktaufgabe, so wird nur der Konflikt für das Entwicklungsobjekt entfernt. Der Konflikt im Textobjekt kann nur entfernt werden, wenn sich das Textobjekt ebenfalls in einer Konfliktaufgabe befindet.
4.4.13 Status am Entwicklungsobjekt setzen
Mit dieser Aktion können Sie ein Entwicklungsobjekt ablehnen oder eine Löschkennzeichnung setzen. Wird ein Status gesetzt, erhält das Entwicklungsobjekt eine lokale Sperre. Ist das Entwicklungsobjekt noch nicht gesperrt, müssen Sie eine Entwicklungsaufgabe angeben. Es kann immer nur ein Status gesetzt werden.
Hinweis:
Das Entwicklungsobjekt darf nicht lokal durch einen anderen Benutzer oder durch die Installation einer Softwareaktualisierung gesperrt sein.
Die Ablehnung können Sie nach einer Aktivierung wieder zurücknehmen. Das Löschkennzeichen können Sie nach der Aktivierung nicht wieder zurückgenommen werden.
- Ablehnen:
Das Entwicklungsobjekt sollte nicht mehr verwendet werden. Wird ein solches Entwicklungsobjekt in anderen Entwicklungsobjekten verwendet, wird eine entsprechende Warnung ausgegeben. - Löschkennzeichen setzen:
Wird ein solches Entwicklungsobjekt in anderen Entwicklungsobjekten verwendet, wird eine entsprechende Warnung ausgegeben. Bei Business Objects kann nicht mehr auf die aktiven Mapper zugegriffen werden. Lediglich auf die versionierten Mapper, um eine Updateanwendung zu schreiben, die die Daten in ein neues Business Object konvertiert.
4.4.14 Merken
Sie können einen beliebigen Bearbeitungsstand eines Entwicklungsobjekts speichern. Die Daten werden nur in den Archiv-Business-Objects gespeichert, die System-Business-Objects werden nicht aktualisiert. Das Entwicklungsobjekt bleibt nach der Merken-Aktion lokal gesperrt. Ist das Entwicklungsobjekt noch nicht gesperrt, dann wird es beim Merken automatisch lokal gesperrt. Geben Sie hierzu eine Entwicklungsaufgabe an.
Hinweis:
Das Entwicklungsobjekt darf nicht lokal durch einen anderen Benutzer oder durch die Installation einer Softwareaktualisierung gesperrt sein.
Prinzipiell können Sie jeden Zustand eines Entwicklungsobjekts speichern, es sei denn, die Daten können nicht in den Archiv-Business-Objects gespeichert werden (z. B. eine Zeichenkette, die länger ist, als im Archiv-Business-Object definiert ist).
Hinweis:
Gespeichert werden auch Referenzen auf nicht existierende Entwicklungsobjekte. Gelöschte Elemente (z. B. Attribute von Business Objects) werden mit der Löschkennzeichnung gespeichert. Diese Elemente werden erst beim Speichern und Freigeben gelöscht.
4.4.15 Angezeigte Version des Entwicklungsobjekts exportieren
Mit dieser Aktion können Sie die aktuell angezeigte Version des Entwicklungsobjekts exportieren. Eine Beschreibung hierzu finden Sie im Dokument „Entwicklungsobjekte exportieren und importieren“.
4.4.16 Benötigte Namensräume erzeugen
Mit dieser Aktion erzeugen Sie die für ein neues Entwicklungsobjekt benötigten Namensräume. Dadurch können Sie ein Entwicklungsobjekt erfassen ohne zuvor alle benötigten Namensräume erfassen zu müssen. Die Aktion steht zur Verfügung nachdem die Prüfung des neuen Entwicklungsobjekts ergeben hat, dass ein benötigter Namensraum nicht vorhanden ist.
Die Namensräume werden mit folgenden Einstellungen erzeugt:
- Bezeichnung: technischer Name des Namensraums
- Verantwortlicher: Benutzer, der die Aktion ausführt
- Test-Namensraum: nein
- Interner Namensraum: nein
4.4.17 Unternamensräume erzeugen
Mit dieser Aktion erzeugen Sie Unternamensräume für den geöffneten Namensraum. Die Aktion steht nur für Entwicklungsobjekte des Typs „Namensraum“ zur Verfügung. Standardmäßig werden folgende Unternamensräume erzeugt:
- obj
- ui
- gui
- log
- model
- reorg
- hook
- ui
- log
Sie können mithilfe der ERP-Propertys festlegen, welche Unternamensräume mit der Aktion erzeugt werden. Weitere Informationen finden Sie in der Dokumentation „ERP-Propertys“.
4.4.18 Aufgabenfeld
Im Aufgabenfeld geben Sie die Entwicklungsaufgabe an, in der das Entwicklungsobjekt bearbeitet wird. Über die Wertehilfe können nur Entwicklungsaufgaben ausgewählt werden, in denen der aktuelle Benutzer als Bearbeiter eingetragen ist.
Folgende Eigenschaften prüft die Anwendung „Entwicklungsobjekte“ an der ausgewählten Entwicklungsaufgabe, wenn in dieser ein Entwicklungsobjekt bearbeitet wird.
Eigenschaft | Erläuterung |
Status | Die Entwicklungsaufgabe muss offen sein. |
Bearbeiter | Der Benutzer muss als Bearbeiter in der Entwicklungsaufgabe eingetragen sein. |
Code-Klasse | Die Code-Klasse des Entwicklungsobjektes muss der Code-Klasse der Entwicklungsaufgabe entsprechen. |
Typ | Der Typ der Anwendung muss dem Entwicklungsobjekt entsprechen. (siehe Dokumentation „Entwicklungsobjekt: Namensraum“) |
4.4.19 Löschen von Attributen in Business Objects, Parts, Extensions und OQL-Views
Attribute von Business Objects, Parts, Extensions und OQL-Views können nur gelöscht werden, wenn sie
- nicht als Indexattribute oder Quellattribute einer Beziehung im selben Entwicklungsobjekt verwendet werden,
- nicht als Zielattribute einer Beziehung in einem anderen Business Object, einem Part oder einer Extension verwendet werden,
- nicht als Attribute in einer OQL-View oder einer OQL-Suche verwendet werden.
4.4.20 Automatisches Hinzufügen/Löschen von Entwicklungsobjekten
Automatisches Hinzufügen
Wird das Attribut eines Business Objects, eines Parts oder einer Extension geändert, dann werden die Entwicklungsobjekte, die dieses Attribut verwenden und neu generiert werden müssen, automatisch in die Entwicklungsaufgabe aufgenommen (globale Sperre). Bei folgenden Varianten werden die Entwicklungsobjekte in die Aufgabe aufgenommen:
- Das Attribut wird als Zielattribut einer Beziehung in einem anderen Business Object, einem Part oder einer Extension verwendet.
- Das Attribut wird als Attribut in einem OQL-View verwendet.
Wenn ein Logischer Datentyp geändert wird, dann werden alle Entwicklungsobjekte, die generiert werden und diesen Logischen Datentypen in ihrer Attributdefinition verwenden, automatisch der Aufgabe hinzugefügt.
Warnung:
Automatisch hinzugefügte Entwicklungsobjekte sollten nicht aus der Entwicklungsaufgabe entfernt werden. Diese Entwicklungsobjekte müssen generiert werden, da sonst der korrekte Zugriff (über die Mapper) nicht gewährleistet werden kann.
Automatisches Entfernen
Entwicklungsobjekte, die automatisch der Entwicklungsaufgabe hinzugefügt wurden (durch Änderung oder Löschung), werden auch wieder automatisch aus der Entwicklungsaufgabe entfernt, wenn das Entwicklungsobjekt aus der Entwicklungsaufgabe entfernt wird, durch das sie aufgenommen wurden. Wurde ein automatisch hinzugefügtes Entwicklungsobjekt manuell bearbeitet, dann wird es nicht mehr automatisch aus der Entwicklungsaufgabe entfernt.
Automatisches Löschen
Wenn ein Business Object, ein Part, eine Extension oder eine OQL-View gelöscht werden, dann werden die generierten aktiven Mapper und die generierten NLS-Objekte automatisch als gelöscht der Aufgabe hinzugefügt.
5 Berechtigungen
Berechtigungen können mithilfe der Berechtigungsrollen vergeben werden. Die Berechtigungen werden über das Business-Entity com.cisag.sys.repository.internal.obj.ObjectDirEntry vergeben. Das Berechtigungskonzept können Sie in der Technischen Dokumentation „Berechtigungen“ nachlesen.