Advanced 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 methods of implementing those scenarios and advises which method should be used and which elements from the BPS system are best to use in them.

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. From the point of view of the implementation method, they can be divided into three categories.

  • Standard data sources in BPS
  • Custom Data Source plugin
  • “offline” 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 Custom Data Source plugin.

A very important issue for standard sources as well as for Custom Data Source, is data access time. If it is long, it can greatly slow down or even make it impossible to work in the PBS system. Frequent querying such a source may also slow down the operation of the external system. In order to solve this, a third type of data source is used, the so-called offline source.

In the offline scenario, the external system data may be synchronized to the table in the SQL Server database. After the synchronization, the table can be connected to the BPS system using standard MS SQL data source. There are many ways to implement the synchronization. It can be done by the SSIS package, a dedicated Windows service or a Custom Action ran cyclically by the BPS service. The frequency of the synchronization can be adjusted according to acceptable delay in access to current data.

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. Let’s start with the methods of data transmission from BPS to the external system.

Synchronous

Integration scenario 1
Scenario

An element is created in BPS 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)

Asynchronous (late reply)

Integration scenario 2
Scenario

The document is created in BPS and following the acceptance it is forwarded to the external system. If the external system is unable to reply straight away (call queuing), we use asynchronous integration.

Implementation

  • creation of the awaiting confirmation step and transfer path to it in BPS
  • attaching the action forwarding data on the path
  • following the transfer of data, the elements await data processing information from the external system in the interim step
  • following the receipt of processing information, the element moves to the destination step

Integration is divided into two stages:

  • sending a message to the external system
  • processing the reply from the external system

The first stage is usually implemented using Custom Action, although integration using the predefined action of “Send configurable e-mail” is possible, too.

Following the transfer of data to the external system, BPS moves to the awaiting reply state. Once the external system has processed the data, it forwards the confirmation of operation execution and return data. The easiest method of forwarding the processing information is invoking the BPS Web API by the external system.

In case, where it is not possible to extend the external system by invoking the BPS API web service, it is necessary to read the result on the BPS side. It can be performed using Custom Action which is run cyclically and queries the external system until the confirmation of prompt processing is received. This action can be run as Timeout action or Cyclical action. Once the confirmation is received, the document is moved to the destination step.
Integration scenario 3
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 invoked but requests are put in a queue
  • the external system is extendable (variant 1) or is able to return the information on the state of documents (variant 2)

Asynchronous (try later)

Integration scenario 4
Scenario

The element is created in BPS and following the acceptance it is forwarded to the external system. The external system can reply immediately but integration often finishes with an error (no access to the external system, awaiting a particular state or resources in the external system).

Implementation

  • creating the await step in BPS for the end of integration and the transfer path for it
  • creating the action forwarding the data and running it on the documents awaiting the end of integration
  • if successful, the documents are forwarded to the destination step

Integration of this type is executed using Custom Action ran cyclically until the information concerning successful processing of the prompt is received from the external system. This action can be run as the Timeout action or the Cyclical action.

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 invoked in a synchronous way (immediate reply) but there may be situations when data cannot be forwarded to the external system

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 possibilities for transferring external data to the BPS are presented below.

Synchronous

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.

In more advanced scenarios, it may be necessary to write a dedicated web service using SDK. Such integration is mainly implemented when the external system requires a formalized way of communication (e.g. the necessity to use a web service with specified parameters in case of data tracks). In this scenario the custom web service should be hosted in BPS and it should use SDK for interaction with BPS elements.
Integration scenario 6
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)

Asynchronous (late reply)

Integration scenario 7
Scenario

The external system is non-extendable but is able to generate files or e-mails with information about the documents which are to be sent to BPS.

Implementation

Depending on the method of information transmission, we can distinct two methods of implementation:

  • forwarding of files – supported in BPS through built in mechanism of Hotfolders
  • forwarding e-mail messages – supported in BPS through Hotmailboxes

If the files (messages) are to be supported in a non-standard way, it is necessary to add Custom Action (e.g. data reading from xml files) onto the connection path.

Conditions for the implementation of this scenario

  • the external system transmits data to BPS
  • the external system is not able to trigger the web service (it is non-extendable)
  • is able to generate e-mails or files

Asynchronous (reversed initialization)

Integrationi scenario 8
Scenario

The external system generates documents to be forwarded to BPS but it is unable to communicate with other systems.

Implementation

During the process of integration with such a system, an approach can be made in which the data would be transmitted from the external system to BPS but it would be the BPS initializing the communication.

It can be implemented using SDK Custom Action run as a cyclical action which retrieves the data from the external system and on its basis runs the elements in BPS.

Conditions for the implementation of this scenario

  • the external system forwards the data to BPS
  • the external system is unable to communicate with other systems but is able to share data, for example in a view form

Next topic