Example:

• We have 1 defined workflow.
• The workflow has 10 steps
• System is used by 100 users on every workday
• Every user registers 10 workflow instances a day
• Every user moves 20 instances by one transition path per a day
• Every workflow instance registration and every path transition triggers a “send e-mail notification” action.
• System is used for 12 months * 21 workdays = 252 workdays
• Every month, 2500 one-paged scans are added to various instances

Space used by instance registration:

252 (days) * 100 (users) * 10 (instances) * 38 kB (average form size) = 9.58 Gb

Space used by path transitions:

252 (days) * 100 (users) * 20 (transitions) * 19.6 kB = 9.88 Gb

Space used by attachments:

12 (months) * 2500 (pages) * 280 kB (page size) = 8.4 Gb

Space used by action logs:

252 (days) * 100 (users) * 30 (steps/notifications) * 0.8 kB = 604.8 MB

In total, for this specific example, the annual database growth is equal to: 28.46 GB

Warning!

This value is applicable to this specific example and form type only. It is important to remember that with more intricate forms, more actions and more steps, calculations will also get more complex. The real database growth should be verified periodically, for example after a month of system usage

For this example, one paged attachments with a baseline size were used. Calculations should reflect the expected format and size of attachments (multi-page documents in DOCX or building projects in DWG format), as attachments are likely to be the workflow component that requires the largest allocation of disk space.

5. Disaster-recovery scenario (SharePoint platform)

The WEBCON BPS system engine operates based on multiple databases and the SharePoint platform. Therefore, the Disaster Recovery of our system should focus on creating and maintaining backup copies of the aforementioned components.

The WEBCON BPS system will always be made up of at least three databases – One Configuration database, one Process (aka. Content) database and one Attachment database. Optionally, more Process and Attachment databases can be created and connected to the Configuration database if necessary. Either way, all of these BPS system databases should always be backed up because they are essential to the system and store some of the most important data, such as:

• Registered workflow instances
• Workflow attachments
• Process definitions
• Database definitions
• Set substitutions
• Workflow service configuration
• System configuration (e.g. HotFolders, HotMailBoxes, OCR AI Projects)
• All permission settings regarding WEBCON BPS (access to instances, workflows, processes etc.)
• License information
• Translations
• WEBCON BPS Portal presentation (applications, raports, dasboards etc…)

In addition the BPS system databases, it is also crucial to create a backup for SharePoint. The database of the SharePoint platform contains data that is integral to WEBCON BPS, for example:

• The entire user interface
• SharePoint lists, which can be used as data sources in WEBCON BPS
• Web Parts
• SharePoint privileges (to sites, libraries, documents, SharePoint lists etc.)
• Farm configuration

In the event of a failure, which results in the inability to restore the SharePoint environment, the user will need to take the following steps in order to restore full functionality to WEBCON BPS:

• Recreate all SharePoint lists that are used as data sources in WEBCON BPS
• Recreate all components of the user interface (tiles and buttons for starting workflows)
• Recreate sites and Web Parts
• Configure the ‘WEBCON BPS Configuration’ feature on the SharePoint site, and connect it with WEBCON BPS Designer Studio.

As mentioned above, due to the critical importance of the WEBCON BPS system databases, there should be backup procedures in place for:

• The Configuration database
• All Process databases (also referred to as Content databases)
• All Attachment databases

Various strategies for Disaster Recovery in SharePoint have been detailed by Microsoft on their knowledge base:

https://technet.microsoft.com/en-us/library/cc263031.aspx

There is also a series of publications that cover various methods and approaches to making SharePoint backups specifically:

https://technet.microsoft.com/en-us/library/ee428315.aspx

It is also important to backup (snapshot) machines. In the event of a major failure, we can quickly restore the SharePoint server without needing to: install it again, implement various SharePoint solutions (WSP files), add a master page, or any other mandatory steps before restoring the pre-failure state. A backup should be created regardless of whether SharePoint is installed on a virtual machine or physical server.

Example 1: Crash of SQL server with both WEBCON BPS and SharePoint databases

Recovery order:

1. Restore SharePoint data from backup
2. Restore WEBCON BPS databases
3. Assign privileges to service accounts that interact with SharePoint and WEBCON BPS system databases.

Example 2: Crash of SQL server with both WEBCON BPS and SharePoint databases + SharePoint server crash.

Recovery order:

1. Restore the SharePoint server from snapshot
   • If the machine with SharePoint didn’t have a backup, it will be necessary to install SharePoint and again, using the exact same version that was on the server before the crash. It will also be necessary to install WEBCON BPS, also using the same version that was installed before the crash.
2. Restore SharePoint data from backup
3. Restore WEBCON BPS databases
4. Assign privileges to service accounts that interact with SharePoint and WEBCON BPS system databases.
5. If the SharePoint server’s SID was changed, it will be necessary to generate* and download a license for the specific environment.

