{{indexmenu_n>2}}
====== Extended Features List ======

===== Interfaces =====

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

  - all structured file types, e.g.:
    - XML
    - JSON
    - CSV((Some generic types are part of the eBiss Rollout.))
    - UN/EDIFACT(( 23 Edifact Releases with up to 19 document types inside the most common releases are part of the eBiss Rollout.))
    - ANSIX12((ASN, INVOIC, ORDERS, ORDERSKN are part of the eBiss Rollout.))
    - etc.
  - Database integrations
    - MS-SQL
    - MySQL
    - MariaDB
    - POSTGRESQL
    - DB2
    - DB2 iSeries
    - Oracle
    - ODBC
  - REST API
  - SOAP API
  - COM

To map these different types eBiss offers a very performant tool with the module [[en:programmierung:typbibliotheken:typeditor|]].

===== Repositories =====

The eBiss-[[en:prozessdefinition:repositorien:start|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 [[en:prozessdefinition:repositorien:er|]]. 
There are:

  * **11**((as of writing)) [[en:prozessdefinition:repositorien:lesekomponenten:start|]]s
    * **12((at time of writing)) character set encodings** can be preset, automatic detection can be resorted to, and other type-specific properties can be set.
  * **11**((at time of writing)) [[en:prozessdefinition:repositorien:schreibkomponenten:start|]]s
    * The write component provides **13((at time of writing)) Character set encodings** and other type-specific properties.
  * **8((at time of writing))** [[en:prozessdefinition:repositorien:kontainerisierer:start|]]s
    * For generating filenames and subjects, the containerization component provides three options for each. The scope of a containerizer can be set to the **4((at the time of writing))** 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**((at time of writing)) [[en:prozessdefinition:repositorien:analysator:start|]]s
    * Analyzers allow **14**((currently being written)) different types of partner identification.
  * **10**((at time of writing)) [[en:prozessdefinition:repositorien:erkennungskomponenten:start|]]s
    * **12((at time of writing)) character set encodings** can be preset, automatic recognition can be resorted to, and other type-specific properties can be set.

===== Partner Management =====

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((This can be e.g. different brands.)). 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((at the time of writing)) [[en:partnerverwaltung:kommunikation:adresseanlegen|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 [[en:prozessdefinition:repositorien:entitaetstyp:start|entitytypes]], [[en:transformation:mappings:start|mappings]], [[en:kommunikation:kanal:start|]], 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.

===== Receiving communication =====

==== Receiving channels ====

**11((at time of writing)) [[en:kommunikation:kanal:start#incoming_communication_channels|incoming channels]]** provide rapid connectivity to standard data transfer protocols.


==== Backend integrations ====

If integration via data exchange is not an option and **direct integration** is desired, then [[en:prozessdefinition:jobs:jobsteps:kommunikation:backend:backendobjectretrieverex|]] for a database connection or specially developed job objects are used, for example to query REST or SOAP APIs.

===== Message baskets =====

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.
===== Processes =====

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 [[en:prozessdefinition:start|processes]].
Here, all conceivable constellations within a digitization in the B2B((Business to Business)), B2C((Business to Customer)) or A2A((Application to Application)) environment are possible.

eBiss has **110((at the time of writing)) 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 [[en:prozessdefinition:jobs:jobsteps:allgemein:executeexternal|]] any external processes of the OS can be executed.
===== automations =====

eBiss offers six different possibilities of [[en:prozessdefinition:automatisierungen:automatisierungen|]]. 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.

===== Variables =====

Often varibale circuits are needed to represent [[howtos:businesslogic|Business logic]]. For this purpose three types of [[en:prozessdefinition:variablendefinition:start|variables]] can be freely defined in eBiss.
  - Variables of the type **Flag**
  - Variables of type **Text**
  - 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.


===== Transformations =====
eBiss offers almost infinite freedom in the editor for [[transformation:start|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((at the time of writing)) mappings** which cover the most common EDIFACT scenarios for D96a and D01b.
With the [[en:programmierung:typbibliotheken:typeditor|]] module, any interface type can be derived from CSV, XML, XSD and tables from the supported database systems with a few mouse clicks.

==== Mapping functions ====

eBiss has **174((at the time of writing)) EDI-specific [[en:transformation:mappings:funktionen:start|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 [[en:transformation:mappings:funktionen:allgemein:executeexternal|]] available by default, any external processes of the OS can be executed. Also handy is the mapping function [[en:transformation:mappings:funktionen:allgemein:sendmail|SendMail()]], which allows arbitrary messages to be generated from the transformation context for informational purposes. 

==== Mappings ====

The eBiss mappings are editable with the [[en:transformation:mappings:anlegen:start|Mapping Editor]] in all possible forms, and a wide variety of constructs can be transformed.
Often hierarchical structures are restructured or transformed to flat((By flat structures are meant objects, which contain in each record or data row the information about group membership or even hierarchical dependencies)). 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 [[en:prozessdefinition:jobs:jobsteps:allgemein: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(([[en:transformation:mappings:funktionen:abfragefunktionen:lookup:start|]])), from Excel(([[en:transformation:mappings:funktionen:excel:loadtab|]])) files or from other documents((To be used if several documents have to be merged in the mapping. )) of the same or different message(s)([[en:transformation:mappings:funktionen:allgemein:getmessage|]])([[en:transformation:mappings:funktionen:allgemein:getmessagebysubject|]]).


==== Conversions ====

eBiss can perform all recoding within the transformation of documents. For this purpose, any [[transformation:lookuptables:start|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 [[en:transformation:werteprovider:start|value lists]] and [[transformation:lookuptables:start|translation tables]] can be created by copy&paste from Excel lists.
[[transformation:werteprovider:start|value lists]] can also be served via [[en:transformation:werteprovider:backendid|backendprovider]].

==== Counter ====

With arbitrary **[[en:transformation:zaehler:start|counters]]** consecutive numbering can be handled in the transformations.

===== Transmitting communication =====

==== Sending channels ====

eBiss has **9((as of writing)) [[en:kommunikation:kanal:start#outgoing_communication_channels|sending_channels]]** that can be used "out of the box".

==== backend integrations ====

If integration via data exchange is not an option and **direct integration** is desired, then [[en:prozessdefinition:jobs:jobsteps:kommunikation:backend:backendobjecttransmitterex|]] for a database connection or specially developed job objects are used, e.g. to serve REST or SOAP APIs.

===== Modules =====

Extended requirements are met with the additionally available **17((at the time of writing)) [[en:ueberblick:ebiss_module:start|eBiss modules]]**.