Diverse interfaces form the basis of integration and are essential for the transformation from one interface type to another.

1. all structured file types, e.g.:
   1. XML
   2. JSON
   3. CSV¹⁾
   4. UN/EDIFACT²⁾
   5. ANSIX12³⁾
   6. etc.
2. Database integrations
   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

To map these different types eBiss offers a very performant tool with the module Type editor.

The eBiss-repositories contain necessary, basic settings or components for recognizing, reading/writing and containerizing document types. In the “eBiss Rollout StandardTemplates” directory there are already three essential repositories, which contain or declare the essential EDIFACT-, as well as manufacturer- and retailer-specific MiddleWare types. As a rule, types are declared separately in repositories according to project/integration. Prerequisite for this are the plugins created with the type editor. eBiss repositories can contain any number of entity types. How the entity types are linked to the different repository components can be seen in the Repository Entity Relationship Diagrams. There are:

• 11⁴⁾ Reading components
  • 12⁵⁾ character set encodings can be preset, automatic detection can be resorted to, and other type-specific properties can be set.
• 11⁶⁾ Writing components
  • The write component provides 13⁷⁾ Character set encodings and other type-specific properties.
• 8⁸⁾ Containerizers
  • For generating filenames and subjects, the containerization component provides three options for each. The scope of a containerizer can be set to the 4⁹⁾ different settings individually by document, by document type, by message, or by inbound file. Depending on the containerization type, the 23 address types can be used to specify which address should be used for the interchange or MapFrameDocumentSender/Recipient.
• 17¹⁰⁾ Analyserss
  • Analyzers allow 14¹¹⁾ different types of partner identification.
• 10¹²⁾ Recognition components
  • 12¹³⁾ character set encodings can be preset, automatic recognition can be resorted to, and other type-specific properties can be set.

The logical business entities are distinguished in eBiss into the two main camps. These are on the one hand the trade partners and on the other hand the system partners¹⁴⁾. Groups of trading partners with same characteristics can be summarized within so-called partner templates. A system or trading partner can have any communication addresses based on 16¹⁵⁾ addresstypes. For this purpose, the hierarchical structure of a partner can be mapped with partner locations. Partner locations can have any variable instances. Partner specific message handling is done by wiring entitytypes, mappings, Channels, communication addresses using the so called type set definitions. Partner detection is done by a flexible system that looks either at communication addresses at the partner itself or at the location at the TNr, GLN or other backendIDs.

11¹⁶⁾ incoming channels provide rapid connectivity to standard data transfer protocols.

If integration via data exchange is not an option and direct integration is desired, then BackendObjectRetrieverEx for a database connection or specially developed job objects are used, for example to query REST or SOAP APIs.

For the organization of the messages eBiss offers the arbitrary creation of message baskets, in which the externally received or the messages generated by eBiss can be stored. Messages can also be manually debugged from these message baskets or saved into the file system. Furthermore, any files can be moved into message baskets via drag & drop or copy & paste.

To map and automate the manifold EDI requirements eBiss offers a variety of so called job objects. These can be extended by customer or project specific own objects and be used in processes. Here, all conceivable constellations within a digitization in the B2B¹⁷⁾, B2C¹⁸⁾ or A2A¹⁹⁾ environment are possible.

eBiss has 110²⁰⁾ Job Objects that can be used to solve a wide variety of requirements.

The open architecture of eBiss allows to create project or customer specific components to solve special tasks. With the standard available job object ExecuteExternal any external processes of the OS can be executed.

eBiss offers six different possibilities of Automation. Very often the processes are triggered by recurring time events. Often listening for changes in a file directory is also a good option. So-called Port-EventListeners are often used in a contemporary integration.

Often varibale circuits are needed to represent Business logic. For this purpose three types of variables can be freely defined in eBiss.

1. Variables of the type Flag
2. Variables of type Text
3. Variables of type value list

These variables can be created in any number and also inherited in subnodes and made available for system and/or trading partners. Through a where-used list, it is again possible to see where variables are instantiated. Variables can be queried in mappings or processes using the mapping functions.

eBiss offers almost infinite freedom in the editor for transformations. Usually a two-step transformation is used. In the first step document types are converted from a source type to a normalizing MiddleWare type and in the second step from the MiddleWare to the desired target type. This is not a mandatory procedure, but it is useful in normal EDI business. There are constellations in which it makes more sense to map directly from the source type to the target type. There are also constellations in which it makes sense to apply more than two mappings in a row one after the other. The possibilities are very diverse and can be chosen according to the current need. It can even make sense to have mappings with identical source and target types, e.g. to use type sets or to do validations in the mappings.

In the StandardTemplates directory there are already > 60²¹⁾ mappings which cover the most common EDIFACT scenarios for D96a and D01b. With the Type editor module, any interface type can be derived from CSV, XML, XSD and tables from the supported database systems with a few mouse clicks.

eBiss has 174²²⁾ EDI-specific mapping functions. These “in-house” functions supplement the XPATH functions that already exist in the system. Mapping functions can be used not only in mappings, but also in job objects that provide an XPATH expression as a property. With the mapping function ExecuteExternal available by default, any external processes of the OS can be executed. Also handy is the mapping function SendMail(), which allows arbitrary messages to be generated from the transformation context for informational purposes.

The eBiss mappings are editable with the Mapping Editor in all possible forms, and a wide variety of constructs can be transformed. Often hierarchical structures are restructured or transformed to flat²³⁾. structures are transformed, or flat structures are transformed to hierarchical structures via groupings. Since eBiss keeps all document entities in XML documents in memory, everything can be retrieved from a source object and also addressed or written back to a target object with the XPATH technology. Through clever use of mapping rule sets, rules, and alternative selectors, mappings remain manageable even for complex constructs.

With the so-called MultiEntityTransformer, it is possible to make overlapping evaluations or transformations over several documents of the same type within one message. eBiss also offers special mapping functions, which allow data from recoding tables²⁴⁾, from Excel²⁵⁾ files or from other documents²⁶⁾ of the same or different message(s)(GetMessage)(GetMessageBySubject).

eBiss can perform all recoding within the transformation of documents. For this purpose, any Recoding tables can be created. These can be used globally or partner specific. The foreign keys can be created automatically and then linked once with the return values. The value lists and translation tables can be created by copy&paste from Excel lists. value lists can also be served via backendprovider.

With arbitrary counters consecutive numbering can be handled in the transformations.

eBiss has 9²⁷⁾ sending_channels that can be used “out of the box”.

If integration via data exchange is not an option and direct integration is desired, then BackendObjectTransmitterEx for a database connection or specially developed job objects are used, e.g. to serve REST or SOAP APIs.

Extended requirements are met with the additionally available 17²⁸⁾ eBiss modules.