Are these warnings or errors ? Can they cause workflows to be stuck ? Is this acceptable for a production env ?The words FAILURE are worrying.How do I know if invalid definitions will not be used in a running process ?What happens if they are ?

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.

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.

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.

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.

Thanks Matt. A very comprehensive answer. Thanks for taking the time to answer.

In order to get rid of these warnings/errors, is it just a case of the developer removing that part of the workflow that isn't required ie. if it's not required or is producing warnings - why is it there at all ? or as you have said, the least they could do is model responses for the lookup types ? Does that sound reasonable ?

I would expect the developer to ensure that there aren't any errors thrown from the customisations that have been made, which would get rid of some of the reuse error messages.

From a purist point of view, I would expect Oracle to either not deliver a seeded process which causes errors, or at the very least document that there may be errors which can safely be ignored.

The problem with lookup types and codes is that they aren't versioned or even item type specific - someone could change the definition in one place and impact the system. If the developer is then taking the definition from the database rather from the Oracle delivered flat file, then they pick up these new problems - so when you deploy the new definition, you see the errors.

If the errors are nothing to do with the customisation, then the developer should really document that these are expected in the MD120 (or whatever installation document they are giving you) so that you know to ignore them.

Looking at some of the errors related to an outcome not being modelled, the version of the requisition approvals Workflow you are using is different from the one I've just opened here, in that the standard lookup types seem to have different values in them, which might explain where the errors are coming from when you deploy the code (I'm looking in 12.0.6 since that's what I have handy at the moment, which could also explain the difference!)