Overview
Bizagi presents an integration layer which provides easy configuration for integration with existing applications, through diverse alternatives.
Through this integration layer, Processes in Bizagi can directly communicate with external systems to obtain business information or to update it.
The main feature presented by the integration layer is the Web services connector in Bizagi, which allows your processes to invoke external services through standard web protocols (e.g SOAP).
|
Other alternatives for B2B integration, such as Bizagi Connectors, are described at Bizagi connectors. |
Before you start
Bizagi has a Proxy configuration option available to connect with external services such as the Web services connector.
When to use the Web services connector?
Consider as an example, a Credit Request Process in which we may need to look up in a Credit Bureau (or any other system) if the applicant is in the Black List, or to verify his or her burrowing capacity.
As shown in the image below, Proce
sses may have many integration points where they need to invoke external services:
In Bizagi, configuring this type of integration is done through a generic Web service connector which can connect to standard SOAP Web services or RESTful services, either residing in an internal network location (intranet) or in the cloud (Internet).
How does it work?
Invoking external services from Bizagi will allow business information from Process instances to be sent as input to that external service.
In return, the external service's response will be automatically updated in Bizagi (back into the Process data model).
The information exchange between Bizagi the service, either set in an ESB, in the cloud or directly as an available system, is done through standard XMLs.
In this way, the integration is independent from the platforms or technologies involved, and the programming language used in the services implementation.
To configure a Web service invocation (either SOAP or RESTful service), Bizagi's Web service connector presents a series of assisted and graphical steps, in which there is no need of programming.
Important
To invoke external services from within Processes in Bizagi, it is recommended to define these integration points as BPMN Service Tasks.
By using Service Tasks to configure integration points, you can specify whether the invocation to external services is done in a synchronous or asynchronous manner.
To view more information about configuring these integration points for asynchronous execution, refer to Asynchronous Activities.
|
When the length of string-type attributes returned by a service exceeds the size of the Bizagi attribute where the data is to be stored, Bizagi will truncate the result in order to fit the length. |
About the Web service connector
Integration points in the Process are defined from the step #6 of the Process Wizard in Bizagi Studio (Define integration interfaces).
In this step, we configure external services invocations through the Web service connector:
Upon selecting on which Service task you want to configure the invocation, Bizagi will present its Web service connector for a guided 4-step configuration.
Take into account that the options presented may vary according to the options selected (i.e, the chosen service type: SOAP or RESTful).
Consider that for RESTful services, it is recommended to use Bizagi Connectors instead.
This is so because Bizagi Connectors supports advanced options such as the possibility to include headers or use OAuth as described next.
Standards supported by the Web service connector
The Web service connector is a powerful generic connector which consumes any Web service, be it set in the corporate ESB, in the cloud, or as an external application.
For SOAP Web services, the following are supported:
•SOAP 1.1 compliant Web services.
•SOAP 1.2 compliant Web services
|
Consider these notes as well: •When invoking SOAP Web services, it is required to use POST as the Web method. •When invoking REST services, XML format must be used in the sent and received information. •WSDL version 1.0. is supported. Its version 2.0 is not supported. |
Additional Web services extensions (WS-*) supported as well:
•WS-Addressing
•WS-Policy
•WS-Trust
•WS-SecureConversation
•WS-Security: Authentication by Username tokens, and by Binary security token (version 1.1 spec).
For authentication through Binary security tokens, message protection (encryption) requires that the service publishes a public key in its WSDL.
|
The WS connector supports WSDLs that publish multiple methods and multiple ports. This latter option is specified through the Advanced interfaces configuration. The WS connector does not support WSDLs that publish multiple services. |
If you need to invoke a SOAP Web service which uses definitions from a standard not listed above (e.g, WS-Discovery), or to consider a requirement not supported by the connector (such as X invocations of a service, say once per each record of a table), then you will need to use either Bizagi Connectors (preferred), or the Component Library feature in Bizagi. See how to choose the right integration feature.
SOAP and RESTful services comparison
Consider the following as a starting point to learn about differences between SOAP and RESTful services.
|
SOAP web services |
RESTful services |
|---|---|---|
Concept & objective |
Bound to its strict protocol definition, it is oriented to exposing pieces of application logic as services (operations). |
Focused on exposing named resources publicly based on URIs (it is protocol independent), optimal for internet applications and mobile access (exposing data). |
Formats |
Tightly based on interchange of information via XML. |
Leverages use of JSON format which is more light-weight --optimal for internet applications and mobile use. Can use other formats such as XML. |
HTTP methods (verbs) |
Mainly use POST. Some web services may feature the use of GET (although not as common). Though, it is not necessarily bound always to HTTP/HTTPS. |
Use POST (to create), GET (to retrieve), PUT (to update), DELETE (to delete). Some services extend the updating capabilities by implementing a PATCH method that sends out only changed information. |
Security |
Usually implement WS-Security and further WS-* specifications of its own. This goes apart from having TLS/SSL on top. |
Usually rely on OAuth to protect resources. TLS/SSL can go on top as well.
|
Advantages & disadvantages |
•Common in enterprise intranets, when there is additional value if having the need of distributing and handling transactions with a higher level of sophistication (e.g. ACID) and with enhanced reliability. •SOAP web services use a descriptor file enabling clients to consume them in a standard way, with relative ease (machines can interpret inputs and outputs for them). |
•Oriented to modern applications and technologies, while said to have better performance and scalability. •RESTful services are much faster to build. But, clients consuming RESTFul services may not be as easy to build, given that RESTful services do not use a descriptor file and their inputs/outputs depend on each service and these services are not unified under a single definition standard. |
Examples
For more information and examples on Web services invocation, refer to:
•Invoking a Web Service from Bizagi.
•Invoking a REST Service from Bizagi.
Last Updated 3/3/2022 9:31:36 AM