Im Rahmen des Customizings werden Funktionen, bezogen auf ein System, einen Organisationstyp, eine Organisation oder einen Datenbanktyp, aktiviert oder deaktiviert, sowie funktionsspezifische Parameter eingestellt. Dieses Dokument beschreibt die Funktionsweise und Verwendung der Systemschnittstellen zu den Daten die in der Anwendung „Customizing“ erfasst werden können.

1                     Zielgruppe

• Entwickler
• Technische Berater

2                     Begriffsbestimmung

Customizing

Vor der Inbetriebnahme eines Semiramis-Systems müssen die Funktionalitäten an die spezifischen betriebswirtschaftlichen Anforderungen des Unternehmens angepasst werden. Dieser Prozess wird Customizing genannt und erfolgt in einem Kundenadaptierungssystem.

Customizing-Daten

Im Rahmen des Customizings werden Einstellungen und Werte zu Funktionen geändert oder erstmalig erfasst. Diese Daten werden Customizing-Daten genannt und können Auswirkungen auf Anwendungen haben. Manche Anwendungen lesen die Customizing-Daten einer oder mehrerer Funktionen und verändern ihr Verhalten oder ihr Aussehen je nach den erfassten Werten in den Customizing-Daten.

Customizing-Zusatzdaten

Wenn für eine Funktion komplexe Daten hinterlegt werden sollen, die nicht alleine in einem Part abgebildet werden können (z.B. tabellenartige Date), so kann ein Customizing-Editor dieser so genannten Customizing-Zusatzdaten in eigenen Business Objects speichern. Die Bearbeitung der Daten erfolgt in diesem Fall integriert in der Anwendung „Customizing“. Der Zugriff auf die Daten erfolgt nicht über die normalen PGM-Schnittstellen, sondern muss in Form von gesonderten Klassen bereitgestellt werden.

Customizing-Editor

Der Customizing-Editor ist eine Java-Klasse die von der Klasse „com.cisag.pgm.base.CisCustomizingEditor“ erbt und die eine parametrisierbaren Funktion als Editor für zugeordnet ist.

Funktion

Eine Funktion in Semiramis ist eine Menge von Funktionalitäten des Systems die über die Einstellungen in der Anwendung „Customizing“ den Benutzern prinzipiell zur Verfügung gestellt werden, oder eben nicht. Eine Funktion kann also in einem konkreten System aktiviert oder deaktiviert sein. Nicht alle Funktionen können deaktiviert werden, manche stehen immer zur Verfügung. Ob eine Funktion aktivierbar ist, kann zusätzlich noch von den vorhandenen Lizenzen abhängen. Manche Funktionen können parametrisiert werden. Dadurch können dann systemweite oder organisationstyp-spezifische Einstellungen vorgenommen werden.

Fremdgesteuerte Funktion

Eine fremdgesteuerte Funktion (engl. „managed function“) ist eine Funktion die nicht direkt als Funktion in der Anwendung „Customizing“ angezeigt wird, und deren „Aktiv“-Kennzeichen durch den Customizing-Editor einer anderen Funktion gesteuert wird. Fremdgesteuerte sind nicht sichtbare, deaktivierbare und nicht parametrisierbare Funktionen. Durch die Verwendung von fremdgesteuerten Funktionen ist es beispielsweise möglich, das Deaktivieren von Anwendungen auf der Basis von komplexen Berechnungen im Rahmen eines bestehenden Customizing-Editors zu implementieren.

Organisationen

Eine Organisation ist ein Partnertyp, mit dem beispielsweise Unternehmen, Niederlassungen, Abteilungen etc. erfasst werden. Für die Erfassung von Personen besteht ein eigener Partnertyp.

Eine Organisation kann Teil einer Organisationsstruktur in den Aufgabengebieten „Beschaffung“, „Lagerlogistik“, „Rechnungswesen“ oder „Vertrieb“ sein. Als Bestandteil einer solchen Organisationsstruktur wird die Organisation entsprechend des Aufgabengebietes auch Beschaffungs-, Lagerlogistik- oder Vertriebsorganisation oder Firma im Rechnungswesen genannt.

Organisationsstrukturen

