Sidebar
en:howtos:data_rail
Table of Contents
Set up a data link with conversion
The following steps outline the procedure for setting up a data link with transformation to eBiss and show which elements are necessary and in which order the procedure is carried out. One works one's way through from back to front in order to be able to use all dependencies.
Note: take Integration Scenario and Naming conventions in eBiss into account.
1. Define interface types
Preferably compile interface objects with the Type-Editor1) as DLL. Data types according to interface description must be created as C# class with corresponding eBiss specific data attributes in compiled form as DLL in the plugin directory of the eBiss installation and eBiss client and service must be restarted2).
Note: take Integration types into account.
2. Create repositories
Define components required for the new INHOUSE interface objects.
Note: INBOUND Define entity type in Repository with corresponding writer component and containerizer3).
Note: Define OUTBOUND entity type in Repository with corresponding recognition-, analysis- and reader- components.
Repositories for EDIFACT and MiddleWare can be imported from the default template directory4).
Note: Interfaces(Entity-Types) used for both incoming and outgoing communication are a special case! Their entity types make use of all repository components.
3. Create mapping definitions
New mappings are defined for transforming from INHOUSE to MiddleWare5) and from MiddleWare to INHOUSE6) interface objects. For the transformation from MiddleWare to EDIFACT or EDIFACT to MiddleWare standard mappings can be imported from the standard template directory and adapted if necessary.
Note: There are cases where it is best to work with only one transformation. E.g. if there is no corresponding counterpart in the MiddleWare.
4. Define default template partner
As a rule, a template partner is assigned to a future trading partner. This contains the type sets which define the standard mappings for the outgoing MiddleWare to EDIFACT and the incoming EDIFACT to MIddleWare to the corresponding types.
Note: The type sets are queried at:
5. Define message boxes
To be able to process messages in eBiss, they must be containerized in a message box. As a rule, two incoming and two outgoing message baskets are required. e.g.:
Note: Message baskets are required to define communication channels .
Note: The property basket type can be incoming, outgoing, or none. This setting affects the default setting when pasting files into a message box. These messages will then be marked as incoming or outgoing and consequently the corresponding set objects will be queried during analysis. In normal operation messages are created in a message basket via receiving channels or BackendObjectRetrieverEx, where the message gets the direction which is set for the channel.
6. Define communication types or communication channels
Determine communication types between eBiss and HOST system11) or partner system and define corresponding communication channels, with database integrations no communication channels, but BackendObjectIntegrations are used in the JOBs. As a rule, incoming EDIFACT messages are received from http://egate.pranke.com, i.e. an incoming POP3 Empfangskanal must be defined for this, which writes to the previously defined message basket.
Note: In practice, acronyms such as EDI, B2B, A2A, MFT, B2C are used at this point to refer to the relationships on abstract
7. Define processes
Note: The following job definitions represent a standard integration case. These processes can be enriched with different job objects to map e.g. Business Logic.
- A first job to open a receive channel or BackendObjectRetreiver, which then delegates to the next dispatcher, consisting of:
- a second job for analyzing, selecting, transforming and containerizing14) or transferring15) consisting of:
- eBiss.ClassLib.JobExecutionController(optional)16)
-
-
- A third job to open a transmission channel consisting of.
Note: See also typical process.
8. Process automation
The automations are done last to automate the previously defined and manually tested processes. Usually it is sufficient to trigger the first job in a processing chain, because the following jobs are linked by delegators or EventRouter and EventRouteReceiver.
1)
Alternatively, this can be created with suitable IDEs for C#.
2)
see also shadow copy
3)
For direct integration there is no need for write components and no containerizer
4)
..eBiss3/StandardTemplates/RepositoryDump*.xml
5)
outgoing messages
6)
incoming messages
7)
contains the original incoming EDIFACT messages from the partner
8)
contains incoming messages transformed to the INHOUSE types
9)
contains the outgoing original INHOUSE types
10)
contains the outgoing messages transformed to EDIFACt
11)
also called ERP or MMS system.
12)
For a direct integration e.g. with a database.
13)
This points to job #2
14)
in an existing message box
16)
This may be necessary in complex systems with many different parallel running processes.
17)
This branch is repeated for all incoming and outgoing message types within a job and parameterized accordingly.
18)
For two-step transformation via eBiss MiddleWare.
20)
This points to job #3
21)
If not already transferred with eBiss.DbAdapter.BackendObjectTransmitterEx
en/howtos/data_rail.txt · Last modified: 2024/02/20 08:15 by 127.0.0.1