Monthly Updates 20.8 – 22.6 to 22.7+ - Workflow Process Consideration

Updating from release 20.8 or higher (20.8-22.6) to a Monthly Update that is 22.7 or higher, may cause duplicate record insert issues for Workflow Processes during workspace Delivery/Rebase. The Delivery/Rebase may fail or cause a crash.

In Siebel Tools/Web Tools, Workflow Processes having multiple versions have the same Process Name such as “My Workflow Process”, but the actual names at database level are “My Workflow Process:1”, “My Workflow Process:2”, … “My Workflow Process:6” in NAME column. This is expected and correct for pre-IP2017 versions.

With the introduction of Workspaces, Workflow versions are now tracked in the WS_OBJ_VER column and hence every Workflow record must have a unique Name to avoid duplicate insert issues.

How the application identifies the one true definition of a Workflow Process

If this is a Workflow Process present in the Repository we shipped with the product and found in the MAIN Workspace, it is the “original” definition of that Workflow Process. Its Row Id is the logical pointer that all Workspaces modifying that Workflow Process will use in their WS_SRC_ID column. The Workspaces all point back to the definition in MAIN using that Row Id. Every Workspace created directly under MAIN will point to the Workflow Process definition found in MAIN. During a merge or rebase, the definition in MAIN will be used. Oracle may modify the Workflow Process definition at some point and ship it with a Monthly Update through the RepositoryUpgrade utility. In this case, the definition we are shipping will import into the Repository using the same Row Id as the original version we shipped. As it is delivered up the Workspace chain, the “original” version should still point to the one in MAIN although the definition may have been changed by you previously.

Creating a different copy of the Workflow Process through a SIF import

Sometimes, developers export a Workflow Process to a Siebel Archive File (SIF) and import it into a different Workspace. When that happens, the WS_SRC_ID does not point to the one in MAIN. It has a new WS_SRC_ID created in that Workspace. Now the situation is that there are two Workflow Processes with the same name but different WS_SRC_IDs. Now the application will not be able to know which one should be used This is one of the sources of the issues that this utility fixes.

There will only be one logical pointer to an object even though this object may be modified in many different Workspaces simultaneously. When a Workspace is delivered, the application must merge the changes made in the Workspace with other delivered versions of this object. For instance, there is only one SIS OM Active Order Sub-Process Workflow Process although it may have been modified in many different Workspaces. When a developer is modifying the SIS OM Active Order Sub-Process Workflow Process in a development Workspace, the WS_SRC_ID holds a logical pointer to the SIS OM Active Order Sub-Process Workflow Process found in the MAIN Workspace that is considered the Golden Version (the source of truth). All the developer Workspaces, if modifying the SIS OM Active Order Sub-Process Workflow Process should have the Row Id of the SIS OM Active Order Sub-Process Workflow Process as it is found in the MAIN Workspace. Sometimes a Repository may have records in a Workspace that do not have the expected, logical pointer to the SIS OM Active Order Sub-Process Workflow Process in the WS_SRC_ID column. In such a case the deliver log may show errors such as the following.

Example of delivery errors

LINE 16610: DUPLICATE OBJECTS FOR TYPE 'Workflow Process' AND PATH 'Configurator Product Info Lookup'
LINE 17384: DUPLICATE OBJECTS FOR TYPE 'Workflow Process' AND PATH 'ISS Promotion WS - Add Missed Items Sub Process'
LINE 17690: DUPLICATE OBJECTS FOR TYPE 'Workflow Process' AND PATH 'SIS OM Active Order Sub-Process'

Remediation

In the update scenario described previously, run a new utility named WFCleanup.exe after you finish the Monthly Update. This utility is found in the <SIEBEL ROOT>/BIN.

Running the Utility

WFCleanup.exe -t <Table Owner> -u <Table Owner User Name> -p <Table Owner Password> -o 
< ODBC Data Source > -r <Repository Name> -s <SIEBEL ROOT/BIN> -d <DB Name>

Examples of running the Utility

Microsoft SQL Server

WFCleanup.exe -t dbo -u MSNMK122 -p ******** -o MSNMK122 -r "Siebel Repository" -s 
"C:\Siebel\22_10" -d MSSQL

Oracle

WFCleanup.exe -t ORAUJD110 -u ORAUJD110 -p ******** -o ORAUJD110 -r "Siebel Repository" -s 
"C:\Siebel\22_10" -d ORACLE

