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 is managed using the standard TransactionScope activity – consult a Windows Workflow Foundation reference for further details.
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.
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.
Visual Studio methods can be exposed to the Workflow, for example for use by the Rules engine, by specifying the
BlueIntegrator.Workflow.MethodVisible attribute. In the case of the Rules engine, rules attributes may also be specified. VSTA properties cannot be exposed to the Workflow, only methods.