Oracle UCM custom Criteria Workflow

Question

I am looking for some help.
I am trying to create a criteria workflow based on a document type. I have used the command wfrelease to commit all metadata to the repository in the entry step.
The user in the workflow will either approve the workflow or select from a custom metadata field option list called "status". Once a user sets the value to "rescan" in the "status" option list I want the user to reject the workflow. Once rejected we want the workflow to be sent to an alias and not the original author.
If the user sets the value of the "status" option list to either "return", "reroute", or "invalid" value and rejects the workflow then I want the workflow to be routed to a different alias.
Is this very difficult to accomplish? What steps would I need to create? I am pretty sure somehow I need to create tokens for the 2 different aliases and call them on reject but I am having trouble putting all of this together.
Thanks in advance for your help!

Answer 1

Hey Data Bitz
The good news is that yes, all this can be done with some configuration and a bit of workflow scripting.
Several items:
1) I'm not seeing a reason why you need to use WfRelease in the entry step. Workflow users can still access and alter the metadata for routing as you describe. Do you want the item to be indexed (to appear in the search results lists)?
2) While there are several ways to do this I would envision a two step workflow. Step one is your "rejection handler" step 2 is your user review step.
first time through content passes through step one with a criteria based jump in the entry event of that step. The criteria is along the lines of if step entry count <= 1 then jump .
Make sure that step one is an edit and review step. Step two is where the user either approves or sets the status metadata field to some other value. If s/he approves, the content is released (or goes on to subsequent steps).
If the status is changed then you want to trigger a rejection. This brings me to point 3...
3) Do you want "rejection" or do you just want to rout the content to another set of users for review. The reason is that rejection is logged as a "rejection" Workflow Action in the database. If you are tracking or reporting against this then you'll want a "real" rejection. If you just want the item to be routed to an alias that is based on the value of the status field then this is different and can be achieved without a full blown rejection action. The choice is yours and the impact is really just on reporting and the routing behavior of the content object.
4) so lets say the user sets the status to "rescan". Remember we're in step 2 here. Use the update event of step 2 to look for the Metadata Update action. Because the update event of the workflow step acts like a loop it is able to pick up the metadata updates that the user executes. Configure a jump in the step event to say +if there has been a metadata update action then check the value of the status metadata field.  if the value of the status metadata field is "rescan" then perform this action, if the value of the metadata field says some other value (either "not rescan" or "return", "reroute" etc) then perform this other action+
5) So if you really want a true rejection then the this action from above will be a bit of IDOC to execute with WFREJECT service. You'll need to pass along the appropriate parameters for the service (see pp 348/349 of the services reference guide for the WF_REJECT service and required parameters. The guide is here: http://download.oracle.com/docs/cd/E10316_01/cs/cs_doc_10/documentation/developer/services_reference_10gr3en.pdf). If you just want to route the content to another set of users then the this action and this other action are actually the same and you can jump back to step 1 with a jump script. While the actions are the same, the users will be different and we can handle this with some basic workflow configuration scripting as well. Now here is where the fun begins.
6) So you're back in step 1 either because the WF_REJECT action happened or because you jumped here. The status field set to "rescan" or some other value like "return", "reroute" etc. Go back int the entry event of step 1. This is where the pass through code from item 2 above was written. The cool thing about the entry event is that it gets evaluated BEFORE step users are set and email notifications go out. This means that you can set any kind of user decision logic right in the event. So beneath the pass through code I would create another block of workflow scripting that does the following: gets the value of the status field - you can do this simply by referencing the metadata field name - e.g. myVar=xStatus. If myVar="rescan" then set a companion file variable to the name of the alias you want - e.g. +<$if myVar="rescan"$><$wfSet("reviewerAlias","YOUR_ALIAS_NAME")$><$endif$>+ If you're unfamiliar with the companion file, see pp 18 of the workflow implementation guide (link below). Think of it as a temporary memory cache for each item in workflow. It is a place where any key value pairs can be set and retrieved for any document as long as it is in workflow. Keep setting the value of "reviewerAlias" to the different alias names based on your IF condition. for example:
+<$if myVar="rescan"$><$wfSet("reviewerAlias","YOUR_ALIAS_NAME")$><$elseif myVar="return"$><$wfSet("reviewerAlias","YOUR_OTHERL_ALIAS_NAME")$><$endif$>+
7) Finally you have the content in the right step, you have evaluated the metadata and have set a variable in the companion file with the correct alias name you want to be the users for the step. The last thing is to retrieve that alias name and set that alias as the step user. Remember that workflow is able to set either individual user names (singly or CSV) or ALIAS names as step users. Remember that an alias in UCM is a list of user names. You will use a token in step 1 to retrieve the value of the companion file key and set the alias to be that user. The token code is straight forward but if you want a walk through then check out the adding ad hoc step users section in chapter 9 of the workflow implementation guide here:
http://download.oracle.com/docs/cd/E10316_01/cs/cs_doc_10/documentation/admin/workflow_guide_10gr3en.pdf
Your token code will look something like this:
<$wfAddUser(wfGet("reviewerAlias"), "alias")$>
The wfAddUser function is the token code. It is what adds the step user and it take two parameters - parameter 1 is the name or names of a user or alias. parameter 2 is the type either "user" or "alias".
So this give you a fully dynamic workflow that allows the routing of the items to be fully dynamic and driven off of metadata - something that is very easy for end users. It also allows the reviewers to be dynamically set using tokens and a bit of idoc. No coding outside of the workflow admin applet has to happen at all.
Of course, my company, Fishbowl would love to talk with you more about what you're doing and see if we can provide any additional service to you. Please let me know!
Warmly,
Billy Cripe
Fishbowl Solutions