Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Kommentierung 1.5.3] A_19356-07 - Prüfen der Version des Empfängers #30

Open
dhufnagel opened this issue May 4, 2023 · 13 comments
Open

Comments

@dhufnagel
Copy link
Contributor

“Ist das LDAP-Directory Attribut komLeData für den Empfänger undefiniert, dann muss ein 136 KOM-LE-Clientmodul mit einer Version 1.0 angenommen werden” - wurde ersatzlos gestrichen. Was passiert wenn weder komLeData noch kimData vorhanden ist?

@dhufnagel dhufnagel changed the title A_19356-07 - Prüfen der Version des Empfängers [Kommentierung 1.5.3] A_19356-07 - Prüfen der Version des Empfängers May 4, 2023
@hank011
Copy link

hank011 commented May 12, 2023

Weiterführende Frage zu dieser AFO:
Wie ist mit dem Caching umzugehen?
in der Vorveröffentlichung zum Opt-In für große Mails gab es den Absatz zum Caching. In der Veröffentlichung selbst war er dann wieder weg. Nun ist er wieder enthalten (aber nicht als Änderung markiert).

konkretes Beispiel:

  • Sender möchte Mail senden, hat für Empfänger 1.5+ im Cache
  • zwischenzeitlich hat der Empfänger sein OptIn für große Mails zurückgezogen - im VZD steht damit 1.5 (ohne +)

Soll diese Mail versendet werden (da Cache genutzt) oder darf die Mail nicht versendet werden, da immer im VZD die Version geprüft werden muss für große Mails?

@CLAM01
Copy link

CLAM01 commented May 12, 2023

Meiner Meinung nach ist das Cachen der KOM-LE Version überflüssig.
Gemäß A_19356-06 (1.5.3 = 07) MUSS das Clientmdoul die Version des Empfängers immer prüfen und abfragen. Somit würde der Cache nie zum Tragen kommen.

Natürlich gibt es auf der Seite des Empfängers auch noch einen Mechanismus der unterbindet, dass das Empfänger CM die Nachricht vom KAS läd wenn nicht dafür frei gegeben und den Empfänger entsprechend informiert.
A_23512 - Auswertung der KOM-LE-Version bei Nachrichten mit KAS-Content

@CLAM01
Copy link

CLAM01 commented May 12, 2023

“Ist das LDAP-Directory Attribut komLeData für den Empfänger undefiniert, dann muss ein 136 KOM-LE-Clientmodul mit einer Version 1.0 angenommen werden” - wurde ersatzlos gestrichen. Was passiert wenn weder komLeData noch kimData vorhanden ist?

Gute Frage. Ich hätte jetzt fast gesagt, dann ist der Empfänger nicht valide, denn er unterstützt laut VZD weder KIM1.0 noch KIM1.5 noch 1.5+ und müsste eigentlich aus dem Empfängerkreis ausgeschlossen werden.

@dhufnagel
Copy link
Contributor Author

@CLAM01 das würde für alle Empfänger mit Kim 1.0 Clientmodul gelten und ein Kim 1.5 Clientmodul unbrauchbar machen. Daher sollte aus meiner Sicht die AFO wieder wie vorher lauten und ein nicht vorhandenes komLeData Attribut als Kim 1.0 werten.

@gem-cp
Copy link
Contributor

gem-cp commented May 23, 2023

Vorschlag:
Ab KIM 1.5.3: VZD sorgt dafür dass kimData und komLeData immer vorhanden sind.
Zumindest kimData muss immer vorhanden sein, da das CM ab KIM 1.5.3 kimData als Suchparameter für die VZD-Abfrage verwenden muss. Das ist rforderlich, damit für die Krankenkassen mehrere KIM-Adressen unterstützt werden können ohne die eAU Anwendung zu beeinflussen. Die Kassen brauchen mehrere KIM-Adressen für die Einführung weiterer KIM-Anwendungen.

@dhufnagel
Copy link
Contributor Author

Wenn der VZD nicht automatisch das kimData Attribut verwaltet oder es HotFixes für alte KIM Fachdienstversionen gibt, wird das kimData Attribut nicht funktionieren. Denn ein KIM 1.5.2 Fachdienst muss das kimData Attribut nicht anpassen und somit wird es nicht gepflegt, auch wenn es einmalig automatisch angelegt wird. Siehe #26

