WEBCON BPS platform – some digressions on sizing

This article explores the challenges of sizing and scaling the WEBCON BPS platform.

What is WEBCON BPS?

WEBCON BPS is a platform.

WEBCON BPS is not a single, closed application with clearly established functionality, but it is a platform for building applications that meet business expectations of the end-users in a given business.

Taking that into consideration, one may conclude that it is difficult (and even impossible) to make a one-to-one comparison between two WEBCON BPS installations implemented in two independent businesses that operate under different business logic.

How to determine the load on the platform

Example

Let us compare two businesses:

• Business A in which the absence registration and approval system for all employees was implemented  (10 000 people),
• Business B in which the system for cost invoice outsourcing registration and assignment registered by 100 users was implemented.

At first glance, it may be stated that Business A requires significantly more efficient infrastructure comparing to Business B (10000 users versus 100 users).

However, let us look at the two installations in terms of registering items (creating new workflow instances) we may arrive at a quite opposite conclusion.

Business A

In view of the average data collected from numerous businesses in which the workflows of absence registration were implemented, we have estimated that in said application (holidays, sick leaves etc. …) an individual employee registers on average 9 items per year (9 workflow instances are started up). Annually, it gives the aggregation of 90 000 workflow instances for 10 000 employees.

Business B

Let us assume that every employee out of 100-employee group registers daily 20 cost documents of the outsourced clients. Taking that within a calendar year there are 220 working days (minus the absence days of employees), it gives then: 100 * 20 * 220 = 440 000 workflow instances.

90 000 < 440 000

Simple arithmetic reveals that the Business B installation may require more intricate infrastructure than Business A. When employing more complex application activities (number of steps, conditions, approvals) to the invoice assignment process, comparing to the absence registration application, we may come to conclusion that scaling WEBCON BPS based only on number of users is inadequate and does not correspond to reality.

Why does WEBCON publish an infrastructure document where it gives examples of configuration based on the number of users?

There are two main reasons for that:

1. Potential clients know their number of users but not are not always able to determine the  annual plausible number of new workflow instances.
2. WEBCON BPS is the platform of not only one application but it has been assumed that in a relatively short time copious business applications can be created to enhance work in various areas of a business. The variety in number and type of applications proves that the approximation of the platform loading appears to be reasonable when taking into account  the number of users.

A document equipped with the examples of installations due to the number of users was created under the feedback delivered by authentic businesses that have been operating the installations for several years.

Can I scale the WEBCON BPS platform then?

In view of the above, one may think that it is a relatively difficult task when taking into account  the number of variabilities that are to be used during sizing. What is more, some of the variabilities do not become apparent until implementation.

To face the challenge, WEBCON developed a standardized methodology for performance tests that should be considered support when sizing the equipment required for WEBCON BPS platform.

The methodology assumes load testing in the environment. The tests aim at executing two predefined test scenarios by increasing in further iterations the number of unique users. It allows for “translating” newly created workflows instances into a figure that speaks better to businesses, that is, the number of platform users.

Applying two predefined scenarios is triggered by the need of reconstructing the actions that load the FrontEnd servers (WEB) to the greatest extent. These are the actions of generating WORD and PDF type documents (compared with a scenario that does not use such actions).

Test scenario 1 (without the action of generating WORD/PDF documents)

A test collection, i.e., a list of queries sent to the application servers that is generated by registering subsequent actions done by the user in a browser.  The test collection consists of the following steps:

1. Log in to WEBCON BPS Portal
2. Navigate to the main page of WEBCON BPS Portal
3. Go to the page of the test application
4. Create a new instance in the test process. Move it to “Step 1”. Preceded by a 3s interval.
5. Use a transition path that doesn’t trigger any actions. Step doesn’t change. Preceded by a 3s interval.
6. Preview test attachment. PDF format.
7. Use a transition path that doesn’t trigger any actions. Step doesn’t change. Preceded by a 3s interval.
8. Use a transition path that triggers an action that updates an item list. Step doesn’t change. Preceded by a 3s interval.
9. Use a transition path that triggers an action that updates form fields. Step doesn’t change. Preceded by a 3s interval.
10. Use a transition path that doesn’t trigger any actions. Step changes to the second intermediate step: “Step 2”. Preceded by a 3s interval.
11. Use a transition path that doesn’t trigger any actions. Step changes to the positive end step: “Finish”. Preceded by a 3s interval.
12. View the My tasks report
13. View a report showing all instances in a process – according to the test user’s privileges.
14. View a Search engine report.

Test scenario 2 ( with actions generating WORD/PDF documents)

1. Log in to WEBCON BPS Portal
2. Navigate to the main page of WEBCON BPS Portal
3. Go to the page of the test application
4. Create a new instance in the test process. Move it to “Step 1”. Preceded by a 3s interval.
5. Use a transition path that that has an action generating a DOCX file. Step doesn’t change. Preceded by a 3s interval.
6. Preview test attachment. PDF format.
7. Use a transition path that has an action converting a file to PDF. Step doesn’t change. Preceded by a 3s interval.
8. Use a transition path that triggers an action that updates an item list. Step doesn’t change. Preceded by a 3s interval.
9. Use a transition path that triggers an action that updates form fields. Step doesn’t change. Preceded by a 3s interval.
10. Use a transition path that doesn’t trigger any actions. Step changes to the second intermediate step: “Step 2”. Preceded by a 3s interval.
11. Use a transition path that doesn’t trigger any actions. Step changes to the positive end step: “Finish”. Preceded by a 3s interval.
12. View the My tasks report
13. View a report showing all instances in a process – according to the test user’s privileges.
14. View a Search engine report.

Test procedure

For delivering tests we use the pool of individual user’s accounts.

Each and every user holds the following privileges:

• access to the test application
• possibility of starting up new instances in the test process

Each and every user goes through the full test scenario described above.

Test scenarios 1 and 2 are carried out independently (first, the full test scenario 1 for the assigned number of users is carried out, later scenario 2 for the same pool of users is conducted).

To better simulate the simultaneous work of many users, each user will begin the test by waiting a random period of time (from 0 to 10s). Some of the requests during the test are also preceded by a fixed waiting period of 3 seconds.

As a parallel activity of XXX users we envisage a start of the test path by all users within the 10 second interval. That is, when we estimate a test for 400 users, within 10 seconds from commencing the tests 400 new independent instances of test scenarios will start up.

As a minimum number of users for whom a test result was considered successful is the number of erroneous queries lower than 0.03% of the total number of queries.

The maximum time for completing the scenario by a single user has been established at 3.5 minutes.

Configuration equipment tested

Configuration 1

(WEB single server + dedicated SQL server + dedicated search server)

Configuration 2

(WEB single server + dedicated SQL server + dedicated search server)

Configuration 3

(WEB (loadbalancing/HA) two parallel servers + dedicated SQL server + dedicated search server + loadbalancer nginx PLUS)