Using Live Instance Migration (LIM) when escalation was removed from process

  • 16 February 2021
  • 0 replies
  • 26 views

Userlevel 5
Badge +20
 

Using Live Instance Migration (LIM) when escalation was removed from process

kbt154591

PRODUCT
K2 blackpearl
BASED ON
K2 blackpearl 4.7
TAGS
Escalations
This article was created in response to a support issue logged with K2. The content may include typographical errors and may be revised at any time without notice. This article is not considered official documentation for K2 software and is provided "as is" with no warranties.
LEGACY/ARCHIVED CONTENT
This article has been archived, and/or refers to legacy products, components or features. The content in this article is offered "as is" and will no longer be updated. Archived content is provided for reference purposes only. This content does not infer that the product, component or feature is supported, or that the product, component or feature will continue to function as described herein.

Issue

After removing the Process Level Escalation and Activity (referred to by this escalation) from the process definition and migrating running process instances to new a definition using LIM; the API escalation still keeps firing causing the process to be stuck in a running state.

Symptoms

When running a process migrated to a new definition where the Process Level Escalation and activity referred by the escalation was removed, the escalation keeps firing causing the process to be stuck in a "Running" state.

Resolution

Removing escalations from process definitions are not supported by LIM API as documented in K2 BLACKPEARL DEVELOPERS REFERENCE - Important Notes about Live Instance Migration (LIM).

Documentation lists process definition changes which are NOT supported when migrating between process versions. In particular, removal of the following from the process definition is not supported:

  • Activities
  • Lines
  • Events
  • Data fields
  • Xml fields
  • Escalations
  • Actions

 

 

 

In case you migrated instances with removed escalations, you can remove scheduled escalations from K2 database as a workaround. 

This workaround involves direct modifications of K2 database. Do not modify any database definition or database content unless specifically instructed to do so by K2. No changes to the K2 Database definition or content are supported unless specifically instructed by K2.  Please see: http://help.k2.com/onlinehelp/k2blackpearl/devref/current/default.htm#Database_Reference.html 


As a workaround to prevent scheduled escalations from firing off, please contact K2 Support to do the following:

Backup the K2 database and execute SQL script shown below. Note that in the script there is 2 variables that need to be set - @VersionWhereEscalationWasDeleted and @ProcessWhichWillExpire.

"DECLARE @VersionWhereEscalationWasDeleted INT;

DECLARE @ProcessWhichWillExpire NVARCHAR(MAX);

 

SET @VersionWhereEscalationWasDeleted = 7; -- (SAMPLE VALUE)

SET @ProcessWhichWillExpire = N'ProjectNameProcessName'; -- (SAMPLE VALUE)

 

DELETE [AS] FROM [Server].[Async] AS [AS]

       WHERE [AS].[Type] = 5

         AND [AS].[ProcInstID] IN (

              SELECT [PI].[ID] FROM [Server].[ProcInst] AS [PI]

                     INNER JOIN [Server].[Proc] AS [EP] ON [PI].[ExecutingProcID] = [EP].[ID] -- Executing

                     INNER JOIN [Server].[Proc] AS [OP] ON [PI].[ProcID] = [OP].[ID] -- Original

                     INNER JOIN [Server].[ProcSet] AS [EPS] ON [EP].[ProcSetID] = [EPS].[ID]

                     INNER JOIN [Server].[ProcSet] AS [OPS] ON [OP].[ProcSetID] = [OPS].[ID]

                     WHERE [OPS].[FullName] = @ProcessWhichWillExpire

                       AND [OP].[Ver] < @VersionWhereEscalationWasDeleted

                       AND [EP].[Ver] >= @VersionWhereEscalationWasDeleted         );"

 

 

 

 

 


0 replies

Be the first to reply!

Reply