Das Repository¹⁾ ist der Speicherort für die Lese-, Analyse- und Schreibwerkzeuge, um eingehende Daten verarbeiten zu können bzw. ausgehende Daten schreiben/erstellen zu können. Es besteht aus maximal sechs Komponenten und findet i.d.R. Anwendung in folgenden Job Objekten:

• EntityAnalyzer
• EntitySelector
• EntityTransformer
• EntityMessageCreator

und darüber hinaus auch von der Methode Debugging/Nachricht analysieren in der Nachrichten Ansicht.

Beim Lesen bzw. Analysieren greift jedes Repository auf die entsprechenden drei Unter-Komponenten Recognizer(Erkennungskomponente), Analyzer(Analysator) und Reader(Lesekomponente) zu.
Außerdem nutzt das Repository mit den ebenfalls unterhalb definierten EntityTypes(Entitäts-Typen) eine vierte Komponente:
Dies sind jene Dokument-Typen bzw. Format-Definitionen, die eBiss kennt – z.B. EDIFACT DESADV D.96A oder Inhouseformat Lieferschein.
Während dieses eingehenden Analysierens wird vereinfacht formuliert zunächst der Dateityp erkannt (XML, CSV, EDIFACT…), um in Folge Dokumente²⁾ und Partner³⁾ zu erkennen.

Beim Schreiben greift das Repository ebenfalls auf jene Dokument-Formatdefinitionen aus den Entitäts-Typen zu, sowie darüber hinaus auf die übrigen zwei Unter-Komponenten Containerizer(Containerisierer) und Writer(Schreibkomponente).
Da eBiss in einem System immer mehrere Dokumentarten mit entsprechenden Lese- und Schreib-Komponenten verwaltet, werden diese gruppiert. Es gibt also mehrere Repositorien:
Typischerweise eines für EDIFACT-Formate, ein weiteres für die Inhouse-Formate sowie ein weiteres für die eBiss-eigenen Middleware-Formaten.

Da eBiss in einem System immer mehrere Dokumentarten mit entsprechenden Lese- und Schreib-Komponenten verwaltet, werden diese gruppiert. Es gibt also mehrere Repositorien: Typischerweise eines für EDIFACT-Formate, ein weiteres für die Inhouse-Formate sowie ein weiteres für die eBiss-eigenen Middleware-Formaten.

Um erfolgreich ein Repository anzulegen muss im Vorfeld der Verwendungszweck festgelegt sein. Empfohlen wird die Abgrenzung eines Repositorium für z.Bsp. alle Typen die zwischen einem Host-System und eBiss ausgetauscht werden sollen.

Das Repository Entity Relationship Diagramme zeigt die Abhängigkeiten der Repository Komponenten zueinander.

Ein Repository kann mehrere optionale und erforderliche Komponenten enthalten.⁴⁾

• Schreibkomponenten haben keine Abhängigkeit, definieren das Format in welcher eine Entität geschrieben werden soll..
• Lesekomponenten haben keine Abhängigkeit, sind aber notwendig um Entitäten von einem externem System zu lesen.
• Erkennungskomponenten haben keine Abhängigkeit, sie definieren wie Entitäten anhand des Datenformats, der Dateimaske oder des Match String und der Nachrichten Richtung(eingehend od. ausgehend) erkannt werden sollen.
• Kontainerisierer benötigen eine vordefinierte Schreibkomponenten und können individuell auch in Typesets verwendet werden. Sie werden benötigt wenn eine Entität als Nachricht angelegt werden soll.
• Analysatoren benötigen eine vordefinierte Erkennungskomponente und eine vordefinierte Lesekomponente. Sie werden verwendet um eine Entität eindeutig zu bestimmen und ggfs. auch die Absender und Empfänger Information zu extrahieren. Einem Analysator muss ein oder mehrere Entitätstypen zugeordnet werden.⁵⁾

• Entitäts Typen brauchen, in Abhängigkeit des Verwendungszwecks⁶⁾, jeweils einen vordefinierten Kontainerisierer, Schreibkomponente oder Lesekomponente. Sie definieren somit verschieden Aspekte eines Objekts für die automatisierte Verwendung in eBiss.

Hinweis: Die Abhängigkeiten der Komponenten untereinander bestimmen also auch das Vorgehen beim Anlegen eines Repository.

Exkurs: eBiss „denkt“ in Nachrichten und Anhängen, somit werden auch z.B. von Festplatte oder FTP importierte Dateien wie eine Nachricht mit Anhang betrachtet ⁷⁾. Der Analysator geht dann über jedes Attachment(Anhang) wie folgt vor:

1. verfügbare⁸⁾ Recognizer für die vorliegende Nachrichten Richtung aller Repositorien werden auf Anwendbarkeit überprüft.
   1. können die ersten 8192 Byte des Dateiinhalts gelesen werden?
      1. optional (und), falls angegeben: ist der MatchString in diesen 8192 Byte?
      2. optional (und), falls angegeben: passt der Dateiname zur Angabe in der Dateimaske?
      3. kann ein dem Recognizer zugeordneter Analysator den Inhalt interpretieren?
2. Bei positivem Ergebnis kann der Inhalt erfolgreich analysiert werden.
   1. also wird nun die beim Analysator angegeben Lesekomponente unter Berücksichtigung des bei der Erkennungskomponente angegebenen Encodings angewendet.
   2. zeilenweise Einlesen mit While Schleife:
      1. hat ein neuer Interchange begonnen?
         1. merke die Interchange Start Position im File
            1. hat ein neues Dokument begonnen?
               1. Lese Header und erste Positions info’s
               2. finde Rahmendaten⁹⁾(FrameVariable) aus MetaItem Information oder durch typisierte Analysatoren (z.b. EDIFACT)
                  1. Dokumenten Nummer
                  2. Datum
                  3. Absender
                  4. Empfänger
                  5. etc. (je nach Attribut auf Datenelement in der Objektklasse)
               3. merke die Dokument Startposition im File
            2. schreibe die Dokument Information in die Datenbank
         2. schreibe die Interchange Information in die Datenbank

Hinweis: Siehe auch ER Diagramm für von eBiss zu verarbeitende Entitäten und Erkennung und Analyse Flußdiagramm.