Testnachrichten für Sterbedatenabgleich Ausland - Antwort Leonid
16 views
Skip to first unread message
Dr. Lofi Dewanto
Oct 23, 2012, 4:50:14 AM10/23/12
to extra-s...@googlegroups.com
Zur Info!
________________________________________
Von: Potap, L., RentS SEG, K
Gesendet: Montag, 22. Oktober 2012 17:10
An: 'florian...@drv-bund.de'
Cc: Dewanto, Dr, L., RentS SEG, K
Betreff: AW: Antwort: Testnachrichten für Sterbedatenabgleich
Hallo Florian,
zu 1:
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
Wir können uns auf die fachlicher Prozedur als Bezeichner festlegen
(hiermit Sterbedatenabgleich).
Mein Vorschlag (DataSendFetch) geht in die Richtung, der Name der
Procedure aus dem technischen Übertragungstype zu gewinnen und von dem
fachlichen Szenario zu entkoppeln.
Angenommen wir wollen das gleiche Szenario für ein anderes fachliches
Verfahren verwenden. Das unterschied auf der "eXTra"-Ebene mach der
Transport.TransportHeader.Receiver. Das technische 3-Stufen-Scenario
bleibt davon unangetastet.
Mann kann darüber auch in einer anderen Entwicklungsphase erneut
Gedanken machen.
2.
Ü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.
Bei der Übertragung der Daten wird bereits jetzt auf der Klientseite
jeder Schritt protokolliert und damit auch das Übertragungszeitpunkt.
3.
1a ist bei uns eine numerische, eindeutige ID, die aus unserem
Verfahrensübergreifenden Ticketsystem generiert wird.
Ich bin auch von einer eindeutigen ID ausgegangen.
4.
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.
Mir wäre lieber eine Möglichkeit zu finden die Nachrichten eindeutig
definieren zu können. Wenn ein Klient mehr als 1 Datei an den Server
versendet (Klient hat auch keine Kenntnisse der Inhalte), wird es
nicht möglich die ankommende und versendete Datei zu verbinden
(Nachvollzug und Auskunftsfähigkeit nicht gegeben).
Ich würde vorschlagen Identifikation der Nachrichten auf dem Server
über die Dateinamen durchzuführen. Wenn ich richtig die Übertragung
auf der Serverseite mir vorstelle, wird die angekommene Datei mit
einer von dem Server vergebenen Namen in eine "Fachverzeichnis"
reingelegt. Für die Generierung der Name könnte das eindeutige auf
dem Server bekannte ID verwendet werden (ResponseId?). Diese Id sollte
in dem Namen der Antwortdatei wiederzufinden sein und die Verbindung
mit der ResponseId sicher zu stellen.
Da ich die Funktionen des Servers nicht kenne, kann ich leider nicht
einschätzen in wie weit es realisierbar ist.
Darüber sollten wir besser über eine Videokonferenz bzw. Telefonisch
die Meinungen austauschen.
Viele Grüße
Leonid Potap
________________________________________
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
Mit freundlichen Grüßen
Florian Stratil
Nationaler Datenaustausch
Deutsche Rentenversicherung
Bund
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
Deutsche Post AG
NL Renten Service
Abteilung Systementwicklung gesetzliche Rente (SEG)
Team SEG4
Venloer Str. 151-153
50672 Köln
Tel.: +49 221 5692 521
E-Mail: Leonid...@DeutschePost.de
[Anhang "3_response_confirmation-sterbedatenabgleich.xml" gelöscht
von Florian Stratil/WBG/VDRGS/DE] [Anhang
"1_request_daten_senden_sterbedatenabgleich.xml" gelöscht von Florian
Stratil/WBG/VDRGS/DE] [Anhang
"1_response_daten_senden_sterbedatenabgleich.xml" gelöscht von Florian
Stratil/WBG/VDRGS/DE] [Anhang
"2_request_anforderung_verarbeitung-sterbedatenabgleich.xml" gelöscht
von Florian Stratil/WBG/VDRGS/DE] [Anhang
"2_response_anforderung_verarbeitung_sterbedatenabgleich.xml" gelöscht
von Florian Stratil/WBG/VDRGS/DE] [Anhang
"3_request_confirmation-sterbedatenabgleich.xml" gelöscht von Florian
Stratil/WBG/VDRGS/DE]
________________________________________
Von: Potap, L., RentS SEG, K
Gesendet: Montag, 22. Oktober 2012 17:10
An: 'florian...@drv-bund.de'
Cc: Dewanto, Dr, L., RentS SEG, K
Betreff: AW: Antwort: Testnachrichten für Sterbedatenabgleich
Hallo Florian,
zu 1:
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
Wir können uns auf die fachlicher Prozedur als Bezeichner festlegen
(hiermit Sterbedatenabgleich).
Mein Vorschlag (DataSendFetch) geht in die Richtung, der Name der
Procedure aus dem technischen Übertragungstype zu gewinnen und von dem
fachlichen Szenario zu entkoppeln.
Angenommen wir wollen das gleiche Szenario für ein anderes fachliches
Verfahren verwenden. Das unterschied auf der "eXTra"-Ebene mach der
Transport.TransportHeader.Receiver. Das technische 3-Stufen-Scenario
bleibt davon unangetastet.
Mann kann darüber auch in einer anderen Entwicklungsphase erneut
Gedanken machen.
2.
Ü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.
Bei der Übertragung der Daten wird bereits jetzt auf der Klientseite
jeder Schritt protokolliert und damit auch das Übertragungszeitpunkt.
3.
1a ist bei uns eine numerische, eindeutige ID, die aus unserem
Verfahrensübergreifenden Ticketsystem generiert wird.
Ich bin auch von einer eindeutigen ID ausgegangen.
4.
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.
Mir wäre lieber eine Möglichkeit zu finden die Nachrichten eindeutig
definieren zu können. Wenn ein Klient mehr als 1 Datei an den Server
versendet (Klient hat auch keine Kenntnisse der Inhalte), wird es
nicht möglich die ankommende und versendete Datei zu verbinden
(Nachvollzug und Auskunftsfähigkeit nicht gegeben).
Ich würde vorschlagen Identifikation der Nachrichten auf dem Server
über die Dateinamen durchzuführen. Wenn ich richtig die Übertragung
auf der Serverseite mir vorstelle, wird die angekommene Datei mit
einer von dem Server vergebenen Namen in eine "Fachverzeichnis"
reingelegt. Für die Generierung der Name könnte das eindeutige auf
dem Server bekannte ID verwendet werden (ResponseId?). Diese Id sollte
in dem Namen der Antwortdatei wiederzufinden sein und die Verbindung
mit der ResponseId sicher zu stellen.
Da ich die Funktionen des Servers nicht kenne, kann ich leider nicht
einschätzen in wie weit es realisierbar ist.
Darüber sollten wir besser über eine Videokonferenz bzw. Telefonisch
die Meinungen austauschen.
Viele Grüße
Leonid Potap
________________________________________
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
Mit freundlichen Grüßen
Florian Stratil
Nationaler Datenaustausch
Deutsche Rentenversicherung
Bund
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
Deutsche Post AG
NL Renten Service
Abteilung Systementwicklung gesetzliche Rente (SEG)
Team SEG4
Venloer Str. 151-153
50672 Köln
Tel.: +49 221 5692 521
E-Mail: Leonid...@DeutschePost.de
[Anhang "3_response_confirmation-sterbedatenabgleich.xml" gelöscht
von Florian Stratil/WBG/VDRGS/DE] [Anhang
"1_request_daten_senden_sterbedatenabgleich.xml" gelöscht von Florian
Stratil/WBG/VDRGS/DE] [Anhang
"1_response_daten_senden_sterbedatenabgleich.xml" gelöscht von Florian
Stratil/WBG/VDRGS/DE] [Anhang
"2_request_anforderung_verarbeitung-sterbedatenabgleich.xml" gelöscht
von Florian Stratil/WBG/VDRGS/DE] [Anhang
"2_response_anforderung_verarbeitung_sterbedatenabgleich.xml" gelöscht
von Florian Stratil/WBG/VDRGS/DE] [Anhang
"3_request_confirmation-sterbedatenabgleich.xml" gelöscht von Florian
Stratil/WBG/VDRGS/DE]
Reply all
Reply to author
Forward
0 new messages