The only thing you can modify in an enabled workflow is the idocScript code in workflow events - well, aliases (user groups) and possibly also tokens, that both define approvers might be modified too.
If you need anything else, don't use native workflows, but expose BPM Suite or BPEL workflows, which have such capabilities as running two or more versions of the same workflow. Note that UCM license contains restricted use of BPEL PM, and WebCenter Content license contains restricted use of the whole Unified BPM Suite.
While directly writing IDOC script in the applet window is perfectly acceptable, you will experience some need to change it, thus your dilemma of having to disable the workflow in order to edit it.
It is a much better practice to put your IDOC logic in a component within a dynamichtml include, and simply reference the include in the applet.
For example, let's say your workflow is named "MyWorkflow" and you have a step called "Step1". To create code in the entry step, in a custom component create a dynamichtml include called "my_workflow_step_1_entry"
Then in the workflow applet for "MyWorkflow" --> "Step1" entry event, simply put the following code
Now you can edit the code in the component resource file rather than the applet, and certainly don't have to enable/disable the workflow.
The one caveat here is that changes to the resource file code will require a server restart in order for the changes to take effect, as workflow code is cached differently as I recall. There is another way to get around that limitation, but I'll leave that solution for a blog post.
Thank you. We have the code in production already and our users found the bug so we have to fix existing workflow in production, We do not use component, just calling workflow from ADF code. There is no problem to restart the server but the issue with disable/enable code - the workflow will lose the content.
If you have idoc scrips in your entry event for example, you have an option to edit the exit event of the step and you need NOT disable and enable your workflow. The change gets reflected. I tried the following and it works:
- Created a 1 step WF
- In my entry event I am assigning a value to the dDocTitle metadata
- Created a content and made it fall in this step
- Now I edited my exit event to assign a different value to the dDocTitle metadata
- Approved the content
- The new value is assigned to dDocTitle field
See if this can fit in your case.
I found this information in Oracle documentation
If a workflow must be disabled to modify it (for example, to add a step) all revisions are immediately released from the workflow (Criteria workflow) or deleted (Basic workflow). To disable a workflow without releasing content:
- Clone the workflow to a static workflow which has the same step sequence as the original workflow but which has no step logic. The content goes into a step and stays there until moved.
- Create an update event in the original workflow. This event is triggered by time and pushes the content into the cloned static workflow at the appropriate step.
- When the content is out of the original workflow, disable the workflow, make the necessary changes, then re-enable it. Then use the same timed event logic to move the content from the cloned workflow back to the original workflow.
Does anybody know how to clone the workflow?