It seems we keep pace, the last release of the Process Dashboard was about three months ago. In this release we focussed on fixing filed bugs, but we also managed to introduce some improvements and a feature.
We resolved 12 issues in this release. There is 1 new feature (plus 2 sub-tasks), 3 improvements and 6 bugfixes. Find more details in the Release Notes.
Especially administrators of Dashboard installations managing a looot of process data might be interested in:
Until now, there was one Retention time for all process data in the AnalyticDB.
The old, single “Retention time” setting was removed in favor of being able to specify the retention time per process. From now on, there is a retention time per process.
Since we want to provide this feature to all of our users, we decided to let administrators manage the retention times in the admin-app:
In the mind of “separation of concerns” a new Analytics area is introduced in the admin-app. For now, the new Analytics area provides only one section, the Processes. The table in this section displays you all available processes, its source system (BPaaS or BRIDGE) and its retention time:
You are able to filter the list using the search field above the table (pro tip: give the filter icon a try).
We assume that it’s more common to set a retention time for a certain set of processes. Thus, you need to select the processes to change by ticking its checkbox. Below the table a panel will appear allowing you to set a retention time for all selected processes.
But wait, where’s the Scheduler Service gone? It was replaced by a new REST API which is called by a scheduler running in the analytics-api-service:
Two of the three improvements in this release care about the service compilation and the build process. The remaining “official” improvement is also especially adressing systems managing a lot of process data.
The majority of tables in the AnalyticDB specify a technical (which means agnostic of business data), numerical primary key. This key was specified as an
INTin SQL Server>
And as we know, integers are finite. A customer reached this limit and we now use
BIGINTin SQL Server
So, instead of a limit near 2^32, the limit is now found at 2^32*2^32. So it would take the mentioned customer 2^32 times the time they used to reach the INT limit. We hope this is enough.
Let’s see, do we have something special here? Yes, besides some minor fixes in the UI we had:
The admin-app provides an export feature. But it didn’t work since it needs an additional Node service (reporting-service) which is now delivered in our package. Hint: You would need to migrate the User Database since the analytics_admin profile needs an additional permission.