Open CLAM01 opened 1 year ago
gem-cp
commented
1 year ago Vorschlag: wir ändern die Afos A_23729 und 30 so, dass wenn der VZD feststellt, dass der Accountmanager ein unbekanntes appTag eintragen will, dann prüft der VZD noch einmal, ob es eine neuere Version gibt und lädt diese, falls vorhanden. Erst wenn dann das appTag noch nicht bekannt ist wird der Request vom Accountmanager mit einem Fehler beantwortet.
stophane
commented
1 year ago Hallo zusammen,
diesen Scope erweiternd, folgende Anmerkungen zum Umgang mit appTags KIM CM - KIM FD - VZD.
Scope: A_23728 - VZD, I_Directory_Application_Maintenance, Aktualisierung zulässiger Anwendungskennzeichen A_23729 - VZD, I_Directory_Application_Maintenance, Anwendungskennzeichen Prüfung LDAP A_23730 - VZD, I_Directory_Application_Maintenance, Anwendungskennzeichen Prüfung REST … A_23722 - Account Manager, regelmäßige Aktualisierung der Liste der Anwendungskennzeichen A_23718 - Account Manager, Eintragung von Anwendungskennzeichen in den VZD
Meinem Verständnis nach haben die appTags bzw. Anwendungskennzeichen den Zweck, dass Primärsysteme geeignete KIM-Adressen für spezifische Anwendungskontexte aus dem VZD ermitteln können. Beispielsweise dann, wenn eine Kasse einen spezifischen KIM-Account/-Adresse definiert an diese nur bestimmte Daten einer Anwendungsdomäne (eAU, ...) gesendet werden sollen. Bezug zur eigentlichen, technischen Anwendungsdomäne des Versand und Empfang über die Transportschicht KIM besteht nicht. Folglich bedarf es keiner Auswertungen oder gesonderten Behandlung dieser Information innerhalb der Transportschicht - Entscheidung der Adressierung erfolgt im Primärsystem (Primärsystem Mail-Client ermittelt kimData-> Adressierung im KIM-externen Anwendungskontext)
Damit appTags im richtigen Kontext in den VZD gelangen, erfolgt die Konfiguration der appTags im Kontext des KIM CM/FD Account Manager interface.
Gemäß der o.g. Spezifikationen zugefasst:
Beachte - Account Manager ist lediglich Vermittler der appTag-Information
Sowohl VZD als auch Account Manager rufen unabhängig voneinander die Liste der appTags aus externer Quelle ab und validieren individuell. Damit besteht automatisch das Risiko der Inkonsistenz dieser Daten -> Fehlerfälle
Im Kontext der Anwendungsdomäne KIM erfolgt das Setzen der appTags synchron im durch I_AccountManager_Service.setAccount. Dies bedeutet, dass bei Veränderung des appTags dieses mit Ziel der Eintragung im VZD übermittelt wird. Somit ist die Validierung des appTags durch den VZD völlig ausreichend, da dieser systemtheoretisch diese Daten aktiv verwaltet und Quelle der Information für die Nutzung durch Primärsysteme ist. Die doppelte Validierung in Account Manager und VZD birgt Fehlerpotenzial durch inkonsistente Abbildung der Validierung oder Datenbasis (VZD lehnt Anwendungskennzeichen ab, FD akzeptiert).
Die Umsetzung der aktuellen Spezifikationslage muss aus o.g. Grunden erneut evaluiert werden (hohes ### Fehlerpotenzial)!
Da der KIM Account Manager lediglich Vermittler dieser Information ist, kein technischer Anwendungsbezug für die KIM-Komponenten besteht und VZD die primär, zentrale Instanz der Verwaltung der appTags ist:
Viele Grüße
stophane
commented
1 year ago Wenn der VZD als zentrale Quelle der appTags eingesetzt wird, bietet das ebenfalls die Möglichkeit, dass der VZD als anti-corruption layer agieren kann (vgl.: anti-corruption layer).
So kann eingegriffen, Probleme gemindert werden, sofern bspw. in der externen Quelle Fehler, betriebstechnische Ausfälle, etc. auftreten, welche direkte Auswirkungen auf die multiplen FD-Instanzen oder andere, sich auf diese Datenbeziehende Systeme hätten.
gem-cp
commented
1 year ago Vorschlag (AccountManager bekommt appTags vom VZD) wird geprüft.
gem-cp
commented
1 year ago OK, Vorschlag angenommen. VZD bezieht die appTag-Liste aus Simplifier und AccountManager vom VZD.
Wie ist es geregelt wenn der AccountManager des KIM-Fachdienstes schon eine neuere Liste hat und der VZD aufgrund der geforderten "stündlichen" prüfung gemäß A_23728 noch keine neuere Liste hat. Das Resultat wäre, dass der VZD aufgrund einer veralteten Liste die Operation nicht durchführt.
Das darf nicht passieren. Der VZD müsste also auch immer prüfen ob es eine neuere Liste gibt sobald Fachdaten gteändert werden sollen durch den AccountManager.
Das gleiche gilt auch für A_23730 - VZD, I_Directory_Application_Maintenance, Anwendungskennzeichen Prüfung REST