Version 1.32.0 − Retrospective pause accounting in indicators, REM support in workflows, and asynchronous processing of configuration packages

In this version, we have enhanced workflow capabilities for automation related to processing extended recording models.

We have accelerated the processing of configuration packages to more accurately track the execution of operations when working with configuration packages.

We have also introduced a new mechanism for retrospective pause calculation when creating indicators, where the countdown time is in the past, and improved the handling of stalled tasks in the scheduler to enhance metric accuracy and reduce process recovery time. Additionally, we have fixed several bugs affecting data migration accuracy, script functionality, and system stability.

New Functionality

Asynchronous Loading of Configuration Packages

An asynchronous mode for processing imported packages has been implemented, and the execution process has been optimized. This functionality ensures stable operation with configuration packages and improves the convenience of importing large packages (over 100,000 VCS records) to an instance.

In the system property platform.vcs.sop_process_quantity, you can specify the number of configuration packages that can be processed simultaneously.

The new Configuration Packages Management widget displays information about configuration packages whose processing has been initiated on the instance. The widget provides details about the initiator and processing status, along with links to package records.

Read more in documentation →

Key Improvements

Retrospective Pause Calculation During Indicator Creation

Now, when calculating the total pause time for an indicator, potential past processing pauses are also taken into account. To enable this, we have added the Consider Retrospective Pause field to the indicator form.

If the Consider Retrospective Pause property is enabled:

  • When the indicator is launched, the system checks the record history and, if it finds record states matching the pause condition, sums their duration and incorporates it into the indicator’s parameters for elapsed working time, overrun time, and pause time.

  • On the indicator form, the Pause Time field displays the value of the retrospective pause at the moment of indicator creation. After creation, it shows the sum of the retrospective and accumulated pauses if the indicator has the Consider Retrospective Pause checkbox enabled and Determined by Duration is selected in the Indicator Overrun Time field.

Read more in documentation →

Full update content with fixes →

3 Likes

How do you consider a retrospective pause through the History table, if history records are written asynchronously and the Created/Modified field in it may be significantly later than when the action actually occurred? Moreover, the records in the history table may not even exist yet. DEF0021004 Large time gap between the creation of a history item and the creation time of the base record

Hello Andrei,

The mechanism with retrospective pause is not mandatory and may not be used if it is not suitable for your installation. Calculations are indeed based solely on sys_history as the only source of historical data for the record; this is important to keep in mind when applying this mechanism.

Regarding the defect “DEF0021004 Large time interval between the created history element and the creation time of the base record,” we are currently evaluating it and will further discuss it with the team lead of the relevant team in the context of the retrospective pause functionality.

Thank you for your observation!

Enter the quote text here

Anton, good day—this question concerns the fact that the new feature in the most critical SLA mechanism in the platform is once again only partially functional.

Please add a note in the official documentation indicating that it may potentially function incorrectly.

The documentation includes a section on Indicators.
Information about the retrospective pause, including details on the optional form field, is provided, stating that calculations are based on the sys_history table.
If you require consultation from subject matter experts on this topic or have questions related to your installation, you can create a request.

2 Likes