Eine Organisationsstruktur spiegelt im Wesentlichen die Ablauforganisation in einer Unternehmensgruppe wider. Auch der Aufbau wird teilweise abgebildet. Für die Nutzung inhaltsbezogener Berechtigungen und die Abbildung von Ge-schäftsprozessen einer Unternehmensgruppe werden Organisationsstrukturen benötigt, die für folgende Organisationsstrukturtypen aufgebaut werden können: Beschaffung, Lagerlogistik, Rechnungswesen oder Vertrieb.

3                     Konventionen

3.1               Hierarchien

Interne Organisationen, die zu einer Organisationsstruktur gehören, können innerhalb dieser Organisationsstruktur in eine beliebig tief geschachtelte, hierarchische Struktur eingeordnet werden. Eine Ausnahme stellt dabei die Organisationsstruktur „Rechnungswesen“ dar, in dieser sind alle beteiligten Organisationen entweder dem Mandanten direkt untergeordnet oder der Mandant selbst. Die Organisationsstruktur eines Organisationsstrukturtyps braucht dabei nicht der Organisationsstruktur eines anderen Organisationsstrukturtyps zu gleichen. Eine Organisation „A“ kann einer Organisation „B“ in der Lagerlogistik übergeordnet sein, während es etwa im Vertrieb genau umgekehrt ist.

Die möglichen Werte für Organisationsstrukturtypen sind in der Klasse „com.cisag.pgm.base.OrganizationHierarchyType“ zu finden. Die Liste aller Organisationen einer OLTP-Datenbank wird der System-Engine von der Klasse „com.cisag.app.multiorg.log OrganizationInfoProvider“ in Form einer Liste von Objekten der Klasse „com.cisag.pgm.base.OrganizationInfo“ zur Verfügung gestellt werden. In der Instanz dieser Klasse ist die Information enthalten, welchen Organisationsstrukturtypen der die Organisation angehört. Es ist durchaus möglich, das eine Organisation mehreren Organisationsstrukturtypen angehört.

Alle Organisationen die in der Liste der „CisOrganizationInfo“-Instanzen stehen, werden später in der Anwendung „Customizing“ in der Auswahlliste der Organisationen angezeigt. Hierbei können für eine Funktion und einen Organisation nur dann Daten erfasst werden, werden beide die gleichen Organisationsstrukturtypen beinhalten. Ist z.B. die Funktion für Lagerlogistik und Beschaffung relevant, so werden sind die Eingabefelder nur für alle Organisationen die den Typ Lagerlogistik oder Beschaffung innehaben aktiv.

Die Hierarchie der Organisationen unterscheidet sich in der Anwendung „Customizing“ von den Hierarchien, die in den Organisationsstrukturen festgelegt sind. In der Anwendung „Customizing“ hat jede Organisation den Mandanten als übergeordnete Organisation oder ist der Mandant selbst. Die Auflösung erfolgt demnach zweistufig. Für organisationsspezifische Funktionen wird zuerst für die angegebene Organisation überprüft, ob Daten vorhanden sind. Wenn nicht, werden die Daten des Mandanten verwendet.

4                     Funktionsweise der Anwendung „Customizing“

Im Customizing werden so genannte Funktionen, bezogen auf ein System oder auf eine Organisation, aktiviert oder deaktiviert, sowie funktionsspezifische Parameter eingestellt. Im Unterschied zu anderen Anwendungen werden die einzelnen Objekte (hier: Funktionen) nicht über den Identifikationsbereich ausgewählt und dann geladen, sondern über eine Liste im Navigationsbereich ausgewählt. Ein weiterer wesentlicher Unterschied besteht darin, dass immer alle Objekte gleichzeitig gespeichert werden. Es können also mehrere Objekte geändert werden und dann abschließend alle Änderungen gleichzeitig durch Drücken des Buttons „Speichern“ in der Standardsymbolleiste werden.

4.1               Durch Funktionen deaktivierbare Anwendungen oder Frameworks

