This is the 2nd part of the previous post Some tips for new vCO plug-in developers (I). These tips are more focused on the workflows than on the plug-in project itself.

 

Again I've grouped them by type.

 

Workflows & Actions

  • Start developing workflows as building blocks

A building block would be a simple workflow that requires some few input parameters and returns some simple output. If we have a rich (and good) set of building blocks it will be much easier to create higher-level workflows and we will offer the users a better set of tools to compose their own complex workflows.

Create higher-level workflows based on smaller components

If we have to develop some complex workflow with lots of inputs and internal steps, it will be useful if we can split it in smaller and simpler building block workflows and actions.

  • Create actions whenever it's possible, for example:
    • To create complex objects or parameters (for scripting methods) easily.
    • To avoid repeating common pieces of code all the time.
    • To perform some UI validations.
  • Workflows should invoke actions whenever it's possible

Furthermore actions can be invoked directly as a node inside the workflow schema. This can keep the workflow schema more clear, because we don't need to add scripting code blocks just to invoke a single action.

  • Fill in the expected information (and it's always easier at creation time!):
    • Description of the workflow/action
    • Description(s) of the input parameter(s)
    • Description(s) of the output(s)
    • Description of the attributes (for the workflows)
  • Keep the version information updated, especially with meaningful comments after modifications (e.g. bug numbers).

Workflow internals

  • It's always recommended to implement some workflow for monitoring long-time running operations (e.g. task monitoring). That workflow will be based on vCO triggers and waiting events. Again, we have to consider that a workflow that is blocked waiting for a task can be resumed as soon as the vCO server starts, and the plug-in must be able to get all the required information to resume the monitoring process properly.
  • Ideally that workflow for monitoring (or the task that it may use internally) should provide a mechanism to specify somehow the pooling rate and a possible timeout.
  • It's not easy to debug a piece of scripting code inside a workflow, especially if this code doesn't invokes any Java code. Because of that sometimes the only option is to use the logging methods offered by the default vCO scripting objects.

Workflow presentation

  • Use the appropriate properties for the inputs
    • “Mandatory”: obvious!
    • “Show in Inventory” (for objects): to help the user to run a workflow from the inventory view by clicking with the right button on it.
    • “Specify a root object to be shown in the chooser” (for objects): to help the user to choose inputs easily. If the root object can be refreshed in the presentation (or it's an attribute of an attribute of… or it's retrieved by an object method) we'll need to create/set an appropriate action to do it.
    • “Maximum string length”: for commonly long strings (e.g. names, descriptions, file paths, etc.).
    • “Minimum string length”: to avoid empty strings from the QA testing tools!
    • “Custom validation”: non-simple validations must be implemented with actions.
    • Any other kind of property should be considered as well!
  • Organize the inputs with “Steps” and “Display group”

That will help the user to identify and distinguish all the input parameters of a workflow.