Testnachrichten für Sterbedatenabgleich Ausland

[Dr. Lofi Dewanto]

Hallo Zusammen,

ich habe hier die Mails an die Mailingliste weitergeleitet, damit wir
später noch wissen, wie das alles entstanden ist ;-)

@Florian und @Leonid: Wir sollten immer ein CC an die Mailingliste
machen... Nur interne Anwendungsarchitekturen bzw. Systemarchitekturen
sollten wir NICHT über die Mailingliste besprechen... :-)

VG,
Lofi.


________________________________________
Von: florian...@drv-bund.de [mailto:florian...@drv-bund.de]
Gesendet: Montag, 22. Oktober 2012 15:05
An: Potap, L., RentS SEG, K
Cc: Dewanto, Dr, L., RentS SEG, K
Betreff: Antwort: Testnachrichten für Sterbedatenabgleich

Hallo Leonid,

Hat etwas länger gedauert, aber die letzten Tage war bei uns viel los.

Erstmal zu Deinem Ablauf:

1 ist aus meiner Sicht okay.
Bei der Procedure sollten sollten wir uns noch auf ein sprechenden
Bezeichner einigen, der auf das Fachverfahren schließen lässt. Dort
steht z.B. http://www.extra-standard.de/procedures/DEUEV im
Soformelde-Verfahren, weil es zum DEUEV-Verfahren gehört. Ich denke,
wir sollten die Systematik beibehalten und in diesem Fall dann auf
etwas wie http://www.extra-standard.de/procedures/Sterbemeldung o.ä.
gehen
Der Datatype würde dann unterscheiden was es ist. /SAAnfrage oder
etwas in der Art.

Überlegen sollte man vielleicht ob ihr beim DataContainer nicht noch
ein Erstellungsdatum mitschicken wollt. Wenn es für euch nicht
fachlich relevant ist, dann könnt ihr das aber auch weglassen.

1a ist bei uns eine numerische, eindeutige ID, die aus unserem
Verfahrensübergreifenden Ticketsystem generiert wird.

2 Für den Header gilt das selbe wie oben mit der Procedure, nur der
DataType ist hier eindeutig mit DataRequest geregelt.

Für die Abfrage müsste ich mich fachlich nochmal mit Herrn Meckelein
nochmal abstimmen.
Der Vorschlag von Dir ist in so fern komplex, da ich dann bei den
Antworten aus dem Ausland eine Zuordnung zur Anfrage durchführen muss.
In wie weit das hier möglich ist, kann ich leider nicht sagen. Soweit
ich weiß, sind die Daten ja verschlüsselt und ich bekomme sie von
unserem Betrieb auch verschlüsselt.

Aus einem ähnlichen Grund haben wir bei den Sofortmeldungen einen
anderen Weg gewählt. Da die ResponseIDs unseres Ticket-Systems streng
aufsteigend sind, sieht die Abfrage dort so aus:

xmsg:Query>
<xmsg:Argument
property="http://www.extra-standard.de/property/ResponseID">
<xmsg:GT>1</xmsg:GT>
</xmsg:Argument>
<xmsg:Argument
property="http://www.extra-standard.de/property/Procedure">
<xmsg:EQ>DUA</xmsg:EQ>
</xmsg:Argument>
</xmsg:Query>

Der Wert bei xmsg:GT entspricht der zuletzt bekommenen ID der Rückmeldungen.

event und type wie in deinem Beispiel kann entfallen.
Eine Unterscheidung, was abgeholt werden soll, kann später über die
Procedure erfolgen.

2a

Wie oben erwähnt bekommt das Package von uns eh eine neue ResponseID,
die der Sendung eindeutig zugewiesen ist. Eine Wiederholung des
gesamten Headers aus der Ursprungssendung ist aus meiner Sicht nicht
möglich, da ich sonst ja zu jeder Sendung das komplette XML speichern
müsste. Dazu käme auch hier wieder die Zuordnung zwischen Eingang und
Ausgang.
Aus diesem Grund wird im Sofortmelde-Verfahren einfach der Header aus
Schritt 2 wiederholt und um die ResponseDetails des entsprechenden
Pakets ergänzt.

Schritt 3 und 3a sehen für mich gut aus. Auch hier wieder die
Procedure und der DateType lautet
http://www.extra-standard.de/datatypes/ConfirmationOfReceipt

Falls noch Fragen sind einfach melden.

Gruß

Florian

________________________________________

Von: <Leonid...@deutschepost.de>
An: <florian...@drv-bund.de>,
Kopie: <Lofi.D...@deutschepost.de>
Datum: 10.10.2012 11:52
Betreff: Testnachrichten für Sterbedatenabgleich
________________________________________



Hallo Florian,

ich habe Testnachrichten für Sterbedatenabgleich vorbereitet. So
stelle ich mir die ausgetauschten Nachrichten vor:

1. Request mit Daten. Request wird über ID identifiziert(z.B. hier
STERBEDATENABGLEICH-7777777)
1.a Response. In Response ist ein ResponseID (z.B. hier
STERBEDATENABGLEICH-7777777-1-RESPONSE)

2. Request Anforderung der Ergebnisse. Die Anforderung erfolgt
über den ResponceID der ersten Nachricht (z.B. hier
STERBEDATENABGLEICH-7777777-1-RESPONSE)
2.a Response mit den Ergebnissen der Verarbeitung. Die Zuordnung der
Ergebnisse erfolgt durch die Wiederholung der AnforderungsId in
Request (z.B. hier RequestID =
STERBEDATENABGLEICH-7777777-1-RESPONSE). Es kann evtl. ein neuer
ResponseID für jedes Package vergeben werden (z.B. hier
STERBEDATENABGLEICH-7777777-1-RESPONSE-DATENRESPONSE)

3. Request mit dem ConfirmationOfReceipt. Die Zuordnung der
Konfirmation erfolgt über der zuletzt vergebenen ResponseID (z.B. hier
STERBEDATENABGLEICH-7777777-1-RESPONSE-DATENRESPONSE)
3.a. Response für die ConfirmationOfReceipt.



Könntest Du bitte die von mir getroffenen Annahmen bestätigen bzw. korrigieren


Vielen Dank und viele Grüße
Leonid Potap