[Kommentierung 1.5.3] A_23729 - VZD, I_Directory_Application_Maintenance, Anwendungskennzeichen Prüfung LDAP

[CLAM01]

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

[gem-cp]

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]

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

Verständnis & Einleitung

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.

Risiken und Problem Spec

Gemäß der o.g. Spezifikationen zugefasst:

1. VZD ruft gültige Liste appTags ab
2. VZD führt Validierung appTag input durch
3. KIM FD Account Manager ruft gültige Liste appTags ab
4. KIM FD Account Manager führt Validierung appTag input durch
5. (synchroner Prozess) CM ruft Liste appTags für Auswahl durch Nutzer ab -> CM sendet setAccount() an Account Manager -> Account Manager übermittelt Daten an VZD

Beachte - Account Manager ist lediglich Vermittler der appTag-Information

Problem Daten-Inkonsitenz (1) & (3)

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

Problem mehrfacher Validierung

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)!

---

Änderungsvorschlag

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:

• Ausschließlich VZD ruft aktuelle Liste der appTags ab
  • VZD stellt diese Liste über ein REST-API den KIM Account Managern zur Verfügung -> Account Manager stellt gleiche Liste KIM CM zu Verfügung (Achtung interface definition hierzu fehlt noch, siehe [Kommentierung 1.5.3] A_23711 - Clientmodul, gültige Anwendungskennzeichen #49)
    • => konsistente Datenbasis
• Ausschließlich VZD validiert die appTags aus synchronem Vermittlungsprozess KIM CM -> KIM Account Manager -> VZD
  • Konistente Validierung = diesbezüglich Anpassung und Fehlerbehebung an einer zentralen Stelle

Viele Grüße

[stophane]

Ergänzung

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]

Vorschlag (AccountManager bekommt appTags vom VZD) wird geprüft.

[gem-cp]

OK, Vorschlag angenommen. VZD bezieht die appTag-Liste aus Simplifier und AccountManager vom VZD.