{{indexmenu_n>2}}
====== Overview ======

** eBiss ** is a system ((see also: [[wpde> Enterprise_Application_Integration| EAI]] or [[wpde> Application-To-Application | A2A]])) for exchanging data between applications inside and outside their own enterprise.
It supports the integration of different WWS applications through its comprehensible real-time data transfer and can be used for highly flexible applications in IT departments as well as in predefined integrated processes. With eBiss, there is a separation between IT staff and users, that is, Users can easily manage their own processes without the need for IT staff.

===== Typical process =====

The following diagram illustrates the typical processes ((It should be noted that the presentation describes the process for incoming and outgoing messages, which is usually displayed separately)) in eBiss in a simplified way.

{{:images:ebiss_process_simplified.png|}}

{{:images:sign_warning.png?nolink|}}**Note:** This is described in detail in the HowTo **[[en:howtos:data_rail|]]**.

====== Basic =====
In order to be able to respond as flexibly as possible to customer requirements and still not have to create individual mappings for each customer, we at [[http://pranke.com|Pranke GmbH]] are pursuing with eBiss the strategy with the so-called two-stage transformation((Incoming from external format to canonized middleware and from middleware to internal format. Starting from internal format to middleware and from middleware to external format)). This provides that the INHOUSE interface is ideally always operated or queried with only one mapping((Depending on the message direction.)) and individual adaptations are only made in partner specific mappings from EDIFACT((or other external formats)) to the middleware or from middleware to EDIFACT((or other external formats)) if necessary.

  * Outgoing processing
    * **from INHOUSE to MiddleWare preferably only one mapping(1 to 1)!((Only in the absolute exceptional case you need several mappings here.))**
    * from MiddleWare to EDIFACT((or other external formats)) any number of mappings(1 to N)((Depending on specific partner requirements, in minimum one standard mapping.))
  * Incoming processing
    * from EDIFACT((or other external formats)) to MiddleWare any number of mappings(N to 1)((Depending on specific partner requirements, in minimum one standard mapping.))
    * ** from MiddleWare to INHOUSE preferably only one mapping(1 to 1)((Only in the absolute exceptional case you need several mappings here.))**

===== Scheme of the two-stage transformation ======

The philosophy of eBiss usually recommends the use of MiddleWare((The eBiss MiddleWare represents an abstraction layer between EDIFACT and custom INHOUSE message structure and allows to minimize the total number of mappings required and the maintenance effort. There are MiddleWare versions for manufacturers and retailers.)) Abstraction Layers. This means that all incoming and outgoing messages pass through two mappings connected in series. This is shown in the above diagram by the **transformers**. It can be understood in detail as shown in the following sequence diagram.
<sequencediagram>
HOST->eBiss:Message(INHOUSE-OUTBOUND)Format
note left of eBiss: fixed Mapping
eBiss->eBiss:transform INHOUSE-OUTBOUND to eBiss.MiddleWare
note left of eBiss: variable Mapping
eBiss->eBiss:transform eBiss.MiddleWare to EDIFACT
eBiss->PARTNER:Message(EDIFACT-OUTBOUND)Format
PARTNER->eBiss:Message(EDIFACT-INBOUND)Format
note left of eBiss: variable Mapping
eBiss->eBiss:transform DIFACT-INBOUND to eBiss.MiddleWare
note left of eBiss: fixed Mapping
eBiss->eBiss:transform eBiss.MiddleWare to INHOUSE-INBOUND
eBiss->HOST:Message(INHOUSE-INBOUND)Format
</sequencediagram>


===== Topics =====
{{indexmenu>.#1|navbar}}