Archiving instances

0

Hi,
In the WEBCON instances I manage, I don’t archive workflow instances. I handle this in a slightly different way.
In the report, I create a separate view for items that are still in progress and another view for completed ones (finished). In general, users (should) focus mainly on the items that are still in progress.

Additionally, I would check whether you have pagination enabled in the report, for example, 25 items per page.
Do you use any calculated columns in your reports? They may also slow down report loading.

Last but not least, I would recommend checking the SQL Server configuration and overall condition. There is a great article here about SQL maintenance best practices:
https://community.webcon.com/posts/post/sql-maintenance-dedicated-maintenance-mechanism-for-large-bps-databases-indexes-and-statistics/331/26

Hi Maria,

Archiving works in three different retention levels (three "modes"). One of them is moving instances to archive database, which removes them completely from content database, thinning out tables related to instances, securities, history, tasks, action logs.
Instances in archive database are still available in WEBCON Portal, but they are read-only and this operation is irreversible. Once you archive an instance, no further operations can be made on it (other than deleting completely).
These instances can be accessed via standard report, but you have to choose whether you display active or archived instances - unfortunately can't do both with standard functionalities.

In bigger environments we recommend archiving outside of business hours, because deleting could lock the SQL tables and slow down user operations.

One *custom* solution to display both active and archived instances in one view is to use User Defined API working as a data source.
Then on an application dashboard (can't use standard report) you could add an HTML widget, fetch data from custom API endpoint with JS and display that data in a custom HTML table/report.
Personally I'd try to create two separate API endpoints, both returning data from BPS internal view data sources - one with archived instances, second with active instances. JS would fetch data from both endpoints. That way you can use native cookie-based privileges checking (which is not available in MSSQL type of data sources).

Regarding overall performance issues, archiving is just the first step. Other than that:
a) it is crucial to implement a maintenance plan as described in https://community.webcon.com/posts/post/sql-maintenance-dedicated-maintenance-mechanism-for-large-bps-databases-indexes-and-statistics/331/26
b) other settings described in "Effect of other settings on SQL engine performance" of above article are also important
c) keep database compatibility levels at the highest available in your SQL Server version (and remember to install Cumulative Updates)
d) for slow opening instances, if you have choice fields with big data sources, put them in autocomplete/pop-up search modes (NOT choice list or choice trees)

Kind regards