EDI-WISSEN Das praktsche Handbuch für den elektronschen Geschäftsverkehr
En Servce von EDI Wssen Das praktsche Handbuch für den elektronschen Datenverkehr Pöckng, März 2015 Alle Rechte am Werk legen be Lobster GmbH Hndenburgstraße 15 D-82343 Pöckng En Tteldatensatz für dese Publkaton st be der Deutschen Natonalbblothek erhältlch. Erstauflage Text: Sascha Raubal Gestaltung: Barbara Elmer, Redcat-Desgn Druck & Bndung: Stulz Druck Meden, München ISBN: 978-3-00-048853-5 Alle Rechte vorbehalten. Nachdruck, auch auszugswese oder unter Verwendung elektronscher Systeme, ncht gestattet. 2
En Servce von 3
En Servce von ALLGEMEINES Allgemenes > E-was?? Das fröhlche Buzzword-Bngo 8 > Brauche ch so was? 10
En Servce von Konzepte > EAI 15 > EDI 19 > ESB 38 > ETL / ELT 39 > SOA 42 > EDI, EAI und darüber hnaus 44 5
En Servce von Datenformate & Nachrchtenstandards > UN / EDIFACT 53 > Fx Record 67 > XML 78 > CSV 95 > IDoc 99 > ANSI ASC X12 104 > ENGDAT 108 > Sonstge 111 6
En Servce von Kommunkatonswege, Datenquellen & -senken > Eher öffentlche Wege 118 > Eher nterne Wege/ Quellen/Senken 143 > Sonstge 158 7
En Servce von ALLGEMEINES E-was?? Das fröhlche Buzzword-Bngo In desem Handbuch stellen wr Ihnen Konzepte vor, de alle das Zusammenspel verschedener Tele der IT-Landschaft enes oder mehrerer mtenander n Bezehung stehender Unternehmen behandeln. So wollen wr Lcht n de unzählgen Abkürzungen, Schlagworte und Marketng-Begrffe brngen. Zu jedem deser Konzepte fnden Se mehr Informatonen auf den weterführenden Seten. EAI EAI steht für Enterprse Applcaton Integraton. Das Wort Enterprse ment dabe Unternehmen. EAI bedeutet, de verschedenen Anwendungen nnerhalb enes Unternehmens zu ntegreren, sprch: mtenander zu vernetzen. Und zwar ncht, ndem man jeder enzelnen Anwendung bebrngt, mt jeder anderen zu reden. Velmehr schafft man ene Zwschenschcht, ene Art gemensame Kommunkatonsplattform, an de de verschedenen Anwendungen angeschlossen werden (ndem man Kommunkatonsschnttstellen aka Adapter schafft), sodass praktsch jeder mt jedem kommunzeren und zusammenarbeten kann. Außerdem werden her de Prozesse, de Regeln der Zusammenarbet, defnert. EAI: Schnttstellen vorher EAI: Schnttstellen nachher EAI EDI EDI st de Abkürzung von Electronc Data Interchange, zu Deutsch elektronscher Datenaustausch. Schent banal zu sen, st aber recht komplex. Man könnte sagen, schon das Senden enes Fax st en elektronscher Datenaustausch, denn mmerhn wrd das Fax, das Daten enthält, auf elektronschem Wege übermttelt. Deses Bespel hat allerdngs weng mt dem EDI zu tun, um das es her geht. EDI ment, dass sch Applkatonen, also Programme, wetgehend automatsch mtenander austauschen, und zwar über Unternehmensgrenzen hnweg. Also ganz ähnlch we EAI, nur zwschen zwe oder mehr Frmen und ncht nnerhalb ener Frma. Wenn bespelswese de Software enes Kunden ene Bestellung drekt als Date zum Leferanten schckt, wo dese ohne Engrefen enes Menschen n dessen Bestellsystem landet, dann haben wr es mt EDI zu tun. 8
En Servce von ESB ESB ment Enterprse Servce Bus, und das st etwas eher stellen Schwammges. wr Ihnen enge En ESB Konzepte st en Konzept, vor, de Her alle ene etwas Technologe, mt dem ene Zusammenspel Infrastruktur verschedener ene Tele Software, der IT-Landschaft um de Integraton enes oder verschedener auch meh- oder auch rerer Anwendungen mtenander nnerhalb Bezehung enes stehender Unternehmens, Unternehmen ener Abtelung zu tun oder haben. enes Enfach, Projektes damt zu mal unterstützen. Der n ESB dese st also gruslgen das, was Abkürzungen, be EAI unten Schlag- drunter etwas Lcht worte legen und kann. Marketng-Kampfbegrffe Er verbndet verschedene kommt. Anwen- Zu ESB: ENTERPRISE SERVICE BUS jedem dungen deser über Adapter Konzepte mtenander, fnden Se dann transportert natürlch Daten noch wesentlch zwschen hnen mehr und Informatonen hlft auch bem auf den Umbau weterführenden (der Transformaton) Seten, der unter Daten, dem damt Menüpunkt sch de Konzepte. Systeme unterenander verstehen. Er hat aber kene Ahnung von komplexeren Zusammenhängen und Geschäftsprozessen, denn EAI ab da bewegen wr uns weder m EAI-Berech. EAI steht für Enterprse Applcaton Integraton. Das Wörtchen Enterprse ment dabe egentlch ETL/ELT nur Unternehmen. Klngt aber selbst für ncht-scf-fans rgendwe unglaublch De Abkürzung wchtg, oder? steht Zu für Deutsch Extract, heße Transform, das ganze Load ETL: Prozess also und Unternehmensanwendungsntegraton st glechbedeutend mt: Daten aus enem (und würde oder mehreren sch UAI abkürzen). Systemen holen (extraheren), Extrakton Laden EAI umformen bedeutet (transformeren) enfach, de verschedenen und n en Anwendungen Zelsystem üblcherwese nnerhalb enes ene Unternehmens Datenbank zu laden ntegreren, Transformaton (egentlch sprch: müsste mtenander man eher zu spechern vernetzen. sagen, Und zwar aber naja). ncht, ELT ndem ment man dasselbe, jeder enzelnen nur n veränderter Anwendung Rehenfolge. bebrngt, Da mt werden jeder anderen de Daten zu erst reden, n de sondern Datenbank ndem gepumpt man ene und Zwschenschcht dann transformert. schafft, Das ene Ganze Art kommt gemensame aus der Kommunkatonsplattform, Ecke des Data Warehouse. Und an de dessen de verschedenen Snn wederum Anwendungen legt darn, Daten angeschlossen aus verschedensten werden (ndem Quellen und man Kommunkatonsschnttstellen Systemen enhetlch aufberetet aka Adapter z.b. für Analysen schafft), sodass und Statstken letztlch beretzustellen. praktsch jeder mt Dese jedem Enhetlchket kommunzeren wrd durch und de zusammenarbeten Transformaton errecht, kann. Außerdem de ncht nur werden de verschedenen de Prozesse, Formate de Regeln der Quellsysteme der Zusammenarbet, n en enhetlches her defnert. Format für de Datenbank umbaut, sondern EDI dabe auch glech noch de Datenqualtät verbessert (Dubletten elmnert und ähnlches). EDI SOA st de Abkürzung von Electronc Data Interchange, zu Deutsch also Elektronscher Datenaustausch. SOA st ene Servce Schent Orented erst mal banal Archtecture, zu sen, also st aber ene etwas denstorenterte komplzerter. Archtektur. Gement Man könnte st damt, sagen, dass auch vele das verschedene, Senden enes womöglch Fax st en über elektronscher de ganze Welt Datenaustausch, verstreute, Anwendungen denn mmerhn ene wrd Schnttstelle das Fax, das beretstellen, Daten enthält, über ja de auf man elektronschem Denste von Wege hnen übermttelt. anfordern Das kann. hat Das aber kann ganz allgemen und global de Berechnung der Entfernung zwschen zwe Koordnaten sen oder ganz spezell nur m Frmennetzwerk de Anfrage, wann welcher LKW für ene Ausleferung beretsteht. Wll man tatsächlch Waren lefern, braucht man ALLGEMEINES 9
En Servce von ALLGEMEINES womöglch bede Denste n Kombnaton, daher kann es enen weteren Denst geben, der de beden anderen "unter der Haube" aufruft. We der jewelge Denst mplementert st, muss nemanden kümmern. Man sollte nur wssen, we er zu nutzen st. Und deshalb muss enzg de Schnttstelle des Denstes zur Außenwelt bekannt sen. En Bespel herfür snd WebServces für den Datenaustausch. Brauche ch so was? Wenn Se sch das Buzzword-Bngo durchgelesen haben, besser noch de detallerteren Beschrebungen der enzelnen Konzepte, dann wssen Se jetzt m Groben, was es mt Begrffen we EDI, EAI oder SOA auf sch hat. Nun st de Frage, ob Se selbst "so was" brauchen können und wenn ja, was denn genau. 1. Frage: We seht Ihre IT-Landschaft aktuell aus? Es gbt nach we vor Unternehmen, be denen de IT aus en paar PCs mt Offce-Paket und EMal-Programm besteht. Bestellungen kommen telefonsch oder per Fax, Bestände hat der Lagerst m Kopf und Leferschene werden manuell ausgefüllt. Größere IT-Systeme? Fehlanzege. Wenn das gut läuft und ken Geschäftspartner nach EDI-Prozessen verlangt, können Se das Thema erst enmal abhaken und deses Handbuch besete legen. De mesten Frmen arbeten heute allerdngs ncht mehr so, und wenn man ene gewsse Größe errecht hat (oder mt entsprechend großen Geschäftspartnern arbetet), blebt rgendwann nchts anderes übrg, als enen Geschäftsvorgang nach dem anderen zu dgtalseren. Und we schon n der EAI-Beschrebung angesprochen, gescheht das oft Stück für Stück. Irgendwann hat man dann ene bunte Sammlung von IT-Systemen, de alle unterschedlche Datenformate und Schnttstellen haben und sch erst mal so gar ncht mtenander verstehen. Vellecht snd Se über dese Phase schon hnaus und haben n den letzten Jahren en Sammelsurum von C-Programmen, Shell-Scrpten oder gar Excel-Macros gebastelt, um rgendwe Daten von enem System zum anderen zu bekommen. Ncht zu vergessen de großen Kunden oder Leferanten, de Ihnen set enger Zet enfach Daten n enem (von denen!) bestmmten Format aufbürden. Da dese nun mt Strafzahlungen drohen, wenn Se hnen ncht endlch Ihre Daten m selben Format zusenden, steht berets der Programmerer n den Startlöchern, um auch herfür neue Programme und Scrpte zu strcken, von denen jedes rgendwe (en Glück, wenn er n enem halben Jahr selbst noch weß, we) ene spezelle 10
En Servce von Aufgabe erledgt. Und kommt en Geschäftspartner mt etwas anderen Anforderungen, snd de nächsten paar tausend Codezelen fällg. Btte: Zehen Se de Notbremse! Se kommen ja n Teufels Küche, wenn Se so wetermachen! Ganz davon zu Schwegen, was passert, wenn der Programmerer ausfällt. Zumndest be Ihnen. Dann stehen Se da mt Unmengen von Sourcen und ohne de gerngste Ahnung, was da m Hntergrund abläuft. Oder, we Se jemals etwas daran ändern sollen. ALLGEMEINES 2. Frage: We genau snd Ihre Anforderungen für de Zukunft? Was passert bs jetzt m Raum zwschen den enzelnen IT-Systemen und zwschen Ihrem Unternehmen und der Außenwelt? Das sollten Se erst mal gründlch analyseren. Fndet Kommunkaton mt der Außenwelt praktsch ncht statt? Dafür snd aber Daten zwschen Ihren egenen Systemen zu transporteren und abzuglechen? Das geht n Rchtung EAI, evtl. auch ETL. Kommen Bestellungen von draußen ren und müssen Bestellbestätgungen, Leferschene und Rechnungen verschckt werden? Geben Se regelmäßg elektronsche Kataloge an Ihre Kunden raus? Haben Se LKWs auf der Straße, deren Postonen zu ermtteln snd (über GPS-Denste)? Wann mmer Daten von außen zu Ihnen und umgekehrt fleßen sollen, st das en EDI-Thema. Welche Art von Systemen steht be Ihnen so rum? Datenbanken? SAP? Ältere WaW-Software, de nur propretäre Dateformate ex- und mporteren kann? Das entschedet, we und womt en evtl. zu beschaffendes EAI- oder EDI-System kommunzeren können muss. Und we sprcht de Außenwelt mt Ihnen? Bsher bekommen Se Excel-Dateen? Blebt das so? Sollte das System ncht auch allgemene Standards beherrschen, um für de Zukunft gerüstet zu sen? Also EDIFACT, X12, XML etc.? Läuft alle Kommunkaton per Mal oder snd schere Übertragungswege we AS2 oder SSH-baserte Kommunkaton gefordert? Dese Punkte entscheden, was das zu beschaffende System können muss. Und wenn Se so drüber nachdenken kommt enges zusammen, oder? En spezelles EDI- oder EAI-System recht vellecht ncht mehr, da de Aufgaben beder Bereche abgedeckt werden müssen. Oh, ncht zu vergessen der regelmäßge Abglech zwschen en paar nternen Datenbanken, en ETL-Thema. Und dann gbt s da ja noch Ihre Kunden, de gerne Anfragen z.b. zu aktuellen Lagerbeständen an Se schcken möchten, was sch mt WebServces wunderbar erschlagen lässt. Dann können Se entweder mehrere, auf den jewelgen Berech spezalserte Tools ensetzen oder aber en enzges, das zwar vellecht ncht mmer an de Bestlestungen von Spezaltools heranrecht, dafür aber alles unter enem Dach verent. 11
En Servce von ALLGEMEINES 3. Frage: Was soll das jewelge Tool noch beten? Abgesehen von den Fähgketen m EAI-, EDI- oder ETL-Berech gbt es auch noch andere Aspekte zu beachten: Darf das neue Tool en ganz bestmmtes System voraussetzen (Lnux/Unx, Wndows, gar AS400/Seres) oder erwarten Se, dass es plattformunabhängg st? We st de Bedenbarket? Muss man erst ene Art Programmersprache erlernen, bevor man de Software überhaupt zum Arbeten bewegen kann, oder stehen de fachlchen Dnge m Vordergrund, während de Bedenung eher ntutv erfolgt (be desem Punkt sollte man allerdngs bedenken, dass EDI und EAI hochkomplexe Prozesse benhalten, de selbst en Fachmann ncht mt lnks "zusammenklckt" - also btte kene zu hohen Erwartungen an de Intutvtät!)? We seht das Montorng aus? Hat man mmer enen guten Überblck, ob alles rund läuft oder rgend etwas hakt und man engrefen muss? Werden Se be Problemen aktv vom System benachrchtgt? Be geschäftskrtschen Daten kommt es auch auf Datenscherhet an. Können z.b. Rechnungen über de gesetzlch geforderte Frst archvert werden? Werden alle wchtgen Daten und Logs für Nachforschungen grefbar gehalten? Gerade m EDI-Umfeld können wetere, spezelle Anforderungen dazukommen. Zum Bespel glt n engen Ländern mmer noch de Pflcht zur dgtalen Sgnatur bestmmter Daten (besonders Rechnungen). Innerhalb Deutschlands st de Pflcht ja zum Glück schon längst weder abgeschafft, aber wenn man mt bestmmten anderen Ländern Geschäfte macht, muss en Sgnatursystem angebunden werden können. Und: En Standard-Tool betet oft ene scher unüberblckbare Fülle von Funktonen, doch we es der Teufel wll, haben Se noch ene ganz bestmmte Anforderung, de sch damt ncht "out of the box" erfüllen lässt. Bestehen dann Möglchketen, das System selbst zu erwetern? Ncht jeder hat enen Programmerer m Haus, aber wenn, dann sollte de engesetzte Software doch Schnttstellen beten, über de man sch enklnken und egene Erweterungen unterbrngen kann. Oder betet zumndest der Hersteller an, solche Erweterungen für Se zu entwckeln? Last but not least: We seht s mt dem Support aus? We schnell reagert der Hersteller auf Probleme? Hlft er auch be enfacheren Fragen weter? Was hört man so über hn? 12
En Servce von Ist Ihnen be Frage 1 aufgefallen st, dass so en Tool gar kene schlechte Idee wäre? Dann überdenken Se de Punkte zu Frage 2 und 3 gut. Wenn se wssen, was Se von der Software erwarten, de Se suchen, schauen Se sch auf dem Markt um, lassen sch von den verschedenen Herstellern Ihre wchtgsten Szenaren bewerten (Geht es überhaupt? We vel Aufwand st es?) und schauen Se, welches Produkt de mesten Ihrer Wünsche erfüllt. Kann sen, dass es ncht das bllgste st, aber besser Se nvesteren enmal rchtg, als mmer weder mt Mehrarbet, Pannen und Zetverlust dafür zu büßen, das falsche Programm gekauft zu haben. ALLGEMEINES Zur Abrundung können Se sch auch m Netz oder be anderen Unternehmen Ihrer Branche umhören, ob jemand enes der favorserten Produkte kennt und was er über Produkt, Hersteller, Support usw. aus egener Erfahrung zu sagen hat. Auch de EDI-Experten der Lobster GmbH stehen Ihnen be allen Fragen rund um EDI und EAI zur Sete (nformaton@lobster.de). 13
En Servce von ALLGEMEINES Konzepte KONZEPTE > EAI 15 > EDI 19 > ESB 38 > ETL / ELT 39 > SOA 42 > EDI, EAI und darüber hnaus 44 14
En Servce von EAI Was st EAI? In enem Unternehmen sammelt sch m Laufe der Zet ene ganze Menge Software an. Lagerverwaltung, Auftragsbearbetung, ERP-System, Lohnbuchhaltung und und und. Oft werden de enzelnen Programme nach und nach engeführt, jedes Mal das für de Aufgabe am geegnetsten Schenende ausgewählt. Dabe stammt fast zwangsläufg jedes Programm von enem anderen Hersteller. Und jedes arbetet mt senen egenen Dateformaten, Datenbanken usw. Nun wäre es durchaus snnvoll, verschedene Programme mtenander n Verbndung zu setzen, da se egentlch auch auf zumndest n der Unternehmenslogk denselben Daten arbeten. Bespelswese wäre es doch super, wenn en Programm, mt dem Aufträge erfasst werden, glech mal be der Lagerverwaltung nachfragen kann, ob en bestmmter, eben bestellter Artkel vorrätg st oder erst neu bestellt werden muss. Dann könnte man dem Kunden gegenüber glech ene vernünftge Aussage zur Leferzet geben. Und das, ohne dass der Sachbearbeter erst den Lagersten anrufen und nachfragen muss. Vollautomatsch. KONZEPTE Her kommt EAI ns Spel. Denn de Lagerverwaltung und de Auftragserfassung snd ncht de enzgen beden Systeme, de mtenander reden müssen. Am Ende muss wahrschenlch jedes IT-System mt mndestens der Hälfte aller anderen reden. Und bevor wr jetzt jedem de Dalekte (aka Schnttstellen) all der anderen bebrngen, wckeln wr dese Kommunkaton leber zentral über en enzges System, ene Art Dolmetscher, ab. Das st das EAI-System. En enfaches Bespel Natürlch st das Bespel von eben arg klen gewählt, aber als Ensteg langt es. Nehmen wr also an, en Sachbearbeter gbt enen neuen Auftrag ns System en. Ins Auftragserfassungssystem. Deses System st n der Lage, ene Auftragsbestätgung zu produzeren, de zum Kunden gesendet werden kann. Dass bedes heute eher automatsert ablaufen sollte, st en anderes Thema (nämlch EDI). In deser Auftragsbestätgung soll nun auch der zumndest annähernde Lefertermn stehen. Dazu st es nun wchtg zu wssen, ob alle bestellten Artkel vorrätg snd, oder ob se evtl. nachbestellt werden müssen. Und wenn se denn nachbestellt werden müssen, sollte man de Leferzet dafür auch glech n Erfahrung brngen. Aber der Rehe nach. 15
En Servce von ALLGEMEINES Der Auftrag kommt also ren. EDI, Das EAI Auftragserfassungssystem und darüber hnaus nennen wr es kurz AES bekommt also ene Lste von Postonen n de Hand. Unter anderem st da der Artkel mt der Nummer 4711. Zwe Stück. De Frage st: Haben wr zwe Stück auf Lager? Das checkt das EAI-System für uns. Netterwese arbetet de Lagerverwaltung mt ener normalen SQL-Datenbank. Ganz egal, ob das ene Oracle st, ene MySql oder auch ene MSSQL. Wr müssen also ledglch en Statement an de Datenbank abfeuern, das uns den aktuellen Bestand des betreffenden Artkels lefert. Wer SQL kann, wrd s verstehen: SELECT bestand FROM lagerbestaende WHERE artkelnummer = "4711" KONZEPTE Für de anderen de Übersetzung: Gb mr aus der Tabelle "lagerbestaende" den Wert "bestand", und zwar aus der Zele mt der Artkelnummer "4711". De Datenbank lefert nun z.b. ene 543 zurück. Heßa, da haben wr aber mehr als genug vorrätg. Also können wr für dese Poston ene sehr kurze Leferzet angeben, da wr de zwe Stück noch heute auf de Rese schcken könnten. Das st EAI. Smpel, ncht wahr? Wchtg st: Das AES weß nchts vom LVS (Lagerverwaltungssystem) oder sener Datenbank. Es gbt nur auf rgend ene Wese dem EAI-System Besched (oder das brngt s selbst n Erfahrung), dass en neuer Auftrag da st, das macht dann den Abglech mt dem LVS und gbt de Informatonen an das AES zurück, damt das ene Auftragsbestätgung mt snngen Leferzeten auswerfen kann. Na gut, fast zu smpel! Es kann durchaus sen, dass de Lagerbestände ncht so schön enfach aus der Datenbank zu holen snd. Oder dese meldet, dass ncht mehr genug Stück vorrätg snd. Sagen wr mal, Artkel 4711 st aus und muss nachbestellt werden. Nun wrd de Sache schon komplzerter. En komplexeres Bespel Artkel 4711 st aus. Wr müssen hn be unserem Leferanten nachbestellen. Dummerwese führt der hn aber unter sener egenen Artkelnummer. De kennt jedoch unser AES ncht. Ergo muss es, nachdem unser LVS den Kopf geschüttelt hat, erst mal de Artkelnummer des Leferanten für desen Artkel n Erfahrung brngen. Und natürlch, wer uns das Dng denn lefern soll. 16
En Servce von Machen wr es uns noch enmal enfach und nehmen weder ene Datenbank an, n der de Umsetzung steht. Es st desmal ene andere Datenbank, aber dasselbe Prnzp. Das Statement spare ch mr, wr machen her ja kenen SQL-Kurs. Retour kommt ene Artkelnummer A08/15 und der Leferant "Hardwarequelle", wel es sch be dem Artkel um Hardware handelt. Genau so gut könnten dese Informatonen auch aus enem SAP kommen, dann lefe de Anfrage über enen RFC-Aufruf. Nun haben wr uns n ene blöde Stuaton manövrert, wel wr nämlch egentlch über EAI schreben wollten, also de Integraton nterner Systeme, nun jedoch de Anfrage be der Frma Hardwarequelle ansteht, de de Grenzen der Frma verlässt und somt zum Berech EDI gehört. Das st das Doofe mt desen Dngern, de lassen sch ncht so rchtg trennen. Wr könnten jetzt natürlch folgendes machen: Wr nehmen an, dass wr zusätzlch zu unserer EAI-Software auch noch ene EDI-Software haben und fragen nun be der an. De soll btte für uns be der Hardwarequelle anfragen, wann Artkel 4711 alas A08/15 denn an uns gelefert werden kann. Unsere EDI-Software st dafür mt ener SOAP-Schnttstelle ausgerüstet, ansprechbar als WebServce. Also basteln wr uns ene klene Anfrage: KONZEPTE <?xml verson="1.0" encodng="utf-8"?> <soapenv:envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:xs="http://www.w3.org/2001/xmlschema-nstance"> <soapenv:header /> <soapenv:body> <AnfrageLeferzet> <Leferant>Hardwarequelle</Leferant> <ArtNr>A08/15</ArtNr> </AnfrageLeferzet> </soapenv:body> </soapenv:envelope> De EDI-Software letet de Anfrage, womöglch als WebServce-Aufruf, an das System der Hardwarequelle weter und lefert uns das Ergebns zurück. Netterwese muss se dazu erst enmal nachschauen, was das denn für en Laden st, we man den errechen kann usw. Dese Infos holt se womöglch aus ener Datenbank, de wr doch genau so gut selbst hätten abklappern können! 17
En Servce von ALLGEMEINES Wenn Se sch jetzt denken "Was für en Quatsch, zwe Systeme, wenn de Arbet doch von enem erledgt werden kann!", dann legen Se rchtg. Unser EDI-System soll nun also auch Datenbanken abfragen können we das EAI-System? Das EAI-System kann WebServces abfragen we en EDI-System? Dann snd doch zwe unterschedlche Systeme völlger Unsnn. Eben drum sollte egentlch alles n enem System zusammengefasst sen. Aber es geht ja zunächst darum, de Begrfflchketen zu erklären, und de machen eben enen Untersched zwschen der Integraton von Systemen nnerhalb ener Frma und der Kommunkaton zwschen Systemen verschedener Frmen. Dass bedes technsch so eng verwandt st und ene Trennung n verschedene Systeme oft Unfug, nteressert de Theore ncht. KONZEPTE Um das Bespel noch kurz zu Ende zu führen: Nach der Bestandsanfrage n unserem egenen LVS und/oder bem Leferanten kann der Auftrag weter bearbetet werden, ndem wr glech de passende Leferzet renschreben und ene Auftragsbestätgung mt vorausschtlchem Lefertermn an den Besteller schcken. Oh, hoppla, das st dann weder EDI. :-) Alles n allem Man kann also sagen, EAI st de Verknüpfung mehrerer nterner IT-Systeme mtenander, und zwar ncht n velen 1:1-Bezehungen, sondern eher stern- oder eben busförmg. Man sprcht n desem Zusammenhang gerne von "hub and spoke", zu Deutsch "Nabe und Speche(n)", wobe letztlch das EAI-System de Nabe darstellt, de über de velen Spechen mt den verschedenen Systemen n hrer IT-Landschaft kommunzert. 18
En Servce von EDI Was st das? Während EAI de Kommunkaton der IT-Systeme nnerhalb enes Unternehmens behandelt, betrfft EDI den Datenaustausch zwschen mehreren Unternehmen. Auch her "sprechen" de IT-Systeme drekt mtenander, der Mensch sollte nur Kontrollfunkton haben. Wenn schon nnerhalb ener Frma oftmals Software unterschedlcher Hersteller m Ensatz st, so wrd de Welt noch wesentlch bunter, wenn verschedene Unternehmen mtenander zu tun haben. Ncht nur gbt es verschedene Standard-Softwaresysteme, oft gestern komplette Egenentwcklungen durch de Prozessoren, de geschreben wurden, als de IT noch n den Knderschuhen steckte. Se wssen ja: Nchts hält länger als en Provsorum. We brngt man nun de Software verschedener Unternehmen, de bunter zusammengewürfelt st als jedes Osternest, zur Zusammenarbet? Jedes Programm hat sen egenes Datenformat, als "Kommunkatonsschnttstelle" kann man oft bestenfalls de Textdateen bezechnen, de ausgeworfen und engelesen werden können. Das artet n babylonsche Sprachenverwrrung aus. KONZEPTE Dafür gbt es zum enen gewsse Datenformate, de von großen Organsatonen (bs hn zu UNO-Abtelungen) als Standards entwckelt wurden, zum anderen Software, de n der Lage st, Daten von enem ns andere Format umzusetzen. Man könnte her von Dolmetschern sprechen, de zwschen all den velen Sprachen und Dalekten übersetzen können. Und we be den Dolmetschern der UNO wrd mest ncht drekt von Afrkaans n Tha übersetzt, sondern n ene der Standard-Sprachen (bspw. Englsch oder Französsch) und von der n de Zelsprache. In der Welt des EDI heßen de Standards EDIFACT, Fortras oder BMEcat, de Äquvalente zu den regonalen Sprachen snd mest CSV-Dateen oder Texte m "Feste Länge"-Format (alas FxRecord), de gerne unter dem Begrff "nhouse" laufen. Also das Format, das m egenen Hause genutzt wrd und sonst womöglch nrgends auf der Welt. Haben bede an der Kommunkaton betelgten Unternehmen solche "Dolmetscher"-Software m Hause, können se Daten vom egenen Format n enes der Standard-Formate umsetzen und auf belebgem elektronschem Wege an den Partner schcken. Der setzt den Standard wederum n sen Format um und füttert damt sene Systeme. De Kommunkaton st somt der Drtte m Bunde, der EDI erst komplett macht. 19
En Servce von ALLGEMEINES Bespel 1 Kurze Frage Im komplexeren Bespel zu EAI mussten wr enen Leferanten fragen, we lange es denn dauert, bs er uns enen bestmmten Artkel lefern kann, da wr den n ener Kundenbestellung gefunden haben und unser Lager leder kenen mehr vorrätg hat. Für so etwas st de EDI-Software zuständg (wobe wr schon festgestellt haben, dass es zemlch unpraktsch st, EAI und EDI so strkt zu trennen. Ist doch nur ene kurze Frage nach draußen, mtten m EAI-Prozess.). KONZEPTE De EDI-Software bekommt also, z.b. als SOAP-Anfrage (her über enen WebServce), den Auftrag, bem Leferanten "Hardwarequelle" nachzufragen, we schnell er uns zwe Artkel mt der Artkelnummer "A08/15" lefern kann. De Artkelnummer st berets de, de der Leferant benutzt, n unserem System hat derselbe Artkel de Nummer "4711". Für solche kurzen Anfragen st en WebServce de optmale Lösung. WebServces werden va HTTP angesprochen, n ener festgelegten Art und Wese. Das wchtgste daran st: Man schckt dem WebServce de Anfrage als XML-Date, und er antwortet auch n desem Format. Um de rene Anfrage bzw. de Antwort wrd noch en sogenannter SOAP-Envelope gepackt, der en paar Zusatznfos enthält, das war s auch schon. De Antwort kommt auf jeden Fall sehr schnell, und darauf kommt es her ja an. Her das Bespel, we unsere EDI-Software vom EAI-System de Anfrage bekommt: <?xml verson="1.0" encodng="utf-8"?> <soapenv:envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:xs="http://www.w3.org/2001/xmlschema-nstance"> <soapenv:header /> <soapenv:body> <AnfrageLeferzet> <Leferant>Hardwarequelle</Leferant> <ArtNr>A08/15</ArtNr> </AnfrageLeferzet> </soapenv:body> </soapenv:envelope> 20 KONZEPTE
En Servce von Das EDI-System muss jetzt n Erfahrung brngen, we es denn de Frma "Hardwarequelle" kontakteren kann. Dese Informatonen können aus ener Datenbank kommen, aus enem SAP-System (ja, das wären egentlch schon weder EAI-Themen) oder auch n rgend ener Wese drekt m EDI-System hnterlegt sen. Egal we, es kommt raus, dass wr den Leferanten auch weder über WebServce ansprechen können. We gesagt, für solche Anfragen st das optmal, da es enfach schnell geht. Sparen wr uns en anderes XML-Bespel, sagen wr enfach, der Leferant schert uns Leferung n dre Tagen zu. Genauer gesagt, sene IT-Systeme schern uns das zu. Denn ene Antwort nnerhalb ener HTTP-Verbndung stammt scher ncht von enem Sachbearbeter, sondern wrd vollautomatsch n dessen IT-Landschaft generert. Auch auf sener Sete snd da EDI- und EAI-Prozesse betelgt. Dese dre Tage meldet unser EDI-System nun an unsere EAI-Software, damt dese de Bestellung weter bearbeten kann. Bespel 2 Kundenbestellung So ene Kundenbestellung, we wr se m EAI-Bespel angesprochen haben, sollte heute ncht mehr wrklch von enem Sachbearbeter engegeben werden. Das st nun ja etwas mttelalterlch. Bestellungen sollten heute elektronsch entreffen, z.b. als Mal oder über das Bestellformular ener Webste. Oder, wenn wr m B2B-Berech bleben, per EDIFACT-Date drekt aus dem EDI-System unserer Kunden. KONZEPTE Da trudelt nun also ene Mal en, an der ene Bestellung m EDIFACT-Format hängt. De Nachrchtenart heßt raten Se! ORDERS. We so etwas aussehen kann, st m Artkel zu EDIFACT genauer beschreben. De EDI-Software nmmt sch de Mal vor und holt den Anhang mt der Bestellung heraus. Anhand des Datenamens oder vellecht des Betreffs erkennt se, um was es geht. Zur Not muss se n den Inhalt schauen, falls de anderen Merkmale ncht ausrechen. Dann lest se de Daten en und spest se ns Auftragserfassungssystem (kurz AES). Ab her übernmmt unsere EAI-Software, da wr her be den Begrffserklärungen ja strkt zwschen beden trennen. Dese st rgendwann mt der Bearbetung fertg, der Auftrag mt allen Leferzeten, vorausschtlchem Lefertermn für den Kunden, evtl. Sonderkondtonen usw. steht m AES, und es kann nun ene Auftragsbestätgung mt allem Drum und Dran an den Besteller rausgehen. Da übernmmt dann weder EDI. 21
En Servce von ALLGEMEINES EDI Ene Möglchket wäre, dass de EAI-Software aus dem AES alle Daten für de Auftragsbestätgung zeht und als klene CSV-Date n en Verzechns legt, aus dem das EDI-System se weder auslest und n en EDIFACT-Dokument enbaut. Der entsprechende Nachrchtentyp heßt n desem Fall ORDRSP (De Namen aller Nachrchtentypen haben sechs Buchstaben, deser Name her steht für Order Response.). Ist das ORDRSP erst mal erstellt, bekommt der Kunde ene Mal von uns, de als Anhang dese EDIFACT-Nachrcht enthält und wahrschenlch sofort weder von senem EDI-System verarbetet wrd. Es lebe de moderne Technk! KONZEPTE Sehen wr uns kurz mal den B2C-Berech an, also de Kommunkaton und den Handel zwschen Unternehmen und Endkunden, we z.b. Prvatleuten. In desem Fall gngen scher kene EDIFACT-Dateen hn und her. Wahrschenlcher st, dass der Kunde über en Webformular sene Bestellung macht, z.b. n enem Webshop mt Warenkorb und allem Schnckschnack. Auch er wrd zwar ene Auftragsbestätgung erhalten, dese dürfte dann aber eher folgende Form haben: Sehr geehrte Frau Musterfrau, wr bedanken uns sehr für Ihren Auftrag und bestätgen hermt hre Bestellung. Artkelnummer Bezechnung Menge Enzelpres Gesamtpres 4711 Nette Überraschung 2 9.99 19.98 Gesamtsumme: 19.98 enth. MwSt: 2.76 Vorausschtlcher Lefertermn: 30.02.2099 Mt freundlchen Grüßen, Ihr Kramerladen-Team De Kommunkaton nach außen läuft ganz anders, m Engang haben wr womöglch ene CSV-Date, de uns en PHP-Scrpt des Webshops per FTP lefert, und de Antwortmal enthält kenen EDIFACT-Anhang, sondern enen Fleßtext. Der Prozess dazwschen allerdngs st derselbe. 22 KONZEPTE