Workflow components

Workflow components

At the heart of the workflow engine lies the WorkflowComponent. A workflow component represents a part of a generator process. Such parts are typically model parsers, model validators, model transformers and code generators. MWE ships with different workflow components which should be used where suitable, but you can also implement your own. The only thing you have to do is to implement the org.eclipse.emf.mwe.core.WorkflowComponent interface:

public interface WorkflowComponent {

	/**
	 * @param ctx
	 * 		current workflow context
	 * @param monitor
	 * 		implementors should provide some feedback about the progress
	 * 		using this monitor
	 * @param issues
	 */
	public void invoke(WorkflowContext ctx, ProgressMonitor monitor, Issues issues);

	/**
	 * Is called by the container after configuration so the
	 * component can validate the configuration before invocation.
	 *
	 * @param issues -
	 * implementors should report configuration issues to this.
	 */
	 public void checkConfiguration(Issues issues);

}

The invoke() operation performs the actual work of the component. checkConfiguration is used to check whether the component is configured correctly before the workflow starts. More on these two operations later.

A workflow description consists of a list of configured WorkflowComponents. Here is an example:

<workflow>
	 <component class="my.first.WorkflowComponent">
			<aProp value="test"/>
	 </component>
	 <component class="my.second.WorkflowComponent">
			<anotherProp value="test2"/>
	 </component>
	 <component class="my.third.WorkflowComponent">
			<prop value="test"/>
	 </component>
</workflow>

The workflow shown above consists of three different workflow components. The order of the declaration is important! The workflow engine will execute the components in the specified order. To allow the workflow engine to instantiate the workflow component classes, WorkflowComponent implementations must have a default constructor.

A workflow is just a composite implementation of the WorkflowComponent interface. The invoke and checkConfiguration methods delegate to the contained workflow components.

The Workflow class declares an addComponent() method:

public void addComponent(WorkflowComponent comp)</para>

which is used by the workflow factory in order to wire up a workflow (see next section Workflow Configuration ).

If you want your workflow components to have an ID (so that you can recognize its output in the log) you have to implement the interface WorkflowComponentWithID and the setID() and getID() operations. Alternatively, you can also extend the base class AbstractWorkflowComponent, which handles the ID setter/getter for you.

There is another base class for workflow components called AbstractWorkflowComponent2. Its main feature is, that it has a property called skipOnErrors. If set to true, it will not execute if the workflow issues collection contains errors. This is convenient, if you want to be able to skip code generation when the preceding model verification finds errors. Note that instead of implementing invoke(...) and checkConfiguration(...), subclasses of AbstractWorkflowComponent2 have to implement invokeInternal(...) and checkConfigurationInternal(...). This is necessary to allow the framework to intercept the invocation and stop it when there are errors in the workflow.