HTTP channels in MEC (part 1)

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:
0

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:
y

Here is a sample HTTP request/response using Fiddler Composer:
0_ 0__

Documentation

To download the MEC documentation, go to Infor Xtreme > Downloads > Products > Product Search, search for MEC Server and download the documentation:
1.2

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:
1.3

And the training material does not provide any information on the HTTP channels either:
Course

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\ :
2

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:

agreement

Partner Admin

We will use the Partner Administrator tool to setup channels and agreements:
3.1

The Communication’s Receive tab reflects the Java classes that extend com.intentia.ec.shared.IncommingChannel:
Receive_ IncommingChannel

The Communication’s Send tab reflects the Java classes that implement com.intentia.ec.shared.IMessageSender:
Send_ MessageSender
The Agreement’s Process tab reflects the Java classes that extend com.intentia.ec.server.process.AbstractProcess:
3.5_ 3.5___

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.

Mapper Mapper

Grid management

We will administer the HTTP channels and messages from the Infor Grid Applications and the MEC Management Pages:
app Grid

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.

Related articles

Published by

thibaudatwork

M3 Technical Consultant

4 thoughts on “HTTP channels in MEC (part 1)”

Leave a Reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s