Sowohl in dem Entwicklungsobjekt Framework als auch im Entwicklungsobjekt Anwendung kann eine Funktion eingetragen werden. Ist diese Funktion in der Anwendung „Customizing“ deaktiviert oder liegt die für die Funktion notwendige Lizenz zum eingetragenen Lizenzschlüssel nicht vor, so wird die entsprechende Anwendung oder das Framework deaktiviert, insbesondere ist sie/es auch nicht mehr sichtbar. Ist ein Framework zwar nicht deaktiviert, aber alle Anwendungen darin sind deaktiviert, so ist das Framework auch nicht sichtbar.

4.2               Durch Funktionen parametrisierbare Anwendungen

Funktionen können Parameter besitzen, die in den Anwendungen abgefragt werden können. Dadurch kann das Verhalten der Anwendung oder die Menge der sichtbaren bzw. aktiven Elemente durch die bei den Funktionen in Form von Einstellungen und Werten hinterlegten Parameter oder über das Aktivieren bzw. Deaktivieren der Funktion gesteuert werden.

4.3               Das Entwicklungsobjekt Funktion

Eine detaillierte Beschreibung des Entwicklungsobjektes Funktion finden Sie in der Dokumentation Entwicklungsobjekte. In diesem Dokument werden nur die wichtigsten Eigenschaften für die Entwicklung von neuen Funktionen in der Anwendung Customizing dargestellt.

In der Anwendung „Entwicklungsobjekte“ werden Objekte vom Typ Funktion erfasst. Die einzelnen Felder eines Funktionsobjektes sind wie folgt

4.4               Die Anwendung Customizing

Eine detaillierte Beschreibung der Anwendung „Customizing“ findet sich in der Dokumentation Customizing. Im Folgenden werden nur technische Details beschreiben, deren Kenntnis für die Softwareentwicklung notwendig ist.

4.4.1          Identifikationsbereich

Im Identifikationsbereich gibt es die folgenden Felder:

4.4.2          Arbeitsbereich

Der Arbeitsbereich ist durch zwei Karteireiter aufgeteilt:

• Einstellungen
• Informationen

Der Karteireiter „Einstellungen“ enthält die Eingabefelder für die Parameter der Funktion, die gerade bearbeitet wird. Der Karteireiter „Informationen“ enthält allgemeine Daten über die Funktion, die nicht veränderbar sind. Die Inhalte der Karteireiter und die Felder werden im Folgenden detailliert beschrieben.

4.4.3          Karteireiter Einstellungen

Die Felder im Karteireiter „Einstellungen“ sind spezifisch für jede Funktion und werden durch ein spezielles Entwicklungsobjekt Part und einem spezifischen Customizing-Editor, abgeleitet von der Klasse „com.cisag.pgm.base.CisCustomizingEditor“, festgelegt. In speziellen Fällen können Customizing-Zusatzdaten, die nicht im Part darstellbar sind, hinzukommen.

4.4.4          Karteireiter Informationen

Die folgenden Felder stehen unter dem Karteireiter „Informationen“ zur Verfügung:

Diese Informationen stehen für jede Funktion zur Verfügung und sind alle in der Anwendung „Customizing“ nicht änderbar.

4.5               Berechtigungen

Für die Anwendung „Customizing“ sind die anwendungsbezogenen Berechti-gungen relevant. Außerdem ist das folgende Business Entity für Berechtigungs-festlegungen für die Anwendung „Customizing“ relevant:

com.cisag.sys.kernel.obj.FunctionConfiguration

Spezielle Fähigkeiten oder Berechtigungen existieren für die Anwendung „Customizing“ nicht.

5                     Entwicklung

Dieses Kapitel beschreibt die Entwicklung und Einbindung von neuen Funktionen in die Anwendung „Customizing“.

Um eine neue Funktion in die Anwendung „Customizing“ einzufügen müssen vier Schritte unternommen werden:

• Ein Entwicklungsobjekt vom Typ Funktion erfassen
• Ein Entwicklungsobjekt vom Typ Part erfassen
• Ein Entwicklungsobjekt vom Typ Java-Klasse für den Customizing-Editor erfassen und implementieren

Die Schritte „Entwicklungsobjekt Part erfassen“ und „Erstellen eines Customizing-Editors“ können entfallen, wenn die Funktion nicht parametrisierbar ist.

