匯出 (0) 列印
全部展開

Using Workflow Persistence in Windows Azure

Using persistence to create long-running workflows is one of the key features of Windows Workflow Foundation (WF). When creating Workflow solutions that run in Windows Azure, there are several options for persistence. The same SqlWorkflowInstanceStore used by on-premise workflow applications can be used in the cloud with a few modifications. To save storage costs, and to have more control over the location and duration of stored information, a custom persistence provider that writes to file, table, or blob storage can be used.

Using SqlWorkflowInstanceStore

The most basic solution for using workflow persistence in the cloud is to use the same SqlWorkflowInstanceStore used by on-premise solutions. While SQL storage is more expensive than using blob or file storage, it also provides a number of views that take advantage of SQL Azure’s relational structure. These views can be used to monitor currently executing workflows. Additionally, unlike a custom file, blob, or table instance store, the SqlWorkflowInstanceStore is provided out-of-box and doesn’t need to be developed and maintained by the solution architect.

note附註
To use SqlWorkflowInstanceStore in the cloud, the persistence database needs to be created by the database scripts provided in .NET Framework 4, version 4.0.1 or later.

Persisted data is normally deleted when an instance completes, but data can be retained by setting the InstanceCompletionAction to DeleteNothing.

Using a local file storage provider

Since local file storage in the cloud is temporary and instance-relative, a file storage provider should only be used for very short-term persistence of volatile data. If the virtual machine supporting the role that spawned the workflow is recycled, then all the persisted data are lost; if the workflow is resumed by a different virtual machine, then the previously persisted data will be inaccessible. For information on creating a custom persistence participant and instance store, see How To: Create a Custom Persistence Participant and How To: Create a Custom Instance Store.

To retain persisted data after an instance completes, the persistence participant’s SaveWorkflowCommand should be written to retain the persisted data in the instance store.

Using a blob or table storage provider

Creating a custom persistence provider that uses Azure storage (either blob or table) allows the application to take advantage of the lower per-Gb cost of Azure storage over SQL Azure, but the application would lose the ability to use relational queries to determine workflow status. For information on creating a custom persistence participant and instance store, see How To: Create a Custom Persistence Participant and How To: Create a Custom Instance Store.

To retain persisted data after an instance completes, the persistence participant’s SaveWorkflowCommand should be written to retain the persisted data in the instance store.

Using on-premise storage

Geopolitical or other policy concerns may demand that data be stored within a specific country, or only on the premises of a company. If these concerns are present, local storage can expose access through web services that Azure processes can access via the Service Bus, or through Virtual Networks. For the geographic location of Windows Azure datacenters, see Privacy.


建置日期:

2013-10-23

社群新增項目

顯示:
© 2014 Microsoft