Mannigfaltige Schnittstellen bilden die Grundlage der Integration und sind essentiell für die Transformation von einem Schnittstellentyp auf einen anderen.

1. alle strukturierten Dateitypen, z.,Bsp.:
   1. XML
   2. JSON
   3. CSV¹⁾
   4. UN/EDIFACT²⁾
   5. ANSIX12³⁾
   6. etc.
2. Datenbank-Integrationen
   1. MS-SQL
   2. MySQL
   3. MariaDB
   4. POSTGRESQL
   5. DB2
   6. DB2 iSeries
   7. Oracle
   8. ODBC
3. REST API
4. SOAP API
5. COM

Zum Abbilden dieser verschiedenen Typen bietet eBiss mit dem Modul Typ-Editor ein sehr performantes Werkzeug an.

Die eBiss-Repositorien beinhalten notwendige, grundlegende Einstellungen bzw. Komponenten zur Erkennung, zum Lesen/Schreiben und Kontainerisieren von Dokumenttypen. Im „eBiss Rollout StandardTemplates“-Verzeichnis befinden sich bereits drei wesentliche Repositorien, welche die wesentlichen EDIFACT-, sowie Hersteller- und Retailer-spezifischen MiddleWare-Typen beinhalten bzw. deklarieren. I.d.R. werden Typen nach Projekt/ Integration getrennt in Repositorien separat deklariert. Voraussetzung dafür sind die mit dem Typeditor erzeugten Plugins. eBiss-Repositorien können beliebig viel Entitätstypen beinhalten. Wie die Entitätstypen mit den verschiedenen Repositorienkomponenten verknüpft werden, ist aus dem Repository Entity Relationship Diagramme ersichtlich.
Es gibt:

• 11⁴⁾ Lesekomponententypen
  • Es können 12⁵⁾ Zeichensatz-Kodierungen voreingestellt, auf eine automatische Erkennung zurückgegriffen und weitere typspezifische Eigenschaften eingestellt werden.
• 11⁶⁾ Schreibkomponententypen
  • Die Schreibkomponente bietet 13⁷⁾ Zeichensatz-Kodierungen und weitere typspezifische Eigenschaften an.
• 8⁸⁾ Kontainerisierungstypen
  • Für die Generierung von Dateinamen und Betreff bietet die Kontainerisierungskomponente jeweils drei Möglichkeiten an. Der Geltungsbereich eines Kontainerisierers kann auf die 4⁹⁾ verschiedenen Einstellungen individuell per Dokument, per Dokumenttyp, per Nachricht oder per Eingangsdatei festgelegt werden. Je nach Kontainerisierungstyp kann mit den 23 Adresstypen festgelegt werden, welche Adresse für die Interchange oder MapFrameDocumentSender/Recipient verwendet werden soll.
• 17¹⁰⁾ Analysatorentypen
  • Analysatoren erlauben 14¹¹⁾ verschiedene Arten der Partneridentifikation.
• 10¹²⁾ Erkennertypen
  • Es können 12¹³⁾ Zeichensatz-Kodierungen voreingestellt, auf eine automatische Erkennung zurückgegriffen und weitere typspezifische Eigenschaften eingestellt werden.

Die logischen Geschäftsentitäten werden in eBiss in die zwei wesentlichen Lager unterschieden. Diese sind zum einen die Handelspartner und zum anderen die Systempartner¹⁴⁾. Gruppen von Handelspartnern mit gleichen Eigenschaften können innerhalb sog. Partnervorlagen zusammengefasst werden. Ein System- bzw. Handelspartner kann beliebige Kommunkationsadressen basierend auf 16¹⁵⁾ Adresstypen besitzen. Dazu kann die hierarchische Struktur eines Partners mit den Partnerlokationen abgebildet werden. Partnerlokationen können beliebige Variableninstanzen besitzen. Eine partnerspezifische Behandlung von Nachrichten erfolgt über die Verdrahtung von Entitätstypen, Mappings, Kommunikationskanälen, Kommunikationsadressen mithilfe der sog. Typsatzdefinitionen. Die Partnererkennung erfolgt über ein flexibles System, welches entweder auf Kommunikationsadressen beim Partner selbst oder bei der Lokation auf die TNr, GLN oder andere BackendIDs schaut.

