FirstSpirit Object Service - Administration und Konfiguration

Nach der erfolgreichen Installation des Moduls wurde die Liste der auf dem FirstSpirit-Server installierten Module in den Server-Eigenschaften um den Ordner UX-Bridge ergänzt. Klicken Sie nach der Selektion dieses Ordners auf Konfigurieren und aktivieren Sie in dem sich öffnenden Dialog die Checkbox Alle Rechte. Der UX-Bridge-Ordner wird nach der Bestätigung über OK mit einem Icon in der Form eines Vorhängeschlosses gekennzeichnet.

Klappen Sie anschließend den Ordner aus und selektieren Sie den Dienst UXBService, bevor Sie erneut auf Konfigurieren klicken. Wechseln Sie in dem sich öffnenden Dialog auf den Reiter Optionen und aktivieren Sie dort den Versand von Status- und Projekt Informationsnachrichten (vgl. Abbildung Konfiguration des UXBServices).

Informationen zu diesen Nachrichten erhalten Sie in der Dokumentation für Entwickler.

Abbildung 3. Konfiguration des UXBServices

Der Versand der Nachrichten für das Portal-Plugin erfolgt standardmäßig an:

activemq:topic:PORTAL-EVENTS

Dieser Endpunkt ist in der applicationContext.xml des FOS definiert:

<endpoint id="PORTAL-EVENTS" uri="acticemq:topic:PORTAL-EVENTS"> </endpoint>

Durch eine Veränderung dieses Eintrags kann ein neuer Endpunkt konfiguriert werden.

Die applicationContext.xml ist innerhalb des Ordners WEB-INF in der fos-service-<Versionsnummer>.war-Datei enthalten.

Der FOS benötigt die folgenden Einstellungen:

Wurden die Einstellungen bisher nicht definiert oder liegen sie unvollständig vor, werden sie beim Aufruf des FirstSpirit Object Service Admin Interfaces abgefragt.

Die Einstellungen werden in einer Java Properties-Datei hinterlegt. Sie müssen bei der ersten Verwendung des FOS angegeben werden, da sie von den lokalen Begebenheiten des Anwendersystems abhängig sind. Für die Generierung der Datei wird ein auf <Dateiname>.properties endender, absoluter Pfad erwartet.

Der FOS stellt ein Bindeglied zwischen FirstSpirit und dem Portal-Server dar. Er ermittelt anhand der an ihn übermittelten Nachrichten alle Änderungen am Datenbestand und gibt diese Informationen an das Portal-Plugin weiter. Für die Speicherung dieses Datenbestands verwendet der FOS einen Ordner, der ihm über einen absoluten Pfad mitzuteilen ist. Der Abruf der Nachrichten erfolgt über eine Verbindung, die der FOS zum UX-Bus aufbaut. Er benötigt daher den Host und den Port des UX-Busses.

Die REST-Schnittstelle des FOS erwartet bei jedem Aufruf einen http-Header namens apikey. Sein Wert muss eine UUID sein, die dem FOS in Form eines API-Keys bekannt ist. Andernfalls endet eine Anfrage mit dem Status 401 Unauthorized. Mit den verschiedenen Keys werden Zugriffsrechte auf Projekte über die REST-Schnittstelle durchgesetzt. Für die Speicherung der API-Keys verwendet der FOS eine bin-Datei, die er bei der Erzeugung des ersten API-Keys anlegt und die ihm über einen absoluten Pfad zur Verfügung gestellt werden muss.

Nach der Generierung der Einstellungsdatei muss diese der Web-Applikation bekannt gemacht werden. Dies kann über drei mögliche Wege geschehen:

Die Erweiterung der web.xml erfolgt über das Hinzufügen eines Context-Parameters oder eines Environment-Entries:

<context-param>
	<param-name>FOS_SETTINGS_FILE</param-name>
	<param-value>PATH OF THE SETTINGS FILE</param-value>
</context-param>

oder:

<env-entry>
	<env-entry-name>FOS_SETTINGS_FILE</env-entry-name>
	<env-entry-type>java.lang.String</env-entry-type>
	<env-entry-value>PATH OF THE SETTINGS FILE</env-entry-value>
</env-entry>

Diese können auch in der context.xml hinzugefügt werden. Die dafür notwendigen Schritte werden unter folgendem Link erläutert:

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Context_Parameters

