Question

It seems that once an Ocean Workstep derivative class has been released to production (and is used by clients), its name, namespace and assembly name are effectively locked for future updates (in order to ensure backwards compatibility).

When a Petrel project is saved, workstep references are saved as a full type name (namespace, class, strong assembly name) inside the binary file Classes.ptd. During loading, if the exact type name (assembly version seems to be ignored) can’t be resolved, the workstep appears as “workstep not available” in the workflow editor.

In other instances of binary serialization we’ve encountered, Petrel makes use of the SerializationBinder registered with PetrelSystem.ProjectSerializationService – not so for Workstep instances.

Is there any other way to facilitate Workstep class/namespace/assembly renames?

Why is this behaviour so poorly documented (if at all)? Have we misunderstood something?

Answer 1

This issue will actually be fixed with the Ocean 2012.1 API. The workstep reference will not include the version number anymore: Both workstep and process serialization is cleaned up. Version number is not serialized (and not used on deserialization) and a UniqueId can be used instead of the type name.

Here is an extract of the 2012.1 Ocean release notes on the subject.

Process and Workstep Unique Id
Namespace: Slb.Ocean.Petrel.Workflow

Processes and worksteps created through Ocean did not have a proper identifier until now. They were identified by their full type name including the version number which means that their identifier could change, for instance, if:
– The version number of the plug-in assembly was increased (e.g. new plug-in install).
– The process/workstep class was moved to a new assembly.
– The namespace of the process/workstep class was changed.
This could cause issues in Petrel such as the display of a “broken link” instead of the process name in the Favorites tree or a workstep appearing as “workstep not available” in the workflow editor.

To solve this, Ocean has removed the version number from the process and workstep identifier and is delivering a new API to support a user defined identifier for custom processes and worksteps which will be unique across the Petrel application. Any process/workstep created through Ocean should now implement a unique identifier.

Please refer to:
– Process.UniqueId to define unique identifier for processes
– Workstep.UniqueId to define unique identifier for worksteps.
The new API also offers backward compatibility support for already serialized processes/worksteps and a few changes in the serialization logic. When a legacy project is being opened the old-style ids are automatically replaced by new ids during deserialization.

Best Regards,
Gaelle