REST Web Service

The feature enables execution of any Web Service method created in the REST architecture and to use returned values as a data source within the WEBCON BPS platform. In the data source configuration, you need to specify, i.a. the URL address to the Web Service resource, additional, optional new headers, and – for the HTTP methods such as POST/PUT/PATCH, the optional request body in JSON format.

Following the initial configuration, the Response tab contains the option to download the response structure (the Load button) and indicate data collection which is to be used by the data source.

Parameters for invoking a Web Service are based on using tags in the body of the JSON function or in the parameters written in the URL (GET/DELETE methods). The REST Web Service data source also supports searching in the Choice field (Popup search window).

By supporting most Web Services and providing two different modes of filtering, it is possible to handle the majority of integration scenarios between BPS and external systems using only the configuration options available in WEBCON BPS Designer Studio – without the need for implementing SDK data sources.

1. ID

The data source identifier (if the value is smaller than "0", the source has not been saved in the database yet).

2. Name

Name of the data source entered by the user.

3. Superior source

Each data source can contain subordinate sources which are related to a company within the system. If a superior source is referenced from a workflow instance which belongs to a specific company, and that company has a subordinate source associated with it, the query will reference this subordinate source instead. If a superior source has been defined for the source, you need to enter the name of the company for which it is defined.

4. Business entity

A business entity to which the defined source belongs. If the source has a defined business entity, entering the superior source is required.

5. Data source type

The type of the current data source. The field specifies the location from which data is retrieved.

6. Connection

The field is intended for defining authorization to access the database.

7. Description

Description of the data source defined by the user.

8. Data source contains personal data

The option designates the current Data source as a source of personal data for other processes. A relation between the Personal data dictionary and a process which uses such a dictionary as a source of data, requires additional configuration in every form field which is marked as containing personal data. Once configured, such a relationship allows the system to trace from which instance of a Personal data dictionary the form field obtained its value. Thanks to this, actions that delete or modify (anonymize) personal data are able to locate all the places that obtained data from a specific Personal data dictionary instance.

When a Data source is designated as a Personal data dictionary, it is required to specify a column in the data source which is to be used as the personal unique identifier. It is recommended that this column contains unique, numerical database identifiers.

9. Personal data identifier column

The field allows you to specify a unique identifier in the form of a database column.

10. Testing environment

The field allows you to select an environment in context of which data source test is executed.

11. Request data

The tab allows you to enter a resource URL address, select HTTP protocol method, and configure custom headers.

• Suffix URL – suffix added to the base service instance URL. Defining the suffix allows you to dynamically modify the request URL address, e.g., by adding additional paths or parameters,
• HTTP Method – the parameter defines the type of operation to be executed on the specified endpoint,
• Based on Swagger – the field enables you to automatically import the API structure based on the Swagger file,
• Parameters – when selecting a request based on the Swagger documentation, it is possible to assign URL parameters. Parameters are automatically loaded based on the documentation structure (it is also possible to add them manually). Parameter types are divided based to their location: Path: /users/{id}, Query: /users?role=admin. Parameters without a value will be skipped when sending the request,
• Custom headers – the field allows you to add custom HTTP headers to requests. These headers can contain additional information about the request which is required by the API server. Using the headers, it is possible, e.g. to handle custom API requirements, define data format, or authorize,
• Filter mode – the field defines the data filtering mode. Selecting the Using BPS option results in retrieving all data from the data source and then applying the filter, whereas choosing the Using web service option involves sending filter value to the web service and retrieving only the filtered data.