HTTP channels in MEC (part 2)

Continuing the guide on how to setup HTTP channels in Infor M3 Enterprise Collaborator (MEC), here is the second part with how to setup and test an HTTPIn channel.

HTTPIn channel

The HTTPIn channel is the easiest to use of the incoming HTTP channels. It creates a simple HTTP server for MEC.

By reading the Java source code of method HTTPIn.runChannel(), we can tell the channel will open a non-blocking Java NIO ServerSocketChannel on the port number that we setup in Partner Admin, and it will wait for incoming connections. Upon receiving a request, the channel will start a thread worker HTTPInSubThreadWorker, then method runWork() will call class HTTPRequest to parse the HTTP request (remember the MEC HTTP channels are not fully HTTP/1.1 compliant so only specific HTTP requests will work), then it will extract the message, it will create a manifest, it will persist the message, it will add the message to the MEC queue, it will return a hard-coded HTTP response with status code 200 OK “The request was successfully processed” regardless of the incoming message (it is also called an acknowledgment received response), then it will close the socket connection, and then the MEC agreement will do the detection and processing of the message.

In EAI, this pattern is called “fire and forget”. There is no possibility of changing the HTTP response, it is a fixed response. I suppose this pattern was designed for high throughput by MEC, to process incoming requests as fast as possible to be able to accept the next requests without bottleneck. This reminds me of the Snd transactions of MI programs that accept requests and do not return a response.

Here is a simple activity diagram of the HTTPIn channel:


Here is an excerpt of the decompiled Java class HTTPIn of package

How to setup

To setup an HTTPIn channel in MEC in an agreement with incoming channel, detection and process:

  1. Start the Partner Administrator.
  2. Select Manage > Communications:
  3. In the Receive tab, click New:
  4. Enter a Name, and select Protocol HTTPIn:
  5. Find an available port number on the MEC server, for example use the following command to see which port numbers are already in use:
    netstat -an | findstr LISTEN


  6. Enter that port number in the Property Port, and click OK:
  7. Check the box Enabled:
  8. Leave the other tabs – Send, M3 API, Databases, DAF – to their default values and click Close.
  9. In the Agreement View, right-click and select Insert group, enter a name for the group, then right-click the group and select Insert agreement, enter a name for the agreement, then in the Basic tab enter a Name:
  10. In the Detection tab, select either XML Detection, Channel detection, or Flat detection. I select Channel detection, Channel Group, and the HTTPIn channel I created earlier:
  11. When we click Save, the Partner Admin will show the warning message “No Body XPath is defined. Are you sure you want to continue?”, it is a false positive because we are not using XML Detection, so we can click Yes to ignore and continue:
  12. In the Process tab, select a process – in order to keep the illustration simple I choose to only Archive the message and not process it – and click Save:
  13. Now Stop and then Start the MEC application in the Infor Grid so that MEC starts our new channel:
  14. In the MEC Management Pages, in the Communication tab, verify that the channel is in State RUNNING:
  15. The HTTPIn channel is now ready to use.

How to test

To test the new HTTPIn channel:

  1. Prepare a sample HTTP request with header and body:
    POST http://localhost:8082/ HTTP/1.1
    Host: localhost:8082
    Content-Type: text/plain
    Content-Length: 12
    Hello World!

    Quirk 1: We send data in the request body using method POST but somehow MEC will also accept method GET even if it is a protocol violation.
    Quirk 2: The HTTP request header Content-Type is mandatory, and without it MEC will throw a java.lang.NullPointerException without further details.

  2. Use an HTTP client like Fiddler Composer to send the request:
    Quirk 3: Somehow when I use a telnet client to send a request to MEC I get a java.nio.BufferUnderflowException on the first byte whereas the telnet client otherwise works correctly with other HTTP servers.
  3. In return, MEC sends the hard-coded response “HTTP 200 OK […] e-Collaborator HTTP Reply […] The request was successfully processed”:
  4. Back in the Infor Grid Management Pages, go to the Message tab and click show on your message:
  5. Click on the icon to open the Archived .rcv file:
  6. That will open the archive file of the message we sent:
  7. The archives files are stored in the file system somewhere at D:\Infor\MECDEV\archive\doc\f\:
  8. You can now use your favorite programming language or application to make the HTTP request.


That was an illustration of how to setup an HTTPIn channel in MEC using the Partner Administrator and Infor Grid so that clients can send HTTP requests to MEC in a “fire and forget” style. For that, we setup the agreement with the incoming channel, detection, and process, then we tested with Fiddler Composer, then we received the hard-coded acknowledgement of receipt, and finally we confirmed in the Infor Grid. In order to keep the illustration simple, I just archived the message and did not process it. In the next part of the guide I will illustrate the HTTPSyncIn and HTTPSyncOut channels and the MEC Mapper to process the message and return customized responses.

Related articles

Published by


ex- M3 Technical Consultant

8 thoughts on “HTTP channels in MEC (part 2)”

    1. Hello Priyantha. Great question. MEC is used for enterprise application integration (EAI) and has a variety of connectors including FTP and HTTP such that MEC can send and receive files using the application protocol chosen by the partner. For instance, this blog post is about the HTTPIn channel in MEC, with it a partner can send files to MEC over HTTP, in case they choose HTTP instead of FTP or in case their software doesn’t do FTP or in case their security policy doesn’t allow FTP. Most implementations use FTP over VPN or FTP+PGP over the Internet neither of which is fully secure so I explored HTTPS in MEC for end-to-end encryption, hence this series of blog posts learning how to do it step by step. /Thibaud


    2. Priyantha, actually, beyond the security properties I mentioned, the other real world usage of HTTP in my case is that after an HTTP request I can immediately send an arbitrary response, and that is not easily possible with FTP. For instance, in my case a partner sends a file to MEC in an HTTP request, then MEC processes the request in M3 by calling some M3 APIs and calculating some data, and then MEC sends the resulting data back to the partner in the HTTP response. That is possible with one HTTP request and response, in the same connection. Unfortunately that is not easily possible with FTP as you can only send a command in the FTP request and get an OK/NOK in the response. The only way to get an immediate arbitrary response with FTP is to extend the protocol with some tricky means like SOAP over FTP or some archaic means like pulling files at a pre-agreed location/time resulting in delays, two roundtrips, and a more complex setup. /Thibaud


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s