Prozessbeschreibungen Datenaustausch mit der Wechselplattform

Transkript

1 Przessbeschreibungen Datenaustausch mit der Wechselplattfrm Datum: Versin 1.0 Beteiligte Rllen / Kmpnenten (aus Kmmunikatinssicht): - Sender: Organisatin, die eine ebxml Nachricht zur Wechselplattfrm (WP) der direkt an den Empfänger versendet. - Empfänger: Organisatin, die eine ebxml Nachricht vn der WP der vm Sender empfängt. - Teilnehmer sind entweder Sender der Empfänger. - Wechselplattfrm (WP): Die WP wird vn der APCS betrieben, um den Lieferanten Wechselprzess bezüglich der Einhaltung vn Fristen zu überprüfen. Die agiert technisch gegenüber einem Sender als Empfänger bzw. gegenüber einem Empfänger als Sender einer ebxml Nachricht. - ebxml Nachricht: Ein Geschäftsdkument, das bilateral vm Sender zum Empfänger übertragen wird. - ( Service): Hauptkmpnente zur Übertragung vn ebxml Nachrichten, welche senderseitig die Validierung, Signierung, Kmpressin, Verschlüsselung und Versendung vn Geschäftsdkumenten durchführt. Empfängerseitig erflgt dies in entgegengesetzter Reihenflge. Der êbms befindet sich in der sicheren Zne des Netzwerkes eines Teilnehmers. - Nachricht: setzt sich zusammen aus dem ebxml Envelpe (grundsätzlich nicht verschlüsselt) und der Paylad (verschlüsselt). Teile des ebxml Envelpes können jedch verschlüsselt sein (WP spezifisch). Für die Paylad wird beim WP Przess immer die Verschlüsselung aktiviert. - SIA (Single Address): Eine bei der Kmmunikatin transparente zentreale Kmpnente, über die alle Teilnehmer ihren IP Datenstrm leiten. Die Verbindung zwischen einem Teilnehmer und dem SIA ist SSL gesichert (verschlüsselt und authentisiert). Im SIA liegt der ebxml Envelpe unverschlüsselt vr, die Paylad ist für den SIA nicht entschlüsselbar. Hauptzweck des SIA ist, den physischen IP Verkehr auf eine Adresse zu knzentrieren, s dass Teilnehmer nicht für die Adresse eines jeden Kmmunikatinspartners die Firewall öffnen müssen. Generelle IKT Sicherheitsanfrderungen der Teilnehmer Damit ein Teilnehmer den Lieferantenwechselprzess zukünftig über die Pntn Plattfrm abwickeln darf, muss er ein Mindestmaß an IKT Sicherheit erfüllen. Zu diesem Mindestmaß zählen Etablierte IKT Sicherheitsrganisatin innerhalb der betrffenen Organisatin