Was war der Hintergedanke beim Streichen des Satzes in der AFO? Die Annahme, dass ein Empfänger nur KIM 1.0 unterstützt ist bei fehlendem komLeData Attribut doch naheliegend?

@gem-cp
Copy link
Contributor

gem-cp commented May 23, 2023

Zu "Was war der Hintergedanke beim Streichen des Satzes in der AFO? Die Annahme, dass ein Empfänger nur KIM 1.0 unterstützt ist bei fehlendem komLeData Attribut doch naheliegend?"

Als komLeData in das Datenmodell des VZD aufgenommen wurde, wurde vom VZD für alle Einträge mit Mail-Adressen auch komLeData angelegt. Daher sind wir davon ausgegangen, dass komLeData mittlerweile immer vorhanden ist und der Satz konnte aus unserer Sicht gestrichen werden.
Es hat sich jedoch gezeigt, dass es wieder Einträge mit mail Adresse aber ohne komLeData gibt, da der VZD komLeData nur einmalig angelegt hat und nicht bei Änderungen an den Einträgen.

@Amarteau
Copy link
Contributor

Amarteau commented May 23, 2023

Aber wäre dann nicht der richtige Weg der, die VZD Spezifikation so zu erweitern, dass der VZD beim Aufruf der Administrationsschnittstelle das komLeData Attribut korrekt befüllt?
Im VZD könnte das zentral an einer Stelle umgesetzt werden, auch in Hinblick auf das kommende kimData Attribut.

@dhufnagel
Copy link
Contributor Author

Das Clientmodul muss in Kim 1.5.2 schon jetzt diese fallback Logik unterstützen. Daher sehe ich die Notwendigkeit diese in Kim 1.5.3 zu entfernen als wenig hilfreich, wenn dadurch weitere Probleme auftreten.

@stophane
Copy link

Hallo zusammen,

Stichwort: Abwärtskompatibilität

Der Teil für undefiniert und fallback auf KOM-LE-Version 1.0, darf nicht gestrichen werden.

  • VZD hat gegenüber KIM kein idempotentes Verhalten. Jederzeit können sich Daten verändern, fehlen etc.
  • Es werden KIM 1.5 CM´s ausgerollt, welche sich bei der Verarbeitung, gemäß bisheriger Spezifikation, auf komLeData beziehen.
    • Im dezentralen Bereich können CM´s nicht global, sofort ausgetauscht werden (Nutzer führen Updates oft nicht durch)
    • komLeData MUSS weiterhin zu jeder KIM-Adresse, egal ob mail und oder kimData existieren, sonst würde dies im Kontext des bisherigen Fallbacks auf KOM-LE-Version=1.0 dazu führen, dass in bestehenden KIM 1.5 Clientmodulen im Feld, die sich auf KOM-LE-Version 1.5(+) beziehenden Feature nicht mehr nutzbar wären.

Viele Grüße

@gem-cp
Copy link
Contributor

gem-cp commented Jun 6, 2023

OK. Die Streichung des Satzes wird nicht erfolgen. Dennoch wird der VZD sicherstellen, dass für KIM 1.5.3 komLeData und kimData immer vorhanden sind (in PU voraussichtlich ab Q4 2023).

@dhufnagel
Copy link
Contributor Author

Also managed der VZD das kimData Attribut? Oder wie soll das nach einer einmaligen Migration sichergestellt werden, wenn danach komLeData durch ein Kim 1.5.2 CM/FD geändert wird. Auf diesen Hinweis/diese Frage wird wiederholt nicht eingegangen.

@gem-cp
Copy link
Contributor

gem-cp commented Jun 12, 2023

Der Prozess läuft wie folgt.
Das CM sendet Accountdaten (Mail Adresse, KIM-Version des CM für diese Mail-Adresse und appTags) an den Accountmanager. Der AccountManager sendet die Daten an den VZD. Der VZD ändert den Eintrag des Nutzers in den KIM Fachdaten (Attribute mail, komLeData und kimData, Primärschlüssel ist die telematikID) und generiert die flache Liste für den Eintrag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants