This post is a follow up to Understanding Workflow Errors - Part 1 that deals with some of the most common errors raised when some of the Workflow Engine APIs are used.
The way to trap and continue processing upon finding these errors is the same: evaluate the content of global variable WF_CORE.error_name.
Error message: 3103 Attribute 'ATTRIBUTE' does not exist for item 'TYPE/KEY'
Error code: WFENG_ITEM_ATTR
The most likely reason for this to happen is a change in the Workflow definition. For instance, an attribute is added to the definition while there are open workflows not having it. Then you attempt to set a value for it and notice new processes have no issues but the ones created before the change will fail.
Whenever possible these regressions should be foreseen and addressed in the design of the Workflow definition. A possible workaround is to add the supporting plsql code to check for the exception:
...EXCEPTION WHEN OTHERS THEN if WF_CORE.error_name='WFENG_ITEM_ATTR' then wf_engine.additemattr(...); end if;END;
Error message: 3120 Activity 'TYPE/ACTID' has no performer
Error code WFENG_NOTIFICATION_PERFORMER
All performers of notification activities are taken from view WF_ROLES. The most typical reason for this error is the originally assigned user/role has been expired. While the correct fix is to unexpire the performer and let the workflow complete, there are two possible ways to go around:
1. Change the value to the attribute holding the name of the performer. For instance, if there is an item attribute RECIPIENT pointing to expired user JSMITH then change it to an active user/role, say JHOPKINS. You will need to call this from a SQL*Plus session:
WF_ENGINE.SetItemAttrText(<type>, <key>, 'RECIPIENT', 'JHOPKINS');
2. The other alternative is to change all references in ALL the workflow runtime tables to change anything related to JSMITH and change it to the taking over user JHOPKINS:
declare l_attributes wf_parameter_list_t;
begin WF_EVENT.AddParameterToList('OLD_USER_NAME', 'JSMITH', l_attributes); WF_EVENT.AddParameterToList('USER_NAME', 'JHOPKINS', l_attributes); WF_LOCAL_SYNCH.Propagate_Role(p_orig_system => <orig system>, --for instance, 'FND_USR' or 'PER' p_orig_system_id => l_orig_system_id, --for instance, 29984 p_attributes => l_attributes);
end;As always, use care and try these APIs on a test environment before using them in production
Error message: 3133 Activity instance 'NAME' is not a notified activity for item 'TYPE/KEY'.
Error code: WFENG_NOT_NOTIFIED
When it is needed that the processing of a workflow stops to wait for something to happen a BLOCK function can be used. When the block function runs the activity goes into NOTIFIED status. Then, to resume the processing, an explicit call to WF_ENGINE.CompleteActivity must be made. But if the activity is not in notified status then the API will raise WFENG_NOT_NOTIFIED.
There is no straightforward action to deal with this error. Rather, troubleshooting must be made to see why the activity did not go into NOTIFIED status. Sometimes the reason is that the workflow process continued to the next activity, leaving it complete or did not even reach it. A good way to understand what the workflow process has done is to run the seeded script wfstat.sql. Check the output and follow the execution path.