{{indexmenu_n>3}}
{{images:typ_repositorien.png?nolink}}
====== Typ-Repositorien ======

Das Repository((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.))
 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:
  * [[prozessdefinition:jobs:jobsteps:allgemein:EntityAnalyzer|]]
  * [[prozessdefinition:jobs:jobsteps:allgemein:EntitySelector|]]
  * [[prozessdefinition:jobs:jobsteps:allgemein:EntityTransformer|]]
  * [[prozessdefinition:jobs:jobsteps:allgemein:EntityMessageCreator|]]

und darüber hinaus auch von der Methode **[[transformation:mappings:debug#quellobjekt_instanzieren_aus_einer_nachricht|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((Der Inhalt der Dateien.)) und Partner((Anhand der in der Objektklasse definierten Merkmale(Identifier).)) 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 **[[prozessdefinition:repositorien:er]]** zeigt die **Abhängigkeiten** der Repository Komponenten zueinander.\\ 

Ein Repository kann mehrere **optionale** und **erforderliche** Komponenten enthalten.((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 [[prozessdefinition:jobs:jobsteps:kommunikation:backend:backendobjecttransmitter|]] und [[prozessdefinition:jobs:jobsteps:kommunikation:backend:backendobjectretriever|]] gehandhabt wird.))
===== Optionale Repository Komponenten =====

  * **[[prozessdefinition:repositorien:schreibkomponenten:start|Schreibkomponenten]]** haben keine Abhängigkeit, definieren das Format in welcher eine Entität geschrieben werden soll..
  * **[[prozessdefinition:repositorien:lesekomponenten:start|Lesekomponenten]]** haben keine Abhängigkeit, sind aber notwendig um Entitäten von einem externem System zu lesen.
  * **[[prozessdefinition:repositorien:erkennungskomponenten:start|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.
  * **[[prozessdefinition:repositorien:kontainerisierer:start|Kontainerisierer]]** benötigen eine vordefinierte Schreibkomponenten und können individuell auch in [[partnerverwaltung:typset:start|Typesets]] verwendet werden. Sie werden benötigt wenn eine Entität als Nachricht angelegt werden soll.
  * **[[prozessdefinition:repositorien:analysator:start|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.((Ausnahmen sind EDIFACT und SAP Idoc Analysator Typen))

===== Erforderliche Repository Komponenten =====

  * **[[prozessdefinition:repositorien:entitaetstyp:start|Entitäts Typen]]** brauchen, in Abhängigkeit des Verwendungszwecks((Von eBiss zu verarbeitend oder zu erzeugend.)), jeweils einen vordefinierten Kontainerisierer, Schreibkomponente oder Lesekomponente. Sie definieren somit verschieden Aspekte eines Objekts für die automatisierte Verwendung in eBiss.

{{:images:sign_warning.png?nolink|}}**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 ((als Betreff der Nachricht wird dann aber der Dateiname gesetzt)). 
Der Analysator geht dann über jedes Attachment(Anhang) wie folgt vor:

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

{{:images:sign_warning.png?nolink|}}**Hinweis:** Siehe auch [[prozessdefinition:repositorien:er#von_ebiss_zu_verarbeitende_entitaeten|ER Diagramm für von eBiss zu verarbeitende Entitäten]] und [[prozessdefinition:repositorien:recognitionandanalyzing]].
===== Themen =====

{{indexmenu>:prozessdefinition:repositorien|navbar}}