WEBCON BPS 2021 Infrastructure guide

  PDF version

 

1. Prerequisites (SharePoint platform)

2. Prerequisites (no SharePoint platform)

3. High availability

4. WEBCON BPS databases

5. Disaster-recovery scenario (SharePoint platform)

6. Disaster-recovery scenario (no SharePoint platform)

7. Good practices in WEBCON BPS platform maintenance

8. WEBCON BPS Farm internat/external communication diagram

9. List of basic components

 

1. Prerequisites (SharePoint platform)

 

1.1.Software

 

• Windows Server 2012 R2, Windows Server 2016, Windows Server 2019
• Microsoft SharePoint Foundation 2013 or Microsoft SharePoint Server 2013/2016/2019
• MS SQL Server 2012 or higher (full text search mode required)
• Active Directory (or Azure Active Directory) environment

 

1.2.Hardware

 

1.2.1.Architecture

There are 3 basic scenarios  for installing WEBCON BPS depending on the scale of your system:

1. Minimal installation – for test, demo and small (up to 10 end users) production environments
2. Recommended installation – for production environments
3. Adding extra servers, redundancy, etc.

 

1.2.2.Minimum requirements – “All-in-one installation”

 

For the simplest and most compact WEBCON BPS configuration, one may use a single machine with the following software:

• Windows Server 2012R2 or newer
• SharePoint Foundation 2013
• SQL Server 2012 Express with Advanced Services (Full Search component is necessary)
• Configured Active Directory service

 

Diagram of „all-in-one” WEBCON BPS installation

Hardware requirements for such installation should correspond with hardware requirements for installation of SharePoint Foundation 2013 on a single server. Requirements are shown in the table below (requirements listed by Microsoft):

 

Installation scenario	Deployment time and scale	RAM*	Processor	Hard Drive
Single server with a built-in database or single server that uses SQL Server	Development or evaluation installation of SharePoint Server 2013/2016/2019 or SharePoint Foundation 2013 with the minimum recommended services for development environments.	16GB	64-bit, 4 cores	80 GB for system drive

 

*It is recommended to use at least 20GB of RAM.

 

1.2.3.Recommended installation – setup for up to 1 000 users

 

Recommended system requirements for WEBCON BPS assume two separate servers for MS SQL and SharePoint. Diagram of sample setup below:

 

Recommended configuration for WEBCON BPS installation – up to 1000 users

 

Suggested parameters for both servers:

  Database server

System	Database	Processor	RAM	Hard drive
Windows 2012 R2 (or never)	SQL 2012 (or newer)Server Standard	64-bit, 4 cores	32 GB (minimum); 1/3 of database size (optimal)	- Storage for system files (RAID1): 140GB - Fast SSD for TEMPDB database: 100GB - Fast SSD  for data files (size depends on number of workflow elements): 200GB

 

  SharePoint Foundation 2013 or SharePoint Server 2013/2016/2019

System	Processor	RAM	Hard drive
Windows 2012 R2	64-bit, 4 cores	16GB (minimum); 20GB (recommended)	Storage for system files 140G Storage for SOLR search indexes: 100GB

 

Notes:

• SharePoint databases will reside on SQL Server
• All WEBCON BPS components will be installed on SharePoint server (except database).
   

1.2.4.Recommended installation – setup for over 10 000 users

 

The system can be scaled-up to support over 10 000 users by allotting additional resources to the following areas:

• Increase the number of SharePoint front-ends to improve the number of web browser client requests that your system can handle. It is recommend to have at least one SharePoint front-end for every 5 000 users.
• Improve SQL server performance and efficiency by adding more RAM, increasing  processing power, and most importantly, improving the performance of your disk array (e.g. by using a larger number of more efficient disks).

WARNING!

Every upgrade should be preceded by comprehensive monitoring and analysis of system parameters, in order to accurately identify and eliminate bottlenecks. This will ensure that your system is scaled-up as efficiently as possible.

Sample configuration of an environment intended for roughly 18 000 users:

 

Database server

System	Database	Processor	RAM	Hard drive (IBM matrix)
Windows 20012 R2	SQL 2012 Server Enterprise	HA cluster, 2 x IBM x3850,   4 x CPU X7560 2,26 GHz	256 GB	- Storage for system files: 140GB - Fast SSD for TEMPDB database: 100GB - Fast HDD x 3 for transaction logs and database files

 

