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.
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#.
Plugins can be run in two different environments: 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 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 2022 Custom Action, BPS 2022 Custom Business Rule, BPS 2022 Custom Data Source, BPS 2022 Custom Control Logic, BPS 2022 Form Field Extension Logic and BPS 2022 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.