# 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.

### Workflow

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 ).

### Workflow Components with IDs

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.

### More convenience

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.