eBiss 3

Hilfe & Dokumentation

Benutzer-Werkzeuge

Webseiten-Werkzeuge


ueberblick:integration:integrationsszenario:start

Integrations-Szenario

Für die rasche Integration von eBiss in einen neue Umgebung wird die Verwendung des Pranke eigenen eGate Mehrwertnetz empfohlen. Dieses bietet den Vorteil der schnellen Anbindung an die Teilnehmer des Netzwerkes. Alle eGate Teilnehmer lassen sich zudem über die Pranke Teilnehmersuche finden und durch die hier downloadbar gehaltenen Partner Konfigurations-Datei1) in das eigene eBiss importieren.

Typischer Nachrichtenfluss zwischen eigenem Host-System und dem Tradingpartner

Die folgende Abbildung zeigt den typischen Nachrichtenfluss zwischen dem Host-System und einem Trading Partner mit dem Konverter eBiss und dem Gateway eGate:

Host->eBiss:Message(INHOUSE-OUTBOUND) eBiss->eBiss:convert message eBiss->eGate:Message(EDIFACT-OUTBOUND) eGate->Trading Partner:Message(EDIFACT-OUTBOUND) Trading Partner->eGate:Message(EDIFACT-INBOUND) eGate->eBiss:Message(EDIFACT-INBOUND) eBiss->eBiss:convert message eBiss->Host:Message(INHOUSE-INBOUND)

Typische Verarbeitung eingehender Nachrichten (INBOUND) vom Handelspartner

Im folgenden Fall wird eine Integration über Dateiaustausch2) beschreiben.

  1. Der in der Automatisierung4) angegebene Job wird von dem Ereignis getriggert und öffnet einen definierten Kommunikationskanal5) und empfängt die über den Kanal eingehenden INBOUND6) Nachrichten.
  2. Die Eingehenden Nachrichten werden durch den Kommunikationskanal in dem beim Kanal definierten Nachrichtenkorb7) angelegt.
  3. Ein zweiter Job wird angestoßen und erhält die vorher empfangenen Nachrichten.
  4. In diesem zweiten Job werden die Nachrichten Analysiert8) und mittels Selektoren9) je nach Einstellung ausgewählt und in Ihr entsprechendes Objekt geladen.
  5. Anschließend wird in einer ersten Transformation vom Quell-Objekt mit geeignetem MiddleWare-Mapping in das passende Ziel-Objekt umgewandelt.
  6. Eine weitere zweite Transformation wandelt das MiddleWare Objekt notwendigerweise in das dem Dokumenttyp zugehörige INHOUSE Ziel-Objekt10).
  7. Danach wird mit einem EntityMessageCreator die Nachricht in den, beim selbigen Jobstep angegebenen, Nachrichtenkorb11) kontainerisiert12).
  8. Mit dem JobStep DelegatorJob werden die im Job erzeugtenNachrichten an einen dritten Job weitergegeben13).
  9. In diesem dritten und meist letzten Job werden die übergebenen Nachrichten wiederum mit einem ausgehenden Kommunikationskanal14) auf einen im Kanal definierten Ort im lokalen Netzwerk abgelegt.

Typische Verarbeitung ausgehender Nachrichten (OUTBOUND) an Handelspartner

Auch hier wird eine Integration über Dateiaustausch15) beschreiben.

  1. Ein automatisiertes Ereignis tritt ein.
  2. Der in der Automatisierung16) angegebene Job wird von dem Ereignis getriggert und öffnet einen definierten Kommunikationskanal17) und empfängt die über den Kanal übermittelten OUTBOUND18) Nachrichten.
  3. Die ausgehenden Nachrichten werden durch den Kommunikationskanal in dem beim Kanal definierten Nachrichtenkorb19) angelegt.
  4. Ein zweiter Job wird angestoßen und erhält die vorher empfangenen Nachrichten.
  5. In diesem zweiten Job werden die Nachrichten auch Analysiert20) und mittels Selektoren21) je nach Einstellung ausgewählt und in Ihr entsprechendes INHOUSE Quell-Objekt geladen.
  6. Anschließend wird in einer ersten Transformation vom INHOUSE Quell-Objekt mit geeignetem Custom-Mapping in das passende Middleware-Ziel-Objekt umgewandelt.
  7. Eine weitere zweite Transformation wandelt das MiddleWare Objekt notwendigerweise in das dem Dokumenttyp zugehörige EDIFACT Ziel-Objekt22).
  8. Danach wird wiederum mit einem EntityMessageCreator die Nachricht in den, beim selbigen Jobstep angegebenen, Nachrichtenkorb23) kontainerisiert24).
  9. Mit dem JobStep DelegatorJob werden die im Job erzeugtenNachrichten an einen dritten Job weitergegeben25).
  10. In diesem dritten und meist letzten Job werden die übergebenen Nachrichten wiederum mit einem ausgehenden Kommunikationskanal26) an den Partner übermittelt.27)

