System architecture from the perspective of SDK plugins
This article explains the WEBCON BPS system architecture from the viewpoint of custom SDK plugins.
It shows how the system is divided into different modules, along with description how they communicate with each other, which technologies are used, and which types of SDK plugins are executed in each module.
This knowledge can be helpful in the design phase of your custom plugins as well as in dividing them into the parts which will be run in different modules.
System architecture can assume two different modes, based on installation type:
- Classic based on SharePoint platform and BPS Portal
- Standalone based on BPS Portal
The communication between different modules of the system has been presented on the diagrams below:
In classic mode both BPS SharePoint Solution and BPS Portal modules act as application servers responsible for displaying web pages and communicating with the web services.
In standalone mode, there is only the BPS Portal module which fulfills the role of the application server.
We distinguish two types of plugins – one associated with logic operations e.g. actions and another one associated with end user interface part e.g. controls. We have divided this types of plugins into two libraries:
WebCon.WorkFlow.SDK library contains base classes responsible for logic operations. You will have to derive from these base classes when you write plugins that consist of only the logic part (e.g. actions) and when you write the logic part of plugins associated with end user interface (e.g. the logic part of controls such as validation). The plugins which only consist of the logic part are always run in the WEBCON BPS business logic. This business logic is implemented with C#.
WebCon.WorkFlow.SDK.SP library contains base classes from which you will have to derive when you create the end user interface part for your plugins associated with user interface available in SharePoint (that is what SP suffix in library name means). When it comes to plugins associated with the user interface, they can consist of both the logic and interface parts.
It is worth noting that in the case of operations that happen in background, or cyclically without user interaction, the plugins run only the logic part (without the interface).
Plugins can be run in three different environments: SharePoint, BPS Portal, and BPS Service. Depending on your business scenario, you can write one logic SDK plugin and then run it across all of the environments mentioned above.
Plugin base classes
The base classes for the interface part of plugins can be found in WebCon.WorkFlow.SDK.SP library.
It consists of
When creating those types of plugins, you can make use of our templates available in Visual Studio Marketplace i.e. BPS 2019 Custom Control, BPS 2019 Form Field Extension and BPS 2019 Items List Extension.
In order to use them, you have to choose the Classic option during the installation of WEBCON BPS and then use classic interface for your processes in WEBCON BPS Designer Studio.
The base classes for the logic part of plugins can be found in WebCon.WorkFlow.SDK library.
It consists of
When creating them you can also make use of our templates i.e. BPS 2019 Custom Action, BPS 2019 Custom Business Rule, BPS 2019 Custom Data Source, BPS 2019 Custom Control Logic, BPS 2019 Form Field Extension Logic and BPS 2019 Items List Extension Logic.
The logic parts of plugins (that inherit from above base classes) are run independently from the environment. The custom control is the only exception to this, because its logic part depends on the interface part and is only available in processes using the Classic interface display mode.