6. Disaster-recovery scenario (no SharePoint platform)

The WEBCON BPS system engine operates based on multiple databases. Therefore, the Disaster Recovery of our system should focus on creating and maintaining backup copies of the aforementioned components.

 The WEBCON BPS system will always be made up of at least three databases – One Configuration database, one Process (aka. Content) database and one Attachment database. Optionally, more Process and Attachment databases can be created and connected to the Configuration database if necessary. Either way, all of these BPS system databases should always be backed up because they are essential to the system and store all of the WEBCON BPS data, such as:

• Registered workflow instances
• Workflow attachments
• Process definitions
• Database definitions
• Set substitutions
• Workflow service configuration
• System configuration (e.g. HotFolders, HotMailBoxes, OCR AI Projects)
• All permission settings regarding WEBCON BPS (access to instances, workflows, processes etc.)
• License information
• Translations
• WEBCON BPS Portal presentation (applications, raports, dasboards etc…)

As mentioned above, due to the critical importance of the WEBCON BPS system databases, there should be backup procedures in place for:

• The Configuration database
• All Process databases (also referred to as Content databases)
• All Attachment databases
• All Archive databases (if exists)

https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-and-restore-of-sql-server-databases?view=sql-server-ver15

It is also important (but not required) to backup (snapshot) machines. In the event of a major failure, we can quickly restore the machine snapshot and then restore WEBCON BPS databases from the latest backup.

7. Good practices in WEBCON BPS platform maintenance.

7.1.Database maintenance.

Basic administrative activities related to WEBCON BPS databases. They have a key impact on system performance and security:

• Backup and tests of Restore procedures.
• Index maintenance (reorganize and rebuild).
• Statistics updating.

Indexes and statistics maintenance is crucial for system performance. Based on this data, the SQL Server engine generates query execution plans which results directly in query execution time.   Daily execution of the above operations in the service window is recommended.

7.2.Resources monitoring.

Similarly to other IT systems, it is advised to monitor basic parameters related to the use of resources by machines included in the WEBCON BPS environment. The basic ones are CPU load, available operating memory, available disc storage.

7.3.Service monitoring.

The basic services that are necessary for the application to operate are:

• SQL Server service of the instance storing BPS data bases.
• IIS server service
• WEBCON Workflow Service
• WEBCON BPS Search Service
• Portal Application – WebCon BPSCloud Portal

8. WEBCON BPS Farm internal/external communication diagram

9. List of basic components

Below is a list and short description of components featured in architecture diagrams.

9.1.WEBCON BPS Portal components

The components that are included in WEBCON BPS Portal are responsible for the implementation of two layers of logic in the application – the presentation layer and the business logic layer. The elements of the presentation share an authentication mechanism which works based on configured authentication providers, access to resources in this layer is granted based on the current returned by the authentication provider.

Business logic elements function in Full Trust mode, where the context of the current user is received from components in higher layers, and privileges are verified against configuration in WEBCON BPS databases.

BPS Portal Site – main interface of WEBCON BPS Portal, contains all interface elements that allow the user to access BPS features (reports, dashboards, navigation etc.). Also contains the dynamic form (Modern form) through which users edit workflow instances in the system. Created via React JS technology as a Single Page Application. This component communicates with the rest of the application via dedicated REST web services.

BPS Portal embedded views – responsible for displaying individual user interface elements on WEBCON BPS Portal in embed mode (e.g. report, dashboard, a form of a selected instance). Allows such interface elements to be embedded in a separate IFrame on any web page. 

BPS Portal files handler – component responsible for giving users access to downloadable workflow attachments (files). Works as a http handler. This component communicates with the business logic of the application.

BPS Portal data REST services – a set of REST Web services hosted within WEBCON BPS Portal, responsible for handling data intended for websites of the BPS Portal Site component. This component communicates with the business logic of the application, and receives user context from a configured authentication provider.

Designer Studio REST service – a set of REST Web services hosted within WEBCON BPS Portal, responsible for handling incoming communication from the BPS Designer Studio App module. This includes licensing mechanisms, reports from various modules, reading and writing configuration. This component communicates with the business logic of the WEBCON BPS system.

BPS Web API (REST) – a set of REST Web services hosted within WEBCON BPS Portal, responsible for handling requests from external applications. Integral to the functions of the public Web API such as loading and modifying the content of instances, starting new instances, moving workflow instances, loading report data, reading process metadata, and more. Communication with this component is only possible for registered external applications. Authentication is handled via JWT tokens. This component communicates with the business logic of the WEBCON BPS system.

BPS REST Mobile App service – a set of REST Web services (JSON messages) hosted on WEBCON BPS Portal, responsible for handling data intended for the WEBCON BPS Mobile App. This component communicates with the business logic of the application.

