Workflows hints
Error Management
In PRIMEUR Data Mover, no error management is required. The only exception is when the user explicitly wants the template to behave in a different way according to a return code, or to intentionally ignore a potential service task exception.
Remote failures on transports and commands are treated forcefully failing the instance itself! The instance can then be RESTARTED (the error instance becomes aborted and a new one will start from the beginning with the same set of variables and properties) or the single service task can be executed again with the RETRY (in this case only the service task that failed is scheduled, anything preceding it will not be re-executed).
Don't forget to set conditions on every branch coming out of an exclusive gateway.
Remember that any triggerable service task that gets a schedule RC that is not 0 will throw an exception! This is because otherwise, it would wait for an event that will never come since the schedule has failed. Therefore, always mark your triggerable service tasks with a throw exception and an error boundary event for proper management.
General modeling rules
In PRIMEUR Data Mover, VirtualBoxes can be seen as "labels" applied to a FileSet. They can be applied or removed with the Virtual Box bind and unbind service tasks and files having a specific VBox (VirtualBox LS service task) can be listed.
Moreover, templates that are triggered with VirtualBox Bind and Unbind operations can be created, so that instances can start from a Contract whenever another instance binds or unbinds that specific virtual box to a Fileset.
This is far more elegant and cleaner than a republish to trigger new instances/contracts!
When you're modeling a template, or configuring a service task, consider only the properties that are available in the "More" section on the right. You can ignore all the rest.
During the first versions of a template, place any logs you need for debugging purposes but remember to remove them when it is stable and running properly, ready for production usage.
Those service tasks are consuming resources to produce data that you can get from the "Workflow Instances" monitor section as well.
If you have used an SpLs like service task that has been executed, you'll find a resulting object which is a variable containing a List of ExternalFile objects, that you will cycle through with a SubProcess shape. That subprocess is the only shape where you configure its "Multi instance" properties: Remember to use MI sequential to avoid unexpected behaviors.
Shapes without Primeur logo
The suggested shapes that do not contain the Primeur logo are not many. Stick to them since there is no apparent scenario where they are not enough to perform... anything! Here's the list of the good ones:
Start event
Subprocess
Timer boundary event
Error boundary event
Exclusive gateway
Parallel gateway
Inclusive gateway
End event
Sequence flow
Last updated
