Showing posts from January, 2016

How MEC Message Flow Work

Like any other middle-ware application MEC has unique architectural components. Below diagram depicts them.Inbound message will be consumed by the MEC and goes through detection rules defined in the partner agreement. Detection is either channel or XML detection. If inbound message is a flat file, channel detection will be used.
For XML detection, inbound message must have meta data to configure the detection.

Note below payload has RequestHeader as meta data.
<!-- Items goes here-->

detection configuration is:
Detection information  & rules are saved in MEC storage. MEC will evaluate all saved detections (in a order) until its find the correct one. Once the detection has passed, process the message based on the defined processing steps. (in the given order)


M3 Integrations (MEC)

I was able to refresh my knowledge of   M3 integration with MEC (M3 E-collaborator).  MEC is a middle-ware specifically design for M3 integration development. Over the past few years it has been evolved.
MEC has following components: Flat-File definition tool -  Using this tool you can create XML schema file. Also it can generate sample Flat File & XML file for the schema. Flat-File Repository manger - Is the repository for the local and server definitions. Mapper - Use to transform data to a output file or update M3 directly for the given input schema and the defined logic. It has certain functions to perform this level of transformation.  (Later, with my next posts I'm hopping to reveal them). If you are familiar with Ms-BizTalk server, it's orchestration and MEC mapper is  similar in behavior. Partner Admin tool - Use to configure agreement for the integration such as, DetectionProcessesError handlingand other admin tasks (e.g. communication, web-service definitions, Ev…