More interfaces

If you need to integrate Infor M3 with any of the following interfaces, here are most of the interfaces with which I have worked in the past two years for which I have not posted anything on this blog yet, and for which I may be able to help you if you have questions (contact me here). For that, I used a variety of Enterprise Collaborator, Smart Office scripts, and other code.

Also, check-out the other interfaces I have worked with.

Custom message process in MEC

Here is an unofficial guide on how to create a custom message process in Infor M3 Enterprise Collaborator (MEC).

What is a message process?

A message process in MEC is one of the steps in a process flow. Technically speaking, it is a Java class that reads a stream of bytes as an input, does some processing on it, and writes a stream of bytes as an output, for example transform a flat file to XML, apply XSLT to an XML, remove an envelope, archive the message, or make a SOAP request. Message processes are chained together in a partner agreement in the Partner Admin Tool.



The Partner Admin Tool User Guide has some information about message processes:

Java classes

The message processes are Java classes located in MEC’s core library:


Each message process is a Java class in package

Each message process may have a configuration dialog box in package 3


The message processes are declared in the MEC database in table PR_Process:

Java code

To create your own message process follow these steps:

  1. Use the following skeleton Java code, fill with your code, set the file extension for the output message (in my example it is .something), use the in input and out output streams to process the message as you need, and eventually use the cat logger to write debug info in the log file:
    package somewhere;
    import org.apache.log4j.Category;
    public class SomeProcess extends AbstractProcess {
      private static Category cat = Category.getInstance(SomeProcess.class.getName());
      public String getState() {
        return "SomeProcess";
      public boolean hasOutput() {
        return true;
      public String getFileExtension() {
        return ".something";
      public void process(InputStream in, OutputStream out) throws ProcessException {
        // your code here"processing...");

    Note: I do not have a sample code for the dialog box, but you can get inspiration from one of the existing classes in package

  2. Compile the Java code with:
    javac -extdirs D:\Infor\LifeCycle\host\grid\M3\grids\M3\applications\MECSRV\MecServer\lib\
  3. Copy the resulting Java class to the classpath of the MEC server and Partner Admin Tool, in the folder corresponding to the package (in my case it was package somewhere):
    D:\Infor\MECTOOLS\Partner Admin\classes\somewhere\SomeProcess.class

    Note: You can probably also put the Java class in a JAR file; to be tested.

  4. In the MEC database, add the process to the PR_Process table, where ?? is a new ID, for example 27:
    INSERT INTO MECDBDEV.dbo.PR_Process (ID, Name, Description, ConfigurationClass, WorkClass, Standard) VALUES (??, 'Thibaud Process', 'My custom message process', null, 'somewhere.SomeProcess', 1)
  5. In the Infor Grid, restart the MECSRV application to pick up the new Java class:
  6. In the Partner Admin Tool, create a partner agreement and add the message process:
  7. Reload the MEC server to pick up the new agreement:
  8. Run the partner agreement, for example I have a channel detection with a HTTPIn receive channel listening on port 8084, and I make an HTTP request to that port number to trigger the partner agreement.
  9. Check the message received (.rcv) and the message produced (in my case it was extension .something); for that, you will need one Archive process in your partner agreement, before and after your custom process:
  10. You can also open the files directly in the folder specified:
  11. And if you used the logger, you can check your logs in the Event tab:

Real-world example

In my case, I needed a custom message process for the following real-world scenario. My current customer does Procurement PunchOut with its partners using cXML, an old protocol from 1999. In that protocol, there is a step (PunchOutOrderMessage) that sends an XML document in a hidden field cxml-urlencoded of an HTML form. That results in a POST HTTP request (to MEC) with Content-Type: application/x-www-form-urlencoded, with the XML document that is URL-encoded as a value of parameter cxml-urlencoded in the request body. Unfortunately, MEC does not have a message process to extract a specific parameter value of a message, and URL-decode it. So I developed my custom message process as explained above, to take the request body, extract the desired parameter value, URL-decode it, and output the resulting XML. I may write a detailed post about it some day, maybe not.


That was a guide on how to create a custom message process in MEC, doing Java development, to take an input message in a partner agreement, do some custom processing on it, and produce an output message. This is an unofficial solution that I figured out by de-compiling and hacking MEC. There may be a simpler solution, I do not know.

That’s it! Thank you for supporting this blog, please like, subscribe, share around you, and come author the next blog post with us.

Procurement PunchOut with cXML

Hi colleagues. It has been a while since I posted anything. Today I will write a quick post as part of an interface I am currently developing to do procurement PunchOut using cXML, an old protocol from 1999, for my customer and its suppliers. This will eventually end up in their Infor M3 and M3 Enterprise Collaborator implementation.

I only needed to test the Message Authentication Code (MAC) so I wrote a quick prototype in Python.

The cXML User’s Guide describes the MAC algorithm using HMAC-SHA1-96:

Here is my implementation in Python:

# Normalize the values
data = [fromDomain.lower(),

# Concatenate the UTF-8-encoded byte representation of the strings, each followed by a null byte (0x00)
data = b''.join([(bytes(x, "utf-8") + b'\x00') for x in data])

# Calculate the Message Authentication Code (MAC)
digest ="utf-8"), data, hashlib.sha1).digest()

# Truncate to 96 bits (12 bytes)
truncated = digest[0:12]

# Base-64 encode, and convert bytearray to string
mac = str(base64.b64encode(truncated), "utf-8")

# Set the CredentialMac in the XML document
credentialMac = xml.find("Header/Sender/Credential").find("CredentialMac")
credentialMac.attrib["creationDate"] = creationDate
credentialMac.attrib["expirationDate"] = expirationDate
credentialMac.text = mac

Here is my resulting MAC, and it matches that of the cXML User’s Guide, good:

I posted the full source code in my GitHub repository at .

That’s it!

Thank you for continuing to support this blog.

HTTP channels in MEC (part 6)

Here is how to securely receive messages in MEC from partners over the Internet, in this sixth part of the guide on HTTP channels for Infor M3 Enterprise Collaborator (MEC). I will illustrate two goals: how to setup an HTTPIn or HTTPSyncIn channels in MEC over SSL/TLS, and how to expose them securely over the Internet. Previously, for the HTTPIn channel, refer to part 2; for the HTTPSyncIn channel refer to part 3; and for MEC over HTTP Secure (HTTPS) refer to part 5.


The desired goal is to allow partners to securely send messages to MEC using HTTP over SSL/TLS over the Internet. Also, the idea is to design the architecture in such a way that adding new partners is easy.

Here is the simplified diagram:


Unfortunately, MEC does not provide incoming channels for HTTPS, there are no HTTPSIn or HTTPSSyncIn channels. There is a WebServiceSyncIn channel that uses WS-Security for XML over SOAP, but it is not what I am interested in. Ideally, I would prefer to use the Infor Grid which already communicates via HTTPS, but unfortunately it does not have a native connection handler for MEC. Surprisingly, most projects I have seen use FTP + PGP, but that is insecure because the FTP username and password transit in clear text, so even though the files are encrypted a man-in-the-middle could intercept the credentials and create havoc like delete files or fill the disk with junk.

Alternatively, I could develop my own HTTPS server in Java on top of a custom MEC channel; the Java Secure Socket Extension (JSSE) is a good reference guide for how to implement SSL/TLS in Java. I have two options. I could use SSLServerSocket, but it uses blocking I/O contrary to MEC that uses non-blocking I/O for scalability and performance, consequently I would have to forgo scalability and performance. Or I could use SSLEngine to have non-blocking I/O for scalability and performance, but I would have to implement the entire TLS state machine which is overkill for my needs.


I will setup a public web server https∶// at my sample company.

For that, I will setup a reverse proxy with SSL termination upstream of HTTPIn or HTTPSyncIn channels. Thanks to Rickard Eklind for the tip on using Apache + mod_proxy; I will use nginx + ngx_http_proxy_module instead, as it uses non-blocking I/O similar to HTTPIn and HTTPSyncIn, and I think it is easier to setup; either combination will work. I will need to setup the proxy server on the DMZ, setup DNS records, and generate digital certificates.

If you cannot host your own server on the DMZ, or if you cannot create your own domain name in the DNS records, or if you cannot create your own digital certificate signed by a trusted certificate authority, you may be able to piggy back on an existing public web server in your company and simply add a new virtual directory, like https∶// that will forward requests to a content-based filtering router, decrypt, filter, re-encrypt and send the requests to your reverse proxy in the LAN.
Alternatively, I could have setup a dedicated secure line per partner – such as a VPN with a filter to restrict access to only a specific destination IP address and port number for MEC on the LAN – but for each new partner that would require a lot of paperwork, security clearance, and setup on both ends, which is possible, it is more sandboxed thus more desirable, but it may not be possible in some companies. And in some clouds it may be easier to setup web servers than VPNs.

Reverse proxy with SSL termination

A reverse proxy is an intermediate server that executes the client’s request to the destination server on behalf of the client without the client being aware of the presence of the proxy; this is unlike a forward proxy that we setup in a browser. In our case, MEC partners will connect to the reverse proxy as if it were MEC, and the proxy will make the requests to MEC.

SSL termination is where the SSL/TLS connection ends. In our case, the partner will initiate the connection to the reverse proxy using the proxy’s digital certificate (which is the proxy’s public key signed by a certificate authority), then the proxy will decrypt the SSL/TLS data using its private key, then the proxy will make the HTTP request in plain text to MEC, and the response will transit back in the opposite direction. The partner will need to previously have verified and added in its keystore the proxy’s certificate or one of the certificate authorities up the chain.

Here is the simplified nginx.conf:

http {
   server {
      listen 443 ssl;
      ssl_certificate cert;
      ssl_certificate_key key;
      location / {
         proxy_pass http://ecollaborator:8080/;

Here is the simplified diagram:

Note 1: This scenario assumes the servers are on the same network which is not true for the Internet. I will put the proxy in the DMZ. See the DMZ section below.
Note 2: This scenario assumes the data does not need to be encrypted on the second network segment which is not true either. I will install a second proxy on the same host as MEC. See the end-to-end encryption section below.


I need to accommodate multiple partners, for example partnerA, partnerB, and partnerC.

I will use virtual hosting to economically share resources on a single server instead of having a dedicated physical server or virtual private server per partner.


I will multiplex by URL path, for example /A, /B, and /C. I conjecture this is no less secure than doing it name-based or port-based. Also, I conjecture it is not subject to XSS attacks so long as we enforce client authentication (see the client authentication section below).

Here is the simplified nginx.conf:

location /A {
   # partnerA
location /B {
   # partnerB
location /C {
   # partnerC

Here is the simplified diagram:


Alternatively, I could multiplex by domain name, for example,, and But then for each new partner I would need a new network interface with a new public IP address – which is scarce to obtain – and update the A records of my DNS server. Or to share the same IP address I could use Server Name Indication (SNI) and update the CNAME records of my DNS server. In any case, I would have to issue a new digital certificate with an updated Subject Alternative Name (SAN) extension, or I could use one wildcard certificate but loose the possibility of Extended Validation Certificate, and anyway wildcard certificate is not considered secure per RFC6125#section-7.2. In the end, it is a maintenance nightmare, and relying on the respective teams could be a bottleneck in some companies.


As another alternative, I could multiplex by port number, for example,, and, indeed the same digital certificate will work for any port number, but then for each new partner I would have to update the firewall rules, it is possible, but it is more maintenance, and relying on the respective teams could be a bottleneck in some companies.


Then, I need to de-multiplex the requests to tell the partners apart in MEC. I will setup as many HTTPIn or HTTPSyncIn channels in MEC as there are partners, for example HTTPSyncIn_A on port 8081, HTTPSyncIn_B on port 8082, and HTTPSyncIn_C on port 8083, and in nginx for each partner I will setup a location block with a proxy_pass directive.

Here is the simplified nginx.conf:

location /A {
   proxy_pass http://ecollaborator:8081/;
location /B {
   proxy_pass http://ecollaborator:8082/;
location /C {
   proxy_pass http://ecollaborator:8083/;

Here is the simplified diagram:


Here are the receive channels in Partner Admin:



I need the client to authenticate the server, and vice versa, I need the server to authentication the client.

One of the properties of SSL/TLS is authentication, using digital certificates to affirm the identity of the entities, where server authentication is mandatory, and client authentication is optional. In my case, client authentication is mandatory.

Server authentication

The server (the reverse proxy) will present its digital certificate to the client (the MEC partner), and the client will do its certificate validation to authenticate the server.

Client authentication

On the other hand, the server (ultimately it is MEC) needs to authenticate the client (the MEC partner).

I could setup peer authentication for the proxy to verify the client’s digital certificate, but I have not tested this.

Instead, I will setup HTTP Basic authentication per path in the proxy. The username and password will be encrypted over SSL/TLS so they will remain confidential.  I will separate the locations and I will forward to each respective HTTPSyncIn channel in MEC.

Here is the simplified nginx.conf:

location /A {
   auth_basic "A";
   auth_basic_user_file A.htpasswd;
   proxy_pass http://ecollaborator:8081/;
location /B {
   auth_basic "B";
   auth_basic_user_file B.htpasswd;
   proxy_pass http://ecollaborator:8082/;
location /C {
   auth_basic "C";
   auth_basic_user_file C.htpasswd;
   proxy_pass http://ecollaborator:8083/;

In addition to that, we could setup rules in the firewall to only allow the source IP addresses of the partners to access the reverse proxy, it is great if combined with Basic authentication, but insufficient on its own.

To setup peer authentication, I would use ssl_verify_client. According to the nginx documentation, the context for the ssl_client_certificate directive is http and server only, not location. So I would have to append the various client certificates into one file; to be verified. And then I could use the $ssl_client_cert variable to tell partners apart; to be tested.
As another alternative, we could setup client authentication in the MEC agreement using a flat file detector to detect a username and password defined in the HTTP request payload. But that has many problems: 1) It would require hard-coding the username and password in clear text in MEC (passwords should be hashed and salted or at least encrypted), 2) if we need to change the password we would have to change and re-deploy the agreement, and 3) it would put the burden of password verification on MEC which is not designed to thwart brute force attacks.

Channel detection

Now, we have to carry over the authentication to MEC because even though nginx can pass the Basic authentication header to MEC, MEC does not use it, and if we do not authenticate partners and tell them apart they risk crossing each other. For that I will use a Channel detector in the MEC agreement of each partner.

Here are the channel detectors in Partner Admin:


A drawback emerges from this setup: the number of possible messages per channel is now limited to only one. If partner A wants to send two different messages 1 and 2, for example new customer order and new rental agreement, MEC is not able to process two messages in one agreement, and it cannot reuse the same receive channel in another agreement. To assist MEC, I would have to discriminate further by path in nginx, for instance /A/message1, and /A/message2, and have as many receive channels as possible messages. I can use nested location blocks (I have not tested this). Here is the simplified nginx.conf:

location /A {
   auth_basic "A";
   auth_basic_user_file A.htpasswd;
   location /message1 {
      proxy_pass http://ecollaborator:8001/;
   location /message2 {
      proxy_pass http://ecollaborator:8002/;

I am not trained in MEC Partner Admin so maybe there is a way around it.

…on the Internet

Once a web server is placed on the Internet it will get attacked, so consult with your network and security team to harden your servers. It should at least be in the DMZ between one or two firewalls:

Here is a simplified diagram:


Take also into account: high availability, redundancy, fail over, disaster recovery, edge caching, DNS round robin, IDS, content-based firewall, restrict physical access to the servers, restrict permissions to the files, software updates, operating system support, etc.

Note: The HTTP channels in MEC will be the single point of failure in spite of all this setup. The MEC Server runs on the Infor Grid, and the Infor Grid is meant to be distributed, fault tolerant, load balanced, scalable, and redundant. However, the HTTP channels of MEC are not Grid enabled (the HTTPIn and HTTPSyncIn channels manage their port and HTTP server themselves), so they are not distributed, fault tolerant, load balanced, scalable, and redundant, they are a single point of failure. You can learn more about Infor Grid application development on my other post.

End-to-end encryption

Now we need end-to-end encryption to protect the data on the second network segment from the reverse proxy on the DMZ to MEC on the LAN. For that, I will chain two reverse proxies with SSL termination. I will simply install the second proxy on the same host as MEC. And I will issue a second pair of digital certificate and private key for the second proxy that the two proxies will use to encrypt/decrypt. That simplifies the rules of the internal firewall, and I can setup peer authentication between the proxies.

Here is the simplified diagram with the two proxies X and Y:


How to add new partners

To add a new partner D:

  1. Setup a new Receive channel in Partner Admin with a new HTTPIn or HTTPSyncIn channel for example on port 8084
  2. Setup a new agreement with channel detector
  3. Test by making an HTTP request to MEC on port 8084
  4. Setup the inner proxy:
    1. Setup a new location block in nginx.conf for path /D with proxy_pass directive to port 8084 and basic authentication
    2. Setup a new htpasswd file
    3. Restart nginx
    4. Test by making an HTTPS request to the proxy
  5. Setup the outer proxy to pass requests to the inner proxy and test it (I do not have guidelines here as my actual setup for the outer proxy uses a content-based router, not nginx)
  6. Test by making an HTTPS request from the partner to https∶//

How to setup multiple environments

To setup multiple environments, such as DEV, TST, PRD, use nested location blocks in nginx.conf, for example /DEV, /TST, /PRD (I have not tested this).

Here is the simplified nginx.conf:

location /DEV {
   location /A {
      # Development partnerA
   location /B {
      # Development partnerB
location /TST {
   location /A {
      # Test partnerA
   location /B {
      # Test partnerB


This is the first time I setup this architecture, I have not tested all the design variations, and I have not validated that my design is a good design nor that it is secure. I am currently using a similar architecture at a major customer of mine for their production environment where they have multiple data centers, high availability, redundancy, fail over, and disaster recovery. One of their technical people reviewed the solution, they approved it, and the only concerns were that this solution might be over engineered (plausible) and that the MEC channels are the single point of failure anyway (true). I conjecture the solution is good enough and secure enough for our needs. Of course I could be completely wrong and not see a major flaw. Nothing is fully secure anyway. Please let me know what you think in the comments below.

Upcoming version of MEC

Johan Löfgren, the component owner for MEC at Infor Product Development, said they are working on a native HTTPSIn channel for an upcoming version of MEC; it is not GA and the release may or may not occur. If and when that happens, you would not need to chain two proxies anymore, you would just keep one proxy in the DMZ and use proxy_pass to send the requests directly to the HTTPSIn channels in MEC.

UPDATE 2015-04-12: What is being released is SFTP, no plans for HTTPS at the moment.


This was one solution to setup incoming HTTP channels in MEC to securely receive messages over SSL/TLS over the Internet. MEC does not have an HTTPSIn or HTTPSSyncIn channel, and I did not want to implement my own HTTP server over SSL/TLS in Java. Instead, I chose to setup a reverse proxy with SSL termination in a DMZ, with digital certificate and private keys, with HTTP basic authentication, with a second proxy in the MEC host for end-to-end encryption. This solution has many properties: it uses standard HTTP and SSL/TLS, and it is easy to add new partners. Also, we simplified the architecture upstream such that we do not have to rely on other teams if we need to add a new partner, which can be a maintenance nightmare and bottleneck in some companies; we can simply add new partners downstream in our proxy and Partner Admin. I conjecture this solution is secure for our needs. But remember it has not been fully reviewed, and the MEC channels are the single point of failure.

Please let me know what you think in the comments below.

Related articles

HTTP channels in MEC (part 5)

Continuing the guide on how to setup HTTP channels in Infor M3 Enterprise Collaborator (MEC), I will illustrate how to setup the HTTPSOut channel for MEC to make requests using HTTP Secure (HTTPS), i.e. HTTP over SSL/TLS; I will investigate the channel’s features and drawbacks, and I will verify if it is safe to use (it is not).

Why it matters

It is important to use SSL/TLS in partner agreements that need to transfer via HTTP sensitive information such as names, addresses, bank account numbers, purchase orders, credit card numbers, financial transactions, health records, user names, passwords, etc. More generally, it is important to accelerate the adoption of cryptography.

HTTPS in brief

SSL/TLS is a security protocol that provides privacy for a client and a server to communicate over insecure networks. It is a communication layer that sits between a transport layer (usually TCP) and an application layer (for example HTTP). Secure Sockets Layer (SSL) is the original protocol and is not considered secure anymore. Transport Layer Security (TLS) is the successor and everybody should upgrade to its latest version 1.2. https is the scheme token in the URI that indicates we are using a dedicated secure channel often on port 443.


SSL/TLS provides the following properties of secure communication:

  • Confidentiality, using a cipher to encrypt the plain text and prevent eavesdropping
  • Integrity, using signed hashes to detect tampering
  • Authentication, using digital certificates to affirm the identity of the entities

It can also provide non-repudiation, using digital signatures to assert the sender cannot deny having sent the message, provided the sender’s private key is not compromised or changed.

And depending on the key agreement protocol, it can also provide perfect forward secrecy, using ephemeral key exchanges for each session, to ensure that a message cannot be compromised if another message is compromised in the future.


During the SSL/TLS handshake, the client and server exchange digital certificates and establish cipher suite settings. The connection bootstraps with asymmetric cryptography using public and private keys (which eliminates the problems of distributing shared keys), and then switches to symmetric cryptography using a temporary shared key for the session (which is several orders of magnitude faster).

Digital certificates

A digital certificate is a public key and the owner’s identity that have been verified and digitally signed by a certificate authority (CA). Public key infrastructure (PKI) is used to create, distribute, and revoke certificates. If an entity trusts a CA, then by transitive relation it will trust that any certificate the CA issues authenticates the owner of the certificate. There can be any number of intermediate CAs in the chain of certificates, and root CAs use self-signed certificates.

The client must verify the server certificate, and optionally the server may verify the client certificate:

  • Verify the chain of trust
  • Verify the hostname in the certificate using SubjectAltNames and Common Name; this could get tricky with wildcard patterns, null characters, and international character sets
  • Verify the certificate’s activation and expiration dates
  • Verify the certificate’s revocation status using a certification revocation list (CRL) or OCSP
  • Check the X.509 certificate extensions (e.g. can this key sign new certificates?)
  • Check that the certificates of the intermediate CAs have the CA bit set in the “Basic Constraints” field

Despite all that, validating certificates is difficult, and the CA model is broken.


You can test HTTP over SSL/TLS and see the chain of certificates,

with cURL:

curl > cacert.pem
curl --verbose --cacert cacert.pem

with OpenSSL:

openssl s_client -connect -showcerts
GET / HTTP/1.1


A web proxy is a program that makes requests on behalf of a client. There are different types of web proxies, for example tunneling proxies, forward proxies, and reverse proxies. And there are different implementations, for example, explicit proxies and transparent proxies. And they have different purposes, for example caching, load balancing, securing, monitoring, filtering, bypassing, and anonymizing. Proxies may require authentication.

An explicit web proxy is for example when you set your browser to use a proxy at a certain host and port number. With that proxy, the client makes an HTTP request to the proxy using the CONNECT method, then the proxy establishes a TCP connection to the destination server, and then the proxy acts as a blind tunnel that is forwarding TCP between client and server, seeing only the SSL/TLS handshake and then encrypted traffic.

You can test HTTP over SSL/TLS via an explicit proxy,

with cURL and Fiddler:

curl --verbose --cacert cacert.pem --proxy

with proxy authentication:

curl --verbose --cacert cacert.pem --proxy http://username:password@proxy:port/

with GNU Wget and Fiddler:

export https_proxy=localhost:8888
wget --debug --https-only

You will see this request and response between client and proxy, then the SSL/TLS handshake, then the HTTP traffic:

HTTP/1.1 200 Connection Established

On the other hand, a transparent proxy intercepts the traffic at the lower network level without requiring any client configuration. It acts as the SSL termination for the client, and establishes a second encryption channel with the destination server thereby being able to monitor and filter the SSL/TLS traffic in transit; in that case the client is not aware of the presence of the proxy but must trust the proxy’s certificate, and the proxy must trust the server’s certificate.


In our case, we want MEC to communicate with partners over a secure channel with confidentiality, integrity, and authentication to protect the data being exchanged, optionally via proxy.


MEC does not provide secure channels for HTTP out of the box. For instance, there are no HTTPSIn, HTTPSOut, HTTPSSyncIn, or HTTPSSyncOut channels. There is an HTTPSOut channel, but it is only a sample in an appendix of the documentation (does that mean it is safe to use?), and it does not come out of the box in the Partner Admin, it must be added manually (although it is available in the Java library). Also, there is a WebServiceSyncIn channels that uses WS-Security specifically for XML over SOAP, but in my case I am interested in HTTPS in general, for example for flat files, I am not interested in SOAP. Ideally, I would prefer to use the Infor Grid which already communicates via HTTPS, but unfortunately it does not have a native connection handler for MEC.

None of this means MEC is insecure, it just means you have to add the security yourself.


The useful documentation

The MEC Partner Admin Tool User Guide contains the necessary source code and some explanation for the HTTPSOut channel and user interface:
doc1 doc2doc3

The obstructing documentation

However, the documentation references HTTPS Communication, HttpServer.xml, and HTTPSOut at the same time, yet it does not clearly explain the relationship between them, so it is confusing:
doc4 doc5

I had to find the Communication Plug-in Development User Guide of an old version of MEC to find the answer. It turns out the HttpServer.xml was a file that existed in old versions of MEC to configure the web user interface. I think the sample in the documentation used that server to test the HTTPSOut channel; I do not know. Anyway, that file does not exist anymore after MEC was ported to the Infor Grid, so that chapter is irrelevant, confusing, and unrelated to HTTPSOut. We can ignore it, and Infor should remove it from the Partner Admin guide.

Java classes

The MEC Java library ec-core-x.y.z.jar includes the Java classes sample.HTTPSOut and sample.HTTPSOutPanel:


Looking at the source code, the HTTPSOut channel is similar to the HTTPOut channel: they both make a POST HTTP request to a destination server, at a host, port number, and path defined in the Partner Admin, with the message sent in the request body.

HTTPSOut uses which in turn uses to establish a secure socket with the destination server. From the HTTPSOut point of view, it just reads/writes plain HTTP to the socket, and the socket underneath takes care of the handshake and encryption/decryption.

HTTPSOut has an advantage over HTTPOut. Given the entire HTTP traffic is encrypted over SSL/TLS, we can safely set a username and password for HTTP Basic authentication, unlike with HTTPOut where we should not set a username and password because they transit in clear text (trivial Base64 decode).


HTTPOut and HTTPSOut share the same drawbacks: they do not use Java NIO, and there are no proxy settings.

HTTPSOut has additional drawbacks: there are no settings for Content-type, multi-part, and keep alive, unlike HTTPOut. Worse, the response is completely ignored unlike HTTPOut where the response is at least added to the debug log.


You can test the HTTPSOut class with the following code and with a message.txt file:

javac -cp log4j-1.2.17.jar;ec-core-;.
java -cp log4j-1.2.17.jar;ec-core-;. Test < message.txt
import java.util.Properties;
import sample.HTTPSOut;

public class Test {
    public static void main(String[] args) throws Exception {
        Properties props = new Properties();
        props.setProperty(HTTPSOut.HOST, "");
        props.setProperty(HTTPSOut.PORT, "443");
        props.setProperty(HTTPSOut.PATH, "/");
        props.setProperty(HTTPSOut.USER, "username");
        props.setProperty(HTTPSOut.PASSWORD, "*****");
        props.setProperty(HTTPSOut.TRUST_STORE, "C:\\somewhere\\keystore");
        props.setProperty(HTTPSOut.TRUST_STORE_PWD, "*****");
        HTTPSOut client = new HTTPSOut();
        client.send(, null, props);

HTTPSOut will send the following request over SSL/TLS:

POST /Hello HTTP/1.1
Content-Type: multipart/form-data; boundary=----------------------------afatudbu6sb5-875oo9dmn52fzfypuig0x1kv
Authorization: Basic: dXNlcm5hbWU6cGFzc3dvcmQ=
User-Agent: M3 Enterprise Collaborator v11.4.1.0
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 256
Content-Disposition: form-data; name="name"; filename="output.xml"
Content-Type: application/xml

Hello, World!

Activity diagram

Here is a sample activity diagram of the HTTPSOut channel:


Authentication bug

There is a bug in the HTTPSOut class regarding the HTTP Basic authentication header that will cause the server to return HTTP/1.1 401 Unauthorized, and that is easy to fix:

// incorrect
urlConn.setRequestProperty("Authorization: Basic", Base64.encode (to64, "ISO-8859-1"));
// correct
urlConn.setRequestProperty("Authorization", "Basic " + Base64.encode (to64, "ISO-8859-1"));

The bug is located in both the HTTPSOut source code in the Partner Admin guide, and in the HTTPSOut class in the JAR file. And the JAR file is located in both the Partner Admin tool and in the MEC server in the Infor Grid.

That code is only executed if you need HTTP Basic authentication (i.e. if you specify a username and password); you can ignore it otherwise.


If you need to use a proxy, add the following code to the HTTPSOut class and recompile it:


// get the proxy properties
String proxyHost = props.getProperty(PROXY_HOST);
int proxyPort = Integer.parseInt(props.getProperty(PROXY_PORT));
String proxyUser = props.getProperty(PROXY_USER);
String proxyPassword = props.getProperty(PROXY_PASSWORD);

// connect via proxy
InetSocketAddress proxyInet = new InetSocketAddress(proxyHost, proxyPort);
Proxy proxy = new Proxy(Proxy.Type.HTTP, proxyInet);
HttpsURLConnection con = (HttpsURLConnection) url.openConnection(proxy);

// authenticate to proxy
Authenticator.setDefault(new Authenticator() {
    protected PasswordAuthentication getPasswordAuthentication() {
        return new PasswordAuthentication(proxyUser, proxyPassword.toCharArray());

//con.setRequestProperty("Proxy-Authorization", "Basic " + Base64.encode(proxyUser + ":" + proxyPassword, "ISO-8859-1")); // this did not work for me

You will need to add some if-then-else so the user can choose to use a proxy or not, and add some exception handling around parseInt.

Also, for the user interface, you will need to add a group widget, a checkbox, four labels and four text boxes to the HTTPSOutPanel class and recompile it:

Security holes

Unfortunately, the HTTPSOut class does not verify the certificate and as such the connection is susceptible to man-in-the-middle attack.

For instance, it does not verify the hostname of the certificate, it just returns true for any hostname:

HostnameVerifier hv = new HostnameVerifier() {
    public boolean verify(String s, SSLSession sslSession) {
        return true;

More so, HTTPSOut does not verify the certificate’s dates, revocation, basic constraint, extensions, etc.

Thus, HTTPSOut is not safe to use out of the box. You have to implement certificate validation yourself. That is probably why it is only a sample.


To compile the HTTPSOut and HTTPSOutPanel classes:

  1. Recover the source code (either copy/paste it from the Partner Admin guide, or decompile the classes).
  2. Change the code as needed (e.g. fix the authentication bug, add the proxy settings, add certificate validation, etc.)
  3. Compile the source code with:
    javac -cp lib\log4j-1.2.17.jar;lib\ec-core- sample\
    javac -cp lib\x86-3.3.0-v3346.jar;lib\log4j-1.2.17.jar;lib\ec-core-;. sample\
  4. Replace the Java classes in both the Partner Admin tool folder and in the MEC server folder of the Infor Grid, for example:
    D:\Infor\MECTOOLS\Partner Admin\classes\sample\
    4.2_ 4.2__
  5. Restart the Partner Admin and restart the MEC server in the Infor Grid.
  6. The class loader will give precedence to the classes you put in the folders over the classes in the JAR file.

1. Preparation

Before we can use HTTPSOut, we have to prepare the terrain for SSL/TLS.

As a reminder, the HTTPSOut channel is an HTTP client that will make an HTTP request to a destination HTTP server over SSL/TLS, e.g. to

1.1. Server authentication

The short instructions to setup server authentication are:

openssl s_client -connect > example.cer
keytool.exe -import -file example.cer -keystore example.ks -storepass changeit

The long instructions are the following.

We need to setup server authentication, i.e. for HTTPSOut to affirm the identity of the server it is connecting to; it will rely on SSLSocket to verify that the server certificate is signed by a certificate authority that is stored in a trusted keystore.

Internet Explorer, Google Chrome, Fiddler and other programs that use WinINet ultimately rely on the Windows certificate manager, certmgr.msc, but Firefox and Java each use their own key management. The JRE has its default keystore at %JAVA_HOME%\lib\security\cacerts that SSLSocket uses. HTTPSOut ignores the default keystore and requires the user to specify one. To create a Java keystore we use keytool.exe and import the server’s certificate in it.

The steps are:

  1. Open a browser to the destination server over HTTPS and open the certificate:
  2. Inspect the certificate, any intermediate certificate authorities, and the root certificate authority, up the chain, and make sure you trust them (if your browser does not trust them it will throw a big warning sign):
    2.5 2.6
  3. Now we need Java to trust that certificate. Check if one of the certificates in the chain is already in your Java keystore. Java already comes with a list of trusted certificates in its keystore. If the destination server presents a certificate that is already trusted by one of the trusted certificates of the JRE, it will automatically be trusted by the JRE, i.e. the friends of my friends are my friends. In my case, my JVM already trusts the certificate authority DigiCert, so by chain of trust it will automatically trust the certificate presented by It may be the same case for you:
    keytool.exe -list -keystore cacerts -storepass changeit | findstr /i DigiCert
    keytool.exe -list -keystore cacerts -storepass changeit -v -alias digicerthighassuranceevrootca


  4. If you already have the server certificate, good, just keep in mind the location of that keystore, and skip the rest of these steps; otherwise continue reading.
  5. Export the certificate to a file, e.g. example.cer:
    2.6_ 2.6__
  6. Import the certificate to a keystore, e.g. example.ks:
    keytool.exe -import -file example.cer -keystore example.ks -storepass changeit

  7. Now you have a keystore ready for HTTPSOut.

1.2. Client authentication

As for client authentication, the HTTPSOut channel does not support that, i.e. it does not have a public/private keys and a digital certificate to present to the server if the server requests it, so we have to forget about that. If the server needs to authenticate the client, we can use Basic authentication (provided we fix the authentication bug).

2. How to setup

Now let’s setup the HTTPSOut channel in MEC.

The steps will be:

  1. Setup the Send protocol
  2. Setup the Send channel configuration
  3. Setup the Agreement with detection and processes

2.1. Setup the Send protocol

  1. Open the Partner Admin tool
  2. Go to Manage > Advanced
  3. Select the Send Protocols tab
  4. Click New, and set:
    Protocol: HTTPSOut
    Send class: sample.HTTPSOut
    UI class: sample.HTTPSOutPanel
  5. Click OK
  6. Click Close

2.2. Setup the Send channel configuration

  1. Go to Manage > Communications
  2. Select the Send tab
  3. Click New:
  4. Select protocol HTTPSOut and enter the information host, port number and path to the destination server, as well as the keystore where you saved the certificate and the keystore password, and optionally set user and password for HTTP Basic authentication to the destination server (provided you corrected the authentication bug):
    Note: The keystore path is relative to the JVM that runs MEC server, i.e. java.exe must be able to access the file and have read permission to it. Also, given the Infor Grid is distributed make sure the keystore file is distributed accordingly to the correct server.
  5. Optionally set the proxy settings if you added that feature to the classes (see proxy section above)
  6. Click Send test message to ensure everything is correct; if you get an error message, test the HTTPSOut class as explained in the test section above, or check the troubleshooting tips in the section below
  7. Click OK
  8. Click Close

2.3. Setup the Agreement with detection and processes

  1. 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.
  2. Go the agreement > Processes, right-click select Send, and select the HTTPSOut channel:
    5.1 5.2
  3. Click OK
  4. Click Save
  5. The HTTPSOut channel is now ready to use

3. How to test

To test the HTTPSOut channel, follow the same instructions as in the test of Part 4.

4. …on the Internet

If you are doing the HTTPS requests to a server out on the Internet you should consult with your security team. I have MEC in a LAN behind a NAT, firewall, content based filter, security appliance, and transparent proxy.

5. Troubleshooting

In case HTTPSOut does not work as expected, here are some troubleshooting tips.

Check the logs

The MEC server logs are useful for troubleshooting problems. For example, in one case I got the following exception: PKIX path building failed: unable to find valid certification path to requested target


That means the server certificate validation failed, either because we put the incorrect server certificate in the keystore that we defined in PartnerAdmin, either because a man-in-the-middle server presented a different certificate.

Test SSL/TLS connection

Some network and security administrators setup firewalls, proxies, and gateways that interfere with SSL/TLS. In my case, I will ensure that my host can access the destination server over SSL/TLS. For that:

  1. Locate on which node is MEC server running:
  2. From that server (for example via Remote Desktop Connection), make a test connection to the destination server over SSL/TLS, for example use OpenSSL s_client:
    openssl s_client -connect -showcerts
  3. Make sure the server certificate that is presented is the correct one.

Test HttpsURLConnection

  1. Check what JVM the MEC server is using:
  2. Use that JVM to test a HttpsURLConnection; that will check if that particular JVM of that host has access to read that keystore, it will check if it can make a SSL/TLS connection to that destination server, and it will show the server certificates received:
    // javac && java -cp . Test
    public class Test {
        public static void main(String[] args) throws Exception {
            System.setProperty("", "D:\\java\\jre\\lib\\security\\cacerts");
            System.setProperty("", "changeit");
            URL url = new URL("");
            HttpsURLConnection con = (HttpsURLConnection) url.openConnection();
            OutputStream out = con.getOutputStream();
            Certificate[] scerts = con.getServerCertificates();
            for (Certificate scert: scerts) {


See the section at the top to test the HTTPSOut class.


That was an illustration of how to setup the HTTPSOut channel in MEC so that MEC can act as a client making secure HTTP requests to servers over SSL/TLS. For that, we reviewed the basics of HTTPS, we reviewed the features and drawbacks of HTTPSOut, we learned how to fix the authentication bug, how to add proxy settings, we identified security holes, we learned how to recompile the classes, how to setup the channel in PartnerAdmin, how to test, and how to troubleshoot.

HTTPSOut lacks features, it has a bug, and it has security holes; that is probably why it is just considered a sample channel that is unsafe to use in a production environment. Take it as a starting point from which you can build your own safe channel with production quality.

Hopefully, Infor will remove the deprecated documentation from the Partner Admin guide, will enhance the HTTPSOut channel from unsafe sample to safe channel with production quality, and will eventually provide a native connection handler in the Infor Grid for MEC.

In the next part of this guide, I will illustrate how to setup HTTPS for inbound messages.

(Congratulations if you made it this far! Let me know what you think in the comments below.)

Related articles

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.


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 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 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; 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 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 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 “ 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.


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


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.

HTTP channels in MEC (part 3)

Continuing the guide on how to setup HTTP channels in Infor M3 Enterprise Collaborator (MEC), here is the third part with how to setup and test the HTTPSyncIn and HTTPSyncOut channels, and how to use the MEC Mapper to process the incoming message and return a customized response.

HTTPSyncIn + HTTPSyncOut

The HTTPSyncIn and HTTPSyncOut channels are used in concomitance to accomplish both HTTP request and response. The HTTPSyncIn channel creates a simple HTTP server to accept requests, and the HTTPSyncOut channel returns custom responses, in the same connection. This is unlike the HTTPIn channel which only responds with a hard-coded acknowledgment of receipt.

Here is a simple activity diagram of both channels jointly in action:

And here is an excerpt of the decompiled Java classes HTTPSyncIn and HTTPSyncOut of package

Both Java classes HTTPSyncIn and HTTPSyncOut live in separate threads, and the keyword sync refers to thread synchronization for the threads to communicate with each other and access the socket channel in shared memory; see class SyncComPool. I do not think the keyword sync refers to synchronous and asynchronous, as in JavaScript XMLHttpRequests, as there are no event handlers in the client here; for the client it is all the same connection.

That means the entire processing of the message in MEC must be completed before the client times out. MEC usually responds within milliseconds, and the client usually times out in tens of seconds, so that leaves plenty of time.

How to setup

We need to setup the following:

  • Messages
  • MEC mapping
  • Receive channel
  • Send channel
  • Detection
  • Processes
  • Test

Prepare the messages

Let’s prepare two messages: one for the request and one for the response. I will keep it simple for the purposes of illustration, so for the request I will simply send a name, and for the response I will return “hello” + name; it is like an echo request (“ping”) and an echo reply (“pong”) containing the exact data received in the request message.

I have to choose my message format. Remember, MEC is XML-centric. If I choose flat file format I have to create a flat file definition which is also XML. I might as well just do XML from the beginning.

My incoming sample message request.xml will be:

<?xml version="1.0" encoding="UTF-8"?>

And my outgoing sample message response.xml will be:

<?xml version="1.0" encoding="UTF-8"?>
<message>Hello Thibaud</message>

Then, we have to create an XML Schema (*.xsd) for each XML file. For that, I will use the XML Schema Definition Tool (Xsd.exe) from the Microsoft .NET Framework with the command:

C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\
xsd.exe request.xml
xsd.exe response.xml

2.1_ 2.2_ 2.3_

The tool creates the files request.xsd and response.xsd.

There is a quirk. The files are encoded in UTF-8 and contain a Byte order mark (BOM) like most Unicode files should contain. But when we generate the mapping the MEC Mapper will trip on the BOM and will throw:

com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character '?' (code 63) in prolog; expected '<'
 at [row,col {unknown-source}]: [1,1]
Generate failed


So we have to remove the BOM, for example with Notepad++ select Encode without BOM and save the file:


Setup the mapping

Now, let’s create a mapping in MEC Mapper to take the input message and create the customized response:

  1. Start the MEC Mapper.
  2. Create a new Project and a new Mapping, browse to the request.xsd and to the response.xsd, and click Finish:
  3. MEC mapper will display the XML elements of the request on the left and those of the response on the right. We have to do the mapping in between.
  4. From the palette, add a Java function to the mapping, then add an Input parameter and an Output parameter to the function, and connect the elements together from left to right:
  5. Then, right-click on the Java function, select Edit Java code, enter the following code in function(), save the file, and close the tab:
    oParameter = "Hello " + iParameter;


  6. Right-click in the mapping, select Save to Database, select the mapping database location, and click Finish:
    3.7_ 3.7__ 3.9_
  7. Right-click in the mapping again, select Generate, select the server location, and click Finish:
    3.10b 3.10c 3.11_
  8. Right-click in the mapping one last time, select Publish, select the server location, and click Finish:
    3.12_ 3.13 3.14
  9. Go to the Infor Grid Management Pages for MEC > Server > Mappings, locate the mapping, click Activate for the state to become Active:
  10. Go to the Server tab, click Reload Server Control, and click Yes to confirm:
  11. The mapping is now ready to be used in Partner Admin.

Setup in Partner Admin

Now let’s setup the HTTPSyncIn and HTTPSyncOut channels in MEC:

  1. Start the Partner Admin.
  2. Go to ManageCommunication.
  3. In the Receive tab, create a new inbound channel with protocol HTTPSyncIn and a port number, and set the checkbox Enabled:
  4. In the Send tab, create a new outbound channel with protocol HTTPSync (it means HTTPSyncOut):
    1.2_ 1.2___
  5. Create a new Agreement.
  6. In the Detection tab, select the HTTPSyncIn channel just created:
  7. In the Processes tab, add process XML Transform, and select the Mapping created earlier:
    1.6_ 1.7
  8. Then add a process Send and select the HTTPSyncOut channel created earlier:
    1.8_ 1.9_
  9. Stop and start the MEC application in the Infor Grid, and the HTTPSyncIn channel will be in status RUNNING:
  10. Now the HTTPSyncIn and HTTPSynOut channels and agreement are ready to be used.


Let’s test the new HTTPSyncIn and HTTPSyncOut channels:

  1. Prepare a sample HTTP request with header and body:
    POST http://localhost:8085/ HTTP/1.0
    Content-Type: application/xml
    Content-Length: 62
    Host: localhost:8085
    <?xml version="1.0" encoding="UTF-8"?>
  2. Use an HTTP client like Fiddler Composer to send the request to MEC, and in return we get the customized response:
    5a 5b
  3. You can now use your third-party applications to communicate with MEC via HTTP.


That was how to setup and use the HTTPSyncIn and HTTPSyncOut joint channels for a client to send a request to MEC via HTTP and receive a custom response. For that, we setup the XML and XSD files for the request and for the response, we created the mapping in MEC Mapper, we setup the agreement in Partner Admin with the receive channel, the detection, the processes, and the send channel, and finally we tested with Fiddler Composer. It is admittedly quite a lot of work for in the end it is just a dynamic HTTP server, but the power of MEC lies in that it is an EAI product tailored to Infor M3 wherein HTTP is just one of the parts of the bigger puzzle. In the next part of the guide I will illustrate the HTTPOut channel for MEC in turn to become an HTTP client.

Related articles

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

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, but I do not have that version available to play with, so I will use the previous MEC version 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:

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>
        Example Domain

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


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- 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
Receive_ IncommingChannel

The Communication’s Send tab reflects the Java classes that implement
Send_ MessageSender
The Agreement’s Process tab reflects the Java classes that extend
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


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