Das Logging der Web-Application ist im ausgelieferten Zustand auf INFO gestellt. Werden weitere Details benötigt, muss in der Datei log4j.properties (im Ordner der Web-Application unter WEB-INF → classes zu finden) die Zeile log4j.rootLogger=INFO, file auf den Ausdruck log4j.rootLogger=DEBUG, file geändert werden.

Zusätzlich zum allgemeinen Logging werden noch Informationen über Laufzeiten gesichert. Diese werden standardmäßig in einer eigenen Datei metrics.log im Logging-Verzeichnis des Web-Application-Servers abgelegt. Des Weiteren werden die Informationen auch per jmx bereitgestellt.

Änderungen an der Laufzeitmessung können in der Datei applicationContext.xml (im Ordner der Web-Application unter WEB-INF zu finden) vorgenommen werden. Um beispielsweise die Frequenz der Messungen zu ändern, muss im folgenden Abschnitt der Wert period verändert werden.

<metrics:reporter type="slf4j" metric-registry="metrics" period="1m" logger="com.espirit.moddev.fos.logger.metrics”/>

Voreingestellt ist hier 1m für eine Messung pro Minute.

Werden weiter Informationen über die Laufzeitmessungen benötigt, können diese unter folgenden Links nachgelesen werden:

https://github.com/ryantenney/metrics-spring

https://dropwizard.github.io/metrics/3.1.0/manual/core/

Besteht der Wunsch, mehrere FOS-Instanzen parallel auf einem Web-Application-Server zu betreiben, so ist dies problemlos möglich. Die initial auf dem Server eingebundene Applikation (vgl. Kapitel FirstSpirit Object Service (FOS)) muss dafür lediglich entsprechend der gewünschten Anzahl von Instanzen kopiert werden.

Für jede der dann existierenden Instanzen wird eine eigene context.xml benötigt, die an einer globalen Stelle auf dem Web-Application-Server abzulegen und wie die zugehörige FOS-Instanz zu benennen ist. Für einen Tomcat-Server entspräche der Ablageort der context.xml-Dateien beispielsweise dem folgenden Pfad:

<Tomcat-Verzeichnis>/conf/Catalina/<HOST>/<FOS-INSTANZ>.xml

Die Dateien dienen zur Angabe des Pfads der Einstellungsdatei für das FirstSpirit Object Service Admin Interface und benötigen daher folgenden Inhalt:

<?xml version="1.0" encoding="UTF-8"?>
<Context>
	<Parameter name="FOS_SETTINGS_FILE"
	value="PFAD ZUR EINSTELLUNGSDATEI" override="true" />
</Context>

Innerhalb des Auftrags muss zunächst eine Initialisierung erfolgen. Dabei wird ein sogenannter MessageGenerator benötigt, der die Nachrichten erzeugt, die vom FirstSpirit-Server an den UX-Bus übermittelt werden.

Über den folgenden Skriptaufruf wird in der ersten Aktion des Auftrags der durch das FOS-Modul bereitgestellte Standard-MessageGenerator hinzugefügt:

Initialize FOSGeneration. 

#! executable-class
com.espirit.moddev.fos.util.FosScheduleInitializer

Soll ein eigener MessageGenerator verwendet werden, so kann dieser als Parameter MessageGenerator in den Skript-Eigenschaften hinzugefügt werden.

Weitere Informationen zum MessageGenerator sind im UX-Bridge-Entwicklerhandbuch enthalten.

Fügen Sie als zweite Aktion des Auftrags ein weiteres Skript hinzu, das den folgenden Aufruf enthält:

Activate Generation. 

#! executable-class
com.espirit.moddev.uxbridge.inline.UxbInlineUtil

Der Aufruf aktiviert die im nächsten Schritt durchzuführende Generierung, die ohne diese Aktivierung nicht durchführbar ist. Der Aufruf ist somit zwingend notwendig für eine erfolgreiche Generierung.

Die in der vorhergehenden Aktion aktivierte Generierung wird durch die Aktion Generate ausgeführt.

In den Eigenschaften der Generierung ist ein beliebiger Name anzugeben und die Option Generierungsverzeichnis vorher leeren auszuwählen (vgl. Abbildung Generierung - Eigenschaften). Die Option Generieren nur wenn erforderlich darf hingegen nicht aktiviert sein.

Abbildung 9. Generierung - Eigenschaften

Im Register Erweitert muss für eine Sprache des Projekts der zuvor angelegte Ausgabekanal ausgewählt werden (siehe Abbildung Generierung - Erweitert).

Abbildung 10. Generierung - Erweitert