Die einzelnen Schritte werden in den folgenden Kapiteln detailliert beschrieben.

5.1               Entwicklungsobjekt Funktion erfassen

Grundvoraussetzung einer neuen Funktion ist ein Entwicklungsobjekt Funktion. Dieses muss immer als erstes angelegt werden.

5.2               Entwicklungsobjekt Part erfassen

Für den Fall dass die Funktion parametrisierbar sein soll, muss ein Part angelegt werden, dass die Parameter aufnehmen kann. Dies ist auch dann notwendig, wenn eigentlich alle Daten als Customizing-Zusatzdaten abgelegt werden sollen.

Hinweis:

Aus dem angelegten Entwicklungsobjekt müssen mit dem Tool „crtjob“ die zugehörigen Java-Klassen erzeugt werden.

Für die generische Löschprüfung, d.h. die Prüfung ob bestimmten Objekte noch in Customizing-Daten verwendet werden, müssen die Beziehungen am Part korrekt angegeben werden.

5.3               Erstellen eines Customizing-Editors

5.3.1          Die Klasse „CisCustomizingEditor“

Um die Daten für eine Konfigurationsfunktion zu erfassen, muss ein Customizing-Editor erstellt werden, für den es eine eigene Basisklasse gibt: com.cisag.pgm.base.CisCustomizingEditor. Um die Anzahl der Instanzen dieser Klasse gering zu halten und die Startzeit beim Öffnen der Anwendung zu begrenzen, verwaltet die Anwendung „Customizing“ intern alle Daten. Der Customizing-Editor dient nur der Prüfung und der Anzeige der Daten für eine Funktion und einen Organisation. Der Customizing-Editor ist zustandslos, insbesondere kann dieselbe Instanz nacheinander für unterschiedliche Organisationen aufgerufen werden. Deshalb ist das Zwischenspeichern von Daten zwischen Aufrufen von Methode des Customizing-Editors in Instanzvariablen nicht sinnvoll möglich und kann zu Inkonsistenzen in den Daten führen. Alle Daten müssen entweder im Part oder eventuell in den Customizing-Zusatzdaten gespeichert werden. Ein Customizing-Editor kann in zwei Ausbaustufen erstellt werden:

• Verwaltung der Daten des Parts
• Verwaltung zusätzlicher Daten, der Customizing-Zusatzdaten

Hinweis:
Wenn Customizing-Zusatzdaten verwaltet werden sollen, muss die Funktion mindestens parametrisierbar sein und das Part muss erfasst werden, selbst wenn das Part keine Daten enthält. In diesem Fall muss das Part mindestens ein Attribut enthalten.

Alle Aufrufe von Methoden des Customizing-Editors aus der Anwendung „Customizing“ heraus erfolgen in einer gültigen Transaktion. Diese Transaktion wird abhängig von der Benutzeraktion und dem Ergebnis der Prüfung mit „commit“ oder „rollback“ abgeschlossen.

5.3.2          Erstellen eines Customizing-Editors

Um einen Customizing-Editor zu implementieren werden in der Regel die folgenden Methoden der Basisklasse überschrieben:

init

initUserInterface

dataToUi

dataFromUi

validate

validateDeactivate

Methode „init“

Die Methode „init“ dient der generellen Initialisierung. Üblicherweise sollten in der Methode „init“ die Logik-Objekte und Validation-Objekte erzeugt werden, die der Customizing-Editor benötigt. Am Customizing-Editor müssen nach der Initialisierung die Methoden „validate“ und „validateDeactivate“ aufgerufen werden können

Methode „initUserInterface“

Die Oberflächenelemente des Customizing-Editors werden in der Anwendung „Customizing“ durch Aufruf der Methode „initUserInterface“ nur bei Bedarf initialisiert, also insbesondere nur dann, wenn der Customizing-Editor Daten anzeigen muss. Hierdurch wird erreicht, dass die Prüfungen der Customizing-Daten auch bei Zugriffen die außerhalb von Dialog-Anmeldungen erfolgen, z.B. bei Datenaktualisierungen oder in Update-Programmen, zugreifbar sind. Es muss bei der Implementierung also beachtet werden, dass die Oberflächenelemente unter Umständen nicht erzeugt worden sind.

