Creating a Workflow Using Visual Studio 2010 Share Point 2010

With our pluggable workflow service and external calculation engine up and running, we can create a basic workflow in Visual Studio that will send messages to the calculation engine. Our test workflow will be very simple; when a new item is added to a list, its title will be sent to the calculation engine. We will then be able to trigger a response manually from the calculation engine, which will be passed to the workflow. The workflow will log the response and complete.

  1. We can add our workflow to the WorkflowDemonstration solution that we created earlier. In Visual Studio, select Project | Add New Item. From the Add New Item dialog, select SharePoint | 2010 | Sequential Workflow. Name the new workflow External Calculation, as shown:
  2. Creating a Workflow Using Visual Studio 2010
  3. In the SharePoint Customization Wizard dialog, leave the default name as WorkflowDemonstration - External Calculation. We can see that the same types of workflow that are available in SharePoint Designer are also available for Visua Studio workflows: List Workflow and Site Workflow. Since we’re planning to use data in a list to trigger our workflow, set the type to List Workflow.
  4. Accept the default association settings. This will associate our workflow with the Products list that we created earlier. Click Finish to complete the process.

Using the Visual Studio Workflow Designer
When the workflow has been added to the project, the workflow designer tool will be displayed. You can see that its user interface is similar to the one we created earlier using Visio 2010. You can drag workflow activities from the toolbox on to the design surface to build up the workflow logic.
Our workflow needs five additional steps: CallExternalMethod, which can be found in the Windows Workflow v3.0 group in the toolbox; SetState, which can be found in the SharePoint Workflow group; HandleExternalEvent, which can be found in the Windows Workflow v3.0 group; LogToHistoryListActivity, which can be found in the SharePoint Workflow group; and CodeActivity, which can be found in the Windows Workflow v3.0 group. Drag the required activities onto the designer surface, as illustrated:

Using the Visual Studio Workflow Designer

Configuring Workflow Activities
You can see from the designer that a few of our activities have not been configured properly. This is indicated by the icon in the upperright corner of the activity control. Let’s work through them in sequence to set the appropriate configuration details. CallExternalMethodActivity Starting with callExternalMethodActivity1, when we select the activity we can see in the Properties pane that the values for InterfaceType and MethodName are invalid as shown. This activity is used to communicate with a pluggable workflow service and in our case will be used to invoke the SubmitCalculation method on our CalculationWorkflowService.

  1. The first property to configure is InterfaceType. This is the interface that we tagged earlier with the ExternalDataExchange attribute. Click the ellipsis to show the Browse and Select a .NET Type dialog. The IExternalCalculationService is already selected since it’s the only interface in our solution with the appropriate attribute. Click OK to use this.
  2. Now the MethodName property needs to be configured. From the drop-down list, select SubmitCalculation. The values in the drop-down list are populated from the InterfaceType by using reflection. Since SubmitCalculation is the only method on our interface, it is the only item in the list.
  3. Configuring Workflow Activities

  4. Once SubmitCalculation has been selected, a new property appears: product. The property is added automatically since it appears in the list of arguments for the SubmitCalculation method. For out test workflow, we’ll set this to the title of the list items on which the workflow has been started. Click the ellipsis to show the Bind dialog, an important part of the workflow designer because it allows us to bind properties to local variables or other properties. We can add new variables by selecting the Bind To A New Member tab if required. For our purposes, we need to bind the product property to the Title property of the current workflow item. Expand workflowProperties | Item | Title, and then click OK to store the binding.

SetStateActivity and CorrelationTokens Moving onto the setState1 activity, we can see that the CorrelationToken property is invalid. CorrelationTokens are an important aspect of WF workflows and are used to determine the scope of the activity. A CorrelationToken is simply a text value that is used to group activities and, more importantly, the properties that they use. If a workflow has a property named foo, for example, when a workflow activity with a correlation token of token A writes to the foo property, other workflow actions with a correlation token of token A will be able to read the value. However, if a workflow action with a correlation token of token B writes to the property, the actions with a token of token A will still see the original value, whereas actions with token B will see the new value. In effect, every property is actually an array with the correlation token being used as an indexer. When it comes to SharePoint workflows, this is particularly relevant when using Task activities. Set the CorrelationToken for setState1 to workflowToken with an OwnerActivityName of External_Calculation.