Die Aktion Result Handler ist eine Funktion zur Fehlererkennung. Sie ermöglicht die Feststellung von Fehlern während der Zustellung der erzeugten Nachrichten und Event-Nachrichten.

Legen Sie hierfür ein weiteres Skript an und fügen Sie diesem den folgenden Skriptaufruf hinzu:

Result Handler. 

#! executable-class
com.espirit.moddev.uxbridge.inline.UxbResultHandler

Öffnen Sie anschließend die Eigenschaften des Skripts und legen Sie über Hinzufügen die folgenden Parameter an (vgl. Abbildung Eigenschaften des Skripts):

Abbildung 11. Eigenschaften des Skripts

Der Wartungsmodus wird im Fehlerfall somit nur genau dann verlassen, wenn eine Vollgenerierung durchgeführt wurde, der Parameter disableMaintenanceWithErrors den Wert true besitzt und die Anzahl der aufgetretenen Fehler und Warnings den über den Parameter errorThreshold definierten Schwellwert nicht überschreitet.

Die optionale Aktion Configure UXB Message Header stellt die Möglichkeit bereit, den von FirstSpirit an den UX-Bus versandten Nachrichten beliebige weitere Root-Attribute hinzuzufügen.

Für die Erzeugung der Root-Attribute muss dem Generierungsauftrag als erste Aktion ein Skript mit dem folgenden Inhalt hinzugefügt werden:

Configure UXB Message Header. 

import java.util.HashMap;

attributeMap = new HashMap();
attributeMap.put("customAttribute1", "customAttributeValue1");
attributeMap.put("customAttribute2", "customAttributeValue2");

context.setProperty("uxbMessageRootAttributes", attributeMap);

Das Skript erzeugt eine HashMap, in der die gewünschten Attribute in Form von Key/Value-Paaren definiert werden können. Diese werden sowohl in die Kommunikation zwischen dem FirstSpirit-Server und dem UX-Bus als auch in die vom FOS versandten Event-Nachrichten übernommen.

Informationen zur Definition von Root-Attributen finden Sie auch im UX-Bridge Entwicklerhandbuch.

Nur wenn das Portal-Plugin auch über potentielle Änderungen an Inhalten informiert werden soll, muss dem Auftrag das folgende Skript als erste Aktion hinzugefügt werden. Andernfalls kann es ignoriert werden.

Activate HTML Generation. 

import de.espirit.firstspirit.access.schedule.DeploymentUtil;

deltaGeneration = DeploymentUtil.createDeltaGeneration(context);
deltaGeneration.levelRule(0, 0).levelRule(1,1).levelRule(2,2);
changeSet = deltaGeneration.calculateChangeSet();
changeSet.configureGenerateTask();

Das Skript ermittelt die vorgenommenen inhaltlichen Änderungen und aktiviert die im nächsten Schritt durchzuführende HTML-Generierung. Ohne diese Aktivierung kann die Generierung nicht erfolgreich durchgeführt werden. Sie ist daher (auf Basis der genannten Voraussetzung) zwingend notwendig.

Die mit dieser Aktion auszuführende Generierung wird nur dann benötigt, wenn das Portal-Plugin auch über potentielle Änderungen an Inhalten informiert werden soll. Sie muss zunächst aktiviert werden und daher zwingend auf die vorhergehende Aktion Activate HTML Generation folgen.

Im Register Erweitert muss für alle Projektsprachen der HTML-Kanal ausgewählt werden (siehe Abbildung erweiterte Einstellungen der HTML-Generierung).

Abbildung 13. erweiterte Einstellungen der HTML-Generierung

In den Eigenschaften der Generierung ist ein beliebiger Name anzugeben und die Option Generierungsverzeichnis vorher leeren auszuwählen (siehe Abbildung Eigenschaften der HTML-Generierung).

Abbildung 14. Eigenschaften der HTML-Generierung

Die Aktion DeltaEventCollector muss auf die HTML-Generierung folgen, da sie die dabei generierten Inhalte erfasst. Dies geschieht über den folgenden Skriptaufruf:

DeltaEventCollector. 

#! executable-class
com.espirit.moddev.fos.util.FosDeltaEventCollector

Der EventCollector wird nur dann benötigt, wenn das Portal-Plugin auch über potentielle Änderungen an Inhalten informiert werden soll. Andernfalls kann auf diese Aktion verzichtet werden.

