This article was last updated on November 6, 2009.
Did you know that your SaaSGrid application can use Windows Workflow Foundation? SaaSGrid even provides native support for the most popular aspect of Windows Workflow Foundation: database persistence.
This article describes how to use different features of Windows Workflow Foundation in your SaaSGrid application. Before reading this article, it is helpful to be familiar with Windows Workflow Foundation.
SaaSGrid Considerations
Windows Workflow Foundation (WF) uses a runtime engine, with a variety of runtime services to perform specific actions related to the workflow. The types of runtime services include a persistence service, scheduling service, tracking service, and so on. There are default implementations of these services included with WF.
The default implementations of these services are not compatible with SaaSGrid's deployment model. Microsoft designed the default implementations of their services to communicate directly with Microsoft SQL Server. Because SaaSGrid controls database deployment to handle SaaS concerns (e.g. multi-tenancy), we require SaaSGrid applications to be database provider agnostic so SaaSGrid's database provider can be used when the application is deployed on the cloud.
It is very easy to write custom implementations of runtime services and configure applications to use them. SaaSGrid provides a custom implementation of the persistence service that you can use to persist workflows in your SaaSGrid hosted database which is sufficient for most customers. SaaSGrid does not provide any custom implementations of other runtime services such as the tracking service. The rest of this article describes how to use our persistence service and guidelines for writing your own custom implementation of other runtime services.
SaaSGrid's Persistence Service
SaaSGrid provides a persistence service that you can use. All that is needed is to configure the engine to use it. The following example App.config file provides an example of this. Note the usage of the conditional configuration system to make it easy to develop and test your application locally.
Note that SaaSGrid's provided SQL persistence service requires the usage of an App.config section in the manner demostrated above, even though it is technically possible to configure runtime services via code. This manner of applying configuration is consistent with how we require you to configure services and classic database connectivity.
Developing your own Runtime Services
As previously mentioned, SaaSGrid does not provide an implementation for other runtime services that you may wish to take advantage of. Fortunately, it is very easy to write your own, and plenty of documentation is available on the MSDN Website.
The main thing to keep in mind when writing your runtime service's database connectivity is to use a configuration-based database provider and connection just as you would for any other code you write in SaaSGrid. In fact, you probably won't be the first person who wishes to use a different provider than SQL Server! There are many blog postings and sample code out there on how to create custom runtime services.
If you can share your experience about creating and using your own runtime service with SaaSGrid, please comment or post in our forums. We'd love to hear about it!
Closing Remarks
To summarize, Workflow Foundation's default implementation of runtime services won't run on SaaSGrid because they are programmed to use the Microsoft SQL Server database provider. SaaSGrid provides a native implementation of the most commonly used feature of Workflow Foundation, which is the persistence service, but you must configure your workflow engine to use it. It is easy to create your own implementations of other runtime services, but be sure to design them to be database provider agnostic and loaded by configuration as you would any SaaSGrid application.