BPS Integration scenarios

The chapter below presents the most frequent scenarios which take place during the integration of the BPS system with other systems. It shows the most common and simplest solution of implementing each of the scenarios. More complex solutions like asynchronous communication and advises how to handle them using BPS APIs are described in the topic Advanced integration scenarios.

Dictionary data and reports

During the integration of BPS with external systems, it is very often necessary to present the data shared by that system. This can be dictionary data, for instance contractor dictionary or data reports from that system in the context of BPS documents, e.g. employee vacation from the HR system.

In BPS, access to such external data is ensured by data sources. The standard data sources can be implemented using one of the few predefined types: MSSQL queries, Oracle queries, CAML (Sharepoint source), Active Directory query.

In case of non-standard access methods to the external system (e.g. through the web service), access to data can be implemented using the SDK Custom Data Source plugin. Custom Data Sources work like adapters. They are able to retrieve a data in any custom format and adapt it to the format required by BPS data sources mechanism.

Sending data to the external system

An inherent scenario of integrating two systems, is the need to synchronize the data modified in one of the systems and forward the changes to the other one. Both directions of data flow are possible. When data is directed from BPS to the external system, the best method is using SDK Custom Action.
Integration scenario 1
Scenario

An element is created in PBS and following the acceptance it is forwarded to the external system. The external system returns the identifier of the document created in it.

The basic scenario is the synchronous variant implemented using the action connected to the transition path. Once the element is moving along the path, the action is executed. It forwards the data, receives the result and finishes the transition.

Implementation

  • creation of transition path in BPS
  • attaching the integration action to the transfer path
  • following the successful transfer of data, the action is successful and the document goes to the destination step

The most frequent method of integration is Custom Action which transmits data and gathers the result of its processing. In case of simple scenarios and access to the external system by the MSSQL server, integration is possible using the predefined the “Execute SQL procedure” action type.

Conditions for the implementation of this scenario

  • change in BPS means the data has to be forwarded outside
  • the external system has an API which can be triggered in a synchronous way (immediate reply)

Transmission of data from the external system

A very frequent example of integration is sending the documents generated in other systems to the BPS. The best solution in this scenario is using BPS Web API by external system.
Integration scenario 5
Scenario

The document is created in the external system and is forwarded to the BPS.

Implementation

The main method of integration with the BPS is invoking the Web API in the external system.

Conditions for the implementation of this scenario

  • the external system forwards data to BPS
  • the external system is able to invoke the web service (it is extendable)