11¹⁶⁾ Empfangskanäle bieten ein rasche Anbindung von Standarddatenübertragunsprotokollen an.

Wenn eine Integration über Datenaustausch keine Option ist und eine direkte Integration angestrebt wird, dann kommen BackendObjectRetrieverEx für eine Datenbankanbindung oder eigens entwickelte Jobobjekte zum Einsatz, um z.Bsp. REST- oder SOAP-APIs abzufragen.

Zur Organisation der Nachrichten bietet eBiss die beliebige Anlage von Nachrichtenkörben an, in welche die von extern vereinnahmten bzw. die von eBiss erzeugten Nachrichten abgelegt werden können. Nachrichten können aus diesen Nachrichtenkörben auch manuell gedebugged oder ins Filesystem gespeichert werden. Darüberhinaus können beliebige Dateien per Drag & Drop oder Copy & Paste in Nachrichtenkörbe bewegt werden.

Zur Abbildung und Automatisierung der mannigfaltigen EDI-Anforderungen bietet eBiss eine Vielzahl an sog. Job-Objekten an. Diese können durch kunden- oder projektspezifische eigene Objekte erweitert werden und in Prozessen eingesetzt werden. Hier sind alle nur denkbaren Konstellationen innerhalb einer Digitalisierung im B2B¹⁷⁾, B2C¹⁸⁾ oder A2A¹⁹⁾-Umfeld möglich.

eBiss verfügt über 110²⁰⁾ Job-Objekte, mit denen die vielfältigsten Anforderungen gelöst werden können.

Die offene Architektur von eBiss erlaubt es, projekt- bzw. kundenspezifische Komponenten zu erzeugen, um besondere Aufgaben zu lösen. Mit dem standardmäßig verfügbaren Job-Objekt ExecuteExternal können beliebige externe Prozesse des OS ausgeführt werden.

eBiss bietet sechs unterschiedliche Möglichkeiten der Automatisierung an. Sehr häufig werden die Prozesse durch wiederkehrende Zeitereignisse angestoßen. Oft bietet sich auch das Horchen auf Veränderungen in einem Dateienverzeichnis an. Bei einer zeitgemäßen Integration kommen häufig sog. Port-EventListener zum Einsatz.

Oft werden varibale Schaltungen benötigt, um Business Logik abzubilden. Dafür können in eBiss drei Typen von Variablen frei definiert werden.

1. Variablen vom Typ Flag
2. Variablen vom Typ Text
3. Variablen vom Typ Werteliste

Diese Variablen können in beliebiger Anzahl angelegt und auch in Unterknoten vererbt sowie für System- und/oder Handelspartner verfügbar gemacht werden. Durch einen Verwendungsnachweis ist es wiederum möglich zu sehen, wo Variablen instanziiert sind. Variablen können in Mappings oder Prozessen mit Hilfe der Mappingfunktionen abgefragt werden.

eBiss bietet im Editor für Transformationen schier unendliche Freiheiten. I.d.R. wird eine zweistufige Transformation genutzt. Im ersten Schritt werden Dokumenttypen von einem Quelltyp zu einem normalisierende MiddleWare-Typ und im zweiten Schritt von der MiddleWare in den gewünschten Zieltyp konvertiert. Dies ist kein zwingend notwendiges Vorgehen, bietet sich aber im normalen EDI-Geschäft an. Es gibt Konstellationen, in denen es sinnvoller ist, direkt vom Quelltyp in den Zieltyp zu mappen. Es gibt auch Konstellationen, in denen es sinnvoll ist, mehr als zwei Mappings in einer Reihe hintereinander anzuwenden. Die Möglichkeiten sind sehr vielfältig und können je nach aktuellem Bedürfnis gewählt werden. Es können sogar Mappings mit identischem Quell- und Zieltypen sinnvoll sein, z.B. um Typsätze zu verwenden oder in den Mappings Validierungen zu machen.

