System architecture
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.
Architecture
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:
Classic mode based on SharePoint platform and BPS Portal
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.
Standalone mode based on BPS Portal
In standalone mode, there is only the BPS Portal module which fulfills the role of the application server.
Plugin types
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
- WebCon.WorkFlow.SDK.SP
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.
Such division is necessitated by the fact that the interface part of the plugins is different depending on where the form is opened, but the logic part always stays the same. When the form is opened in SharePoint, we are dealing with the Classic Form that uses C# and ASP.NET Web Forms. However, when the form is opened in mobile app or in the BPS Portal, we are dealing with the Modern Form that uses JavaScript along with React library. The fully functional infrastructure for this interface type will be available in 2020 version of WEBCON BPS. When using the modern interface, only the logic part is available for item list and form field customization.
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
- CustomFormFieldSPControl
- FormFieldExtensionSPControl
- ItemListExtensionSP
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
- CustomAction
- CustomBusinessRule
- CustomDataSource
- CustomFormField
- FormFieldExtension
- ItemListExtension
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.