In der Methode werden alle Oberflächenelemente erstellt und als Referenzen in Instanzvariablen gehalten. Der erforderliche Container kann per

View view = getView();

abgefragt werden, standardmäßig ist ein zweispaltiges Standardlayout gesetzt. Normalerweise werden noch Insets mit

view.setDefaultMargin(VisualElementContainer.INSETS_ALL);

gesetzt. Die GUI-Felder werden dem View nach dem Erzeugen mit „add“ hinzugefügt. Anschließend werden die Message-Ids für die Fehlermeldungen der Prüfungen gesetzt. Wie auch in anderen Anwendungen geschieht dies durch Aufruf von „registerMessage(…)“ an den GUI-Feldern.

Methode „dataToUi“

Diese Methode wird von der Anwendung „Customizing“ aufgerufen wenn die Daten in die Oberflächenelemente übertragen werden müssen. Liefert der Aufruf der Methode „isEnabled()“ den Wert „false“ zurück, müssen die GUI-Felder geleert werden, in allen anderen Fällen dürfen die Werte in den GUI-Feldern angezeigt werden. Der Datencontainer mit den zu übertragenden Daten kann per Aufruf von

<Part>Mutable part = (<Part>Mutable) getData();

erhalten werden. Nach dem Auffüllen der Daten müssen die GUI-Felder noch auf aktiv/nicht aktiv („enabled“) und editierbar/nicht editierbar („editable“) gesetzt werden, in Abhängigkeit von dem Ergebnis des Methodenaufrufs „isEnabled()“ bzw. „isEditable()“. Am einfachsten geschieht dies durch Aufruf von

setVisualElementProperties(VisualElement[]);

wobei ein Array aller GUI-Felder übergeben wird.

Methode „dataFromUi“

In dieser Methode Werte müssen aus den GUI-Feldern ausgelesen und in das Part gesetzt werden.

Methode „validate“

Die Methode „validate“ dient der Überprüfung der Konsistenz der Daten. Sie wird für jede Kombination von Funktion und Organisation aufgerufen, für die es Daten geben kann und die Funktion aktiv ist. Die Message-Group, die für die Prüfung verwendet wird muss von der Basisklasse durch den Aufruf der Methode „getMessageGroup()“ bestimmt werden, damit die Positionierung auf den Fehler korrekt funktioniert. Wenn keine Abhängigkeitsprüfung notwendig ist, kann die Prüfung für vom Mandanten geerbte Daten übersprungen werden. Ob Daten lediglich durch Vererbung vom Mandanten vorliegen kann durch Aufruf der Methode „isDataInherited()“ geprüft werden.

Die Korrektheit der Daten wird vom Vorhandensein von Fehlermeldungen abhängig gemacht.

Methode „validateDeactivate“

Diese Prüfung wird aufgerufen, wenn die Funktion für die entsprechende Organisation deaktiviert werden soll oder sie bereits deaktiviert ist. Falls die Funktion in einem bestimmten Kontext nicht oder nicht mehr deaktiviert sein darf, muss in dieser Methode eine entsprechende Fehlermeldung gesendet werden.

5.3.3          Customizing-Editor mit Customizing-Zusatzdaten

Wenn der Customizing-Editor mehr Daten benötigt, als im Part abgelegt werden können, so kann dies mit Customizing-Zusatzdaten erfolgen. Diese Zusatzdaten können Zustandinformation oder Daten aus anderen Tabellen aufnehmen.

Achtung:

Selbst wenn nur Zusatzdaten benötigt werden, muss die Funktion mindestens parametrisierbar sein und das Part muss erfasst werden, selbst wenn das Part keine Daten enthält.

Soll der Customizing-Editor mit Customizing-Zusatzdaten arbeiten so werden im Allgemeinen die folgenden Methoden der Klasse „CisCustomizingEditor“ zusätzlich überschrieben:

Methode „loadAdditionalData“

Diese Methode wird beim Laden der Daten für jede mögliche Konstellation aufgerufen. Ist z.B. die Funktion für alle Organisationen vom Organisationstrukturtyp Lagerlogistik registriert, so wird die Methode für jede Organisation vom Organisationsstrukturtyp Lagerlogistik aufgerufen.

