As part of a larger engagement, our client tasked us with migrating their existing, on-premises accounting system to a cloud based solution. They have around 20 individual feeds of data–systems such as inventory, sales order generation, and payroll–which at the time wrote directly to an on-prem Microsoft Dynamics GP instance. The client chose Microsoft Dynamics AX in Azure as their backend system going forward, so I needed to architect and execute a solution to get their current systems to feed data into this new Azure backend.
I ended up choosing MuleSoft Anypoint as the integration platform for the project.
Benefits of MuleSoft
• Intuitive interface: MuleSoft offers a relatively simple flowchart-like interface for constructing “workflows” for data. Even non-technical stakeholders could make sense of the workflows when we’d bring them into demos, which helped to grow confidence in both the tool and the system we are using it to build.
• Composable: Support is included for many common systems such as Salesforce, and can be made to pull data from generic REST APIs or HTTP URLs, SQL databases, flat files on disk, and other ways. The data can be manipulated, transformed, and eventually output to the format of one’s choosing–the same options one has for taking in data are available as outputs.
• Custom code possible: MuleSoft itself is built on top of Java–in fact, there are components available for workflows which allow execution of pure Java code, which can leverage the JDK, which makes MuleSoft incredibly dynamic.
• Testable: MUnit is Mulesoft’s totally integrated unit testing environment. Parts of workflows can be isolated and tested, with mocking services available for mocking data sources, variables, environment settings, etc.
• Continuous Integration/Deployment Support: MuleSoft leverages Maven, the Java build tool, to provide everything you expect in a CI/CD pipeline.
• Easy to maintain: Developing one-off .NET applications to integrate these systems would’ve required a lot of custom code–quite a maintenance headache. Here we had a system that was built specifically to do the kind of integration work required, and offered us a simple and fast way to construct the integration workflows in a more logical, higher-level way, without having to worry about the lower level programming aspects.
A Sample Workflow
For this solution, we needed to consume data from Microsoft SQL databases and from flat files. Several integrations, as we discovered, were Excel workbooks which business stakeholders downloaded from third party sites, transformed according to business rules, and then uploaded manually to GP via GP’s file integration system.
On the output side, AX contains a system called DIXF – Data Import and eXport Framework – which can take various formats of flat file data and import that data into AX. We decided, for simplicity, that all integration outputs would be either pipe delimited CSV or XML for more complex output data structures such as invoices.
We configured AX to pick up our outputs from MuleSoft workflows and store those records, much in the same way as the previous integration system in GP worked.