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.