Kommunikationspartner
Fachlich/inhaltliche Beschreibung
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:
- Nachrichten: Die Nachrichten sind die Nachrichtentypen, mit denen Datensätze zwischen ASYS-Repository-Standorten manuell oder automatisch ausgetauscht werden können. Jeder Nachrichtentyp stellt dabei einen Ausschnitt des ASYS-Datenmodells dar, wobei dieser Ausschnitt sich über eine oder mehrere miteinander verknüpfte Tabellen des Datenmodells erstreckt (Kommunikationsbaum). Die Nachrichtentypen sind in einem Baum entsprechend dem Navigationsbaum der Anwenderoberfläche angeordnet. Jeder Nachrichtentyp ist einer Hauptdatenkategorie/Maske zugeordnet. Einer Hauptdatenkategorie/Maske können mehrere Nachrichtentypen zugeordnet sein. Hauptdatenkategorien/Masken ohne Nachrichtentyp sind nicht im Baum aufgeführt.
Zu jedem Nachrichtentyp können zwei Tochterobjekte gehören:- Regelmenge: Für den Empfang einer Nachricht eines bestimmten Nachrichtentyps kann diesem jeweils eine Nachrichtenregelmenge zugeordnet sein. Eine Nachrichtenregelmenge ist auf die gleiche Weise aufgebaut, wie ein Prüfplan für die Oberfläche. Das Ergebnis wird - wie das Ergebnis des Oberflächenprüfplans - in einer Fehlerprotokolltabelle des jeweiligen Datensatzes in der Datenbank gespeichert.
Wichtig: Mit ASYS7 ist der Prüfmechanismus geändert worden: Beim Nachrichteneingang wird zunächst der Nachrichtenprüfplan und anschließend der fachliche Prüfplan ausgeführt. Aus diesem Grunde sind im Nachrichtenprüfplan nur noch Prüfungen enthalten, die beim Nachrichteneingang zusätzlich ausgeführt werden sollen - z.B. die Prüfung auf Einhaltung des erlaubten Wertebereiches für Datumsangaben. Die Prüfungen, die in bislang in beiden Prüfplänen enthalten waren, sind nun nur noch im Oberflächenprüfplan enthalten. - Empfängerermittlung: Für einen automatischen Abgleich aller Datensätze in ASYS, die in mehr als nur einer Datenbank (entspricht in der Regel einem Bundesland) auf einem einheitlichen Stand gehalten werden sollen, können die betreffenden Datensätze mit Empfängerermittlungsskriptmengen versehen werden. In diesen Skriptmengen - sie bestehen, vergleichbar zu Regelmengen, aus Skriptgruppen und diese wiederum aus Skripten - lassen sich ein oder mehrere Empfänger aus der Liste der Kommunikationsparter als Empfänger einer Nachricht des jeweiligen Typs ermitteln. Mit den Skripten ist es möglich, die Datensätze in Abhängigkeit ihres Inhalts (z.B. behördlichen Nummern von Beteiligten oder behördliche Nummern von Vorgängen) nur den jeweils betroffenen Empfängern (meist die ASYS-Knotenstellen der Bundesländer) zuzusenden. Für einen Datensatz wird nur dann geprüft ob bzw. welche Empfänger ihn erhalten sollen, wenn er seit der letzten Versendung verändert wurde.
- Kommunikationspartner: Kommunikationspartner sind Repository-Standorte. Einstellungen zur Kommunikation, die pro Sender/Empfänger vorgenommen werden müssen, sind dieser Objektart zugeordnet.
Kommunikationspartner gibt es in zwei Hauptvarianten, als 'normale' ASYS-Kommunikationspartner und als WebService-Kommunikationspartner. Da sich diese beiden Varianten in wichtigen Konfigurationsparametern unterscheiden, werden sie zwar gemeinsam im Objektbaum verwaltet, aber mit unterschiedlichen Objektklassenicons angezeigt. - Kommunikationsjobs: Die automatisierte Kommunikation wird vom ASYS-Kommunikationsserver (AsysComServer) erledigt. Ausführliche Informationen zu den Kommunikationsjobs finden sich in der Spezifikation (s. 5. Jobs und Auslösen von Jobs ff. und 6. Empfang - Protokollierung und Ablauf der Jobs ff.) In der Standardkonfiguration findet dieser Service in mehreren separaten Schritten statt:
- Abholung VPS BMU: Abholung der BMU-XML-Dokumente aus dem Knotenstellenpostfach der ZKS-Abfall via OSCI-Protokoll. Die abgeholten Nachrichten werden in der Datenbank abgelegt. Protokollierung in den Protokollen 'Nachrichtenabholung' und 'Empfangene Nachricht'. Die Nachrichten werden noch nicht importiert. Dies geschieht erst bei der Ausführung des Jobs 'Empfang BMU'.
- Abholung VPS ASYS intern: Abholung der ASYS-internen Nachrichten aus dem Knotenstellenpostfach der ZKS-Abfall via OSCI-Protokoll. Die abgeholten Nachrichten werden in der Datenbank abgelegt. Protokollierung in den Protokollen 'Nachrichtenabholung' und 'Empfangene Nachricht'. Die Nachrichten werden noch nicht importiert. Dies geschieht erst bei der Ausführung des Jobs 'Empfang ASYS intern'.
- Abholung Verzeichnisse: Abholung von Nachrichten aus Verzeichnissen. Es werden alle Empfangsordner aller Kommunikationspartner überprüft, bei denen ein Empfangsordner angegeben ist. Dieser Jobtyp dient in erster Linie der Abholung von Nachrichten mit den Nachrichtenformaten 'Extern-XML' und 'Text-CSV'. Es werden allerdings auch die aus einem Registerauszug extrahierten und damit zum Import bereitgestellte Nachrichten im Empfangsordner des Kommunikationspartners mit dem Nachrichtenformat 'BMU-XML' abgelegt. Die abgeholten Nachrichten werden in der Datenbank abgelegt. Protokollierung in den Protokollen 'Nachrichtenabholung' und 'Empfangene Nachricht'. Die Nachrichten werden noch nicht importiert. Dies geschieht erst bei der Ausführung eines der Jobs 'Empfang …' (in Abhängigkeit vom Nachrichtenformat).
- Empfang BMU: Verarbeitung/Import aller Nachrichten mit dem Nachrichtenformat 'BMU-XML', die erfolgreich abgeholt aber noch nicht verarbeitet wurden. Protokollierung in den Protokollen 'Empfangene Nachricht', 'Empfangener Datensatz' und 'Prüfergebnis'.
- Empfang ASYS intern: Verarbeitung/Import aller Nachrichten mit dem Nachrichtenformat 'ASYS-intern', die keine 'ASYS-interne Quittung' sind und erfolgreich abgeholt aber noch nicht verarbeitet wurden. Protokollierung in den Protokollen 'Empfangene Nachricht', 'Empfangener Datensatz' und 'Prüfergebnis'.
- Empfang Sonstige: Verarbeitung/Import aller Nachrichten mit den Nachrichtenformaten 'Extern-XML' oder 'Text-CSV', die erfolgreich abgeholt aber noch nicht verarbeitet wurden. Protokollierung in den Protokollen 'Empfangene Nachricht', 'Empfangener Datensatz' und 'Prüfergebnis'.
- Empfang ASYS-QT: Verarbeitung/Import aller Nachrichten mit dem Nachrichtenformat 'ASYS-intern', die eine 'ASYS-interne Quittung' sind und erfolgreich abgeholt aber noch nicht verarbeitet wurden. Protokollierung im Protokoll 'Empfangene Nachricht' und 'Versandter Datensatz'.
- Quittierung BMU: BMU-Quittungserstellung und -versand für alle erfolgreich verarbeiteten Nachrichten mit dem Nachrichtenformat 'BMU-XML', für die eine Quittung erstellt werden soll. Protokollierung in den Protokollen 'Empfangene Nachricht', 'Versandte Nachricht' und 'Versandter Datensatz'.
- Quittierung ASYS intern: ASYS-interne-Quittungserstellung für alle erfolgreich verarbeiteten Nachrichten mit dem Nachrichtenformat 'ASYS-intern', für die eine Quittung erstellt werden soll. Die Quittungen werden im '…Outgoing-Ordner' abgelegt (und beim nächsten OSCI-Versand versandt). Protokollierung im Protokoll 'Empfangene Nachricht'.
- PreVersand: Ermittlung aller zu versendenden Datensätze und Ermittlung der Empfänger anhand der Empfängerermittlungsskripte. Generierung von Nachrichten im ASYS-internen XML-Format für alle Datensatz-Empfänger-Pärchen.
- OSCI-Versand: Versand aller generierten Nachrichten via OSCI-Protokoll an das jeweilige Empfängerpostfach der Kommunikationspartner in der VPS der ZKS-Abfall. Der OSCI-Versand verschickt alle ASYS internen Nachrichten aus dem '…Outgoing-Ordner' an die VPS. Hierbei werden die OSCI-Quittungen geordnet abgelegt und es erfolgt eine Protokollierung in den Versandtabellen.
- Batchausführung: Es findet ausschließlich die Ausführung der Pre- und Post-Batchjobs statt. Dieser Jobtyp kann z.B. verwendet werden, um vor oder nach anderen Jobs Nachrichtendateien mittels Konsolenkommandos auf Betriebssystemebene zu kopieren, zu verschieben oder zu archivieren. Dieser Jobtyp kann nicht in der Serverüberwachung des Kommunikationsservers manuell gestartet werden.
- AsysServer: Der ASYS-Kommunikationsserver (AsysComServer), der ASYS-WebServer (AsysWebServer) und der ASYS-Funktionsserver (AsysJobServer) arbeiten als eigenständige Serverprozesse. Damit diese Programme überwacht und beeinflusst werden können, müssen ihre IP-Adressen bzw. DNS-Namen hinterlegt werden.
- Freie Empfängerermittlungsskriptmengen: So wie sich Regelmengen als 'freie Regelmengen' ohne Zuordnung zu einer Maske im Repository für eine spätere Verwendung vorhalten lassen, können auch Skriptmengen der Empfängerermittlung ohne Zuordnung zu einer Nachricht als 'freie Empfängerermittlungsskriptmenge' verwaltet werden. Im Unterschied zu den 'freien Regelmengen' können 'freie Skriptmengen' auch bearbeitet werden.
Bedienung
Kommunikationspartner
Es wird unterschieden, ob der Kommunikationspartner ein anderer Standort ist oder der eigene Standort.
Kommunikationspartner ist anderer 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:
Kommunikationspartner ist der eigene Standort
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).
Kommunikationspartner / Eigener Standort
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.
- Name: Der Name des Kommunikationspartners ergibt sich aus dem Namens des Standortes. Er wird hier nur angezeigt und ist nicht änderbar. Rechts daneben wird die zugehörige Standortkennung angezeigt.
- Empfangsordner: Der Empfangsordner ist der Ordner im Dateisystem, in dem die Nachrichten anderer Kommunikationspartner (manuell) für einen Empfang bereitgestellt werden können. Der Pfad ist als absoluter Pfad einzutragen.
Der Empfangsordner kann nur bei Standorten eingetragen werden, die nicht mit dem Nachrichtenformat ASYS-intern konfiguriert sind (also Nachrichtenformat 'BMU-XML', 'Extern-XML' oder 'Text-CSV'). Er lässt sich über den Button Pfad auswählen
mit einem Standard-Dateiauswahldialog des Betriebssystems auswählen. - Nachrichtenformat: Das Auswahlfeld Nachrichtenformat ist mit der passenden Alternative zu belegen2). Festgelegt wird dann das grundlegende Format der Daten für den Im- und Export.
Es können vier Nachrichtenformate ausgewählt werden:
| 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. |
- ASYS-interne Quittierung: Das Ankreuzfeld Quittierung zeigt an, ob von dem entsprechenden ASYS-Kommunikationspartner eine Quittung für versandte Nachrichten erwartet wird. Für die ASYS-Kommunikationspartner (die Knotenstellen) sollte dieses Feld obligatorisch gesetzt werden, für andere Kommunikationspartner ist dieses Feld in der Regel nicht zu setzen, da diese Partner die ASYS-interne Quittierung überwiegend nicht beherrschen. Für sie werden andere Protokolle mit eigenen Quittierungsmechanismen eingesetzt (z.B. OSCI-Protokoll für die Kommunikation mit der ZKS) oder auf eine Quittierung verzichtet.
- Wiederholungszeit (in Stunden): Das Feld Wiederholungszeit nimmt die Anzahl Stunden auf, nach denen eine Nachricht erneut versendet wird, wenn keine Quittung vom Empfänger - dem Kommunikationspartner - zurückgekommen ist. Diese Angabe wird nur bei gesetztem Ankreuzfeld Quittierung ausgewertet. Ist die Anzahl auf 0 Stunden eingestellt, erfolgt niemals ein erneuter Versand, unabhängig vom Ankreuzfeld Quittierung.
- Bei Empfang weiterleiten: Nachrichten von diesem Kommunikationspartner werden automatisch auf 'zu versenden' gesetzt und bei nächster Gelegenheit in Abhängigkeit vom Ergebnis der Empfängerermittlungsskriptmengen der Nachrichtentypen weitergeschickt.
- Kommunikationskennung: Genau eine Kommunikationskennung4) pro Kommunikationspartner wird benötigt, um den Partner innerhalb einer Empfängerermittlung als Empfänger einer Nachricht festlegen zu können. Die Kennungen müssen über alle Kommunikationspartner eindeutig sein!
- Info: Das Info-Feld kann für eine interne Dokumentation genutzt werden.
VPS-Postfach
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!
Listenbereich
Der untere Teil des Bearbeitungsbereichs enthält einen Tab-Reiter.
Kommunikationsrechte
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.
- Nachricht: Die darüber stehend eingestellten Kommunikationsrechte gelten nur im Kontext des hier angegebenen ASYS-Nachrichtentyps.
Die Datenrechte auf Attributebene werden in Kombination folgendermaßen interpretiert:
- Kein 'Änderungsrecht' und kein 'Einfügerecht': Der Inhalt des Attributes im vorhandenen Datensatz bleibt immer unverändert.
- Kein 'Änderungsrecht' aber 'Einfügerecht': Sofern der Inhalt des Attributes im vorhandenen Datensatz nicht leer (null) ist bleibt er unverändert. Bei leer (null) wird der Inhalt aus der Nachricht importiert (dieser Inhalt kann natürlich auch leer sein).
- 'Änderungsrecht' aber kein 'Einfügerecht': Ist im vorhandenen Datensatz Inhalt im Attribut enthalten, wird er aktualisiert. Ist das Attribut im Datensatz leer, bleibt es leer.
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!
Kommunikationspartner - WebService
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.
Listenbereich
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:
- Einen Technischen Namen unter dem die Anfrage gestellt wird. Zu einer Anfrage können Parameter gehören, die durch den anfragenden Kommunikationsinhaber mit Werten versehen werden müssen.
- Einen Sprechenden Namen unter dem die Anfrage in einer Liste der Anfragetypen geführt wird.
- Einen Info-Text mit Angaben zu den Suchparametern des Anfragetyps.
- Eine dem Anfragetyp zugeordnete Abfrage. Die zugeordnete Abfrage wird mit ihrem Namen als Link in Feld Abfrage angezeigt. Mittels Strg+Linksklick auf den Link wechselt der Administrator zur Perspektive 'Prüfregeln, Abfragen…' und öffnet die Abfrage im Bearbeitungsbereich7).
- Den Kommunikationsbaum des Anfragetyps, der die Struktur der Datensätze anzeigt, die als Antwort auf die Anfrage zurückgeliefert werden
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 |