Lars Fløe Nielsen

Very often I’m asked if it’s possible to hook in, - or trigger remote workflow engines from within Sitecore. There are several of approaches to do so. This is the two most common methods:

1. Workflow action
   Build a .NET class and hook them into the workflow as an action. The workflow event, e.g. when entering the “editing state” of a workflow, will trigger the remote workflow engine, such as a BizTalk orchestration, K2 or WWF.
   
   The Sitecore workflow API also allow you to change the state of the content item, e.g. move it to a new state, the remote engine can set new states in Sitecore such as the “done state”: To do so, you can use either the base .NET API or the Web API (for example Web Services)
    
   1. Advantages:
      1. Simple to implement: Cause workflow to invoke an action.
      2. Still maintains visualization in Sitecore. For example, you can use the workbox: The Sitecore workbox.
         
         
   2. Disadvantages:
      1. Involves a cross-workflow configuration as you will need to set up at least two steps in the Sitecore visualization (state that activates remote engine, and state that sets the item in “ready for publishing” state
         
         
2. Workflow provider
   You can build your custom workflow provider, fully exchanging the Sitecore workflow class. To do so, implement the methods of the workflow class, and exchange the default workflow provider specified in the web.config file with your custom class.
   
   This is what you could consider the “real integration”.
   
   
   1. Advantages:
      1. Fully bypasses the Sitecore visualization state.
      2. May require fewer steps for binding Sitecore document types to a workflow (as you can configure the “bind document type to workflow” in the remote workflow engine).
         
         
   2. Disadvantages:
      1. Requires some complex coding as you should hook in features to hook remote workflow to a Sitecore item.
      2. Requires some coding to hook remote engine workflow state visualizations into the Sitecore shell (however, this is very often solved by loading the item as a frame, if  you can solve the challenge of authorization and authentication).

To be honest, i cannot recommend one approach for another. It's all about the level of integration you wish to execute