BPS REST Office Apps service – a set of REST Web services (JSON messages) hosted on WEBCON BPS Portal, responsible for handling data intended for the Microsoft Outlook and Word Add-Ins. This component communicates with the business logic of the application.

Communication between components of the WEBCON BPS Portal module is carried it within one system process.

9.2.WEBCON BPS SharePoint Solution components

The components that are included in WEBCON BPS SharePoint Solution are responsible for the implementation of two layers of logic in the application – the presentation layer and the business logic layer.

The presentation layer uses authentication configured in the SharePoint Farm, access to resources in this layer is granted based on the privileges of the current SharePoint user.
Business logic elements function in Full Trust mode, where the context of the current user is received from components in higher layers, and privileges are verified against configuration in WEBCON BPS databases.

BPS GUI Web Parts – user interface elements that grant access to WEBCON BPS system features. Contains interface elements that are presented to the end user in the form of SharePoint Web parts. This component communicates with the business logic of the application.

BPS GUI aspx Pages – user interface elements that are presented to the end user in the form of SharePoint sites (aspx pages). Responsible for (among other things) the dynamic form (and classic form) used to edit process instances in the system. This component communicates with the business logic of the application.

BPS GUI Files http handler – component responsible for giving users access to downloadable workflow attachments (files). Works as a http handler. This component communicates with the business logic of the application.

Designers & Service Web service – a set of SOAP Web services hosted on SharePoint, responsible for handling communication from BPS Designer Studio App. This includes operations such as verifying the correct loading of SDK plugins. This component communicates with the business logic of the application.

BPS Web API (SOAP) – a set of SOAP Web services hosted on SharePoint, responsible for handling requests from external applications. Integral to the functions of the public Web API such as loading and modifying the content of instances, starting new instances, moving workflow instances. This component communicates with the business logic of the application.

9.3.Shared components – business logic libraries

BPS WorkFlow Engine – an engine for processing instances within the system. Responsible for starting and processing instances according to workflow configuration. This component is used by the business logic of the system.

BPS Business Logic & Internal Communication Engine – the main component of the business logic layer. Responsible for handling all logic operations of the workflow and user forms. Preparers and processes data or assigns it to other components of the business logic (BPS  WorkFlow Engine, BPS SDK Engine). Also responsible for saving and reading data from the database.

BPS SDK Engine – component responsible for loading registered SDK plugins into processes, applying their configuration, and also invoking individual interfaces used for communicating with these plugins.

Communication between components inside the WEBCON BPS SharePoint Solution module takes place within one system process.

9.4.WEBCON BPS Background Service

Individual components within this module are managed by a common mechanism, which is responsible for cyclically verifying the schedules/configuration and activating other components accordingly.
Each of these components communicates with the WEBCON BPS database in order to download data for processing and to save the result.

BPS User caching – responsible for synchronizing BPS users from the Active Directory and SharePoint, as well as building a cache of this list in the WEBCON BPS database. This component communicates with the Active Directory specified in the configuration, and uses Microsoft system directories available for .NET Framework (System.DirectoryServices). It will also communicate with a SOAP Web service from the Designers & Service Web service component in order to obtain information about SharePoint users.

OCR AI Engine – used to process files with a text layer (.pdf) and find information on them according to the OCR AI project configured in the system.

Timeout and cyclical tasks runner – activates actions defined in processes to trigger cyclically or on timeout. Communicates with a SOAP Web service from the Designers & Service Web service component in order to pass information about operations to be carried out by business logic.

Push notification service – sends push notifications for the WEBCON BPS Mobile App on iOS. When an instance is changed for which a notification should be sent, this component communicates with the Apple Web service and sends it.

Archiving Module – component responsible for archiving workflow instances. Depending on the configuration, it can save archived instances in a shared network location or in a dedicated BPS archive database.

Email sender – component responsible for handling the e-mail sending queue. Messages are sent via the SMTP server configured in the system settings.

Batch file processing (folders, emails) – responsible for processing so-called Hot folders and Hot mailboxes. Hot folders are shared network locations where newly arrived files are processed by the component. Similarly, Hot mailboxes are Exchange inboxes where newly arrived e-mails and their attachments are processed by the component. Depending on the configuration, it either reads from the appropriate network share or connects to the specified Exchange server. It may can also attempt to connect to a SOAP Web service from the Designers & Service Web service component in order to – for example – launch a new workflow instance and add the newly processed file as an attachment.

Barcode printing proxy – component responsible for sending printout requests to the configured barcode printers. Depending on the configuration, it can connect to a specified printer and (local TCP/IP connection) and send it printout requests.

9.5.Additional components

Optional components that are not required during WEBCON BPS installation include: WEBCON BPS Mobile App, WEBCON BPS Outlook Add-In, and Word Add-In.