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

And here is an excerpt of the decompiled Java classes HTTPSyncIn and HTTPSyncOut of package com.intentia.ec.communication:
HTTPSyncIn HTTPSyncOut

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"?>
<name>Thibaud</name>

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

3.10_

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

XML

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.1_
  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:
    3.4__
  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;

    3.5_

  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:
    4.1_
  10. Go to the Server tab, click Reload Server Control, and click Yes to confirm:
    4-2__
  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:
    1.1
  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:
    1.5_
  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:
    4.2__
  10. Now the HTTPSyncIn and HTTPSynOut channels and agreement are ready to be used.

Test

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"?>
    <name>Thibaud</name>
    
  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.

Conclusion

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

Published by

thibaudatwork

M3 Technical Consultant

14 thoughts on “HTTP channels in MEC (part 3)”

  1. I hate to be a critic, but in my opinion this as at best the second best way to interact with M3 over a HTTP socket. I have been to the MEC training since it was highly recommended by consultants and as a result have opted to avoid using the tool all together. I honestly don’t know why people use this tool since setting up transactions takes forever. The MEC tool might be “Easy to use” (I would say that’s up for debate) but it is cryptic and poorly documented and honestly a bit low tech. In my opinion the most powerful way to interact with M3 over a HTTP socket is to host your own web service that uses the M3 API toolkit. You can set up simple transactions like say reporting pick lists or moving stock from one location to another in under 2 hours. Also if you host your own web service you get the benefit of being able to include table lookups in order to make more intelligent transactions an even look up data in other servers outside of the M3 database so that the client doesn’t have to produce all the data required for the transaction. A good example of this would be if you were lot tracking and you wanted to use lot numbers from another system. I guess this sort of assumes you are writing the third party application yourself. I suppose if the data is being presented in XML format from an existing application, using MEC isn’t the worst but if you are writing an application and putting data in XML format just to use MEC that is a bit of an indirect form of communication. I think hosting a web service is a much easier, faster and a more powerful method of communicating with M3. If you take the time and set it up properly you can do some pretty powerful stuff with M3 outside of smart office. On a side note if you host your own service you do get the luxury of using HTTPS protocol instead of HTTP if always using the most up to date protocol is something you are concerned about.

    Like

    1. Hi Luke. Thanks for your feedback. Yes, MEC is up for debate. I’m trying to stay away from it as much as possible, like MAK. But MEC is great for its specific purpose of EAI for M3. If you are lucky to be a software developer then you have a plethora of alternative options like the ones you listed. But for those who are not core software developers like us, which is most tech consultants and tech users, MEC will do the job with way fewer lines of code. Also, MEC comes with connectors for banks and business protocols, which you would have to implement yourself otherwise, or find another application that does them. Also, MEC is pre-connected to M3 via Event Hub, MBM, BODs, M3 API. As for table lookups, remember MEC can do JDBC as well, i.e. SQL on M3 and other databases, it’s not a gap. As for web services, if you meant M3 Web Services (MWS) (I don’t think you meant), MWS doesn’t do orchestration whereas MEC does. Also, remember MEC is message based so if M3 goes down, the message-based interfaces to banks and partners will continue to work, whereas a simple home-made web service will throw a connection error to M3, unless you too implement message persistence and message resume, in which case you’re re-implementing the wheel. Like all products, it has its advantages and disadvantages. MEC is one more tool in the toolbag.

      Like

  2. Hello Thibaud,

    Very interesting posts. I have always wondered how HTTP was working with MEC. Just like you said, most of consultants are not java expert or software designers. Due to my lack of java knowledge, i am unable to decompile and understand the different classes of MEC. It^s always interesting to understand what you can do with it, even if it’s not the best way to communicate with M3.

    Nice work!

    Like

    1. Salut Maxime, thank you for the feedback. Yes, I saw some technical consultants very confused about the whole thing and I decided to figure out the answer by myself and write a post about it. My next posts will be on HTTPS with MEC.

      Like

  3. UPDATE: I don’t work with MEC, so I don’t know most of the steps. When I update the XSD in my mapping, and I try to “Save to Database”, MEC Mapper throws “The mapping contains #X new or changed documents which can not be updated on a published mapping. Please unpublish the mapping and save again.” The solution I was told is to:

    1. Go to Partner Admin > your agreement > Processes > XML Transform > Delete + Save
    2. Go to Manage > XML Mappings > your mapping > Unpublish
    3. Go to MEC Mapper > Save to database + Generate + Publish
    4. Re-add the XML Transform process to your partner agreement + Save
    5. Reload the server
    6. Re-activate your map

    That seems like a lot of work during development time. Let me know if there is a quicker way to continuously update mappings in short cycles.

    Like

  4. UPDATE: It turns out we don’t necessarily need a Channel detector per agreement (step 6). Instead, we can keep the global HTTPSyncIn/HTTPSyncOut communication channels (steps 3-4), and use an XML detector per agreement (Target, Target Group, Target Order)). The channel will persist the message, and MEC will iterate thru the XML detectors until it finds ours.

    Like

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 )

Google+ photo

You are commenting using your Google+ 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 )

Connecting to %s