Pages

Contact

HTTP channels in MEC (part 3)

Continuing the guide on how to setup HTTP channels in Infor M3 Enterprise Collaborator (MEC), here is the third part with how to setup and test the HTTPSyncIn and HTTPSyncOut channels, and how to use the MEC Mapper to process the incoming message and return a customized response.

HTTPSyncIn + HTTPSyncOut

The HTTPSyncIn and HTTPSyncOut channels are used in concomitance to accomplish both HTTP request and response. The HTTPSyncIn channel creates a simple HTTP server to accept requests, and the HTTPSyncOut channel returns custom responses, in the same connection. This is unlike the HTTPIn channel which only responds with a hard-coded acknowledgment of receipt.

Here is a simple activity diagram of both channels jointly in action:

And here is an excerpt of the decompiled Java classes HTTPSyncIn and HTTPSyncOut of package com.intentia.ec.communication:

Both Java classes HTTPSyncIn and HTTPSyncOut live in separate threads, and the keyword sync refers to thread synchronization for the threads to communicate with each other and access the socket channel in shared memory; see class SyncComPool. I do not think the keyword sync refers to synchronous and asynchronous, as in JavaScript XMLHttpRequests, as there are no event handlers in the client here; for the client it is all the same connection.

That means the entire processing of the message in MEC must be completed before the client times out. MEC usually responds within milliseconds, and the client usually times out in tens of seconds, so that leaves plenty of time.

How to setup

We need to setup the following:

Messages

MEC mapping

Receive channel

Send channel

Detection

Processes

Test

Prepare the messages

Let’s prepare two messages: one for the request and one for the response. I will keep it simple for the purposes of illustration, so for the request I will simply send a name, and for the response I will return “hello” + name; it is like an echo request (“ping”) and an echo reply (“pong”) containing the exact data received in the request message.

I have to choose my message format. Remember, MEC is XML-centric. If I choose flat file format I have to create a flat file definition which is also XML. I might as well just do XML from the beginning.

There is a quirk. The files are encoded in UTF-8 and contain a Byte order mark (BOM) like most Unicode files should contain. But when we generate the mapping the MEC Mapper will trip on the BOM and will throw:

Use an HTTP client like Fiddler Composer to send the request to MEC, and in return we get the customized response:

You can now use your third-party applications to communicate with MEC via HTTP.

Conclusion

That was how to setup and use the HTTPSyncIn and HTTPSyncOut joint channels for a client to send a request to MEC via HTTP and receive a custom response. For that, we setup the XML and XSD files for the request and for the response, we created the mapping in MEC Mapper, we setup the agreement in Partner Admin with the receive channel, the detection, the processes, and the send channel, and finally we tested with Fiddler Composer. It is admittedly quite a lot of work for in the end it is just a dynamic HTTP server, but the power of MEC lies in that it is an EAI product tailored to Infor M3 wherein HTTP is just one of the parts of the bigger puzzle. In the next part of the guide I will illustrate the HTTPOut channel for MEC in turn to become an HTTP client.

14 thoughts on “HTTP channels in MEC (part 3)”

I hate to be a critic, but in my opinion this as at best the second best way to interact with M3 over a HTTP socket. I have been to the MEC training since it was highly recommended by consultants and as a result have opted to avoid using the tool all together. I honestly don’t know why people use this tool since setting up transactions takes forever. The MEC tool might be “Easy to use” (I would say that’s up for debate) but it is cryptic and poorly documented and honestly a bit low tech. In my opinion the most powerful way to interact with M3 over a HTTP socket is to host your own web service that uses the M3 API toolkit. You can set up simple transactions like say reporting pick lists or moving stock from one location to another in under 2 hours. Also if you host your own web service you get the benefit of being able to include table lookups in order to make more intelligent transactions an even look up data in other servers outside of the M3 database so that the client doesn’t have to produce all the data required for the transaction. A good example of this would be if you were lot tracking and you wanted to use lot numbers from another system. I guess this sort of assumes you are writing the third party application yourself. I suppose if the data is being presented in XML format from an existing application, using MEC isn’t the worst but if you are writing an application and putting data in XML format just to use MEC that is a bit of an indirect form of communication. I think hosting a web service is a much easier, faster and a more powerful method of communicating with M3. If you take the time and set it up properly you can do some pretty powerful stuff with M3 outside of smart office. On a side note if you host your own service you do get the luxury of using HTTPS protocol instead of HTTP if always using the most up to date protocol is something you are concerned about.

Hi Luke. Thanks for your feedback. Yes, MEC is up for debate. I’m trying to stay away from it as much as possible, like MAK. But MEC is great for its specific purpose of EAI for M3. If you are lucky to be a software developer then you have a plethora of alternative options like the ones you listed. But for those who are not core software developers like us, which is most tech consultants and tech users, MEC will do the job with way fewer lines of code. Also, MEC comes with connectors for banks and business protocols, which you would have to implement yourself otherwise, or find another application that does them. Also, MEC is pre-connected to M3 via Event Hub, MBM, BODs, M3 API. As for table lookups, remember MEC can do JDBC as well, i.e. SQL on M3 and other databases, it’s not a gap. As for web services, if you meant M3 Web Services (MWS) (I don’t think you meant), MWS doesn’t do orchestration whereas MEC does. Also, remember MEC is message based so if M3 goes down, the message-based interfaces to banks and partners will continue to work, whereas a simple home-made web service will throw a connection error to M3, unless you too implement message persistence and message resume, in which case you’re re-implementing the wheel. Like all products, it has its advantages and disadvantages. MEC is one more tool in the toolbag.

Very interesting posts. I have always wondered how HTTP was working with MEC. Just like you said, most of consultants are not java expert or software designers. Due to my lack of java knowledge, i am unable to decompile and understand the different classes of MEC. It^s always interesting to understand what you can do with it, even if it’s not the best way to communicate with M3.

Salut Maxime, thank you for the feedback. Yes, I saw some technical consultants very confused about the whole thing and I decided to figure out the answer by myself and write a post about it. My next posts will be on HTTPS with MEC.

UPDATE: I don’t work with MEC, so I don’t know most of the steps. When I update the XSD in my mapping, and I try to “Save to Database”, MEC Mapper throws “The mapping contains #X new or changed documents which can not be updated on a published mapping. Please unpublish the mapping and save again.” The solution I was told is to:

UPDATE: It turns out we don’t necessarily need a Channel detector per agreement (step 6). Instead, we can keep the global HTTPSyncIn/HTTPSyncOut communication channels (steps 3-4), and use an XML detector per agreement (Target, Target Group, Target Order)). The channel will persist the message, and MEC will iterate thru the XML detectors until it finds ours.