Werden Customizing-Zusatzdaten für eine Kombination benötigt, so muss die Methode „setAdditionalData“ aufgerufen werden. Dabei werden ein Datencontainer und sein Backup registriert. Nur wenn die Methode „setAdditionalData“ aufgerufen wurde, werden im weiteren Verlauf auch die anderen Methoden für Customizing-Zusatzdaten aufgerufen.

Methode „duplicateAdditionalData“

Diese Methode wird aufgerufen, wenn das erste Mal der Schalter „Mandantendaten verwenden“ deaktiviert wird. Die Mandantendaten werden als Vorlage übergeben.

Methode „clearAdditionalData“

Der Customizing-Editor muss die Customizing-Zusatzdaten in den Ausgangstand versetzen.

Methode „isAdditionalDataChanged“

Damit kann die Anwendung „Customizing“ bestimmen, ob Customizing-Zusatzdaten geändert wurde. Nur geänderte Daten werden gespeichert.

Methode „updateAdditionalData“

In dieser Methode können die Customizing-Zusatzdaten gespeichert werden.

Methode „deleteAdditionalData“

Wenn eine Funktion deaktiviert wird, muss der Inhalt der Customizing-Zusatzdaten in der Datenbank gelöscht werden. In dieser Methode muss das Löschen implementiert werden.

Methode „boolean isSupportedOrganization(CisOrganizationInfo info)“

Diese Methode liefert den Wert „true“ zurück, wenn die ausgewählte Organisation einen Organisationsstrukturtyp hat, der bei der Funktion verfügbar ist. Falls der Organisationsstrukturtyp nicht bei der Funktion gibt, können die Daten für diese Funktion bei der ausgewählten Organisation nicht erfasst werden. Wenn es andere oder komplexere Kriterien als den Organisationsstrukturtyp gibt, kann die entsprechende Logik hier implementiert werden.

Methode „boolean isDataInherited(CisOrganizationInfo ouInfo)“

Werden Zusatzdaten für den Mandanten geändert, so müssen diese für alle die Organisationen repliziert werden, die ihre Zusatzdaten vom Mandanten erben. Mit dieser Methode kann für eine beliebige Organisation überprüft werden, ob diese ihre Customizing-Daten erbt oder nicht.

5.4               Organisationsbezug  erfassen

Für Funktionen, die einen Customizing-Editor haben sollen oder parametrisierbar sind, erfassen Sie die Organisationsbezüge unter der Rubrik „Organisationsbezug“. Falls eine Funktion  nur für die gesamte OLTP-Datenbank gelten muss, ist es nicht notwendig, den Organisationsbezug zu erfassen, da diese Funktion standardmäßig für die ganze OLTP-Datenbank gilt.

Hinweis: Ab Semiramis 5.0 benötigen Sie nicht mehr die Einträge bei der Klasse „com.cisag.app.customizing.log.FunctionRegistry“ zu erfassen.

5.5               Fremdgesteuerte Funktionen

Ein Customizing-Editor hat die Möglichkeit, das Aktivkennzeichen anderer Funktionen zu steuern. Diese fremdgesteuerten Funktionen dürfen nicht parametrisierbar sein, müssen deaktivierbar sein, dürfen nicht angezeigt werden, müssen dieselben Organisationsstrukturtypen unterstützen wie die Funktion des Customizing-Editors und dürfen von keiner anderen Funktion fremdgesteuert werden.

Den Wert des Kennzeichens „Aktiv“ der fremdgesteuerten Funktion darf der Customizing-Editor nicht selbst speichern, also insbesondere nicht in seinem Part speichern.

Methode String [] getManagedFunctionNames()

Die Methode muss überschrieben werden wenn der Customizing-Editor die Steuerung für andere Funktionen übernehmen soll. Die Funktionsnamen werden durch die Anwendung „Customizing“ bei der Initialisierung abgefragt. Es müssen die voll qualifizierten Namen der zu steuernden Funktionen zurückgegeben werden.

Methode boolean isManagedFunctionActivated( String name )