SharePoint Foundation 2013 or SharePoint Server 2013/2016/2019

Application servers (dedicated) (virtual)

• 3 production servers (front-ends available to users)
• 1 test server
• 1 development server

Each virtual server has the following parameters:

System	Processor	RAM	Hard drive
Windows 2012 R2	4 x CPU X5650 3,47 GHz	16GB	Storage for system files (RAID1): 140GB

 

Solr Search Server

System	Processor	RAM	Hard drive
Windows 2012 R2	4 x CPU X5650 3,47 GHz	16GB	Storage for system files (RAID1): 100GB Storage for search indexes (RAID1): 400GB

 

 

VMware vSphere was used as the virtualization platform.

F5 / VIPRION 2400 Load balancer ensures that active users are spread evenly across SharePoint front-ends.

 

Diagram of the proposed 18 000 user setup:

 

Recommended configuration for WEBCON BPS installation – over 10 000 users

 

2. Prerequisites (no SharePoint platform)

 

2.1.Software

• Windows Server 2012 R2 or newer
• MS SQL Server 2012 or higher (full text search mode required)
• Active Directory or Azure Active Directory or BPSAuth service as authentication provider

2.2.Hardware

Architecture

 

 

There are 3 basic scenarios  for installing WEBCON BPS depending on the scale of your system:

1. Minimal installation – for test, demo and small (up to 10 end users) production environments
2. Recommended installation – for production environments
3. Adding extra servers, redundancy, etc.

 

2.2.1.Minimum requirements – “All-in-one installation”

 

For the simplest and most compact WEBCON BPS configuration, one may use a single machine with the following software:

• Windows Server 2012R2 or newer
• SQL Server 2012 Express with Advanced Services (Full Search component is necessary)
• Configured authentication provider supported by WEBCON BPS.

 

Diagram of „all-in-one” WEBCON BPS installation

 

 

Installation scenario	Deployment time and scale	RAM*	Processor	Hard Drive
Single Windows 2012R2 (or newer) server that uses SQL Server	Development or evaluation installation	16GB	64-bit, 4 cores	100 GB for system drive

 

*It is recommended to use at least 20GB of RAM.

2.2.2.Recommended installation – setup for up to 1 000 users

 

Recommended system requirements for WEBCON BPS assume two separate servers for MS SQL and Windows Web Server (IIS). Diagram of sample setup below:

 

Recommended configuration for WEBCON BPS installation – up to 1000 users

 

Suggested parameters for both servers:

  Database server

System	Database	Processor	RAM	Hard drive
Windows 2012 R2 (or newer)	SQL 2012 Server Standard (or newer)	64-bit, 4 cores	32 GB (minimum); 1/3 of database size (optimal)	- Storage for system files (RAID1): 140GB - Fast HDD for TEMPDB database: 100GB - Fast HDD (RAID10) for data files (size depends on number of workflow elements): 200GB

 

  WEBCON BPS Portal Server

System	Processor	RAM	Hard drive
Windows 2012 R2 (or newer)	64-bit, 4 cores	12GB (minimum); 16GB (recommended)	Storage for system files (RAID1) 140G Storage for SOLR Search indexes (200GB)

 

Notes:

• All WEBCON BPS components will be installed on WINDOWS IIS server (except database).

 

2.2.3.Recommended installation – setup for over 10 000 users

 

The system can be scaled-up to support over 10 000 users by allotting additional resources to the following areas:

• Increase the number of Windows Web Server (IIS) front-ends to improve the number of web browser client requests that your system can handle. It is recommend to have at least one IIS front-end for every 5 000 users.
• Improve SQL server performance and efficiency by adding more RAM, increasing  processing power, and most importantly, improving the performance of your disk array (e.g. by using a larger number of more efficient disks).

WARNING!

Every upgrade should be preceded by comprehensive monitoring and analysis of system parameters, in order to accurately identify and eliminate bottlenecks. This will ensure that your system is scaled-up as efficiently as possible.

 

Sample configuration of an environment intended for more then 10 000 users:

 

Database server

System	Database	Processor	RAM	Hard drive (IBM matrix)
Windows 2012 R2	SQL 2012 Server Enterprise	4 x CPU (8 cores each)	256 GB	- Storage for system files (RAID1): 140GB - Fast SSD for TEMPDB database: 100GB - Fast SSD 3 x RAID10 (200GB + 500GB + 800GB)

 

WWEBCON BPS Portal Server (Windows Server)

