Member Serialization

By default, any data members defined in the Visual Studio for Applications ThisWorkflow class associated with a Workflow are not guaranteed to be persisted across Workflow Activities.  That is, they may get reset to their default value between calls.  Generally this isn’t an issue, as we recommend state is stored in Workflow Messages and Variables, however if required the state of the Visual Studio for Applications ThisWorkflow class can be stored by simply marking it with the Serializable attribute.  Once this attribute has been specified, any data members defined in your class must themselves by serializable or marked with the NonSerialized attribute in order for your project to compile.

If this route is taken, any currently running Workflows are likely to fail if the class structure is changed whilst they are running.

Transactioning

Transactioning is managed using the standard TransactionScope activity – consult a Windows Workflow Foundation reference for further details.

Workflow Nesting

The nesting of Workflows is achieved using the CallSmartsWorkflow activity, or the standard InvokeWorkflow activity if you want to invoke an external Workflow.  Note that Workflow assembly references are added via Visual Studio for Applications.

Calling WCF and Web Services

Web Services can be invoked via the CallWebServiceDirect activity, or via the standard Windows Workflow Foundation web service activities if you have added a service reference via Visual Studio for Applications.  You can also call a web or WCF service via a Send Port, or you can call it directly from Visual Studio for Applications code.

Exposing Visual Studio for Applications Methods

Visual Studio methods can be exposed to the Workflow, for example for use by the Rules engine, by specifying the BlueIntegrator.Workflow.MethodVisibl attribute.  In the case of the Rules engine, rules attributes may also be specified.  VSTA properties cannot be exposed to the Workflow, only methods.