Die Aktion Calculate Changes ermittelt die seit der letzten Generierung durchgeführten Änderungen innerhalb des verwendeten FirstSpirit-Projekts. Des Weiteren konfiguriert sie die nachfolgende Generierungsaktion so, dass für eine Aktualisierung des FOS lediglich eine minimale Anzahl von Nachrichten an diesen versandt wird. Wurden keine Änderungen festgestellt, so wird der Auftrag an dieser Stelle abgebrochen.

Es ist daher zwingend notwendig, dass die Aktion nach der Initialisierung und vor der Generierung ausgeführt wird.

Die Ermittlung der vorgenommenen Änderungen sowie die Übermittlung der notwendigen Informationen an die Generierungsaktion erfolgt über die folgenden, in ein Skript einzufügenden Zeilen:

Calculate Changes. 

import com.espirit.moddev.fos.generation.*;

deltaGeneration = DeploymentUtil.createFosDeltaGeneration(context);
FosDeltaGeneration.ChangeSet changeSet = deltaGeneration.calculateChangeSet();
generateTaskConfigurator = GenerateTaskConfigurator.getInstance(context, changeSet);

generateTaskConfigurator.configureGenerateTask(true);

Der dem configureGenerateTask-Aufruf übergebene boolean-Wert steuert, ob nach Änderungen an Templates auch eine Generierung der auf ihnen basierenden Seiten ausgelöst werden soll. Ist dies nicht gewünscht, muss der Wert von true auf false geändert werden.

Die Aktion Remove Delete Nodes informiert den FirstSpirit Object Service über die in FirstSpirit gelöschten Elemente. Dies geschieht über folgenden Skriptaufruf:

Remove Deleted Nodes. 

import com.espirit.moddev.fos.generation.DeploymentUtil;

DeploymentUtil.removeDeletedNodes(context);

Die Aktion DeltaEventGenerator wird nur dann benötigt, wenn das Portal-Plugin über potentielle Änderungen an Inhalten informiert werden soll. Andernfalls kann auf diese Aktion verzichtet werden.

Der EventGenerator verschickt die Nachrichten bezüglich der inhaltlichen Änderungen an den FOS. Dafür verwendet er die vom EventCollector ermittelten Informationen. Dies erfolgt über den folgenden Skriptaufruf:

Event Generator. 

#! executable-class

com.espirit.moddev.fos.util.FosDeltaEventGenerator

Die Erzeugung der Nachrichten durch den EventGenerator muss zwischen der FOS-Generierung und vor dem ResultHandler positioniert werden, damit die Informationen fehlerfrei durch den FOS verarbeitet werden können.

Die Aktion Finalize DeltaGeneration schließt die Deltagenerierung ab:

Finalize DelteGeneration. 

#! executable-class

com.espirit.moddev.fos.util.FosDeltaFinalizer

Der Schieberegler Maintenance Mode dient zur manuellen Aktivierung bzw. Deaktivierung des Wartungsmodus eines Projekts und besitzt daher die Zustände ON und OFF. Standardmäßig ist der Wartungsmodus deaktiviert und der Regler befindet sich im Zustand OFF.

Abbildung 18. Maintenance Mode

Befindet sich ein Projekt im Wartungsmodus, verschickt der FOS keine Event-Nachrichten und alle Anfragen des Portal-Plugins an die REST-Schnittstelle des FOS werden für dieses Projekt mit einer Retry later-Nachricht beantwortet. Es werden somit in dieser Zeit keine Daten dieses Projekts vom FOS an das Portal-Plugin ausgeliefert. Ein Zugriff auf die innerhalb der Persistenzschicht des FOS gespeicherten Projektdaten ist erst wieder nach der Deaktivierung des Wartungsmodus möglich.

Eine Änderung des Wartungsmodus kann auch automatisch durch eine Generierung erfolgen. Dabei muss zwischen einer Teil- und einer Voll-Generierung unterschieden werden.

Die manuelle Deaktivierung des automatisch durch FirstSpirit aktivierten Wartungsmodus‘ erzeugt eine Warnung mit einer Sicherheitsabfrage (siehe Abbildung Warning). Diese Sicherheitsabfrage bietet dem Administrator die Möglichkeit, den Wartungsmodus tatsächlich zu deaktivieren oder den Vorgang abzubrechen.

Abbildung 19. Warning

Mit der Deaktivierung des Wartungsmodus‘ nimmt der FOS den Versand der Event-Nachrichten für den restlichen Verlauf der Generierung wieder auf. Des Weiteren steht die REST-Schnittstelle erneut für Anfragen des Portal-Plugins zur Verfügung. Die an das Portal-Plugin übermittelten Informationen sind damit potentiell unvollständig oder auf einem Stand, der durch die laufende Generierung noch verändert wird. Es kann somit zu Inkonsistenzen kommen.

