The Repository is the location for the read, analysis and write tools to process incoming data or to write/create outgoing data. It consists of a maximum of six components and is usually used in the following job objects:

• EntityAnalyzer
• EntitySelector
• EntityTransformer
• EntityMessageCreator

and also used by the method Debugging/Analyse message on the message view.

When reading or analyzing, each repository accesses the corresponding three subcomponents Recognizer (recognition component), Analyzer (analyser) and Reader (reading component). The repository also uses a fourth component with the entity types that are also defined below. These are the document types or format definitions that eBiss knows - e. g. EDIFACT DESADV D. 96A or in-house format delivery notes. During this detailed analysis, the file type (XML, CSV, EDIFACT…) is first of all recognized in order to recognize documents2) and partners3).

When writing, the repository also accesses the document format definitions from the entity types, as well as the other two sub-components Containerizer (containerizer) and Writer (write component). Since eBiss always manages several document types in one system with corresponding read and write components, these are grouped. So there are several repositories: Typically one for EDIFACT formats, another for in-house formats and another one for eBiss-specific middleware formats.

Since eBiss always manages several document types in one system with corresponding read and write components, these are grouped. There are therefore several repositories: typically one for EDIFACT formats, another for in-house formats and another for eBiss-specific middleware formats.

To create a repository successfully, you must first define the purpose of the repository. It is recommended that you delimit a repository for e. g. all types that are to be exchanged between a host system and eBiss.

The Repository Entity Relationship Diagrams shows the dependencies of the repository components to each other.

A repository can contain several optional and required components.

• Writing component have no dependency, define the format in which an entity is to be written…
• Reading component have no dependency, but are necessary to read entities from an external system.
• Recognition component have no dependency, they define how entities are to be recognized based on the data format, the file mask or the match string and the message direction (incoming or outgoing).
• Containerizerrequire a predefined write component and can also be used individually in Typesets hey are required if an entity is to be created as a message.
• Analysers require a predefined recognition component and a predefined read component. They are used to uniquely identify an entity and, if necessary, to extract the sender and recipient information. One or more entity types must be assigned to an analyzer.¹⁾

• Entity types need, depending on the purpose of use²⁾, a predefined containerizer, writer or reader. Thus they define different aspects of an object for the automated use in eBiss.

notice: The dependencies between the components also determine the procedure for creating a repository.

Excursus: eBiss “thinks” in messages and attachments, thus also e.g. files imported from hard disk or FTP are considered as a message with attachment (but the file name is then set as subject of the message). The analyzer then proceeds over each attachment as follows:

1. available³⁾ recognizers for the present message direction of all repositories are checked for applicability.
   1. can the first 8192 bytes of the file content be read?
      1. optional (and), if specified: is the MatchString in these 8192 bytes?
      2. optional (and), if specified: does the file name match the specification in the file mask?
      3. can an analyzer associated with the recognizer interpret the content?
2. If the result is positive, the content can be successfully analyzed.
   1. so now the read component specified at the analyzer is applied considering the encoding specified at the recognition component.
   2. line by line reading with While loop:
      1. has a new interchange started?
         1. note the interchange start position in the file
            1. has a new document started?
               1. read header and first position info's
               2. find frame data⁴⁾(FrameVariable) from MetaItem information or by typed analyzers (e.g. EDIFACT)
                  1. Document number
                  2. date
                  3. sender
                  4. Recipient
                  5. etc. (depending on attribute on data element in the object class)
               3. note the document start position in the file
            2. write the document information into the database
         2. write the interchange information into the database

Note: See also ER diagram for entities to be processed by eBiss and Recognition and analysis flowchart.