Die Methode liefert „true“ wenn die Funktion mit dem gegebenen Namen aktiviert ist. Diese Methode wird typischerweise in der Methode „dataToUi“ aufgerufen.

Methode setManagedFunctionActivated( String name, boolean activated )

Die Methode setzt den Status der entsprechenden Funktion auf den Wert des Parameters „activated“. Diese Methode wird typischerweise in der Methode „dataFromUi()“ aufgerufen.

5.6               Customizing-Daten abfragen

In manchen Anwendungen muss das Vorhandensein gewisser Funktionen getestet werden bevor gewisse Aktionen in der Anwendung möglich oder erlaubt sind. Für die Abfrage von System-Funktionen und OLTP-Funktionen stehen Methoden an drei PGM-Schnittstellen zur Verfügung. Für den Zugriff auf die PGM-Schnittstelle „com.cisag.pgm.appserver.CisSystemManager“ existiert zudem die Klasse „com.cisag.app.customizing.Customizing“, die für die meisten Funktionen direkte Zugriffsmethoden zur Verfügung stellt, um den Zugriff zu vereinfachen.

5.6.1          PGM-Schnittstellen

• cisag.pgm.appserver.CisSystemManager
  Für den Zugriff aus normalen Anwendungen und Logikklassen heraus.
• cisag.pgm.base.CisUpdateBase
  Für den Fall, dass eine Update-Klasse für ein Business Object Customizing-Daten abfragen muss, müssen die Methoden direkt an der Klasse „com.cisag.pgm.base.CisUpdateBase“ aufgerufen werden. Update-Klassen erweitern die Klasse „CisUpdateBase“ spezifisch für ein Business-Objekt.
• cisag.pgm.base.UpdateApplication
  Für den Fall dass eine Datenaktualisierung Konfigurationsdaten der Anwendung „Customizing“ abfragen muss, müssen die Methoden direkt an der Klasse „com.cisag.pgm.base.UpdateApplication“ aufgerufen werden. Datenaktualisierungen erweitern die Klasse „UpdateApplication“

Im allgemeinen Fall einer (Hintergrund- oder Dialog-) Anwendung müssen die Methoden an der Klasse „CisSystemManager“ aufgerufen werden. Eine Instanz des Schnittstelle „CisSystemManager“ erhält man durch Aufruf von:

CisEnvironment.getInstance().getSystemManager();

Für eine konkrete Funktion können zwei Dinge abgefragt werden. Zum einen ob die gewünschte Funktion überhaupt zur Verfügung steht durch den Aufruf von „isAvailable()“, zum anderen das dazugehörige Konfigurationsobjekt durch den Aufruf der Methode „getConfiguredValues()“.

Je nach Ebene der Funktion (System, OLTP oder Organisation) muss beim Aufruf der Methoden die Organisation bei organisationsspezifischer Pflege als zweiter Parameter angegeben werden, oder eben nicht bei System- oder OLTP-Datenbank-weiten Funktionen. Wird die GUID einer Organisation angegeben obwohl die Funktion auf Systemebene (oder OLTP-Ebene) verwaltet wird, so wird eine Exception geworfen. Wird keine GUID angegeben obwohl die Funktion auf Organisationsebene verwaltet wird, wird ebenfalls eine Exception geworfen.

Bevor die Customizing-Daten für eine Funktion abgefragt werden, sollte immer geprüft werden, ob die Funktion überhaupt verfügbar ist. Wenn die Funktion deaktiviert, nicht lizenziert oder nicht konfiguriert ist, wird eine Exception geworfen, wenn die Daten trotzdem abgefragt werden.

Beispiel:

CisSystemManager sm;
sm = CisEnvironment.getInstance().getSystemManager();