Weitere Informationen zum Wartungsmodus sind in der Dokumentation für Entwickler enthalten.

Ein Klick auf den Button Settings öffnet einen Dialog, in welchem projektspezifische Einstelllungen vorgenommen werden können.

MediaEvent mode

In den an das Portal-Plugin versandten Event-Nachrichten werden grundsätzlich alle Änderungen an FirstSpirit-Elementen erfasst. Eine Modifikation der vererbbaren Attribute eines Struktur-, Inhalte- oder Medien-Ordners hat jedoch nicht nur eine Auswirkung auf den Ordner selbst, sondern auch auf alle in ihm enthaltenen Elemente.

Für Struktur- und Inhalte-Ordner wird dieser Aspekt bereits über die generelle Struktur der Event-Nachrichten erfasst. Medien-Ordner stellen hingegen einen Sonderfall dar und erfordern daher eine besondere Behandlung. Diese wird über den Schieberegler MediaEvent mode definiert (siehe Abbildung aktivierter Inheritance mode).

Abbildung 20. aktivierter Inheritance mode

Nähere Information zur Vererbung erhalten Sie in der Dokumentation für Entwickler.

Ein Klick auf die Schaltfläche Clear Cache löscht alle für das Projekt vorhandenen Daten im FOS. Das Projekt und alle Einstellungen bleiben dabei erhalten.

Ein Klick auf die Schaltfläche Delete Cache entfernt den entsprechenden Eintrag aus der Liste der Projekte. Des Weiteren werden innerhalb des FirstSpirit Object Service Admin Interfaces alle Daten des Projektes unwiderruflich gelöscht. Das Projekt lässt sich anschließend nur über eine Voll-Generierung erneut in die Persistenzschicht des FOS übertragen.

Die Anwendung der Funktionalität macht genau dann Sinn, wenn das entsprechende Projekt zukünftig nicht mehr genutzt wird und es auch auf dem FirstSpirit-Server nicht weiter besteht. Einen solchen Fall stellen beispielsweise Test-Projekte dar.

Bei einer hohen Anzahl von API-Keys und Projekten kann es vorkommen, dass nicht alle API-Keys bzw. Projekte von Interesse sind und die Übersicht unnötig vergrößern. Um die API-Keys-Übersicht zu filtern, befinden sich über der Liste deshalb zwei Eingabekomponenten: Filter Projects und Show empty API-Keys.

Wenn ein Projekt in Filter Projects ausgewählt ist, werden API-Keys mit Rechten auf diesem Projekt in der Übersicht angezeigt. Andernfalls werden die entsprechenden API-Keys ausgeblendet.

Standardmäßig sind alle Projekte in Filter Projects ausgewählt, so dass die Übersicht alle API-Keys enthält, die auf mindestens einem Projekt Rechte besitzen. Dies bedeutet gleichzeitig, dass API-Keys, die auf keinem Projekt Rechte besitzen, standardmäßig nicht angezeigt werden. Aus diesem Grund gibt es die Schaltfläche Show empty API-Keys, mit der ebendiese Keys ein- bzw. ausgeblendet werden können.

Zum Anlegen eines neuen API-Keys existiert ein spezieller Dialog (siehe Abbildung Dialog zum Anlegen eines neuen API-Keys). Dieser wird durch einen Klick auf die Schaltfläche + Add API-Key aufgerufen.

Abbildung 22. Dialog zum Anlegen eines neuen API-Keys

Im oberen Teil des Formulars muss im Feld Description eine Beschreibung für den neuen API-Key eingetragen werden, um ihm einen fachlicher Bezug zu geben.

Initiale Projektrechte für den neuen API-Key werden im unteren Teil des Formulars erteilt. Hier befindet sich eine tabellarische Übersicht aller Projekte im Portalservice. Wird ein Kontrollkästchen in der linken Spalte dieser Liste ausgewählt, erhält der API-Key lesende Rechte auf das entsprechende Projekt. Administrative Rechte erhält er, wenn zusätzlich der Schieberegler in der rechten Spalte auf ON gesetzt wird.

Durch einen Klick auf Save werden die Formulardaten gespeichert und ein neuer API-Key generiert. Ein Klick auf Cancel bewirkt hingegen, dass alle Eingaben verworfen werden.

