Here is a multi-part guide on how to setup HTTP channels in Infor M3 Enterprise Collaborator (MEC) using the HTTPIn, HTTPOut, HTTPSyncIn, HTTPSyncOut channels such that MEC can communicate with other applications via HTTP.
About this guide
In this first part of the guide I will give an overview of MEC and the tools we will need. In upcoming parts of the guide I will illustrate each HTTP channel: HTTPIn, HTTPOut, HTTPSyncIn, and HTTPSyncOut. And at the end of the guide I will illustrate how to setup MEC for HTTP-Secure (HTTPS), i.e. HTTP over SSL/TLS.
The latest version of MEC that is available for download on Infor Xtreme is MEC version 11.4.2.0, but I do not have that version available to play with, so I will use the previous MEC version 11.4.1.0 from 2013 for which I have a server to play with and to learn.
I do not know the actual design decisions of MEC, and I have not been to a MEC training. In addition, it is difficult to learn MEC from its documentation because it only has partial explanations about the HTTP channels. Therefore, I will decompile the MEC server Java libraries to discover how MEC works internally, and I will ask my colleague Sheryll Limmex for help. As a result, what I write on this guide about MEC may or may not be accurate.
HTTP overview
HTTP is a stateless application protocol for communication between clients and servers usually over TCP/IP. There is an HTTP client and an HTTP server. The client makes an HTTP request to the server with a GET or POST method and a message, and the server responds with an HTTP response to the client with a status code and a message; in brief. The request and response each have a header and a body separated by a blank line. To maintain a session across requests the client and server must use a session identifier usually as a unique id in cookie or a parameter in the URL.
Here is a simple activity diagram between HTTP client and server:
Here is a sample HTTP request:
POST http://www.example.com/ HTTP/1.1 Host: www.example.com Content-Length: 12 Hello World!
Here is a sample HTTP response:
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 81
<!doctype html>
<html>
<body>
Example Domain
</body>
</html>
I like to use a telnet client or Fiddler Composer to simulate a simple HTTP client and forge HTTP requests. And I like to use Netcat or Fiddler AutoResponder to simulate a simple HTTP server and forge HTTP responses.
Here is a sample HTTP request/response using the Windows telnet client:
Here is a sample HTTP request/response using Fiddler Composer:
Documentation
To download the MEC documentation, go to Infor Xtreme > Downloads > Products > Product Search, search for MEC Server and download the documentation:
The M3 Enterprise Collaborator Partner Admin Tool User Guide trickles a few sentences on the HTTPIn and HTTPSyncIn channels, but nothing on the HTTPOut or HTTPSyncOut channels, and nothing on how to secure the communication either:
And the training material does not provide any information on the HTTP channels either:
Java libraries
The most interesting Java library to learn about MEC channels is ec-core-11.4.1.0.0.jar. You can find it in the product download by unzipping products\MEC_11.4.1.0\components\MEC_11410.gar and continuing to MecServer\lib\ . You can also find it in the LifeCycle Manager folder of the MEC server at D:\Infor\LifeCycle\<host>\grid\<grid>\grids\<grid>\applications\<MEC>\MecServer\lib\ :
Client + server
MEC can act either as a server listening to incoming requests from clients (HTTPIn and HTTPSyncIn channels) and returning a response (HTTPSyncOut), either as a client making requests to servers (HTTPOut). The suffixes in/out in the channel names can lead to confusion as they do not exactly reflect the pairs of words client/server nor request/response.
Java NIO
By looking at the Java source code for the HTTP channels in MEC, I can tell they use Java Non-blocking I/O (NIO) and buffers, I suppose it is for high scalability and high throughput of its HTTP channels, for good reason, and it does not use the former and unfavorable Java I/O with its serialization, one-thread per connection and other bottlenecks; that is wondrous as I suppose that allows MEC to handle Gigabytes of data received, and tens of thousands of messages or connections simultaneously; to be confirmed.
Not HTTP/1.1
Unfortunately, when I look at the source code, I can tell the HTTP channels in MEC do not fully implement the HTTP 1.1 specification. They are just in-house subsets of the specification for the purposes of MEC; that is wary if we need specific parts of HTTP 1.1.
Partner agreements
MEC works with partner agreements. They are a combination of:
- Incoming channels of various sorts to accept incoming messages
- Detections to detect the type of incoming messages
- Processes to take action on the messages, for example to decode the message
- Mappings to act on the message, for example to call M3 API, SQL statements or Java code
- Message senders to send a response back to the client
Here is a sample activity diagram:
Partner Admin
We will use the Partner Administrator tool to setup channels and agreements:
The Communication’s Receive tab reflects the Java classes that extend com.intentia.ec.shared.IncommingChannel:
The Communication’s Send tab reflects the Java classes that implement com.intentia.ec.shared.IMessageSender:
The Agreement’s Process tab reflects the Java classes that extend com.intentia.ec.server.process.AbstractProcess:
Mapping development
We will use the MEC mapper (plugin for Eclipse) to create the mappings that will process the incoming requests (and eventually transform XML, call M3 API, SQL statements, and Java code) and send customized responses.
Grid management
We will administer the HTTP channels and messages from the Infor Grid Applications and the MEC Management Pages:
Conclusion
That was a quick introduction of the HTTP channels and tools in MEC that we will use in this guide to setup channels and agreements to communicate with MEC via HTTP.
M3 ideas 
4 thoughts on “HTTP channels in MEC (part 1)”