Nachrichtenfluss ganz allgemein

Eventlistener→Job→ReceiveChannel→Messagebox→Analyzer→Selector→Transformierung→Transformierung→Containerisierung→MessageSelector→Job→SendChannel

note right of eBiss: outbound message types eBiss-->eBiss:Event triggers outbound procedures HOST-->eBiss:Direktintegration/FILE transfer eBiss-->eBiss:transform eBiss->Partner:via SMTP,FTP,SFTP,HTTP,AS2,X400 note right of eBiss: inbound message types eBiss-->eBiss:Event triggers inbound procedures Partner->eBiss:via SMTP,FTP,SFTP,HTTP,AS2,X400 eBiss-->eBiss:transform eBiss-->HOST:Direktintegration/FILE transfer

Interknotenkommunikation

Datenaustausch zwischen mehreren eBiss Systemen via HTTP ist unter Multiknotenkommunikation via HTTP erläutert.

Themen

1)
Dies sind i.d.R. sog. *.ini Dateien.
2) , 15)
Eine weit verbreitet Methode. Alternativ dazu ist die direkte Integration mit lokalen Datenbanken möglich.
3)
Definiert durch: zeitlich geplanter, Port oder Datei bei Automatisierung.
5)
I.d.R. ein SMTP Empfangskanal, welcher Nachrichten vom eigenen eGate VAN Account abholt.
6)
INBOUND ist die Richtung einer Nachricht vom Handelspartner an das Host-System
7)
Nachrichtenkorbname ist üblicherweise From.Partner
8) , 20)
I.d.R. Partnererkennung, Dokumentnummer über Plugindefinition und Dokumentyp/Subtyp anhand des Repositoriums
9)
Hier wird eien Slektion i.d.R. über den Zieltyp definiert, da unterschiedliche EDIFACT Release Standards bei eingehenden Edifact Nachrichten angenommen werden sollen.
10)
Dies ist i.d.R: eine Objektklasse welche in einem kundenspezifischen Plugin definiert wurde.
11)
Nachrichtenkorbname ist hier üblicherweise To.Host
12) , 24)
Dies erfolgt in Abhängigkeit des beim Entitätstyp im Repository hinterlegten Containerizer.
13) , 25)
Alternativ kann auch mit einem MessageSelector die neu erzeugten Nachrichten aus dem entsprechenden Nachrichtenkorb selektiert und weiter delegiert werden.
14)
Hier ist dies üblicherweise ein Dateisystem Sendekanal
17)
Hier dann i.d.R. ein Dateisystem Empfangskanal, welcher Nachrichten vom eigenen Host System bzw. Festplatte abholt.
18)
OUTBOUND ist die Richtung einer Nachricht vom Host-System an den Handelspartner
19)
Nachrichtenkorbname ist üblicherweise From.Host
21)
Hier wird meist mit einem fix hinterlegten Quelltyp selektiert, da pro Nachrichtentyp und Richtung nur ein bestimmtes Format vom Host System zu erwarten ist.
22)
Dies ist i.d.R: eine Objektklasse welche in bestehenden Plugins definiert ist.
23)
Nachrichtenkorbname ist hier üblicherweise To.Partner
26)
Hier ist dies üblicherweise ein SMTP Sendekanal
27)
Bzw. im Normalfall über den eigenen eGate VAN Account zustellt.
ueberblick/integration/integrationsszenario/start.txt · Zuletzt geändert: 2024/02/20 08:15 von 127.0.0.1