Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Summary

Previously, when a new workflow definition was implemented in production, any in-progress instances submitted beforehand were automatically updated to adhere to the new workflow design. However, this transition could lead to complications, especially with incomplete or missed tasks, due to discrepancies between the workflow definitions, potentially resulting in broken instances.

To address this issue, we implemented a new process to isolate in-flight workflow instances from the latest FAB workflow changes introduced in production. Existing instances in production will maintain their original workflow definition at the time of submission, ensuring continuity. Similarly, new instances will seamlessly adopt the most recent available workflow definition, maintaining consistency across the project lifecycle.

Auto-Versioning (FAB v3.3)

Changing the workflow definition automatically increments the WF version.

To deactivate this feature, follow these steps: https://iqxbusiness.atlassian.net/l/cp/QuU2TqTU

Revised Versioning (FAB v3.3.1)

With the introduction of Non-Breakable Workflow design in FAB version 3.3, any modifications made to workflows in development now automatically trigger versioning. This results in the creation of a new workflow version each time changes to the WF definition are saved. While this ensures version control, it presents challenges during the development and testing phases where numerous modifications and test instances are expected.

Moreover, tracking and monitoring the specific workflow version used at the time a form instance was created has become difficult.

To address these issues, we have enhanced the revision process for workflow versions. We have introduced a new API to collect the deep structure of revision fields and to facilitate workflow version control for in-flight form instances.

Below is the relational deep structure from the Project App level to the Workflow Version level.

image-20240229-081524.png

Description

Table Field

Project Form App

In every Project Form App, there may exist multiple Form Iterations.

ZFORM_NAME

Form Iteration

Each Form Iteration can accommodate multiple Workflow IDs intended for future Alternate Workflows. Form Iteration value increments whenever user saves the form app via 'SAVE (new iteration)' button or form is transported through systems.

ZITERATION_NO

Workflow ID

Since the Alternate Workflow functionality has not been released yet, Workflow IDs as of FAB released v3.3.1 will consistently remain set to '1'.

ID

Workflow Version

Within each Workflow ID, numerous Workflow Versions can be found, each possessing a unique HASH character identifier.

All workflow versions available for each Form App can now be easily viewed via the new workflow designer. See Version List

VERSION_ID

Related Tables

  • /IQX/FAB_WF - FAB Enhanced Workflow Definition

    • Adds new line for every new Project App-Form Iteration-WF ID-WF Version combination

    • Features:

      • WF instance

      • Multiple workflows per Project

      • Default workflow

      • Traceability - fields MODIFIED_*

    • Repurposed Fields:

      • ZITERATION_NO: incrementing, to be used as WF Version

      • ID: to be used as WF ID

      • ZID: to be used as WF Description

    • New Fields:

Field

Key

Type

Description

ZDEFAULT

BOOLEAN

Indication for default Workflow ID

MD5_CHECKSUM

HASH160

MD5 generation from ZDEFINITION, to be used as key in

MODIFIED_BY

CHAR 12

Modified By

MODIFIED_DATE

DATS 8

FAB Changed on date

MODIFIED_TIME

TIMS 6

FAB Changed at time

  • /IQX/FORMHD_INST - FAB Form Header Instance Data (run-time values)

    • New Fields:

Field

Key

Type

Description

WF_INSTANCE

FK

HASH160

WF Instance

IS_TERMINATED

 

BOOLEAN

Is FAB Instance EOL

  • /IQX/FAB_WF_INST - FAB - Enhanced Workflow Instance (New Table)

    • To store the definition snapshot of WF Definition when a FAB instance is submitted.

    • Fields:

Field

KEY

Type

Description

ZWF_INSTANCE

PK

HASH160

WF Instance (MD5)

ZFORM_NAME

FK

CHAR 24

FAB Project ID

ID

FK

NUMC 6

Workflow ID

ZITERATION_NO

FK

NUMC 6

Workflow Version

ZDEFINITION

 

STRING

WF Definition in JSON

Other related objects

For list of technical objects affected by this change, see https://iqxbusiness.atlassian.net/wiki/spaces/IPM/pages/2159542343/Design+of+non-breakable+WF+for+in-flight+FAB+instances?atlOrigin=eyJpIjoiM2Q4NDk3OTY0NDNlNDcxY2FhOWFlZGY0ZjQ3YTMzNTEiLCJwIjoiYyJ9 .

  • No labels