Initialize plugins

There are a handful of pluginable components that can influence the execution of the Link Initialize process. For all the various types there are implementations that comes with Link out of the box, but cusom implementations can also be made.

InitializeSteps

How to develop Link 3 artifacts | Initialize-Steps

There is a phase in the initialize process where the received payload is intepreted and parsed into a format that is optimal to work with (most often this is XML). Also the input message can be split into multiple messages in this plase, if the payload is a batched message that contains multiple business documents. This phase consists of 5 steps, that are driven by InitializeStep implementations:

DisassembleSystemPre
DisassemblePre
Disassemble
DisassemblePost
DisassembleSystemPost

The main difference between these steps is that the Disassemble step has the responsibility of the following:

Interpreting the payload and parsing it to a format that is optimal to work with (most often XML).
Splitting the message if the payload is a batched message, that contains multiple business documents.

The other 4 steps are in place to provide the oppertunity to inject business logic before and after the DisassembleStep.

The difference between DisassembleSystemPre and DisassemblePre is that the DisassembleSystemPre step executes an implementation specified on a system level, meaning that it is always executed (if one is specified). Whereas when the DisassemblePre step runs, an implementation specified on the current InitConfiguration (todo: insert link to definition of InitConfiguration) is loaded and executed.

The samme difference applies to DisassemblePost and DisassembleSystemPost, where DisassembleSystemPost uses the same InitilizeStep implemtation globally.

DisassembleSystemPre

The InitializeStep specified for this step (if any) will always be executed regardless of what is configured for the InitConfiguration (todo: insert link to definition of InitConfiguration).

A InitializeStep can be configured to be executed at this step, by specifying it under Developer → System Init Steps (associated configurations are also done here):

DisassemblePre

A InitilizeStep can be spefified for the DisassemblePre step on the InitConfiguration (todo: insert link to defintion of InitConfiguration). Both the implementation and the associated configurations are done on the InitConfiguration (todo: insert link to defintion of InitConfiguration):

Disassemble

When the Disassemble step runs, the default behaviour is to run the InitilizeStep specified on the current FormatType (todo: insert link to definition of FormatType):

By default the assocaiated configuration also set on the FormatType (todo: insert link to definition of FormatType) will be applied. The configuration can be overridden on the Format (todo: insert link to definition of Format):

For this to be effective, it is necessary to either specify the Format (todo: insert link to definition of Format) on the InitConfiguration (todo: insert link to definition of InitConfiguration), either exlicitly or implicitly by having a Distribution (todo: insert link to definition of Distribution) set up.

The InitializeStep implementation specified on the FormatType (todo: insert link to definition of FormatType) can be overridden on the InitConfiguration (todo: insert link to definition of InitConfiguration). When doing so the configuration for that step will also be configured there:

DisassemblePost

A InitilizeStep can be spefified for the DisassemblePost step on the InitConfiguration (todo: insert link to defintion of InitConfiguration). Both the implementation and the associated configurations are done on the InitConfiguration (todo: insert link to defintion of InitConfiguration):

DisassembleSystemPost

The InitializeStep specified for this step (if any) will always be executed regardless of what is configured for the InitConfiguration (todo: insert link to definition of InitConfiguration).

A InitializeStep can be configured to be executed at this step, by specifying it under Developer → System Init Steps (associated configurations are also done here):

FormatTypeProbers

How to develop Link 3 artifacts | Format-Type-Probe

Artifacts of type FormatTypeProbe can be used in the Initilize flow in Link to determine if a message matches a given FormatType (todo: insert link to definition of FormatType). The artifact implementation is specified on the FormatType (todo: insert link to definition of FormatType):

The probing mechanism will only be invoked when no FormatType (todo: insert link to definition of FormatType) can be detmined based on the InitConfiguration (todo: insert link to definition of InitConfiguration). Note that best practice is to always specify the FormatType (todo: insert link to definition of FormatType) whenever it is possible, since there can be some overhead when probing the FormatType (todo: insert link to definition of FormatType). This should only be needed when messages with non-distinct FormatTypes (todo: insert link to definition of FormatType) are received at the same endpoint.

DocumentTypeClassifierResolvers

(todo: insert link to definition of DocumentTypeClassifierResolver)

DocumentTypeClassifiers are used in Initilize to facilitate dynamically resolving the DocumentType (todo: insert link to definition of DocumentType) based on the payload.

A DocumentTypeClassifierResolver is registered linked to a ContentTypeGroup (todo: insert link to definition of ContentTypeGroup). So when Initialize is trying to resolve the DocumentType (todo: insert link to definition of DocumentType), all DocumentTypeClassifiers (todo: insert link to definition of DocumentTypeClassifier) configured with a DocumentTypeClassifierResolver that matches the ContentTypeGroup of the current message, will be exectued. The first DocumentTypeClassifer (todo: insert link to definition of DocumentTypeClassifier) that returns a possitive match will determine the DocumentType (todo: insert link to definition of DocumentType).

Example of a DocumentTypeClassifier where the Edifact DocumentTypeClassfierResolver is used. Here the message will be recognized as a “Sales Order” document when message type “ORDERS” is given in the EDIFACT UNH segment. This will be executed if the current message is of ContentTypeGroup Edifact.

ControlMessageInResolver

(todo: insert link to definition of ControlMessageInResolver)

ControlMessageInResolvers can help Link Initialize to process a message as a control message / technical acknowledgement. When this occurs the ControlMessageInResolver implementation retrieves the needed meta-data from the current payload that Link needs to be able to identifiy the original Interchange (todo: insert link to defintion of Interchange) that the control message refers to, so that it’s status can be updated accordingly. This is configured on the DocumentTypeClassifier (todo: insert link to definition of DocumentTypeClassifier).

The example below utilizes the ControlMessageInResolver Edifact, which is a part og Link to process an EDIFACT CONTRL as a control message. When this happens Link updates the original message that the CONTRL message refers to, and skips the Link Itinerary Frameworks (todo: insert link to definition of Itinerary Framework) and completes the current message flow.