if (sm.isAvailable(“com.cisag.app.Example”){

Values values;

values = (Values)

sm.getConfiguredValues((“com.cisag.app.Example”);

}

Für die Abfrage der Customizing-Daten gibt es die folgenden Methoden an jeder der oben angeführten Klassen:

• isAvailable(String function)
  Abfrage der Verfügbarkeit für eine System-Funktion oder eine Organisations-unabhängige OLTP-Funktion.
• isAvailable(String function, byte[]organizationGuid)
  Abfrage der Verfügbarkeit für eine Organisations-abhängige OLTP-Funktion
• getConfiguredValues(String function)
  Abfrage der Konfigurationsdaten für eine System-Funktion oder eine Organisations-unabhängige OLTP-Funktion.
• getConfiguredValues(String function, byte[]organizationGuid)
  Abfrage der Konfigurationsdaten für eine Organisations-abhängige OLTP-Funktion.

5.6.2          Die Klasse „Customizing“

Die Klasse „com.cisag.app.customizing.Customizing” ist eine Sammlung von Methoden, die die Zugriff auf die im vorangegangenen Abschnitt beschriebenen PGM-Schnittstellen für einzelne Funktionen kapseln. Die Vorteile der Verwendung diese Klasse sind:

• Vereinfachung der Verwendung durch konkret typisierte Schnittstellen für jede Funktion.
• Geringere Fehleranfälligkeit bei der Verwendung durch Prüfungen zur Compile-Zeit. Die Namen von Funktionen stehen nur an einer Stelle im Java-Source.
• Indirekter Verwendungsnachweis für die Verwendung von Funktionen auf Grundlage der Verwendung der Zugriffsmethoden.

Im Application-Code sollte daher bevorzugt diese Klasse für den Zugriff auf die Customizing-Daten verwendet werden.

Nachfolgend ein Ausschnitt aus der Implementierung der Klasse:

/**

* Returns the configured value of <tt>com.cisag.app.General</tt>.

*

* @return The value, not <code>null</code>.

*/

public static com.cisag.app.customizing.obj.GeneralMutable

getGeneral() {

return (com.cisag.app.customizing.obj.GeneralMutable)

getConfiguredValues(“com.cisag.app.General”);

}

/**

* Returns whether or not <tt>com.cisag.app.Sales</tt>

* is available for specified sales organization.

*

* @return <code>true</code> if the function is available.

*/

public static boolean isSalesAvailable(byte[] salesOrganization) {

return isAvailable(“com.cisag.app.Sales”,

maintainingSales(salesOrganization));

}

6                     Spezielle Szenarien und deren Lösungen

6.1               Anwendungen mit mehreren Lizenzschlüsseln und Funktionen

Es gibt Anwendungen die vom Vorhandensein mehrerer Lizenzschlüssel abhängen sollen. Wird die Anwendung über eine Funktion „eins“ aktiviert (bzw. deaktiviert), so kann hier nur ein Lizenzschlüssel angegeben werden. Um die Abhängigkeit von einem weiteren Lizenzschlüssel zu modellieren, wird eine Abhängigkeit der Funktion „eins“ von einer weiteren Funktion „zwei“ erfasst. Diese Funktion „zwei“ ist dann von dem zweiten Lizenzschlüssel abhängig. Beide Funktionen werden als nicht sichtbar, nicht parametrisierbar und nicht deaktivierbar erfasst. Damit ist die Anwendung automatisch nur aktiviert wenn beide Lizenzschlüssel in der Lizenz frei geschaltet sind.

6.2               Komplexe Bedingungen für die Verfügbarkeitslogik von Funktionen

Es gibt Anwendungen bei denen das Kriterium für ihre Verfügbarkeit nicht nur einfach vom Vorhandensein anderer Funktionen oder Lizenzschlüssel abhängt. Wenn die Logik, wann eine Anwendung verfügbar sein soll, komplexer ist als es sich über die Metadaten abbilden läst, so ist dafür eine fremdgesteuerte Funktion zu verwenden. Die Funktion „eins“ hat einen Customizing-Editor in dem alle relevanten Daten erfasst werden die zur Entscheidungsfindung über die Verfügbarkeit notwendig sind. Die Funktion „zwei“ ist eine fremdgesteuerte Funktion, deren „Aktiv“-Kennzeichen durch den Customizing-Editor der Funktion „eins“ gesteuert wird. Für die Anwendung selbst wird dann die Funktion „zwei“ als erforderlich eingetragen. Aus der Sicht des Benutzers der Anwendung „Customizing“ ist die Funktion „zwei“ unsichtbar.