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 10 Next »

Summary

Prior to Version 3.3, when a new workflow definition was implemented in production, any in-progress live instances were automatically updated on deployment to adhere to the new workflow design. This had the potential to lead to complications with existing in flight workflows if the cut-over was not carefully handled.

To Provide choice and control over workflow changes, V3.3 implements a new process to detach in-flight workflow instances from automatically adopting the latest FAB workflow changes introduced in production. By default, existing instances in production will maintain their original workflow definition as assigned at the time of submission, ensuring inflight workflows can complete without interruption or update. Similarly, new instances will seamlessly adopt the most recent available workflow definition, maintaining consistency across the project lifecycle. Lastly, the ability for prior instances to be updated to the latest version is made available in the Instance data report.

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 result in many versions.

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.

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

A Workflow Version can be Editable or Active/Locked.

VERSION_ID

Related Tables

/IQX/FAB_WF - FAB Enhanced Workflow Definition

  • Adds new line for every new combination set of Project App>Form Iteration>WF ID>WF Version

  • Modifies existing lines for every modification done on the existing WF Versions. Change Date and Timestamps are recorded in fields with pattern MODIFIED_*

  • Notable Fields:

    • ZFORM_NAME: Form App

    • ZITERATION_NO: Form Iteration

    • ID: Workflow ID (Always set to '1' as of FAB v3.3.1)

    • MD5_CHECKSUM: Unique character identifier of Active Workflow Versions

    • VERSION_ID: Workflow Version

  • Description Fields:

    • ITERATION_DESC: Form Iteration Description

    • ZID: Workflow ID Description

    • VERSION_DESC: Workflow Version Description (editable via new workflow designer)

    • DESCRIPTION: Project Form App Description

  • Status Fields:

    • IS_ACTIVE: Sets to 'X' (TRUE) when WF Version is in Active or Locked status

    • IS_RELEASED: Sets to 'X' (TRUE) when WF Version is released and transported

When no Workflow Version is activated yet for the Project Form Application, the Workflow Instance ID (/IQX/FAB_WF-MD5_CHECKSUM) will be on its fall-back value:
WF Instance = FormName + IterationNo+ WF_ID + WFVersion_ID

Form Instances submitted for WF Versions with Editable status will have this fall-back value as their unique MD5_CHECKSUM.

/IQX/FAB_WF_INST - FAB - Enhanced Workflow Instance (New table released in FAB v3.3)

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

  • Notable Fields:

    • WF_INSTANCE: Contains the same value as /IQX/FAB_WF-MD5_CHECKSUM

    • ZFORM_NAME: Form App

    • ZITERATION_NO: Form Iteration

    • ID: Workflow ID (Always set to '1' as of FAB v3.3.1)

  • Description Fields:

    • VERSION_DESC: Workflow Version Description (editable via new workflow designer)

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

  • Run-time values of created Form App Instances

  • Notable Fields:

    • ZFORM_NAME: Form App

    • ZINSTANCE: Form Instance

    • WF_INSTANCE:

      • Unique Workflow Version Identifier on which the Form Instance is currently running

      • Contains the same value as /IQX/FAB_WF-MD5_CHECKSUM

Developer Guide

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