Folgenden Schritte skizzieren das Vorgehen für das Einrichten einer Datenstrecke mit Transformierung in eBiss und zeigen welche Elemente notwendig sind und in welcher Reihenfolge vorgegangen wird. Man arbeitet sich gewissermassen von hinten nach vorne durch um alle Abhängigkeiten jeweils bereits bedienen zu können.
Hinweis: Integrations-Szenario und Nomenklatur in eBiss berücksichtigen.
Schnittstellenobjekte vorzugsweise mit dem Type-Editor1) als DLL kompilieren. Datentypen gem. Schnittstellenbeschreibung muss als C#-Klasse mit entsprechenden eBiss-spezifischen Daten-Attributen versehen in als DLL kompilierter Form im Plugin Verzeichnis der eBiss Installation angelegt sein und eBiss Client und Service neu gestartet werden2).
Hinweis: Integrationsarten berücksichtigen.
Für die neuen INHOUSE Schnittstellenobjekte notwendige Komponenten definieren.
Hinweis: INBOUND Entitätstyp im Repository mit entsprechender Schreibkomponente und Kontainerisierer definieren3).
Hinweis: OUTBOUND Entitätstyp im Repository mit entsprechendem Erkennungs-, Analyse- und Lesekomponente definieren.
Repositorien für EDIFACT und MiddleWare können aus dem Standardtemplate4) Verzeichnis importiert werden.
Hinweis: Schnittstellen(Entitätstypen) die sowohl für ein- und ausgehende Kommunikation verwendet werden stellen einen Sonderfall dar! Deren Entitätstypen haben dann alle Repository-Komponenten im Einsatz.
Für die Transformierung von INHOUSE auf MiddleWare5) und von MiddleWare auf INHOUSE6) Schnittstellenobjekten werden neue Mappings definiert. Für die Transformierung von MiddleWare auf EDIFACT oder EDIFACT auf MiddleWare können Standardmappings aus dem Standardtemplate Verzeichnis importiert und ggfs. angepasst werden.
Hinweis: Es gibt Fälle, da bietet es sich an mit nur einer Transformierung zu arbeiten. Z.Bsp. wenn es kein entsprechendes Pendant in der MiddleWare gibt.
i.d.R. werden einem zukünftigen TradingPartner ein sog. TemplatePartner zugeordnet. Dieser beinhaltet die Typsätze, welche die Standardmappings für die ausgehenden MiddleWare auf EDIFACT und eingehenden EDIFACT auf MIddleWare zu den entprechenden Typen definiert.
Hinweis: Die Typsätze werden abgefragt bei:
Um Nachrichten in eBiss verarbeiten zu können müssen diese in einem Nachrichtenkorb kontainerisiert werden. i.d.R. werden zwei eingehende und zwei ausgehende Nachrichtenkörbe benötigt. z.Bsp.:
Hinweis: Nachrichtenkörbe sind Voraussetzung um Kommunikationskanäle zu definieren.
Hinweis: Die Eigenschaft Korbtyp kan eingehend, ausgehend, oder keine sein. Diese Einstellung hat Auswirkung auf die Voreinstellung beim Pasten von Dateien in eine Nachrichtenbox. Diese Nachrichten werden dann entsprechend ein oder ausgehend markiert und folglich werden beim Analysieren die entsprechenden eingestellten Objekte abgefragt. Im Normalbetrieb werden Nachrichten über Empfangskanäle oder BackendObjectRetrieverEx in einem Nachrichtenkorb angelegt, dabei erhalten die Nachrichtung die Richtung welche beim Kanal eingestellt ist.
Kommunikationsarten zwischen eBiss und HOST-System11) bzw Partner-System bestimmen und entsprechende Kommunikationskanäle definieren, bei Datenbank Integrationen werden keine Kommunikationskanäle, sondern BackendObjektIntegrationen in den JOBs verwendet. i.d.R. werden eingehende EDIFACT Nachrichten von http://egate.pranke.com empfangen, d.h. es muss dafür ein eingehender POP3 Empfangskanal definiert sein, welcher in den zuvor definierten Nachrichtenkorb schreibt.
Hinweis: In der Praxis werden an dieser Stelle Acronyme wie EDI, B2B, A2A, MFT, B2C angewendet um die Zusammenhänge auf abstrakter Ebene zu kennzeichnen. Im Wesentlichen muss hier aber konkret ermittelt werden auf welche technische Art eine Übertragung von Daten zwischen den Systemen erfolgen soll. Die Auswahl ist groß, entscheidend sind Sicherheit und Zuverlässigkeit der gewählten Verfahren. Im Prinzip kann eBiss alle Szenarien abbilden.
Hinweis: Die folgenden Jobdefinitionen repräsentieren ein Standard Integrationsfall. Diese Prozesse können mit verschiedenen Jobobjekten angereichert werden um z.Bsp. Business Logik abzubilden.
Hinweis: Siehe auch Typischer Prozess.
Die Automatisierung werden zuletzt vorgenommen um die zuvor definierten und manuell getesteten Prozesse zu automatisieren. I.d.R. genügt es den jeweils ersten Job in einer Verarbeitungskette anzutriggeren, da die folgenden Jobs mittles Delegatoren oder EventRouter und EventRouteReceiver verkettet werden.