iProcess case data migration - behaviour/actions when steps have been removed in the new procedure
Article ID: KB0085662
Updated On:
| Products | Versions |
|---|---|
| TIBCO iProcess Engine (Oracle) | - |
| Not Applicable | - |
Description
Resolution:
Description:
===========
iProcess case data migration - behaviour/actions when steps have been removed in the new procedure.
Care should be taken in deleting steps in iProcess procedures if the intention is to migrate cases to avoid corrupted/hang (see below scenarios)
Environment:
============
TIBCO iProcess Engine 11.x
Symptoms:
===========
Consider the procedure:
...
A->B->C
...
where A,B,C are user steps.
Assume that there are three cases 1,2 and 3 which are respectively on step A, step B and step C.
If step C is deleted and case 1 is released twice, the case will close normally. This is because when step A is released and the new step B is processed, the actions (following steps) will be loaded.
If step C is deleted and case 2 is released, the case will close normally.
If step C is deleted and case 3 is opened, then a message will be seen stating "Cannot access form data. contact your system administrator."
If step B is a subprocedure call containing a user step and this subprocedure call is deleted, then "Error, workflow transaction aborted because of a system failure messages will be seen in both the audittrail of the proc and subproc:
...
A->Sub(B)->C
...
If B is a step into a wait W and step W is deleted and the procedure migrated, and the wait has already been processed (by release of D , then the release of B would leave the wait W unable to be automatically processed:
...
D
|
\/
A -> B--W
...
Also consider the following scenario:
1). Create a procedure that calls a sub-procedure (STEP1 >> STEP2 >> SUB2CALL >> STEP3).
2). Release to SUB2CALL, then perform a 'jump to' to STEP3, then back to SUB2CALL.
3). Change the procedure to a differently named reference SUB3CALL and release and migrate cases.
4). Now when you first attempt a jumpto from the existing step, it is possible to get the following error:
...
Error encountered suspending cases:
The iProcess Objects Server returned the following error:
One of the items in the array returned an error.
Error details:
Bad SAL/FIL function parameter. :PROC3 case number = 8952
...
The following may also be seen in the debug logs:
...
[T=4084516528]131120131329.215048:p001: fil_pdc_pd_name_to_dir_ex(SUB2CALL) dir not found
[T=4084516528]131120131329.215059:c001: proc_case(proc:PROC3, case:8952): Place record references step 'SUB2CALL' THAT DOES NOT EXIST IN PDEF.
...
This is because there already exists a step name entry with the old reference in the outstanding_addr table. These are just some of the effects of deleting steps prior to a procedure migration.
Cause:
======
New Procedure has been released with case data migration. One or more Step(s) has been deleted in the new procedure.
RESOLUTION:
===========
1). Do not migrate cases for a new procedure with deleted steps and outstanding workitems for the deleted step.
2). When this is not possible, don't delete the step in the procedure (just delete all links) or create new gateway steps (or equivalent) with the same name as the deleted step.
NOTE: This has to be tested on the testsystem before apply the changes in the production system.
3). If cases are already stuck as a result of a delete/migrate, then contact TIBCO Support.
Description:
===========
iProcess case data migration - behaviour/actions when steps have been removed in the new procedure.
Care should be taken in deleting steps in iProcess procedures if the intention is to migrate cases to avoid corrupted/hang (see below scenarios)
Environment:
============
TIBCO iProcess Engine 11.x
Symptoms:
===========
Consider the procedure:
...
A->B->C
...
where A,B,C are user steps.
Assume that there are three cases 1,2 and 3 which are respectively on step A, step B and step C.
If step C is deleted and case 1 is released twice, the case will close normally. This is because when step A is released and the new step B is processed, the actions (following steps) will be loaded.
If step C is deleted and case 2 is released, the case will close normally.
If step C is deleted and case 3 is opened, then a message will be seen stating "Cannot access form data. contact your system administrator."
If step B is a subprocedure call containing a user step and this subprocedure call is deleted, then "Error, workflow transaction aborted because of a system failure messages will be seen in both the audittrail of the proc and subproc:
...
A->Sub(B)->C
...
If B is a step into a wait W and step W is deleted and the procedure migrated, and the wait has already been processed (by release of D , then the release of B would leave the wait W unable to be automatically processed:
...
D
|
\/
A -> B--W
...
Also consider the following scenario:
1). Create a procedure that calls a sub-procedure (STEP1 >> STEP2 >> SUB2CALL >> STEP3).
2). Release to SUB2CALL, then perform a 'jump to' to STEP3, then back to SUB2CALL.
3). Change the procedure to a differently named reference SUB3CALL and release and migrate cases.
4). Now when you first attempt a jumpto from the existing step, it is possible to get the following error:
...
Error encountered suspending cases:
The iProcess Objects Server returned the following error:
One of the items in the array returned an error.
Error details:
Bad SAL/FIL function parameter. :PROC3 case number = 8952
...
The following may also be seen in the debug logs:
...
[T=4084516528]131120131329.215048:p001: fil_pdc_pd_name_to_dir_ex(SUB2CALL) dir not found
[T=4084516528]131120131329.215059:c001: proc_case(proc:PROC3, case:8952): Place record references step 'SUB2CALL' THAT DOES NOT EXIST IN PDEF.
...
This is because there already exists a step name entry with the old reference in the outstanding_addr table. These are just some of the effects of deleting steps prior to a procedure migration.
Cause:
======
New Procedure has been released with case data migration. One or more Step(s) has been deleted in the new procedure.
RESOLUTION:
===========
1). Do not migrate cases for a new procedure with deleted steps and outstanding workitems for the deleted step.
2). When this is not possible, don't delete the step in the procedure (just delete all links) or create new gateway steps (or equivalent) with the same name as the deleted step.
NOTE: This has to be tested on the testsystem before apply the changes in the production system.
3). If cases are already stuck as a result of a delete/migrate, then contact TIBCO Support.
Issue/Introduction
iProcess case data migration - behaviour/actions when steps have been removed in the new procedure
Feedback
Yes
No
Powered by
