In my presentation I cover briefly the details of the methodology we developed for this project which allows us to build a basic interface between two systems in about 30 minutes. In this post I'll outline this methodology and, over the next few posts, I will build out the detail of how this works.
Note that the interface approach I'll describe here focuses on the plumbing between the two systems and intentionally moves business logic for any transformations, control flow or quality of service required outside the interface itself.
There are 5 main components of the interface:
- M3 Web Service
- ION Endpoint for Web Service
- ION Endpoint for file system
- ION Document flow to connect Web Service and file system
- SQL server stored procedure to create XML file for ION
Each of these components take about 5 minutes to set up, and the way they are set up is the same for all web services which makes for a very quick, repeatable process.
M3 Web Service
Via M3 Web Services and the M3 Web Services Designer (both licensed modules from Infor) we expose the API as a SOAP web service, which can be widely consumed to allow easy integration with M3. Conveniently, ION can consume these Web Services and thereby expose standard M3 APIs for List, Get, Create, Update and Delete functions.
ION Endpoint for Web Service
This advises ION the url that the web service will be exposed on, and the methods that will be exposed via this web service. We also define the authentication with M3 (using a M3 username and password) and the identifier that will be used to track the processing of the ION message.
Through this endpoint ION will be able to call the web service we defined above.
ION Endpoint for File System
For this interface design we're accepting an XML file from an external system (in this case SQL Server) and passing this through ION to M3. So here we define the source directory where ION will find the XML files. This source directory can be on a network share, so we also specify the authentication to connect to that share.
Note that we could instead of using the file connector be querying a SQL Server directly via a stored procedure, but we chose the file system approach as it was ultimately simpler and led itself more to code reuse than the direct to SQL approach did.
ION Document flow
The document flow connects the endpoints together and the XML data that will be passed from the file system to the web service. The document flow is where we can use the ION mapper to define business logic (like we can in MEC), but with this approach we do not. ION is simply used to pass the message between systems. Again this design decision reduced complexity and enabled reuse.
SQL Server to create XML file
Here we use SQL server to create the XML file that ION requires. The SQL Server command "FOR XML" allows us to take the output from a SQL query and generate an XML document. We then use bcp to create the XML file.
When we put these components together the architecture looks like this:
The two components on the left refer to the solutions we were integrating with M3 via ION, in this case Infor's Advanced Planner and Advanced Scheduler and a manufacturing plant.
In my presentation I go into some detail about the challenges inherent in those integrations and why an Agile approach was required.
The following posts will cover:
- Building a M3 Web Service over an API and SQL Server's FOR XML
- Building the endpoints and document flow in ION
- Control logic and other considerations