DB2UDB

WFCleanup.exe -t SIEBEL -u SIEBEL -p ******** -o DB2DM115 -r "Siebel Repository" -s 
"C:\Siebel\22_10" -d DB2UDB

DB2390

WFCleanup.exe -t CQ10C002 -u QADMIN -p ******** -o Q10C -r "Siebel Repository" -s 
"C:\Siebel\22_10" -d DB2390

Argument List for the Utility

Argument	Description	Comment
-t	Siebel Table Owner	Required
-u	TBLO Username	Required
-p	TBLO Password	Required
-o	ODBC Data Source	Required
-r	Repository Name	Default: "Siebel Repository"
-s	Siebsrvr/Tools Installation path specified	Required
-d	DB Platform Name	Oracle, MSSQL,DB2UDB or DB2390

Utility Output Log Location

The utility Logs are generated in <SIEBEL SERVER_ROOT>\log.

The WFCleanup.exe performs the following actions:

Identifies the primary record for each Workflow having identical process names but different WS_SRC_IDS. The process with the highest version that is in the status of COMPLETED is treated as the PRIMARY record. For this primary record, it updates the NAME value to what is in the PROC_NAME column. For the other records with the same name the PROC_NAME column will be updated with NAME value and the record is inactivated by setting its INACTIVE_FLG = Y. This makes each record unique.

Note: If highest version of the Workflow in Completed status is also inactive, then it makes highest versioned IN_PROGRESS record the surviving Workflow record.

Example of records before running the utility

NAME	PROC_NAME	VERSION	STATUS_CD	INACTIVE_FLG
ABO Bulk Request -Validate Process:0	ABO Bulk Request -Validate Process	0	Completed	N
ABO Bulk Request -Validate Process:1	ABO Bulk Request -Validate Process	1	In Progress	N
ABO Bulk Request -Validate Process:2	ABO Bulk Request -Validate Process	2	Completed	N
ABO Bulk Request -Validate Process:3	ABO Bulk Request -Validate Process	3	In Progress	N

Example of records after running the utility

NAME	PROC_NAME	VERSION	STATUS_CD	INACTIVE_FLG
ABO Bulk Request -Validate Process:0	ABO Bulk Request -Validate Process:0	0	Completed	Y
ABO Bulk Request -Validate Process:1	ABO Bulk Request -Validate Process:1	1	In Progress	Y
ABO Bulk Request -Validate Process	ABO Bulk Request -Validate Process	2	Completed	N
ABO Bulk Request -Validate Process:3	ABO Bulk Request -Validate Process:3	3	In Progress	Y

Note: The surviving Workflow record in this case is version 2. It was in a status of Completed and had the highest version. The NAME of this record changes from ABO Bulk Request -Validate Process:2 to ABO Bulk Request -Validate Process and becomes the only active record for the Runtime Repository once migrated. The PROC_NAME is updated with the value in the NAME column and the INACTIVE_FLG is set to Y for the remaining records.

Workflow records with the same name but with different versions, all with a status of “In Progress”are handled in the following manner. The most recent IN PROGRESS record is considered as primary. This primary workflow NAME is then renamed with PROC_NAME and Activated. For rest of the records PROC_NAME is changed to NAME to make them unique, and Inactivated.

Example of records before running the utility

NAME	PROC_NAME	VERSION	STATUS_CD	INACTIVE_FLG
ABO Bulk Request - ApplyProductPromotion:0	ABO Bulk Request - ApplyProductPromotion	0	In Progress	N
ABO Bulk Request - ApplyProductPromotion:1	ABO Bulk Request - ApplyProductPromotion	1	In Progress	N

Example of records after running the utility

NAME	PROC_NAME	VERSION	STATUS_CD	INACTIVE_FLG
ABO Bulk Request - ApplyProductPromotion:0	ABO Bulk Request – ApplyProductPromotion:0	0	In Progress	Y
ABO Bulk Request - ApplyProductPromotion	ABO Bulk Request - ApplyProductPromotion	1	In Progress	N

Note: The latest Version is 1. The NAME of this record changes from ABO Bulk Request - ApplyProductPromotion:1 to ABO Bulk Request – ApplyProductPromotion. The other In Progress record has been inactivated and the PROC_NAME column has been updated with the value in the NAME column.