Adding Custom Status Values to SharePoint Although the configuration of the setState activity is now valid, it doesn’t quite do what we want it to. When a workflow is added to a list item in SharePoint, a new column is added to the appropriate list that shows the current state of the workflow. The setState activity allows us to specify the value that should appear in this list. In our case, we want to show the text Awaiting Calculation Result. Before we can display a custom value for workflow status, we need to let SharePoint know what our new value is. Workflow states are stored in SharePoint in a similar format to lookup values, so each state needs an ID and a text value. To add new states, we need only the text value, since SharePoint will automatically generate a new ID. We can add the text for the new state in the Elements.xml file that exists under our External Calculation workflow in the Solution Explorer pane. Add an ExtendedStatusColumnValues element to the MetaData element, as shown:

<MetaData><AssociationCategories>List</AssociationCategories><StatusPageUrl>_layouts/WrkStat.aspx</StatusPageUrl><ExtendedStatusColumnValues><StatusColumnValue>Awaiting Calculation Result</StatusColumnValue></ExtendedStatusColumnValues></MetaData>

With the text value for our new status added, we can now configure our setState activity to use it. Unfortunately, it’s not quite as simple as that though. SetState expects the ID of our new state, and since this will be generated by SharePoint when our workflow is installed, we don’t currently have a reference to the ID value. We can calculate the ID for our new state simply by adding one to the ID of the last state that SharePoint defines internally.

  1. Right-click the workflow designer and then select View Code to see the code behind for our workflow. Add the following field:
  2. public int AwaitingCalculationState = ((int) SPWorkflowStatus.Max);
    SPWorkflowStatus is an enumeration of the workflow states that SharePoint provides by default. Our new extended status column value will be assigned the next ID in the sequence, which we can retrieve using the SPWorkflowStatus.Max value. If we wanted to add more than one additional state, we could use SPWorkflowStatus.Max +1, SPWorkflowStatus.Max+2, and so on, to determine the IDs for subsequent states.

  3. We can now bind the State property of our SetState activity to our new AwaitingCalculationState field. HandleExternalActivity The next activity to configure is handleExternalEventActivity1. This activity listens for an event from a pluggable workflow service. It’s configured in much the same way as callExternalMethodActivity1.
  1. Set the InterfaceType to IExternalCalculationService, and then select CalculationComplete from the EventName drop-down.
  2. Since this is an event, we don’t need to specify any parameters. Although, since we’re interested in the CalculationResultArgs parameter that is passed with the event, we can bind this value to a local variable using the e property. Click the ellipsis to show the Bind dialog. This time, select the Bind To New Member tab and then add a new property with the name CalculationCompleteArgs, as shown. This binding will store the values passed with the event in a local variable called CalculationCompleteArgs that we’ll be able to use in subsequent workflow activities.

Configuring Workflow Activities
LogToHistoryListActivity We’ve now configured all the mandatory properties for our workflow. Before we deploy, we need to make one additional change. The logToHistoryListActivity1 action is not set up to log anything useful to the workflow history list. Since we want it to pick up the calculation result, we need to set a few properties.

  1. For HistoryOutcome, type Calculation Result.
  2. Using the Bind dialog, bind the HistoryDescription property to CalculationCompleteArgs.Result, as shown:

CodeActivity The CodeActivity can be used to execute arbitrary code within the workflow engine. Our workflow requires that, as a result of the external calculation process, the Environmental Compliance flag is set to true or false. For the purposes of our demonstration, we’ll assume that our organization manufactures only environmentally friendly products and that the result of the calculation always indicates compliance.

  1. To configure the CodeActivity for the ExecuteCode property, enter UpdateFlag.
  2. Press enter, and the designer switches to code-behind view and a new method is automatically created for UpdateFlag. Add the following code:
private void UpdateFlag(object sender, EventArgs e) { workflowProperties.Item[“Environmental Compliance"] = true; workflowProperties.Item.Update(); }

We’ve now completed our test workflow. When deploying the solution to SharePoint, our workflow will automatically be attached to the Product list With our DemoCalculationEngine project running, we can add new items to the Product list and see the messages being passed to our calculation engine as expected. Viewing the workflow history will also show that the status value is being updated as expected and the calculation result is being written to history before the workflow completes.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Share Point 2010 Topics