Within the scope of process robotics and decision automation, it’s not uncommon for your model the need to have a web service automation mechanism. This can be your internal web service or an external public one on the Internet. Also, the web service can be the new REST API or the old good SOAP. In this blog post, we are going to show you how to deal with these scenarios.
RESTful services are the modern web services that are designed for ease of use, and are lightweight enough to allow almost all mobile devices with any type of platform and hardware to be able to consume them with less CPU intensive instruction. These mostly use JSON as the messaging format, which is widely adapted everywhere.
To consume a REST API service end point, you can simply drag and drop REST API from the toolbox, set up the end point URL, then set the headers and body of the REST API client so that it invokes the service. It’s as simple as that. For authentication, you can also use the same method to grab the authentication token, which allows the next call to use the token.
For example, the flow below authenticates with Sales Force and invokes the second call to grab the list of Leads from the Sales Force account. As a final step, we process the leads that we read from the Sales Force account:
SOAP and WSDL
SOAP is the widely adapted older form of Web Services, and while there are many legacy services you need to integrate into your process, FlexRule provides a discovery platform (using WSDL) as well as client in order to call SOAP services.
To understand the usage of SOAP with your services, simply open the Type Browser (F12 in FlexRule Designer), add the WSDL address, press ‘Discover’, and the list of operations on the service will be listed:
To call grab a client to call a service, you can simply get a client when you define a parameter for your logic (i.e., Flow, Decision, Workflow, etc.).
And once the client is created automatically at runtime, you can call the service operators like any other expressions in your process, robotic or decision automation scenarios:
When the service requires specific types of input parameters, the Native Complex Values can be used for both REST API and SOAP services, which makes it easy to build complex and hierarchical values directly rather than building them indirectly from types to a service call. All the mapping between created values and service arguments will be achieved automatically for you.