Hi,
That's a lot of reported messages
I'll break them into common problems...
Activity 'END-23' has no out transition
The process has an End activity which hasn't been correctly defined - the developer has used the standard End activity (which is great) but hasn't modified the activity to mark it as an end node for the Workflow Engine to process correctly. If the process is left as is, and the Engine hits that node, then the process will hang because there is nothing else for it to do.
- 403: 'SAVE' validation failed for subprocess tree under activity 'REQAPPRV/XXSSE_MAIN_REQAPPRV_PROCESS'.
- 402: Should not reuse process 'REJECT_REQUISITION_PROCESS'.
----
- 403: 'SAVE' validation failed for subprocess tree under activity 'REQAPPRV/XXSSE_GENMAIN_REQAPPRV_PROCESS'.
- 402: Should not reuse process 'REJECT_REQUISITION_PROCESS'.
----
- 403: 'SAVE' validation failed for subprocess tree under activity 'REQAPPRV/XXSSE_APPROVAL_ROUTING_CHOOSER'.
- 402: Should not reuse process 'NOTIFY_APPROVER_CHOOSER'.
----
- 403: 'SAVE' validation failed for subprocess tree under activity 'REQAPPRV/XXSSE_APPROVAL_LIST_ROUTING'.
- 402: Should not reuse process 'NOTIFY_APPROVER_CHOOSER'.
----
- 403: 'SAVE' validation failed for subprocess tree under activity 'REQAPPRV/MAIN_REQAPPRV_PROCESS'.
- 402: Should not reuse process 'REJECT_REQUISITION_PROCESS'.
The developer has re-used the same sub-process at different points in the same hierarchy,
e.g. it goes MAIN > NOTIFY_APPROVER_CHOOSER > some other process > NOTIFY_APPROVER_CHOOSER again
The second time that the process is reused, you will get all sorts of problems because the Workflow Engine will look to update data and won't know which time through it is executing the sub-process. Sometimes it might work correctly, other times it won't but in all likelihood it will fail in all circumstances. The best that you can hope for is that it works OK but destroys the history and ruins any audit trail, which isn't good
- 354: 'SAVE' validation failed for activity 'REQAPPRV/WR4_RESPONSE_REJECT'.
- 362: Validation failed for child activity 'REQAPPRV/UPDATE_APPROVAL_LIST_RESPONSE'.
- 358: Activity result code 'FAILURE' has no transition defined for it. All valid result codes must be modeled with specific transitions or a <Default> transition.
----
- 354: 'SAVE' validation failed for activity 'REQAPPRV/WR4_RESPONSE_FORWARD'.
- 362: Validation failed for child activity 'REQAPPRV/UPDATE_APPROVAL_LIST_RESPONSE'.
- 358: Activity result code 'FAILURE' has no transition defined for it. All valid result codes must be modeled with specific transitions or a <Default> transition.
----
- 354: 'SAVE' validation failed for activity 'REQAPPRV/WR4_RESPONSE_APPROVE_FORWARD'.
- 362: Validation failed for child activity 'REQAPPRV/UPDATE_APPROVAL_LIST_RESPONSE'.
- 358: Activity result code 'FAILURE' has no transition defined for it. All valid result codes must be modeled with specific transitions or a <Default> transition.
----
- 354: 'SAVE' validation failed for activity 'REQAPPRV/WR4_RESPONSE_APPROVE'.
- 362: Validation failed for child activity 'REQAPPRV/UPDATE_APPROVAL_LIST_RESPONSE'.
- 358: Activity result code 'FAILURE' has no transition defined for it. All valid result codes must be modeled with specific transitions or a <Default> transition.
----
- 354: 'SAVE' validation failed for activity 'REQAPPRV/WR4_RESERVE_BEFORE_APPROVE'.
- 362: Validation failed for child activity 'REQAPPRV/UNABLE_TO_RESERVE'.
- 358: Activity result code 'OVERRIDE' has no transition defined for it. All valid result codes must be modeled with specific transitions or a <Default> transition.
The activities are using a lookup type but haven't modelled a response for each possible outcome. These might be OK - for example the last one should have an OVERRIDE result, but doesn't. If the code being called can't possibly return that outcome, then you can ignore the error. If the code might return OVERRIDE as a result, then the Workflow process will move to a STUCK status because it has nowhere to go any more. Even if the code doesn't return the value, it's bad practice for the Workflow definition not to model that possible result - if the code changes in the future and starts to return the result, then the Workflow process will need to be modified now because it is now invalid.
- 328: 'SAVE' validation failed for message 'REQAPPRV/PO_REQ_FORWARD'.
- 401: Could not find token 'DELIVER_TO_LOC_DISPLAY1' among message attributes
- 401: Could not find token 'FORWARD_FROM_DISP_NAME1' among message attributes
A message is trying to include some attributes which haven't been defined for the message - when the message gets sent, instead of the value of the DELIVER_TO_LOC_DISPLAY1 attribute, the message will contain the text "&DELIVER_TO_LOC_DISPLAY1" instead.
wferr:
- 1405: Invalid performer 'KH PO 1' in process activity 'WFSTD/VOTEFORRESULTTYPE'.
- 1405: Invalid performer 'PREPARER_USER_NAME' in process activity 'WFSTD/END'.
- 1405: Invalid performer 'PREPARER_USER_NAME' in process activity 'REQAPPRV/RESERVE_DOCUMENT'.
The activities have a hard-coded performer which doesn't exist in your environment. I'd guess that the PREPARER_USER_NAME should be referencing the item attribute of that name rather than a hard-coded value. I would be concerned that the standard End activity has been modified and is now referencing a performer (even if it was one that existed!) - this is not right.
Since these are activities rather than notifications, you can ignore the errors if you want to, because the performer is irrelevant. One thing that it does show is that at some stage the definition was extracted from the database rather than working from a flat file, because the WFSTD definition shouldn't be reporting the error if the developer is working from the original definition.
How do I know if invalid definitions will not be used in a running process ?
What happens if they are ?
thanks for any help.
Cheers
Dave
There's no way of knowing whether an invalid definition will get used or not - only running the process and dealing with it will show you that. That's part of the fun of working with Workflow
The entire definition isn't invalid, though, even if certain parts of it are - it's not like having a function in a package which is invalid and renders the whole package invalid, so even looking at these errors, they might never cause a problem if they are left alone, because it's possible that when running the processes, the invalid parts never get hit. It's only when the Workflow Engine tries to execute an invalid part of the definition that you are going to see any problems, which may never happen.
The developer would have seen some if not all of these errors when they tried to save the definition - particularly those which are thrown by your custom requisition process, so I'd be tempted to send it back to them to resolve the issues or at least explain whether they feel that they can be safely ignored or not.
HTH,
Matt
