Heutiges Thema: Schnittstellen-Standards zum elektronischen Datenaustausch zwischen Applikationen (EDI)

Transkript

1 Heutiges Thema: Schnittstellen-Standards zum elektronischen Datenaustausch zwischen Applikationen (EDI)

2 Literatur Krüger, Reschke: Lehr- und Übungsbuch Telematik, Fachbuchverlag Leipzig 2002 Müller, Eymann, Kreutzer: Telematik- und Kommunikationssysteme in der vernetzten Wirtschaft, Oldenbourg 2003 Levi, Rembold: Einführung in die Informatik für Ingenieure... Diverse VDA-Richtlinien

3 Definitionen EDI: Electronic Data Interchange (elektronischer Datenaustausch), jede Form des Datenaustausches auf elektronischem Wege zwischen Anwendungs-Systemen über Systemgrenzen. DFÜ: Daten-Fern-Übertragung (im Prinzip dasselbe wie EDI, nur wird EDI meistens mit EDIFACT gleichgesetzt, was falsch ist.

4 Anforderungen Korrektheit (fehlerfrei, selbstkorrigierend, autom. Fehlererkennung) Vollständigkeit, Wiederholungsfreiheit, Transaktionsfähigkeit, Pufferung Einfachheit (geringe Komplexität, einfache Bedienung und Überwachung) Gute Automatisierbarkeit Transparenz (alle Datenformate, binär und zeichenorientert, Transport-Mechanismen für Programmierer unsichtbar) Zuverlässigkeit, Verfügbarkeit Sicherheit gegen Mithören und Manipulation

5 Schnittstellen-Kategorien Datei-Übertragungs-Verfahren Programm-zu-Programm-Kommunikation Datenbank-Integration Messages Transfer Systeme

6 Datei-Übertragung (Transfer) Punkt-zu-Punkt offline = Datenträger-Austausch Punkt-zu-Punkt online seriell (Modem usw.) File Transfer in Netzwerken (Inter/Intra/Extranet)

7 Punkt-zu-Punkt Transfer Punkt-zu-Punkt offline Datenträger-Austausch: CD-Rom, Diskette, Band, Memory-Stick, Barcode-Label mit voller Information,... Punkt-Zu-Punkt seriell Ascii-Zeichen ungesichert zmodem, xmodem, ymodem kermit uucp

8 File Transfer in Netzwerken ftp: File Transfer Protocol (Port 21/20) rcp: Remote Copy scp, sftp: Secure Copy, Secure FTP nfs: Network File System smb, samba: MS Windows Netzwerks-Funktionen für verteilte Filesysteme, Druck, Messageing. (allgemein): smtp, imap, pop Mailbox -Verfahren (X.400): Standard-MHS

9 Programm-zu-ProgrammKommunikation Direkte TCP/IP- bzw. ISO/OSI-Kommunikation Middleware-Systeme

10 Direkte TCP/IP-Schnittstellen Client/Server-Modell Peer-to-Peer Modell Nutzung der jeweils vom Betriebssystem bereitgestellten API's Verbindungsaufbau, Kommunikation, Abbau, Fehlerhandling liegen in der Verantwortung der Applikationen

11 Ablauf Socket-API C/S

12 Middleware Unter "Middleware" werden Software-Schichten in netzwerkfähigen Rechnern verstanden, die Dienste für verteilte Anwendungen liefern. Sie verdecken dabei, dass die darunter liegenden Schichten evtl. sehr verschieden und "nicht kompatibel" sind. Middleware ist die "Infrastruktur" für verteilte Anwendungen.

13 Schema Middleware im Netz Verteilte Anwendung Middleware Betriebssystem Netzwerk-Hardware Netzwerk Netzwerk-Hardware Netzwerk-Hardware Netzwerk-Hardware Betriebssystem Betriebssystem Betriebssystem Middleware Middleware Middleware Verteilte Anwendung Verteilte Anwendung Verteilte Anwendung

14 Middleware-Systeme RPC (remote procedure call) DCE (distributed computing environment) RMI (remote method invocation) CORBA (common object request broker arch.) COM (component object model) DCOM (distributed COM)

15 Datenbank-Integration Beide Applikationen teilen eine Datenbank Bestimmte Tabellen werden gemeinsam genutzt Rechteabgrenzung wichtig bei externen Partnern Nativer Zugriff: Embedded SQL (z.b. in "C") ODBC: Open DataBase Connectivity JDBC: JAVA DataBase Connectivity Performant, aber Sicherheits-Risiken!

16 Message Transport Systeme Garantie der Zustellung Was man absendet, geht nicht verloren Wenn Transport zum Empfänger scheitert, wird ein Operator alarmiert (siehe Netzwerks-Informations-Management bei SCM) Aufwändig und teuer durch Clearing-Server Meist bei Dienstleistern angesiedelt (IBM)

17 Was die Zukunft bringt... XML-RPC: Per http werden in XML codierte remote procedure calls an einen Server gesendet Die Antwort ist eine http-response mit einer AntwortDatenstruktur SOAP: Nachrichtenformat, Codierungsregeln, RPC und Transport-Bindungen.

18 Organisation von Datenaustausch-Schnittstellen hostcom: Beispiel einer einfachen Organisation für Batch-Schnittstellen. SAP R/3 RFC: Beispiel für Online-Kopplung (RPC-artig, aber mit anderen Mechanismen). Storagement Packplatz: Beispiel für Client-Server mit wenig Organisation außer Wiederaufsetzen nach einem Crash.

19 Datenformate CSV (comma separated values) Satzarten-Dateien mit festem Satzaufbau (gen_ls) Message-Dateien mit variablem Satzaufbau (EDIFACT, SAP IDoc): Hauptsegment, variable optionale Zusatzsegmente. Auszeichnungs-Sprachen: html, XML,...

20 Datenformat-Standards (1) EDIFACT: Electronic Data Interchange For Administration, Commerce and Transport. EDIFICE: Electronic Data Interchange für die ElektronikIndustrie. CEFICE: Electronic Data Interchange für die ChemieIndustrie. ODETTE: Organisation for Data Exchange by Teletransmission in Europe, VDA xxxx: Electronic Data Interchange für die (deutsche) Automobil-Industrie, wird ersetzt durch ODETTE-Standards.

21 Datenformat-Standards (2) TRADACOM: Trading Data Communication Standard. SWIFT: Society of Worldwide Interbank Financial Telecommunication. SEDAS: Standard-Regelungen einheitlicher Datenaustausch-Systeme. IDoc: Datenaustausch-Standard von SAP R/3. gen_ls: Generische Lieferauftrags-Schnittstelle, Beispiel für ein Inhouse-Format.

22 VDA-Empfehlungen Schnittstellen und Belege VDA 4905: Lieferabrufe VDA 4913: Lieferschein- und Transportdaten VDA 4920: Speditionsauftragsdaten Lieferant an Spediteur VDA 4921: Transportverfolgungsdaten Spediteur an Kunde VDA 4930: Lagerbestands- und Bewegungsdaten VDA 4902: Warenanhänger (barcodefähig) VDA 4912: DFÜ-Warenbegleitschein

23 Beispiel: VDA-Label (4913)

24 VDA Nachrichten und Belege im Zusammenhang

25 Szenario mit EDL

26 SAP Idoc-Struktur Control-Records Data-Records Parent Segment Child Segment Type 1 Child Segment Type 2 Child Segment Type 3 Administrative Part Data Segment Status-Records

27 Konverter, Mapping Die Formate können durch Konverter ineinander umgewandelt werden, z.b.: gen_ls (Inhouse Flat File) Konverter mit Inhouse->EDIFACT-Mappings EDIFACT-Messages X.400-Mailbox Konverter mit EDIFACT->Inhouse-Mappings Kunden-Inhouse-Format, z.b. SAP R/3 IDoc

28 Was ist XML? extensible Markup Language (Metasprache) Mit Hilfe von XML lassen sich alle DokumentenTypen beschreiben Dokumenttypdefinitionen (DTD) werden zur Festlegung benutzt Man kann beliebige Strukturen definieren Dokumenteninhalt, Formatierungsdaten und Struktur werden getrennt beschrieben

29 XML-Komponenten DTD: Document Type Description beschreibt die Struktur XML-Schema ist eine Fortentwicklung von DTD CSS (Cascading Style Sheets) beschreiben das Layout von html-seiten XSL (extensible Style Language) beschreibt das Layout von XML-Dokumenten Dadurch können Inhalte beliebig dargestellt werden.

30 Trennung von Struktur-, Inhaltsund Formatierungsdaten Formatierung Struktur DTD XML Schema XSL CSS DSSSL Inhalt XML SGML

31 DTD-Beispiel <!ELEMENT personen_tabelle (person)*> <!ELEMENT person (name, vorname, telefon?)> <!ATTLIST person person_nr ID #REQUIRED geschlecht (m w) #REQUIRED> <!ELEMENT name #PCDATA> <!ELEMENT vorname #PCDATA> <!ELEMENT telefon #PCDATA>

32 XML-Beispiel <?xml version= 1.0?> <!DOCTYPE personen_tabelle SYSTEM personen_tab.dtd > <personen_tabelle> <person person_nr= 10 geschlecht= m > <name> Schmidt </name> <vorname> Peter </vorname> <telefon> 030/ </telefon> </person> <person person_nr= 11 geschlecht= w > <name> Schmidt </name> <vorname> Ursula </vorname> </person> <person person_nr= 12 geschlecht= m > <name> Schmitt </name> <vorname> Hans </vorname> <telefon> 030/ </telefon> </person> </personen_tabelle> oder eher Nokia 8810?

33 Schnittstellen-Inhalte Durch Formate und Strukturen wird keine Aussage zu den tatsächlich zu übertragenden Inhalten gemacht. Man benötigt daher auf XML aufsetzende Standards, die (analog EDIFACT) die Inhalte vorgeben. Beispiele: BizTalk (Initiative von Microsoft) ebxml (Initiative von UN und OASIS), siehe

34 Aufgabe Machen Sie einen Lösungsvorschlag für eine auf Anwendungsebene sichere EDI-Lösung: Partner 1 sendet einen Auftrag an Partner 2. Partner 2 empfängt den Auftrag und verarbeitet ihn GENAU EIN MAL. Partner 2 meldet Partner 1 die Bearbeitung des Auftrages GENAU EIN MAL. Partner 1 reagiert angemessen: Wiederholung bei Verlust, Abhaken bei erfolgreicher Bearbeitung.

35 Details zur Aufgabe Wie sieht ein Auftrag in der Schnittstelle aus? Wie erfolgt die Übertragung physisch? Woran wird erkannt, dass die Übertragung erfolgreich war? Woran erkennt man, dass der Auftrag auch verarbeitet wurde? Wie wird wiederholt, und wie wird sichergestellt, dass der Auftrag nur einmal bearbeitet wird?