HTTP channels in MEC (part 4)

Here is the fourth part of the guide on how to setup HTTP channels in Infor Enterprise Collaborator (MEC), this time with how to setup and use the HTTPOut channel such that MEC acts as a client making HTTP requests to servers; that is the opposite of the HTTPIn and HTTPSyncIn and HTTPSyncOut channels where MEC acts as a server.

Documentation

The M3 Enterprise Collaborator Partner Admin Tool User Guide does not mention anything about the HTTPOut channel (no matches found in search), but if we read the pages attentively there is a chapter Setting Up Send Channels with a section on HTTP. After some studying of the HTTPOut Java code and testing in PartnerAdmin I confirm that section is effectively referring to the HTTPOut channel. Unfortunately it is just one sentence with no substantial information, and it is incorrect in that “the content type returned” should be “the content type of the request” and in that there is no such thing as “content type web browser”.

Java code

By reading the partially recovered Java source code of class HTTPOut in package com.intentia.ec.communication we determine it is indeed an HTTP client (not a server, and not a response like the word out in HTTPSyncOut suggests). It uses a java.net.HttpURLConnection to make the request to the server defined in PartnerAdmin with host, port number and path.

It supports connection keep alive, Basic authentication, no-cache directives, and multi-part content types.

Unfortunately, there are some drawbacks. The scheme is hard-coded to “http” so there is no HTTP-Secure possible; whereas it is possible with javax.net.ssl.HttpsURLConnection; although there is an HTTPSOut channel provided in the sample chapters of the documentation. The user and password transit in clear text (trivial Base64-decode). It is a departure from the benefits of Java NIO; see part 1 of the guide. The response is ignored (at best it is logged in the debug files) so I do not think there is a possibility for MEC to process the response. And it does not have support for a proxy.

Activity diagram

The HTTPOut channel is a Send process in a partner agreement, in other words it is a message sender, or an outgoing channel. More precisely it is an HTTP client making a request to a server. For the HTTPOut channel to run, the partner agreement must be triggered by an incoming channel such as DiskIn, Event Hub subscriptions, HTTPIn, and others.

Here is a simple activity diagram of the HTTPOut channel:

Again, the word pair in/out does not reflect the word pairs client/server and request/response, and that can cause confusion.

How to setup

To setup an HTTPOut channel in MEC:

1. Start the PartnerAdmin.
2. In Communications > Receive, setup any incoming channel such that we can simply trigger the partner agreement for the purposes of illustration; the protocol is not important right now; for instance I have a simple DiskIn channel that has status RUNNING in my Infor Grid, and I have a partner agreement with it in a channel detection:
   
3. In Communications > Send, add a new HTTPOut channel by selecting Protocol HTTP:
   
4. Enter the host, port number, and path of the server; that will construct the URL http://host:port/path:
   
   Note 1: The Content type is optional as HTTPOut will attempt to guess it based on the contents of the file using the Java method URLConnection.guessContentTypeFromName.
   Note 2: The checkbox Keep connection alive is to keep the TCP connection persistent and not close it, probably if there are multiple Send processes to eliminate the three-way handshake during connection establishment and reduce latency, although that is only useful for millisecond requirements, or to reduce network congestion (fewer TCP connections) although that is only useful for requirements with tens of thousands of concurrent connections; for the rest of us we can leave unchecked; I have not tested this.
   Note 3: The checkbox Post as multi-part is for sending multiple messages into one request; I have not tested this. By reading the Java code of the HTTPOut class, I can see the boundary is hard-coded to —————————, i.e. simply 27 repetitions of the dash character, which means if your file contains the same string (plausible) there could be unexpected results, like the request will fail or the message will be truncated.
   Note 4: The user/password is for HTTP basic authentication (Base64 encoded), but because this is for HTTP only (not HTTPS) the user/password transit in clear text (trivial Base64 decoding), i.e. it can be viewed by eavesdroppers, and it has no encryption and no message verification, i.e. it can be tampered by man-in-the-middle, so do not use this over unsecure networks.
5. You can click Send test message for the HTTPOut channel to send a sample HTTP POST request to your server; I have Fiddler running on default port 8888 and it has a neat Fiddler Echo Service that I use as a simple HTTP server:
   
   Quirk: I notice the HTTPOut channel (or something else in MEC) generated two content type headers, they do not have the same case, they have different values from each other, and neither value is text/plain as I had specified in the PartnerAdmin; that again causes an HTTP protocol violation:
   
6. Go to the Partner Agreement > Processes, add a Process Send:
   
7. Select the HTTPOut channel created earlier:
   
   Note 1: I suppose the encoding is for the binary encoding of the message in the HTTP response body; I have not tested this.
   Note 2: I suppose the Zip-output checkbox is for compressing the message in the HTTP response body; I have not tested this.
   Note 3: The Zip entry name is probably referring to java.util.zip.ZipEntry to compress the message and give it a file name; I did not know HTTP compression needed a file name.
   Note 4: I do not know what Routing Run On Host means.
8. You can choose actions for Error Handling; in my case I leave it blank to keep it simple here:
   
9. The HTTPOut channel is now ready to use.

How to test

To test the new HTTPOut channel:

1. Prepare a sample trigger for the partner agreement; in my case I have a simple message.txt file with content Hello, World! that I drop in the folder to trigger my DiskIn channel detection.
2. Prepare the HTTP server on the other end to log the request so we can see the result; in my case I have Fiddler AutoResponder that will return the built-in HTTP 200 with a sample HTML page:
   
3. Trigger the partner agreement to execute the Send Process; in my case I drop the message.txt file in the folder.
4. The HTTPOut channel makes the request to the server, and we get the result; in my case in Fiddler:
   
5. We can see the Event in the MEC Management Pages in the Infor Grid “Message successfully sent using protocol HTTP”:
   
   Note: I see no trace of the HTTP response in MEC; as suspected, MEC seems to ignore the response body.
6. Also, for testing purposes, I set my Fiddler AutoResponder to respond with HTTP 404 Not Found, and thankfully the MEC Events show “error processing”, ERROR, and a Java stack trace with java.io.FileNotFoundException which is correct:
   
7. Also, for testing purposes, I set my Fiddler AutoResponder to respond with HTTP 502 Unreachable Server, and likewise the MEC Events show “error processing”, ERROR, and a Java stack trace with “java.io.IOException: Server returned HTTP response code: 502 for URL” which is correct:
   
8. You can now use your third party applications to receive HTTP requests from MEC.

Conclusion

That was how to setup the HTTPOut channel for MEC to act as a client and make requests to servers. For that, we setup the HTTPOut channel in PartnerAdmin, we setup the partner agreement with the Send process, and we tested with Fiddler. The HTTPOut channel is almost undocumented, not a state-of-the art HTTP client, and has drawbacks, but it suffices for most simple cases. In the next part of this guide I will illustrate how to setup a secure incoming HTTP channel for MEC, i.e. HTTP over SSL/TLS for MEC.

Related articles

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

UPDATES

2015-03-31: I removed my incorrect note about the boundary as in fact there is a random string appended to the boundary.

2015-03-19: I updated the documentation section about the content type, proxy, and HTTPSOut, and updated the quirk section about the content type.