2 Einsatz vn Schutzkmpnenten zur Erhöhung der IKT Sicherheit (Installierte Malwarescanner auf den jeweiligen Arbeitsstatin, welche am Datenaustausch beteiligt sind, Firewallknzept, ) Diese Anfrderungen gelten auch für die WP. Vrgaben an Datenaustausch für den Lieferantenwechselprzess Bei der Abwicklung des Lieferantwechselprzesses sllten flgende Kriterien erfüllt sein: Verschlüsselung der Inhaltsdaten (enthält eigentliches Dkument, welches über die Wechselplattfrm ausgetauscht werden sll) sdass nur der Empfänger Zugriff auf die Inhaltsdaten hat. Ein Teil der ebxml Headerinfrmatin wird ebenfalls verschlüsselt, auf der zentralen Plattfrm sll jedch aus Gründen der Beweisbarkeit Zugriff darauf bestehen. Dies ist der Fall durch eine spezielle Erweiterung der Mappinglgik Eine Verschlüsselung der Kmmunikatinsstrecken Sender WP und WP Empfänger erflgt mit SSL. Signierung der Nachrichten durch die Teilnehmer erflgt durch eine XML Signatur. Ablauf einer ebxml Übertragung End t End Erflgreiche Übertragung ( Happy Path ) Für die flgende Beschreibung einer EDA Datenübertragung wird angenmmen, dass die beteiligten des Senders und des Empfängers mit den jeweiligen Back end Systemen verbunden sind. Dies kann je nach Prdukt auf unterschiedliche Weise erflgen: Durch die Verwendung eines Ht Flders für eingehende und ausgehende Dkumente Durch die Verwendung einer prduktspezifischen API Durch die Verwendung einer EDA spezifischen WebServcie Schnittstelle. Hierbei hat swhl der als auch die Back end Anwendung ihren jeweiligen Teil der Services zu implementieren. Diese Schnittstelle ist in einem separaten Dkument spezifiziert. Die nachflgende Przessbeschreibung knzentriert sich auf den Übertragungsweg zwischen Sender und Empfänger. W nötig wird auf die Web Service Schnittstelle Bezug genmmen. 1. Die Back end Applikatin des Senders erzeugt intern ein ebutilities Dkument und führt einen Aufruf der Methde sendmessage() beim WebServcie des durch. Dabei wird eine XML Struktur als Parameter des WS Aufrufs übergeben, die eingebettet das ebutilities Geschäftsdkument enthält. In anderen Przessen als dem Wechselprzess (P2P Übertragung zwischen EDA Teilnehmern) muss dies jedch nicht zwingend ein XML Dkument sein (es kann sich beispielsweise auch um ein MSCONS der Binärdkument handeln). 2. Der extrahiert die zu übertragende Paylad. Weitere Parameter, die evtl. mit dem WSDL Aufruf erhalten wurden, werden ebenfalls im Envelpe für die Übertragung gesetzt. 3. Der führt verschiedene Przessschritte für den Versand einer ebxml Nachricht durch und versendet die Nachricht an die WP. Abweichend vn der üblichen Verarbeitung erflgen flgenden Schritte: Seite 2