Da ein neu angelegter API-Key automatisch in die Übersicht einsortiert wird, öffnet sich nach dem erfolgreichen Anlegen ein weiterer Dialog, der dem Nutzer den neuen Key mitteilt (siehe Abbildung Bestätigungsdialog nach dem Anlegen eines API-Keys).

Abbildung 23. Bestätigungsdialog nach dem Anlegen eines API-Keys

Die Beschreibung eines API-Keys kann in der Übersicht editiert werden. Dazu reicht es aus, auf die Beschreibung zu klicken, um sie anschließend in der eingeblendeten Eingabekomponente zu bearbeiten (siehe Abbildung Editieren der Beschreibung eines API-Keys).

Abbildung 24. Editieren der Beschreibung eines API-Keys

Nachdem die Beschreibung überarbeitet wurde, kann sie durch einen Klick auf den blau hinterlegten Button mit dem Häkchen übernommen werden. Da die Beschreibung ein Pflichtfeld ist, wird das Speichern verweigert, solange das Textfeld leer ist. Um die Änderungen zu verwerfen, genügt ein Klick auf die zweite Schaltfläche.

Hinzufügen eines weiteren Projektes

Wenn ein API-Key für ein weiteres Projekt Rechte erhalten soll, kann in einem passenden Dialog ein Projekt ausgewählt werden (siehe Abbildung Hinzufügen eines weiteren Projektes). Dieser Dialog wird durch einen Klick auf die Schaltfläche + Add Project unter der Projektliste des entsprechenden API-Keys geöffnet.

Abbildung 25. Hinzufügen eines weiteren Projektes

Der Dialog enthält zwei Eingabekomponenten: Zunächst eine Auswahlliste, in der alle Projekte gelistet sind, für die der API-Key noch keine Rechte besitzt. Für das Projekt, das in dieser Liste ausgewählt wird, erhält der API-Key Rechte. Des Weiteren enthält der Dialog einen Schieberegler, mit dem administrative Rechte für das ausgewählte Projekt gesetzt werden können. Steht dieser Regler auf ON hat der API-Key administrative Rechte, andernfalls ausschließlich lesende.

Sobald ein Projekt in der Auswahlliste selektiert wurde, kann der Vorgang durch einen Klick auf Add fortgesetzt werden und die Rechte des API-Keys werden gemäß der Auswahl im Dialog ergänzt. Durch einen Klick auf Cancel wird der Dialog geschlossen und keine Änderungen am API-Key vorgenommen.

Administrative Rechte für ein Projekt setzen oder entfernen

Nachdem Rechte für ein Projekt zu einem API-Key hinzugefügt wurden, können nachträglich jederzeit administrative Rechte für dieses Projekt gesetzt oder entfernt werden. Dazu reicht es, in der Übersicht aller API-Keys den Schieberegler in der Spalte ADMIN RIGHTS des betroffenen Projektes umzuschalten. Steht der Regler auf ON, sind die administrativen Rechte gesetzt, andernfalls nicht.

Alle Rechte für ein Projekt entfernen

In der Projektliste jedes API-Keys befindet sich links neben jedem Projekt ein Button, der mit einem X beschriftet ist. Ein Klick auf diesen Button entzieht dem jeweiligen API-Key alle Rechte für das Projekt. Dies muss allerdings erst in einem Dialog bestätigt werden, der sich nach dem Klick automatisch öffnet (siehe Abbildung Entzug aller Rechte für ein Projekt).

Abbildung 26. Entzug aller Rechte für ein Projekt

Nach einem Klick auf OK werden dem API-Key die Rechte entzogen. Um sie wiederherzustellen, müssen sie manuell neu gesetzt werden. Ein Klick auf Cancel schließt den Dialog und der API-Key behält seine Rechte.

Ein API-Key kann unwiderruflich durch Betätigen der Schaltfläche mit dem grauen X links neben einem API-Key gelöscht werden. Zuvor öffnet sich allerdings ein Dialog, in dem der Benutzer aufgefordert wird, das Löschen des API-Keys zu bestätigen (siehe Abbildung Löschung eines API-Keys).

Abbildung 27. Löschung eines API-Keys

Das Löschen wird durch Klicken auf die Schaltfläche OK bestätigt. Anschließend ist der API-Key dauerhaft verloren und aus der Übersicht entfernt. Durch einen Klick auf Cancel wird der Vorgang stattdessen abgebrochen und der API-Key nicht gelöscht.