Application servers (dedicated) (virtual) - 3 production servers (front-ends available to users)

Each virtual server has the following parameters:

System	Processor	RAM	Hard drive
Windows 2012 R2	4 core	16GB	Storage for system files (RAID1): 140GB

 

Solr Search Server

System	Processor	RAM	Hard drive
Windows 2012 R2	4 core	16GB	Storage for system files (RAID1): 100GB Storage for search indexes (RAID1): 400GB

 

 

3. High availability

 

With planning and preparation, WEBCON BPS can operate in high-availability mode.

Here is a breakdown of vital elements which are essential to the availability and reliability of a WEBCON BPS system:

• SQL data bases (solutions like: HA Cluster, Always On Availability Group, Log Shipping) – security policy and available budget are usually the deciding factors when choosing a solution. https://docs.microsoft.com/en-us/sql/database-engine/sql-server-business-continuity-dr?view=sql-server-ver15
• SharePoint front-end or Windows Web Server (IIS) – redundancy is achieved by adding extra front-ends to the SharePoint farm (or build IIS Cluster).
• Load balancer has to support sticky session mechanism.
• WEBCON BPS – duplicating the WEBCON BPS service on multiple machines.
• Search service (SOLR) –  includes the ability to set up a cluster of Solr servers that combines fault tolerance and high availability. Called SolrCloud, these capabilities provide distributed indexing and search capabilities.

https://lucene.apache.org/solr/guide/8_5/solrcloud.html (3 servers minimum)

Depending on the equipment provider and technologies already in place, other solutions can be employed.

 

 

4. WEBCON BPS databases

 

4.1.Overview

There are four types databases of databases employed by WEBCON BPS:

• Configuration database – contains information about the configuration of a given installation, e.g. information about the number and addresses of Frontend servers, information about the search server configuration, information about the installation’s authentication providers, information about languages available on WEBCON BPS Portal etc. One installation will have exactly one configuration database.
• Content database (main database) – collects all information about the configuration of applications created on the platform e.g. process definitions, information about individual form fields and forms configuration, information about privileges for the individual objects on both the data side and the presentation side. This database also contains all metadata about processes (data entered by users in form fields) and a full history of changes. For a given installation you can create multiple content databases – how many are needed depends on the administration, security, and performance requirements of the platform.
• Attachments database – a dedicated database that stores all attachments added to forms (e.g. docx, xlsx, pdf, tiff files). A separate database for storing attachments is created for performance reasons and to better facilitate administration and backup/recovery procedures. One attachments database is created during the standard installation process, but you can create separate databases and assign them to individual processes.
• Archive database – optionally, you can create dedicated archive databases to reduce the strain on content and attachment databases. The system will transfer data from content and attachment databases to the archive database based on defined criteria.

All databases used by WEBCON BPS are created by the installer, which will automatically set up all necessary parameters required by the platform.

 

4.2.Estimation of WEBCON BPS database size

 

With WEBCON BPS, as with other database systems, it is hard to precisely calculate database growth over a certain period of time, as it is dependent on many variables which are hard to define at the start of implementation. This article intendeds to provide a basis for evaluating potential database size growth based on the specifics of the system’s core elements.

During database size evaluation, the user must take the following into consideration:

1. Volume of workflow instances registered daily
2. Complexity of the form (number of form fields, item lists)
3. Number of steps in given workflow (every path transition is recorded in the instance’s history)
4. Number and type of actions used in the system (e-mails, changing field values, launching subworkflows)
5. Average size and number of attachments per workflow instance (document scans, docx, pdf, tiff, xlsx)

As an example, we will use a form made up of 20 form fields (all of them are required):

• 3x Choice field (1x dropdown, 1x autocomplete, 1x SharePoint Picker)
• 3x Date & time
• 3x Floating-point number
• 1x Integer number
• 3x Single line of text
• 3x Multiple lines of text
• 2x Person or group picker
• 1x Yes/No choice
• 1 item list comprised of 5 column and 5 rows:
  • 1x Choice field column
  • 2x Single line of text column
  • 1x Date & time column
  • 1x Floating-point number

 

 

For the form pictured above, the average size of the workflow instance just after registering it, is equal to 38 kB. Every path transition adds a database entry whose size is 19,6 kB.

Average size of an attachment (one page scan with 300 dpi resolution) is 280kB.

Average size of an action execution log is 0,8 kB.

 

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.