3 a. Die Verschlüsselung der Paylad erflgt nicht für die WP, sndern für den Empfänger. Hierbei wird der AT Cde aus <Receiver> in übernmmen. b. Ein Teil des ebxml Headers wird für die WP verschlüsselt ( Transaktinsdaten ). Dieser wird als zusammenhängende XML Substruktur aus dem Paylad Dkument kpiert. c. Als Empfänger der Übertragung (ebxml Evelpe Element <T>) wird der AT Cde WP eingetragen. 4. Die WP verarbeitet die Nachricht und antwrtet mit einem ebxml Ack, sbald die Nachricht erflgreich validiert und persistiert werden knnte. 5. Das ebxml Ack wird vm des Senders verarbeitet und an die back end Applikatin weiter geleitet. 6. Nach Schritt 4 verarbeitet die WP das Geschäftsdkument fachlich. Insbesndere leitet sie es weiter an den Empfänger. Dabei wird ein neuer ebxml Envelpe erzeugt und neben den Transaktinsdaten ( verschlüsselt für den Empfänger) nch der Empfangszeitstempel der WP eingetragen (als Teil vn <HubDirectry>, ebenfalls verschlüsselt für den Empfänger). Diese Daten werden mit dem ebutilities Namespace ( in den ebxml Envelpe eingebettet, das Namespace Kürzel ist eda. Der Zeitstempel der Wechselplattfrm wird mit dem Namespace und dem Kürzel wp eingebettet. Die WP versendet nun eine ebxml Nachricht an den Empfänger mit beiden Erweiterungen des Envelpes. Diese Nachricht enthält: a. Die vm Sender empfangene Paylad (verschlüsselt für den Empfänger) wird 1:1 durchgereicht hne zusätzliches Validieren / Signieren Kmprimieren / Verschlüsseln durch die WP. b. Die unveränderten Transaktinsdaten des Senders als Einbettung in den ebxml Envelpe. c. Die Sektin <HubDirectry> mit ihren Subelementen der WP als Einbettung in den ebxml Envelpe. 7. Der empfangende a. Validiert die XML Signatur der WP b. entschlüsselt und dekmprimiert die Paylad, validiert sie und persistiert das Geschäftsdkument. c. Die Paylad wird zusammen mit den beiden d. Ein ebxml Ack wird an die WP zurück geliefert. 8. Der des Empfängers liest den Empfangszeitstempel der WP aus und gibt diesen zusammen mit der Paylad und den Transaktinsdaten weiter an die Back end Applikatin des Empfängers im Falle der WebService Schnittstelle durch den Aufruf ReceiveMessage(). Seite 3

4 3 1 2 Teilnehmer A 4 ebxml Ack 6 5 êbxml Ack 7 WP 8 Teilnehmer B Flgende Fehlersituatinen sind denkbar und werden entsprechend behandelt: 1. Der EbMS des Senders liefert eine Fehlermeldung bei der Vrbereitung für den Versand. - Hierbei liefert die Adapter API eine Fehlermeldung an das Back end. - Nach Fehlerbehebung muss die Back end Applikatin die Übertragung wiederhlen. Teilnehmer- (WP) WP- Mögliche Gründe für Fehlermeldungen vr Versand sind: - Dkument knnte nicht Validiert werden - Dkument knnte nicht signiert werden - Dkument knnte nicht für den Empfänger verschlüsselt werden - Sender der Empfänger Cdes sind nicht knfiguriert - Weitere erfrderliche Cdes sind nicht vrhanden der falsch 2. Die Versendung der Nachricht an die WP scheitert. Hierbei versucht der EbMS des Senders entsprechend der einheitlich vereinbarten Wiederhlversuche, die Nachricht erneut zu übertragen. - NumberOfRetries = Wiederhlversuche = 2, - RetryInterval = Timeut Spanne bis zum nächsten Wiederhlversuch. Dabei sllte das Wiederhlmuster den Anfrderungen der Wechselverrdnung angepasst sein, d.h., die Anzahl der Wiederhlversuche ist 2, die TimeTLive ist 15 Minuten: - Erste Wiederhlung: 1 Minute nach dem ersten Übertragungsversuch - Zweite Wiederhlung: 8 Minuten nach dem ersten Übertragungsversuch Seite 4

5 - Abbruch der Übertragung: 15 Minuten nach dem ersten Übertragungsversuch. Scheitern diese Übertragungsversuche, wird der Back end Applikatin ein Fehler gemeldet. Nach Fehlerbehebung muss die Back end Applikatin die Übertragung wiederhlen. Teilnehmer- (WP) WP- Gründe für einen Übertragungsfehler können sein: - Der Kmmunikatinspartner ist nicht erreichbar - Die eigene der die gegenseitige Firewall ist falsch knfiguriert - Prbleme beim Aufbau einer SSL Verbindung (Z.B. wegen abgelaufener Zertifikate) - Der des Kmmunikatinspartners läuft nicht der auf einer falschen IP Adesse bzw. Prtnummer. 3. Die WP liefert eine Fehlermeldung in Frm einer ebxml ErrrMessage. Die Fehlerursache kann hier beispielsweise sein: - Validierungsfehler der Transaktinsdaten - Fehler bei Überprüfung der Signatur (Zertifikat abgelaufen?) - Fehler bei Entschlüsselung (z.b. Falscher Schlüssel bei Sender verwendet?) - Time t Live abgelaufen - Partner ID unbekannt - Fachliche Fehler, welche die WP überprüft ebxml errr Teilnehmer- (WP) WP- 4. Beim Zustellen der Nachricht zum Endempfänger tritt ein Übertragungsfehler auf. Seite 5

6 Ein slcher Übertragungsfehler sllte in der Sphäre der WP und des Empfängers gelöst werden. Ggf. durch Nachsenden der Nachricht vn der WP an den Empfänger nach Behebung der Fehlerursache. Bei der Kmmunikatin zwischen WP und Empfänger können prinzipiell die gleichen technischen Fehler auftreten wie ben in den Schritten 1 3 beschrieben. Teilnehmer A ebxml Ack ebxml errr WP Teilnehmer B 5. Beim Empfänger tritt ein Fehler auf, den er per ebxml ErrrMessage an die WP meldet. Alle fachlichen Fehler, die sich auf die ebutilities Dkumente beziehen, können nicht zwischen WP und Empfänger behben werden, daher muss auch der Sender über diese Fälle infrmiert werden. Hierbei muss die WP anhand der Fehlercdes der ebxml ErrrMessage feststellen, b es sich um einen fachlichen Fehler handelt. Die WP schickt in diesem eine fachliche Fehlermeldung an den Sender (unter Verwendung des ebutility Fehlerdatensatzes, Schema: Ntificatin ). Wenn diese Nachricht an den des Empfängers geleitet wird, übermittelt er den Fehlerdatensatz an seiner Back end Schnittstelle nicht als fachliches Dkument an die Back End Applikatin, sndern über die lkale Schnittstelle zur Fehlerbenachrichtigung als eine gescheiterte Übertragung (WS Aufruf backendrespnse() ). Sender und Empfänger haben nun die Diskrepanzen ihrer Knfiguratinen zu klären und anschließend das Dkument neu zu übertragen. Teilnehmer A ebxml Ack Validatin errr WP ebu-ntificatin Teilnehmer B Es wird hierbei als in Kauf genmmen, dass eine Übertragung zunächst vn der WP psitiv bestätigt, nachträglich jedch ein fachlicher Fehler gemeldet wird. Der Grund, dass bei EDA dennch ein ptimistischer Ansatz gewählt wurde ist, dass diese Situatin praktisch nur nach Knfiguratinsänderungen auftreten kann (z.b. Empfänger validiert gegen eine andere Seite 6

7 Schemaversin als der Sender). Insfern wäre eine bligatrische, spätere Empfangsmeldung des Empfängers an den Sender in der überwiegenden Mehrheit aller Übertragungen redundant. Erfrderliche Knfiguratin der beteiligten Services: Im Flgenden wird die Übertragung vn Dkumenten im Rahmen des Wechselprzesses beschrieben, bei denen ein Ruting über die WP erflgt. Schritt 1: Übertragung an WP Schritt 2: Weiterleitung an Empfänger Lgischer Sender A Empfang WP Versand Lgischer Empfänger B PartyID/Frm = A PartyID/Frm = A PartyID/Frm = WP PartyID/Frm = WP PartyID/T = WP PartyID/T = WP PartyID/T = B PartyID/T = B SupplierChangeRequest SupplierChangeRequest SupplierChangeRequest SupplierChangeRequest XML Validatin = Yes XML Validatin = N XML Validatin = N XML Validatin = Yes Appl Signatur = N Appl Signatur = N Appl Signatur = N Appl Signatur = N Cmpressin = Yes Decmpressin = N Cmpressin = N Decmpressin = Yes Encryptin = Yes Decryptin = N Encryptin = N Decryptin = Yes XML Signature = Yes XML Signature = Yes XML Signature = Yes XML Signature = Yes <HubDirectry> <HubDirectry> Falls die Übertragung direkt erflgt zwischen Sender und Empfänger, dann gilt flgende Parametrisierung: Lgischer Sender A PartyID/Frm = A PartyID/T = B MveOutRequest XML Validatin = Yes Appl Signatur = Yes Cmpressin = Yes Encryptin = Yes XML Signature = Yes Lgischer Empfänger B PartyID/Frm = A PartyID/T = B MveOutRequest XML Validatin = Yes Appl Signatur = Yes Decmpressin = Yes Decryptin = Yes XML Signature = Yes Knfiguratin und standardisierte Einrichtung für OE Teilnehmer Elemente des Header: <eb:frm>/<eb:partyid>: AT Nummer des Senders, XML Attribut type = "ATCde" (die WP besitzt dazu eine eigene AT Nummer) < eb:t>/< eb:partyid>: AT Nummer des Empfängers, XML Attribut type = "ATCde" < eb:cpaid>: nicht verwendt, aber gefüllt mit Dummy. < eb:cnversatinid> nicht verwendt, aber gefüllt mit Dummy. Seite 7

8 < eb:service>: nicht verwendt, aber gefüllt mit Dummy. < eb:actin>: nicht verwendt, aber gefüllt mit Dummy. XML Signatur verwenden für MessageHeader, Paylad und Attachment(s) < eb:ackrequested>: aktiviert < eb:messageid>: wird aus Paylad Dkument vn MessageNumber übernmmen < eb:syncreply>: aktiviert <NumberOfRetries>: 2 RetryInterval: gestaffelt mit 2 Retries: nach 60 Sekunden nach 8 Minuten Timeut nach 15 Minuten. Das Ziel ist hierbei, einerseits schnell eine Nachricht nachzusenden, falls dies nicht mit dem ersten Versuch klappte, gleichzeitig aber auch die Frist vn 15 Minuten im Falle einer längeren Verzögerung auszunutzen. <eb:duplicateeliminatin>: Aktivieren Ein Acknwledgement besitzt eine eigene MessageID und eine Referenz auf die Original MessageID des Senders. Manifest Parameter zur Identifizierung vn paylads, z.b. ist dies für den Wechseldatensatz (SupplierChangeRequest): eb:lcatin= " Rest bleibt wie die Standardknfiguratin Für ebxml genutztes Transprtprtkll: https Signatur auf Anwendungsebene bei Peer t Peer Przessen: SMIME Signatur bei WP Przess: keine Signatur Zertifikats Schlüssellänge: 2048 Jeder Teilnehmer beantragt zwei Zertifikate eines für die XML Signatur (bzw. die Anwendungssignature im Falle der Peer t Peer Kmmunikatin) eines für SSL hash Länge: 512 Bit Algrithmus zur Dkumentenverschlüsselung: RSA mit AES256 Algrithmus zur Datenkmpressin: ZIP Einheitliche Verwendung vn XML Schema Sets muss sichergestellt werden, z.b. durch ein zentral durchgeführtes Patch Verfahren. Weiterhin sllte der Zeichensatz für übertragene Dateinamen vereinheitlicht werden. Zeichensatz z.b.: [A Z] [a z] [0 9] _ Maximalen Dkumentgröße: 300 KB (dies ist eine Knventin, keine technische Einschränkung. Ein XML Dkument muss mit flgendem Header beginnen z.b: <?xml versin="1.0" encding="utf-8"?> <CntractlessStateCnfirmatin xmlns=" xmlns:xsi=" xsi:schemalcatin=" CntractlessStateCnfirmatin.xsd"> Seite 8

9 Weitere Richtlinien (gilt auch für den Betrieb der WP): - Ablaufende Zertifikate müssen 4 Wchen vr Ablauf erneuert werden. - Während dieses Zeitraums sind zwei Zertifikate gültig. Anfrderungen an die WP: - Validierungs, Entschlüsselungs, Dekmpressins Fehlermeldungen (End t End Fehler) des Empfängers werden als ebxml ErrrMessage an die WP geliefert (Errr Cdes sind 15, 35 und 31). Verantwrtlich für diese Fehlermeldung ist jedch in den meisten Fällen der Sender. Daher muss die WP in slchen Fällen ein fachliches Fehlerdkument an den Sender schicken (Basis: ebutilities ErrrNtificatin). - Hierbei hat die WP den Fehlercde des Empfängers zu analysieren im Falle eines End t End Fehlers ist eine Nachricht mit flgendem Inhalt an den Sender zu schicken: <?xml versin = "1.0"?> <Ntificatin xmlns=" xmlns:xsi = " xsi:schemalcatin = > <MarketParticipantDirectry SchemaVersin = "01r00" DcumentMde = "Prd" Duplicate = "false"> <RutingHeader> <Sender>AT0000WP</Sender> <Receiver>AT000001</Receiver> <DcumentCreatinDateTime> T18:39:09 </DcumentCreatinDateTime> </RutingHeader> <Sectr>01</Sectr> <PrcessStep>TE</PrcessStep> <InstallatinID>AT </InstallatinID> <CaseID>123</CaseID> </MarketParticipantDirectry> <PrcessDirectry> <MessageNumber>1</MessageNumber> <PrcessReferenceNumber>3h4g5f3d55hjj5</PrcessReferenceNumber> <RespnseData RespnseCdeGrup= TERR01 > <RespnseCde>31</RespnseCde> </RespnseData> </PrcessDirectry> </Ntificatin> Hierbei sllten die Werte durch die WP wie flgt eingesetzt werden: - DcumentMde, Duplicate, Sectr, PrcessStep, InstallatinID, CaseID, PrcessReferenceNumber = entsprechend dem Originaldkument - Sender = WP - Receiver = Ursprünglicher Sender - DcumentCreatinTime = Erstellungszeitstempel für dieses Fehlerdkument seitens der WP - MessageNumber = neu vergeben durch die WP - RespnseData = (TERR01 = Technical Errr, Fehlercde wie ben beschrieben). Seite 9

10 Die Wechselplattfrm muss die Zertifikate aller der Teilnehmer (SSL und Anwendungszertifikat) vrhalten, um Signaturen zu überprüfen, und Sitzungsschlüssel zu erlangen. Umgekehrt muss die WP ihre Zertifikate (Anwendungsebene und SSL, einschließlich ggf. der erfrderlichen Rt Zertifikate) den Teilnehmern zur Verfügung stellen. Seite 10