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

Summary

Before FAB version 3.3, deploying a new workflow in production automatically updates all in-progress form instances to adhere to the new workflow, potentially causing issues due to differences in task configurations.

FAB v3.3 introduces Workflow Versioning, allowing control over which workflow definition a form instance uses. It records workflow definition changes and shows the current workflow being used for each form instance.

By default, in-progress form instances keep their original workflow definition, avoiding interruptions. while new instances adopt the latest workflow definition, ensuring consistency.

Auto-Versioning (FAB v3.3)

Changing the workflow definition automatically creates new Workflow Definition Instance in table /IQX/FAB_WF_INST and directly links it to tables /IQX/FORMHD_INST and /IQX/FAB_WF via fields WF_INSTANCE and MD5_CHECKSUM, respectively.

If you are running on FAB 3.3 version and wants to deactivate this feature, follow these steps: https://iqxbusiness.atlassian.net/l/cp/QuU2TqTU

Revised WF Versioning (FAB v3.3.1)

With FAB version 3.3, changes to workflow definitions in development automatically trigger workflow versioning, creating a new workflow instance each time WF definition changes are saved. This ensures version control but complicates development and testing due to the creation of many workflow instances.

Tracking the specific workflow version used when a form instance was created has also become difficult.

To address these issues, we enhanced the workflow versioning process and introduced a new API. This API collects detailed versioning data and helps control workflow versions for in-progress form instances.

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

image-20240229-081524.png

Description

Table Field

Release Notes

Project Form App

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

ZFORM_NAME

AS-IS logic before FAB 3.3

Form Iteration

Form Iteration value increments whenever user saves the form app via 'SAVE (new iteration)' button or form is transported through systems.

Each Form Iteration can accommodate multiple Workflow IDs intended for future Alternate Workflows.

ZITERATION_NO

AS-IS logic before FAB 3.3

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'.

Within each Workflow ID, numerous Workflow Versions can be found.

ID

Workflow Version

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

A Workflow Version can be Editable or Active/Locked.

VERSION_ID

Added logic on FAB 3.3.1

Related Tables

/IQX/FAB_WF - FAB Enhanced Workflow Definition

  • As of FAB v3.3.1, this table adds new line for every new combination set of Project App>Form Iteration>WF ID>WF Version. It also modifies existing lines for every change 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 set to the “fallback” value:
WF Instance = FormName + IterationNo+ WF_ID + WFVersion_ID

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

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

  • As of FAB v3.3.1, this table stores the definition snapshot every time WF Definition is activated.

  • As of FAB v3.3, this table stores the definition snapshot of WF Definition when a FAB Form 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

More Information

To know more the differences between data fields for different FAB release version, please check FAB Process Flow Version Comparison.

  • No labels