Inhaltsverzeichnis

Einrichten einer Datenstrecke mit Konvertierung

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.

1. Schnittstellen Typen definieren

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.

2. Repositorien anlegen

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.

3. Mappingdefinitionen anlegen

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.

4. Standard Template Partner definieren

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:

5. Nachrichtenboxen definieren

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.

6. Kommunikationsarten bzw. Kommunikationskanäle definieren

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.

7. Prozesse definieren

Hinweis: Die folgenden Jobdefinitionen repräsentieren ein Standard Integrationsfall. Diese Prozesse können mit verschiedenen Jobobjekten angereichert werden um z.Bsp. Business Logik abzubilden.

  1. einen ersten Job zum Öffnen eines Empfangsskanals oder BackendObjectRetreiver, der dann an den nächsten Dispatcher delegiert, bestehend aus:
    1. eBiss.ClassLib.ChannelReceiver oder eBiss.DbAdapter.BackendObjectRetrieverEx12)
    2. eBiss.ClassLib.DelegatorJob13)
    3. eBiss.ClassLib.TaskNotificatorEx
  2. einen zweiten Job zum Analysieren, Selektieren, Transformieren und Kontainerisieren14) oder Übertragen15) bestehend aus:
    1. eBiss.ClassLib.JobExecutionController(optional)16)
    2. eBiss.ClassLib.EntityAnalyzer
    3. eBiss.ClassLib.EntitySelector17)
      1. eBiss.ClassLib.Jobs.EntityLoader
        1. eBiss.ClassLib.Jobs.EntityTransformer oder bei Bedarf eBiss.ClassLib.Jobs.MultiEntityTransformer
          1. eBiss.ClassLib.Jobs.EntityTransformer18)
            1. eBiss.ClassLib.Jobs.EntityMessageCreator oder eBiss.DbAdapter.BackendObjectTransmitterEx19)
            2. eBiss.ClassLib.Jobs.EntityStateSetter
    4. eBiss.ClassLib.DelegatorJob20)
  3. einen dritten Job zum öffenen eines Sendkanals bestehend aus:
    1. eBiss.ClassLib.ChannelSender21)

Hinweis: Siehe auch Typischer Prozess.

8. Automatisierung

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.

1)
Alternativ, kann dies mit geigneten IDEs für C# erzeugt werden.
2)
siehe auch Schattenkopie
3)
Bei einer direkten Integration brauch es keine Schreibkomponenten und auch kein Kontainerisierer
4)
..eBiss3/StandardTemplates/RepositoryDump*.xml
5)
ausgehende Nachrichten
6)
für eingehend Nachrichten
7)
beinhaltet die original eingehenden EDIFACT Nachrichten vom Partner
8)
beinhaltet die eingehenden, auf die INHOUSE -Typen transformierten Nachrichten
9)
beinhaltet die ausgehend original INHOUSE -Typen
10)
beinhaltet die ausgehend, auf EDIFACt transformierten Nachrichten
11)
Auch ERP- oder WWS-System genannt.
12)
Bei einer Direktintegration z.Bsp. mit einer Datenbank.
13)
Dieser zeigt auf den Job Nr. 2
14)
in eine vorhandene Nachrichtenbox
15) , 19)
mit BackendObjectTransmitter in eine bestehende direkt-Integration
16)
Dies kann in komülexen Systemen mit vielen verschiedenen, parallel laufenden Prozessen notwendig werden.
17)
dieser Zweig wird für alle ein- bzw. ausgehenden Nachrichtentypen innerhalb eines Jobs wiederholt und entsprechend parametriesiert.
18)
Bei zweistufiger Transformation via eBiss MiddleWare.
20)
Dieser zeigt auf den Job Nr. 3
21)
Falls nicht mit eBiss.DbAdapter.BackendObjectTransmitterEx bereits übertragen wurde.