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. Instead of “pushing” data changes to the ERP, they now only provided Webhook subscriptions. The client’s ERP software was unable to manage this type of communication.
We were asked to add new integration options to the existing integration. 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). So, this meant that we had to make sure that certain data changes in the Field Service software also appeared back in the ERP. The Field Service software had a reasonably common method of allowing this: they provided web hook subscriptions, which monitored changes to certain types of records. This mechanism can often 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. They had 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. But 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.
- We knew that the data contained in the call body from the Web Hook subscription in the Field Service software was limited to the specific record ID. It meant that we needed to trigger a standard API in order 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. The 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. It 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. They could also add additional functionality.
- 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 for our contact details.
You must be logged in to post a comment.