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 com.intentia.ec.communication:

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.

Conclusion

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

• HTTP channels in MEC (part 1)
• HTTP channels in MEC (part 3)