Freigeben über

Hosting WF Workflow Designer in a Web Application

  • Artikel

The WF workflow designer is a very powerful tool for developers and non-developers who want to design workflow solutions. There is a desire in the community to host workflow designer in web applications and questions on how to achieve this keep on coming up. Ghenadie Plingau and I decided to write up a background and information regarding the task of hosting workflow designer in web application. We hope you find this useful.

The main reason why it is hard to host workflow designer in a web application is CLR Code Access Security.  Workflow designer uses reflection and needs full trust permission set to execute.  There are multiple ways to implement workflow authoring functionalities in a web application. The following are the options you have if you desire to achieve this:

  • Start from a fully trusted source. If you want to execute workflow assemblies from a web hosted user control, you can place all workflow designer assemblies on a share,altercode access securitypermissions and give full trust to the internet zone. For more information about how to alter CAS check MSDN article here. Thismay bean unacceptable solution for intranet applications.
  • Install the hosting application locally. If you don't want to alter CAS but still need the full workflow designer functionality, you will need to have the workflow designer assemblies installed locally and then execute them on local machine. If you go this route, you're fundamentally hosting the workflow designer in a windows application locally installed that gets launched from a link in IE.
  • Use Ajax designer. If you want to execute the workflow assemblies on the server side, as people expect in web applications, you will lose most of the workflow designer functionality. As a result, you will need to rewrite some of the workflow designer functionality (drag and drop, condition editors, etc) and either display an image of the workflow on the client side as Jon Flanders describes here, or redraw the activity tree yourself as Ghenadie did here on https://www.netfxlive.com/. In this case, the workflow designer assemblies are running on the server. The browser on client side is making use of full trust mode on the server by invoking server side methods using AJAX calls.  Components like workflow compiler, activity validators, rules engine, condition parser, expression validator, etc are running on server. The XOML serialization happens on client and validated on server at compile time. Activity bind and custom activities are also validated at compile time on the server. Drag and drop, condition dialog and activity bind dialogs are running on client. This is assuring a fairly good UI responsiveness and is a good distribution model. Workflow designer is making use of html element hierarchy already implemented in browser. Drag/drop actions are actually dynamic modifications of html code. During serialization, each activity produces a xoml node and workflow xoml is assembled from html element tree. Resulted xoml is later validated on server side during compilation.

The following are related forums post on this issue:

https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=147319&SiteID=1

https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=190987&SiteID=1

https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=621636&SiteID=1

Comments

  • Anonymous
    January 17, 2007
    The stuff above is really good. Specially the one on workflow assemblies on AJAX.