When you use a workflow automation platform like, you sometimes want a workflow to update another system in the organisation. Every time your company receives a customer order, for example, you want the order fulfilment process to update a giant scoreboard in the office that shows the number of orders placed that day. This is a job for web service integration.
This article describes how you can connect a workflow to another application’s database. As a simple example, the web service integration will capture the identifier of every case when it starts to record ‘case started’ events.
The source code and documentation for this example is available at
Web service integration is a completely flexible way to publish data from a workflow to other systems in the organisation. This makes it possible for workflows to automatically update other systems.
In this architecture, the workflow sends data to a connector that acts as a proxy for the database. The organisation that owns the database will typically deploy the connector in a, to avoid the risk of making the database available on the public Internet. Alternatively, you could host both the database and the connector in the cloud.
The connector is a simple web service that updates the database. Specifically, it must provide:
Java is one of many common choices for building this kind of connector. There are many Java libraries and frameworks that you can use to implement the HTTP interface, and connect to a database. Theuses the for HTTP, and to connect to a MySQL or PostgreSQL relational database using the databases’ JDBC drivers.
In practice, you can also build a connector with a different programming language and its associated libraries, or use a non-relational database. The best choice for this kind of task is typically whatever the developers are most familiar with.
If you want to use theexample connector yourself, you’ll first need to deploy it somewhere. To deploy the example connector on , follow the detailed instructions in the example’s , which describes the following steps.
Test that the installation worked by sending an HTTP request to publish a case started event, using an HTTP client such as:
The result should be an HTTP response with a ‘201 CREATED’ status:
HTTP/1.1 201 Created Connection: close Content-Type: text/html;charset=utf-8 Date: Thu, 17 Aug 2017 09:05:40 GMT Server: Jetty(9.4.4.v20170414) Via: 1.1 vegur
Now check that the case started event was added to the database:
$ heroku pg:psql --> Connecting to postgresql-blackberry-12345 psql (9.6.4, server 9.6.1)
database-update::DATABASE=> select * from case_event; id | case_id | created | type ----+---------+-------------------------+--------- 1 | 42 | 2017-08-17 09:07:08.563 | started (1 row)
Now that the connector works, you can send it data from a workflow.
To send data to the connector every time a case starts, configure a script task at the start of the process to send the HTTP request. In the script configuration, add the ‘Case’ variable, so you can access the case ID.
Now publish the process, start a new case, and check the database again to see the new case event.
database-update::DATABASE=> select * from case_event; id | case_id | created | type ----+--------------------------+-------------------------+--------- 1 | 42 | 2017-08-17 09:07:08.563 | started 2 | 59955edfd1dfff2afffe4dd6 | 2017-08-17 09:16:16.795 | started (2 rows)
The second row includes the ‘case_id’ from the new workflow case. To extend the example, you could include more information in the HTTP request and in the database table, such as the case name or trigger form data.
Try your own web service integration with, and register for a today.