Im StandardTemplates-Verzeichnis befinden sich bereits > 60²¹⁾ Mappings, welche die gängigsten EDIFACT-Szenarien für D96a und D01b abdecken. Mit dem Modul Typ-Editor können beliebige Schnittstellentpyen mit wenigen Mausklicks aus CSV, XML, XSD und Tabellen aus den unterstützten Datenbanksystemen abgeleitet werden.

eBiss verfügt über 174²²⁾ EDI-spezifische Mappingfunktionen. Diese „hauseigenen“ Funktionen ergänzen die ohnehin schon systembedingt vorhandenen XPATH-Funktionen. Mappingfunktionen können nicht nur in Mappings, sonderen auch in Job-Objekten zur Anwendung kommen, welche eine XPATH-Expression als Eigenschaft anbieten. Mit der standardmäßig verfügbaren Mappingfunktion ExecuteExternal können beliebige externe Prozesse des OS ausgeführt werden. Praktisch ist auch die Mappingfunktion SendMail(), die es ermöglicht, aus dem Transformstionskontext beliebige Nachrichten für informative Zwecke zu erzeugen.

Die eBiss-Mappings sind mit dem Mapping Editor in allen möglichen Ausprägungen editierbar, und es können die unterschiedlichsten Konstrukte transformiert werden. Häufig werden hierarchische Strukturen umstrukturiert oder auf flache²³⁾ Strukturen transformiert, oder flache Strukturen werden über Gruppierungen zu hierarchischen Strukturen umgewandelt. Da eBiss alle Dokument-Entitäten in XML-Dokumenten im Speicher hält, kann mit der XPATH-Technologie alles aus einem Quellobjekt abgefragt und auch wieder in ein Zielobjekt addressiert bzw. geschrieben werden. Durch geschickte Anwendung der Mapping-Regelsätze, -Regeln und alternativen Selektoren bleiben die Mappings selbst bei komplexen Konstrukten überschaubar.

Mit dem sog. MultiEntityTransformer ist es möglich, über mehrere Dokumente gleichen Typs innerhalb einer Nachricht übergreifende Auswertungen bzw. Transformierungen zu tätigen. eBiss bietet darüber hinaus spezielle Mappingfunktionen an, welche es erlauben, Daten aus Umschlüsselungstabellen²⁴⁾, aus Excel²⁵⁾-Dateien oder aus anderen Dokumenten²⁶⁾ der gleichen oder anderen Nachricht(en)²⁷⁾²⁸⁾ zu extrahieren.

eBiss kann sämtliche Umschlüsselungen innerhalb der Transformierung von Dokumenten vornehmen. Dazu können beliebige Umschlüsselungstabellen angelegt werden. Diese können global oder partnerspezifisch verwendet werden. Die Fremdschlüssel können automatisch angelegt werden, um dann einmalig mit den Rückgabewerten verknüpft zu werden. Die Wertelisten und Umschlüsselungstabellen können per Copy&Paste aus Excel-Listen angelegt werden. Wertelisten können dazu auch über Backendprovider bedient werden.

Mit beliebigen Zählern können fortlaufende Nummerierungen in den Transformierungen bewältigt werden.

eBiss verfügt über 9²⁹⁾ Sendekanäle, die „out of the box“ verwendet werden können

Wenn eine Integration über Datenaustausch keine Option ist und eine direkte Integration angestrebt wird, dann kommen BackendObjectTransmitterEx für eine-Datenbankanbidung oder eigens entwickelte Job-Objekte zum Einsatz, um z.Bsp. REST- oder SOAP-APIs zu bedienen.

Erweiterte Anforderungen werden mit den zusätzlich verfügbaren 17³⁰⁾ eBiss Modulen bedient.