At this time, the majority of developers and solution architects are very well aware of the MS Dynamics AX capabilities to support different integration paths with third-party applications. Based upon different requirements one can choose integration paths like file-based, http based, etc. However, sometimes there are peculiar requirements from customers where none of the standard integration paths can be used and at such times, we have to think ‘outside the usual’ and come out with a workable solution for the same. There can be various reasons for this – like customer already has an established php front end for its customers/vendors/employees and wants to use & integrate it with AX with minimal changes to the existing system. One such option is to integrate (http adapter) with php application using JSON.
JSON integration is not supported in AX, so we have to do customizations for the same. Again, we have many options like either we write a code to accept JSON based values and serialize it to xml or dataset and use the records OR develop a utility bundled in dll, which will do the transformation for you. In this blog, we will discuss the later approach.
We will create an integration port in AX to accept the data and store it in the staging tables. Secondly, we will create mid-tier .net utility as a web service, which will accept JSON values from the third party, serialize it and send that converted data to AX by calling AX web service.
- Creating integration port in AX: One can either use document-based integration using a wizard or write custom data contract & service class to create an inbound port in AX. This service will accept the data and store it in staging tables so that other functionalities can use the data for various postings.
- Creating .net web service (mid-tier): One can create a simple web service in asp.net using C#. In this service, one will add a reference to the AX web service we created in point (1) above. In addition, one needs to use third-party dll for serializing the received JSON values to AX SOAP xml format. Hosting this service and sharing the service url with third-party dev so that they can consume it and send across the JSON data.
This is a very important aspect in this whole process. If we do not have proper error handling in place then be prepared to spend hours in identifying the issue and long delay in fixing the same. We will break the error handling points as below:
- JSON formatting error: Most of the dll that you are going to use for serialization itself will handle this. So make sure this code is inside ‘try-catch block’. In addition, there needs to be a mechanism in place to communicate the ‘error to caller’ based on specific requirements.
- Data error: Best would be to get this handled at AX level. In AX, we already have ‘service and contract’ objects where you can have a validation in place, which checks the incoming data. Also, we need to make sure that the error raised by AX propagates to the caller via .net utility web service.
Once everything is in place the integration is ready for testing, and thereafter for production. It goes without saying that to solve one problem there are numerous solutions, but one has to pick a solution, which seems feasible depending upon the requirements.