Using an external session state repository

<< Click to Display Table of Contents >>

Navigation:  Automation Server > Automation Server configuration and administration guide > Initial project configuration > Best practices in the production environment > Setting up a load balancer >

Using an external session state repository



When you use a cluster configuration in Bizagi, by default each nodes stores information regarding the user's session.

However, to achieve greater scalability and enhanced reliability, you may choose to delegate storage of such session state information externally into a central repository.

To do so, have Bizagi rely on a session state database or a session state server, as supported by Microsoft's .NET framework.

Generally, using a session state server should be faster, while using a session state database supports best concurrency.


In addition to providing high availability, the use of a cluster is fundamental for your system to be able to scale easily.


Why can this alternative help?

This alternative is useful for scalability purposes, especially to optimize processing in nodes that have implemented processes which are expected to produce a large number of cases or activities performed by the same subset of end users over a short period of time.

By having sessions delegated to a central repository, processing of requests is distributed efficiently by the algorithm in your load balancer, and it is done across the multiple nodes of the Bizagi cluster while avoiding the use of session affinity configuration (having sessions bound to a specific node to process all requests from that user's session, i.e sticky sessions).

In addition to being more scalable by avoiding local management of sessions, this alternative is also more reliable for the IIS, mainly because sessions stored externally (e.g, in a SQL Server database) will survive ASP.NET restarting and recycling, or even SQL Server restarts.



Using an external session state storage relies on technology supported by Microsoft's .NET framework.

This means that it applies to project using IIS and a Microsoft SQL Server database.

To use a session state database, we recommend that you use Standard or Enterprise edition for you SQL Server).

For more information, refer to



What you need to do

In this section we will demostrate how to perform a setup to use a session state database, following these steps:


1. Create the session state database in your SQL Server instance

This is done through a utility provided by the .NET framework.


2. Configure your Bizagi Work portal to use the session state database.

You can do this through the IIS Manager graphical options, or by directly editing the web.config file of the Bizagi Work portal.



To use a session state server, you don't need to create a database (skip step #1), and you need to configure your Bizagi Work portal to use a server instead of a database in step #2.



Follow these steps.


1.  Create the session state database in your SQL Server instance.

1.1. Open a command prompt with admin rights and browse to the path of your installed .NET framework.

Use the utility provided by the .NET framework in its version 4.0 full (since it is the version used by the Bizagi Work portal).

To make sure this, you may use the utility directly from your Bizagi server (having by default, the version 4.0 full for a 64-bit architecture installed at: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\).


1.2. Execute the utility (called aspnet_regsql.exe), adding parameters which will create the tables and schema to store sessions, and by defining a custom database.

Do this by using the following:

aspnet_regsql.exe -S [SQL_INSTANCE] -E -ssadd -sstype c -d [DATABASE_NAME]





[SQL_INSTANCE]: Is the name of your SQL Server instance. Use backslashes for named instances.

[DATABASE_NAME]: Is the name you provide for your custom database.


Note that -E uses the current credentials of the user running the command prompt, which should be valid if the user account has sysadmin rights (given that mixed mode in SQL Server supports Windows authentication). If you do not wish to use the current user's credentials, use the -U and -P parameters (to specify a username and password).

For further options for the aspnet_regsql parameters, refer to:



We recommend the session state database alternative or Enterprise editions of SQL Server.

You can verify the edition of your SQL Server by executing select @@version:




Once the command is executed, you can verify in your SQL Server instance that the custom database has been created and has the ASPStateTempApplications and ASPStateTempSessions tables:





We recommend that you use a custom database (as opposed to relying on tempdb) to have persistent session state information which is not affected by events like a database restart , and to set up the feature as independently as possible (as opposed to using the ASPState database, which is set per instance).


2. Configure your Bizagi Work portal to use the session state database.

You can do this configuration directly editing the web.config file of the Bizagi Work portal, or through the IIS Manager options (which present a UI for such change, though it results in the same changes at the web.config file).

The sample below illustrates the use of a session state database.


Yo can do this through direct modification of the web.config file located by default at C:\Bizagi\Projects\WidgetContest\WebApplication\. Edit the attributes of the <sessionState> element, by adding these values:

mode: SQLServer

allowCustomSqlDatabase: true

timeout: 20 (default value)

cookieless: false

sqlConnectionString: Data Source=[SQL_INSTANCE];Initial Catalog=[DATABASE_NAME];User ID=[LOGIN];Password=[PASSWORD];


For the sqlConnectionString connection , provide:

[SQL_INSTANCE]: The identifier for the database server (or IP address), including its instance.

[DATABASE_NAME]: The name of the custom database, as created through the aspnet_regsql.exe utility in the previous step.

[LOGIN]: The account login for the connection's access.

[PASSWORD]: The password for that login.


For example:

<sessionState allowCustomSqlDatabase="true" cookieless="UseCookies" mode="SQLServer" sqlConnectionString="Server=MyServer\SQL2012;Database=MySessionsDB;User ID=MySQLAccount;Password=MySQLAccount" timeout="20" />




To do this through the UI options of the IIS Manager, locate your Bizagi Work portal specific site, and click the Session State feature:



Select the SQLServer mode, and specify further details.



To use a session state server instead, select State Server mode instead.


You need to select Enable custom database as well:




By default, a 20 minute Time-out is set.


For the Connection String, edit the field directly or use the Create... button to specify a connection (recommended).

When doing so, provide:

Server: The identifier for the database server (or IP address), including its instance.

Database: The name of the database created through the aspnet_regsql.exe utility in the previous step.

Credentials: Use the option to Specify credentials. Use the Set... button to input the account login and its password.




Click OK to save changes.

You may verify the web.config file to check that your changes were applied.



When having customized sections, or modifications at the web.config file, such as the one above, follow one of two alternatives when carrying out a version upgrade:


1. If you do this through the Bizagi Management Console, you need to reconfigure and verify that the use of session states is still applied after the upgrade (we recommend backing up customizations before doing so).

By default, the upgrade done by the Management Console will not verify whether you have done modifications to the original files and file structure.


2. You can do this through a manual procedure (without using the Bizagi Management Console).

If you do, make sure you consider all the relevant components and files that you need to replace manually for the Work Portal and Scheduler, while verifying that you keep your configured customizations (in this case, use of the session state database).