How to use the DevExpress Workflow Instance Store to be able to persist state information in more than a dozen of popular database systems

I have just created a new Code Central example, which  is based on the How to: Configure Persistence with WorkflowServiceHost and How to: Enable SQL Persistence for Workflows and Workflow Services help articles from MSDN.
I hope it will be helpful for non-XAF users longing to store the state of their workflow instances in databases other than Microsoft SQL Server (currently, creating a custom workflow instance store provider is not that straighforward).

The only difference is that in code you can use the DevExpress.Workflow.Store.WorkflowInstanceStoreBehavior class (it is a part of the DevExpress.Workflow.Activities library) instead of the standard SqlWorkflowInstanceStoreBehavior one.

If you want to enable persistence for self-hosted workflows that use WorkflowApplication programmatically by using the SqlWorkflowInstanceStore class, you can use the built-in DevExpress.Workflow.Store.WorkflowInstanceStore one (it is also a part of the DevExpress.Workflow.Activities library):

[C#]... using DevExpress.Workflow.Xpo; using DevExpress.ExpressApp.Xpo; using DevExpress.Workflow.Store; ... WorkflowInstanceStore dxWorkflowInstanceStore = new WorkflowInstanceStore( typeof(XpoWorkflowInstance), typeof(XpoInstanceKey), new XPObjectSpaceProvider(yourDatabaseConnectionString, null) );

 

If you configure it via the configuration file, use the DevExpressWorkflowInstanceStore element instead of the standard sqlWorkflowInstanceStore one.

Refer to the XAF Workflow persistence storage blog post for more information.

See also:
How to create a correct connection string for XPO providers?
eXpressApp Framework > Concepts > Extra Modules > Workflow Module

Nested vs Root ObjectSpace

I think that the information I've just posted in http://www.devexpress.com/issue=Q472381 will be helpful for new XAF users:

"When designing XAF many years ago we implemented the following behavior:
- if an object is aggregated (when this object is a part of a master object), a nested ObjectSpace is created for it, because this object should not be physically saved to the database until its owner is saved itself.
- if an object is not aggregated (when this object can exist separately), a separate ObjectSpace is used for it.

The same behavior is enforced when opening Views for existing objects, and not only for new ones.

This can be controlled via the virtual GetObjectSpaceToShowViewFrom method of the XafApplication class.
To learn more about ObjectSpace and Views in XAF, check out the following documentation:
http://documentation.devexpress.com/#Xaf/clsDevExpressExpressAppBaseObjectSpacetopic
http://documentation.devexpress.com/#Xaf/CustomDocument2611

P.S.
In Entity Framework, there is no such entity as NestedObjectSpace or UnitOfWork at all."