Inhaltsverzeichnis

Typ-Repositorien

Das Repository1) 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:

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 Dokumente2) und Partner3) 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.

Abhängigkeiten der Komponenten

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

Ein Repository kann mehrere optionale und erforderliche Komponenten enthalten.4)

Optionale Repository Komponenten

Erforderliche Repository Komponenten

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

Ablauf beim Lesen: Erkennung & Analyse

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 7). Der Analysator geht dann über jedes Attachment(Anhang) wie folgt vor:

  1. verfügbare8) 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 Rahmendaten9)(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.

Themen

1)
Das Repository ist ein Objektcontainer für Hilfsobjekte, welche zur Analyse eingehender bzw. ausgehender Entitäten herangezogen werden. Mit Hilfe dieser Objekte können eingehende Entitäten auf ihren Inhalt, z.B. Dokumente oder Interchanges untersucht und ausgehende Entitäten zusammengestellt werden.
2)
Der Inhalt der Dateien.
3)
Anhand der in der Objektklasse definierten Merkmale(Identifier).
4)
Je nach Anwendung können diverse Komponenten wie z.Bsp. Anaylsatoren, Schreib- oder Lesekomponenten obsolet sein. So ist z.Bsp. im Rahmen einer Datenbankintegration i.d.R. keine Lese- oder Schreibkomponente erforderlich, da dies für den entsprechenden Entitätstyp vom BackendObjectTransmitter und BackendObjectRetriever gehandhabt wird.
5)
Ausnahmen sind EDIFACT und SAP Idoc Analysator Typen
6)
Von eBiss zu verarbeitend oder zu erzeugend.
7)
als Betreff der Nachricht wird dann aber der Dateiname gesetzt
8)
nur aktive bzw. die vom im Analyser Jobstep ausgewählten Repository vorhandenen
9)
Hier werden die Rohdaten (auch für die Partnererkennung) gesammelt . Beim Schritt in die DB speichern wird nun versucht die Verbindung zu den Trading- bzw. SystemPartner anzulegen.