A workflow definition is stored in the database as a stream of serialized objects. That's why your own workflow beans have to stick to the following rules:
Avoid incompatible changes to classes which are already in use by a workflow definition.
Consider using a serial UID for all your classes from the start on.
Serialize and deserialize the object graph manually (see Oracle JDK Serialization documentation for details). This gives you the most control, but the most work, too.
Use the
workflowconvertertool to reparse and rebuild definitions which are not deserializable anymore.New versions of a workflow bean must be compatible with all uploaded XML definitions.
New configuration options can be added as long as they are backwards compatible with the old ones.
Additional objects, such as workflow variables, introduced with a new bean and definition will never be available in any old instance.
If semantics have to be changed you should consider writing a new bean and keeping the old one.
![[Caution]](../common/images/caution.png) | Caution |
|---|---|
The semantics must work in any still existing instances of older workflow definitions. |
Since the workflow beans of a given definition are shared by all the definitions instances:
No workflow bean must store any state in a local variable. State is always restricted to an instances context.
No workflow bean must cache any objects requested from the server or client instances such as ObjectRepository, DirectoryService, CoreMedia Content Management Server Session etc. These objects may carry session specific information that is only valid to the current bean invocation.
Every bean must be reentrant, that means is must be thread safe and never use nested synchronization.
To circumvent some of the mentioned problems, you might want to use the feature to upload a JAR together with a workflow definition. This separates the classes for each workflow definition. But when you update the JAR file for an existing workflow definition, the same problems occur as when loading the classes from the workflow servers classpath.
Additionally, references from the classes inside the JAR to classes outside of the JAR file are likely to cause problems. It might seem, that packaging all classes that are referenced by the customized workflow classes into one huge JAR file is a solution. But consequently, you would have to package the transitive closure of your workflow classes into that one JAR. That may not be feasible. It's better to document the dependencies of the customized workflow classes and to keep care that they are always fulfilled when running the Workflow Server.
 |  |  |
 |