Re-assign a route to previously initiated workflows

Martin_Beveridge_(ap_mbeveridge_(Delete)_2221942)

We recently have migrated from 8.1.5 to 9.0.0.1 and everything seems to be running smoothly. During this process a workflow map was exported from 8.1.5 instance and imported into 9.0.0.1 and by mistake one of its sub-workflow map was not assigned in the Sub-Workflow Step of the main map. The result of this was evident only a few days ago when the initiated workflows started to get stuck on the Sub-workflow step in question. The problem was resolved by assigning the relevant Sub-Workflow map to the appropriate Sub-Workflow Step. After the problem resolution all the newly initiated workflows are flowing through the corrected Workflow successfully, however now we have a few hundred workflows which were initiated after the migration and until the discovery and elimination of the problem in the workflow. Our workflows involve a lot of backend processing as the workpackage goes along and hence it is not simply a matter of suspending the workflow and initiating it again. I have looked into the structure of the tables involved in the workflow execution and have found that by modifying the SUBWORKTASK_STATUS field of WSUBWORKTASK table we can set the previous step to be the current steps in a workflow, or in other words, move the workflow one step backwards. This however still does not solve the problem of the wrong workflow map assigned at the time of initialization.So my question is, can we assign a new route to previously initiated workflows without loosing its existing data ? Any comments or suggestions will be highly appreciated.Thanks & RegardsJaleel Shaheen

Jeff_Lang_(lang_(Delete)_2245920)

Here is a possible solution to your problem.First, make a backup of your database in case something goes wrong.Next, in a SQL editor select a row from the WMapTask table that is the sub-map step that is causing problems. Also, select a row that is the same step, but after the sub-map was hooked back up.Compare the MapTask_SubMapIDCb fields of the 2 records. What you have to do is to run a SQL statement that copies the good data to the row that contains the bad data. The statement will be something like this:update WMapTask set MapTask_SubMapIDCb = ( select MapTask_SubMapIDCb from WMapTask where MapTask_MapID=*the good mapid* and MapTask_TaskID=*the good taskID* ) whereMapTask_Type=2 and MapTask_SubType=128 and MapTask_TaskID=*the bad taskid* and MapTask_Title="*the sub-map step name*"Once you get the statement correct it should make all the executing workflows that didn't have a submap assigned now call the correct submap.