Objective
Our client had an existing, simple integration in place between their ERP and a Field Service software package. They wanted to expand on this integration, but the integration methods provided by the Field Service software had changed from “pushing” data changes to the ERP, to the use of Webhook subscriptions. The client’s ERP software was unable to manage this type of communication.
We had been approached to add to their existing integration between the two software packages, so as part of this work we also needed to develop an inexpensive and simple way of handling the data traffic between the two software solutions.
Solution Delivery
- The Field Service software saw themselves as the source of truth of the data. They published APIs to enable data to be read or updated in their own software, as well as allowing for new data to be added in their required format. For our client, the actual data source of truth was their ERP software, not the Field Service software. This meant that certain data changes in the Field Service software had to be reflected in the ERP. The method available to do this in the Field Service software was not uncommon: they allowed for web hook subscriptions to monitor changes to certain types of records. This mechanism can be as simple as for a data type trigger on an insert, change or delete or as sophisticated as a configurable query. In this particular scenario, it only offered a simple insert, change, or delete trigger.
- In order to use these web hook subscriptions to send changes to the ERP, the responsibility fell back on our client to setup and maintain a public web server with a web service endpoint configured to accept the contents of the web hook call.
- This intermediary piece also needed to be able to manage the different levels and methods of authentication required by both the Field Service software and the ERP. Each system also had its own way of dealing with both the trigger mechanism for firing or receiving a web hook call and the data contained in the call. These were not compatible, as both systems essentially wanted the other system to do all the work.
- Data contained in the call body from the Web Hook subscription in the Field Service software was limited to the specific record ID. This meant that a standard API would need to be triggered to retrieve all data relating to the record changed.
- We built a “Web Hook Listener”, which we placed on existing server infrastructure that our client had in place. This Web Hook Listener was configured to:
- manage the security authentication that both sides needed;
- to “listen” for each change notified by the Field Service web hook subscription;
- to make the call to trigger the appropriate standard API containing all changes for the record;
- and then to send that data on to the ERP for interpretation and processing.
Achievements
- Our Web Hook Listener was implemented without additional hardware costs and required minimal network configuration changes.
- We delivered a solution which was an inexpensive fix for a complicated problem and allowed each of the software systems in use to work within their requirements and limitations.
- The solution worked within the client’s existing infrastructure. It was capable of being deployed server based or serverless, cloud or self hosted.
- As a bespoke solution, we were able to apply logic at the receipt of the web hook call. Alternatively, the web service could simply pass through the payload to the downstream system for processing.
- All of this meant that it was possible for the client to expand on their existing integration and add additional functionality, as required.
- The Web Hook Listener is adaptable, allowing integrations to new software products to be added as required.
If you’d like to learn more about this project or talk to us, click here to contact us.
You must be logged in to post a comment.