Die Perspektive Kommunikation, Nachrichten… umfasst die ASYS-Repositoryobjekte der Nachrichten, Kommunikationspartner und Kommunikationsjobs des ASYS-Kommunikationsservers. Die genannten Objektklassen sind global für alle Repository-Standorte gültig und nutzbar.
Die in dieser Perspektive konfigurierbaren Repository-Objekte sind:
Es wird unterschieden, ob der Kommunikationspartner ein anderer Standort ist oder der eigene Standort.
Der Tab-Reiter eines Kommunikationspartners besteht zuoberst aus zwei Abschnitt mit allgemeinen Angaben, an den sich darunter ein Tab-Reiter mit den Kommunikationsrechten anschließt:
Der Tab-Reiter des eigenen Standortes als Kommunikationspartners besteht nur aus dem obersten Abschnitt mit allgemeinen Angaben. Die Angaben zum eigenen Postfach werden beim Standort verwaltet (siehe hierzu den Standort), Kommunikationsrechte entfallen, da sie sich nicht sinnvoll konfigurieren lassen1).
Der Abschnitt Kommunikationspartner / Eigener Standort umfasst die Eigenschaften eines Standortes, der als Kommunikationspartner eingerichtet wird. Für diese Kommunikationspartner gilt: Der ASYS-Kommunikationsserver baut eine Verbindung mit einem Postfach der VPS der ZKS-Abfall auf und verschickt oder empfängt Nachrichten in das oder aus dem Postfach.
Format | Erläuterung |
---|---|
ASYS-intern | Der Kommunikationspartner sendet und empfängt Nachrichten im ASYS-internen XML-Format (eingepackt in ZIP-Archivdateien). |
BMU-XML | Der Kommunikationspartner sendet und empfängt Nachrichten im Format der BMU-XML-Schnittstelle. In den Empfangsordner des Kommunikationspartners mit diesem Nachrichtenformat werden aus einem Registerauszug extrahierte BMU-Dokumente abgelegt. |
Text-CSV | Der Kommunikationspartner sendet und empfängt Nachrichten in einem kommaseparierten3) Textformat |
Extern-XML | Der Kommunikationspartner sendet und empfängt Nachrichten in einem anderen XML-Format, als dem ASYS-internen- oder BMU-XML-Format. |
Nicht beim eigenen Standort!
Die ASYS-interne Kommunikation findet über die Virtuelle Postelle VPS der ZKS-Abfall statt. Hierzu werden ASYS-interne Nachrichten in das jeweilige Knotenstellenpostfach des Empfängerbundeslandes übermittelt. Das Postfach ist identifiziert durch die Behördliche Nummer (zzgl. Prüfziffer), unter der die Knotenstelle bei der ZKS-Abfall registriert ist.
Zum Postfach gehört außerdem der öffentliche Zertfikatsteil des Verschlüsselungszertifikats für den Postfachinhaber. Das Zertifikat wird über den Button Zertifikat auswählen zugewiesen. Das Zertifikat wird dazu über einen Standard-Dateiauswahldialog des Betriebssystem ausgewählt. Der Dateifilter ist auf die übliche Dateiendung *.cer für öffentliche Zertifikate eingestellt. Kann die zugewiesene Datei als Zertifikat identifiziert werden, so erscheint das Ablaufdatum der Zertifikatsgültigkeit im Feld Gültig bis5). Soll ein anderes Zertifikat zugewiesen werden, so ist ebenfalls der zuvor genannte Button zu verwenden. Soll dem Kommunikationspartner kein Zertifikat mehr zugewiesen sein, ist der Button Zertifikat lösen zu verwenden. Mit dem Button wird ausschließlich der Verknüpfung mit der Zertifikatsdatei gelöscht, die *.cer-Datei bleibt davon unberührt.
Achtung: Der hier vergebene Pfad auf diese Datei muss auf dem Kommunikationsrechner, auf dem der Kommunikationsserver läuft, auch auf die Zertifikats-Datei zeigen!
Der untere Teil des Bearbeitungsbereichs enthält einen Tab-Reiter.
Für die Kommunikation kann es notwendig sein, für jeden (externen) Kommunikationspartner zu bestimmen, welche Rechte dieser auf welchen (eigenen, lokalen) Daten hat. Einstellungen für Tabellen bzw. Views (Fachobjektemodellklassen) oder ihr Attribute sind nur notwendig, wenn Einschränkungen vorgenommen werden sollen. Nicht in den Kommunikationsrechten aufgeführte Klassen oder Attribute werden per Default uneingeschränkt im ASYS-Verbund versandt und empfangen.
Es werden die Rechte des jeweiligen Kommunikationspartners verwendet, mit dem die Kommunikation stattfindet. Bei einem Datenaustausch mit der Knotenstelle eines anderen Bundeslandes werden somit die bei dieser anderen Knotenstelle eingetragenen Rechte ausgewertet6).
Wichtig: Die Rechtevergabe kann hierarchisch erfolgen. Die Rechteeinstellung für ein Attribut hat eine höhere Priorität, als die Rechteeinstellung für die Kollektion aller Attribute einer Klasse. Diese wiederum sind höher in der Priorität, als die Rechteeinstellung nur für die Klasse.
Beispiel (Auszug aus der Standardkonfiguration):
Klasse/Attribut | Rechte | Erklärung | |||
---|---|---|---|---|---|
Lesen | Ändern | Einfügen | Löschen | ||
EFB.EFB Maengel | Ja | Ja | Nein | Nein | Mängel, Hinweise zu einem EFB-Zertifikat dürfen gelesen (=versandt) und geändert werden. Neu erstellen oder löschen ist nicht erlaubt. |
EFB.EBF Maengel.* | Ja | Nein | Nein | Nein | Sämtliche Einzelangaben/Attribute der Mängel, Hinweise dürfen nur gelesen, aber weder geändert, noch erstellt oder gelöscht werden. |
EFB.EFB Maengel.Fehlerschreibenrelevant | Ja | Ja | Ja | Ja | Ausgenommen dieses Attribut, für welches das Recht auf Änderung, Einfügung und Löschung (siehe nachfolgende Tabelle) trotzdem gilt. |
Die hier einstellbaren Rechte beziehen sich immer auf den externen Kommunikationspartner zum Schutz der eigenen, lokalen Daten. Hierbei unterscheidet man die folgenden Rechte:
Recht | angewand bei… | wenn gesetzt | wenn nicht gesetzt | ||
---|---|---|---|---|---|
Klasse | Attribut | Klasse | Attribut | ||
Leserecht | Versand | Inhalt der Klasse wird in eine Nachricht an den Kommunikationspartner geschrieben. | Der Inhalt des Attributs wird in eine Nachricht an den Kommunikationspartner geschrieben. | Inhalt der Klasse wird nicht in eine Nachricht an den Kommunikationspartner geschrieben. | Der Inhalt des Attributs wird nicht in eine Nachricht an den Kommunikationspartner geschrieben. |
Änderungsrecht | Empfang | Der Inhalt der Klasse wird aus einer Nachricht des Kommunikationspartners übernommen und aktualisiert einen bereits vorhandenen Inhalt. | Der Inhalt des Attributs wird aus einer Nachricht des Kommunikationspartners übernommen und aktualisiert einen bereits vorhandenen Inhalt. | Der Inhalt der Klasse wird aus einer Nachricht des Kommunikationspartners nicht übernommen, wenn es ihn bereits gibt. | Der Inhalt des Attributs wird nicht geändert. |
Einfügerecht | Empfang | Der Inhalt der Klasse wird aus einer Nachricht des Kommunikationspartners übernommen und eingefügt, falls er noch nicht vorhanden ist. | Wenn der Inhalt des Attributs leer ist, wird er mit dem Inhalt aus einer Nachricht des Kommunikationspartners gefüllt. | Der Inhalt der Klasse wird aus einer Nachricht des Kommunikationspartners nicht übernommen, wenn es ihn noch nicht gibt. | Wenn der Inhalt des Attributs leer ist, bleibt er leer, auch wenn in einer Nachricht des Kommunikationspartners ein Inhalt enthalten ist. |
Löschrecht | Empfang | Der Inhalt der Klasse wird aus der Datenbank gelöscht. | Wenn der Inhalt des Attributs in einer Nachricht des Kommunikationspartners leer ist, wird der Inhalt gelöscht. | Der Inhalt der Klasse bleibt erhalten, auch wenn er nicht in einer Nachricht des Kommunikationspartners enthalten ist. | Der Inhalt eines Attributs bleibt erhalten, auch wenn der Inhalt des Attributs in einer Nachricht des Kommunikationspartners leer ist. |
Wird eine Einstellung für eine Klasse vorgenommen, so gilt sie auch für ihre abhängigen Klassen (rekursiv), sofern für diese keine gesonderten Einstellungen vorgenommen werden. Einstellungen für ein Attribut gelten nur für dieses.
Die Datenrechte auf Attributebene werden in Kombination folgendermaßen interpretiert:
Die Rechte eines Kommunikationspartners können für jedes Attribut jedes Datenbereichs (nicht jedoch für einzelne Datensätze) in verschiedenen Kontexten spezifiziert werden (mittels Pfadausdrücken). Das Entziehen eines Rechtes für einen Klassenpfad gilt automatisch rekursiv für alle Unterknoten. Die Standardvoreinstellung ist, dass jeder Kommunikationspartner bei allen Klassen und Attributen aller Datenbereiche in allen Kontexten (Pfadausdrücken) alles darf. Hiervon ausgeschlossen sind implizit übermittelte Katalog- oder Stammdaten. Hier ist nur Leserecht vorkonfiguriert. Vom Administrator werden also in der Regel keine Rechte gesetzt sondern Rechte entzogen!
Mit der Kennzeichnung 'Attribut' werden Attribute von Klassen abgegrenzt. Notwendig ist dies, da es Attribute und Klassen mit gleichem Namen gibt. Wird beispielsweise ein Kommunikationsrecht für ein Attribut konfiguriert, ohne die Kennzeichnung zu setzen, wir diese Einstellung möglicherweise ignoriert, wenn es keine Klasse gleichen Namens gibt oder (ungewollt) für die gesamte Klasse angewendet, wenn es eine entsprechende Klasse gibt.
Ein Kommunikationsrecht neu eintragen
Über der Tabelle der Kommunikationsrechte befindet sich der Button Kommunikationsrecht neu anlegen . Es öffnet sich ein Dialog zur Eingabe einer neuen Kennung.
Mittels Strg+Leertaste kann ein kontextsensitiver Auswahldialog für Fachobjektemodellklassen und ihre Attribute geöffnet werden. Die Kontexthilfe besteht aus einer Liste aller Klassen des Fachobjektemodells (FOM) und einem Anzeigefenster für die im FOM integrierte Dokumentation zu einer Klasse.
Rechtepfade werden - ausgehend von der Hauptklasse einer Nachricht - in der Punktnotation aufgebaut, die auch im CLASSES-Abschnitt von Abfragen verwendet wird. Wird hinter einem Klassennamen ein Punkt (.) gesetzt, so öffnet sich jeweils ein Auswahldialog aller Klassen (), die mit der vor dem Punkt stehenden Klasse im FOM verknüpft sind. Daran anschließend enthält die Liste alle Attribute () der Klasse vor dem Punkt. Neben der Auswahlliste erscheint erneut ein Anzeigefenster mit der im FOM hinterlegten Dokumentation zur Klasse oder zum Attribut.
Die Auswahl aus den Auswahllisten erfolgt per Doppelklick. Wenn Sie die Kontexthilfe ohne Auswahl schließen wollen, genügt ein Druck auf die Esc-taste.
Die Kontexthilfe an dieser Stelle ist generisch programmiert, d.h. Sie erhalten immer alle Attribute zu einer Klasse zur Auswahl. Der Kontexthilfe liegen aber nicht genügend Informationen vor, um zu entscheiden, ob die o.g. Einschränkungen für die Kommunikationsrechte von Attributen gelten. Daher werden die Attribute auch dann zur Auswahl angeboten, wenn es sich nicht um die Kopftabelle handelt oder Tochterklasse nicht in einer 1:1-Beziehung zu Kopftabelle steht. Die o.g. Einschränkungen gelten aber trotzdem! Dem entgegenstehende Konfigurationen sind wirkungslos.
Ein Kommunikationsrecht löschen
In der Liste wird der zu löschende Pfad markiert. Über den Button Kommunikationsrecht löschen kann der Pfad zusammen mit den eingestellten Rechten nach einer Sicherheitsabfrage gelöscht werden.
Ein Standardset von Kommunikationsrechten eintragen
Über den Button Standardrechte übernehmen kann ein Set von Standardrechteeinstellungen für einen Kommunikationspartner übernommen werden. Die Übernahme erfolgt nach einer Sicherheitsabfrage. Die neuen Einträge werden an das Ende der Liste angefügt. Falls die Übernahme in eine Liste vorhandener Kommunikationsrechte erfolgt, werden Doppeleinträge nicht verhindert!
Der Tab-Reiter eines Kommunikationspartners besteht zuoberst aus drei Abschnitten mit allgemeinen Angaben, an die sich darunter ein Tab-Reiter mit den Anfragentypen und den zugehörigen Kommunikationsbäumen und Übermittlungsbeschränkungen anschließt:
Kommunikationspartner via WebService
Der Abschnitt Kommunikationspartner via WebService umfasst die Eigenschaften eines Standortes, der als Kommunikationspartner via WebService mit ASYS kommunizieren soll. Für WebService-Kommunikationspartner gilt, dass sie einen Kommunikationsvorgang mit ASYS initiieren und der WebService-Server von ASYS auf Anfragen der konfigurierten Partner wartet. WebService-Kommunikationspartner können ausschließlich lesend auf den ASYS-Datenbestand zugreifen!
Der Name des Kommunikationspartners ergibt sich aus dem Namens des Standortes, wird hier nur angezeigt und ist nicht änderbar.
Das Info-Feld kann für eine interne Dokumentation genutzt werden.
Identifizierung des Anfragenden
In die Felder Benutzer und Passwort sind die Authentifizierungsangaben des Kommunikationspartners einzutragen. Beide Angaben werden von der IKA vergeben und mitgeteilt.
Das Zertifikat für Kommunikationspartner IPA wird nur noch aus Gründen der Abwärtskompatibilität (war erforderlich für den 'alten' WebService) angezeigt und wird in zukünftigen Versionen entfernt werden.
Der untere Teil des Bearbeitungsbereichs enthält einen Tab-Reiter mit den Anfragetypen, die vom WebService-Kommunikationspartner gestellt werden können.
Anfragetypen
Die Anfragetypen stellen die verschiedenen Anfragen dar, die durch den Kommunikationspartner an den ASYS-WebService gestellt werden können. Jeder Anfragetyp besitzt fünf Eigenschaften:
Die Namen und die Struktur der Anfragetypen und ihrer oben genannten Eigenschaften werden durch die ASYS-Entwickler bereitgestellt und können im Administrator nicht neu vergeben, erstellt, verändert oder gelöscht werden.
Verschiedenen WebService-Kommunikationspartnern können aber unterschiedliche Untermengen der definierten Kommunikationsbäume der Anfragetypen zugeordnet werden. Hierzu können Einschränkungen auf dem Tab-Reiter Nicht übermittelte Datenkategorien und Einzelangaben eingetragen werden.
Einen Anfragetypen neu anlegen
Ein Anfragetyp wird angelegt, in dem ein Anfragetyp mittels Drag&Drop aus der Auswahlliste der Anfragetypen rechts in die Liste der Anfragetypen zum Kommunikationspartner eingefügt wird. Wenn er in der Liste gedroppt wird, so wird er am Ende der Liste angefügt. Mehrfachzuweisungen werden ignoriert.
Alternativ kann der Button Anfragetyp hinzufügen über der Liste genutzt werden, um einen Auswahldialog aller für den WebService vorgesehenen Anfragetypen anzuzeigen. Dieser Auswahldialog kann nach einem Namensbestandteil der Bäume gefiltert werden.
In beiden Fällen ist eine Mehrfachauswahl möglich8). Die Reihenfolge der Einträge am Ziel richtet sich nach der alphabetischen Reihenfolge der Anfragenamen und nicht nach der Reihenfolge der Auswahl in der Auswahlliste bzw. dem -dialog.
Einen Anfragetypen entfernen
In der Liste wird der zu entfernende Anfragetyp markiert. Über den Button Anfragetyp entfernen kann der Anfragetyp des Kommunikationspartners nach einer Sicherheitsabfrage gelöscht werden. Der Anfragetyp bleibt unverändert erhalten.
Nicht übermittelte Datenkategorien und Einzelangaben
Für die nicht übermittelten Datenkategorien und Einzelangaben gilt im Kern das bereits weiter oben zu den Kommunikationsrechten der Kommunikationspartnern dokumentierte.
Mit Eintragungen in dieser Liste können einzelne Klassen oder Attribute aus dem Kommunikationsbaum des jeweiligen Anfragetyps von der Übermittlung an den WebService-Kommunikationspartner ausgenommen werden. Hierzu ist jeweils ein entsprechender Pfad von der Baumwurzel zum auszuschließenden Objekt zu definieren.
Für diese Objekte gilt automatisch, dass das Leserecht nicht erteilt ist. Da WebService-Kommunikationspartner nur lesend auf den ASYS-Datenbestand zugreifen können, entfallen die anderen Rechteeinstellungen.
Weitere Informationen zu dieser Maske | ||||||||||||||||
keine | ||||||||||||||||
landesspezifische Zusatzinformationen: | SH | HH | NI | HB | NW | HE | RP | BW | BY | SL | BE | MV | ST | BB | TH | SN |