To create a declarative activity, you must have a development environment with SharePoint 2013 Server and Workflow Manager installed locally. On the same machine that houses SharePoint 2013, you must also install Visual Studio 2012 Professional or higher, as well as the Microsoft Office Developer Tools for Visual Studio 2012.

Imagine that you want to create a custom activity for consuming a list of customers from an external Representational State Transfer (REST) or OData service. For example, you can consume the publicly available OData service for reading the well-known Northwind database, which is available at http://services.odata.org/Northwind/Northwind.svc. To begin, launch Visual Studio 2012, create a new project of type SharePoint 2013 - Empty Project, and choose to produce a sandboxed solution. Next, add a new item of type Workflow Custom Activity to the project. You will be prompted with a workflow activity designer that already includes a Sequence activity.

The order-approval workflow needs to retrieve some data about the target customer of the order; it does so by querying the Northwind OData service using the CustomerID field. The REST URI for retrieving the customer data is http://services.odata.org/Northwind/Northwind.svc/Customers(’ALFKI’)?$select={CustomerID},CompanyName,ContactName,ContactTitle,Country.

Replace the {CustomerID} argument with the CustomerID value of the customer to look up. The JSON response of the Northwind OData service during a query for a specific customer instance shows the JavaScript Object Notation (JSON) result of the service invocation.

{
  "d" : {
    "__metadata": {
    "uri": 
    "http://services.odata.org/Northwind/Northwind.svc/Customers('ALFKI')",
    "type":"NorthwindModel.Customer"
  },
  "CustomerID": "ALFKI",
  "CompanyName": "Alfreds Futterkiste",
  "ContactName": "Maria Anders",
  "ContactTitle": "Sales Representative",
  "Country": "Germany"
  }
}

To implement the custom activity (call it NWCustomerLookup), you first need to create an input argument with name CustomerID to receive the ID of the customer to look for in the Northwind database. You also need a set of output arguments for holding the return values, which are all of type String; name them CompanyName, ContactName, ContactTitle, and Country.

To effectively contact the remote OData service, you can use the HttpSend activity, available in Visual Studio 2012. Simply provide the target URL, as well as the Accept HTTP header (application/json). To create the set of HTTP headers, use a BuildDynamicValue activity and put the output into a responseHeaders variable of type DynamicValue. You can place the response in a variable of type DynamicValue, as well. Table 18-1 shows the configuration provided to the main properties of the HttpSend activity.

By using the GetDynamicValueProperties activity, you can retrieve the fields and place them inside the specific output arguments. Figure 18-1 illustrates the outline of the custom declarative activity.

Figure 18-1. The outline of the custom declarative activity in the designer of Visual Studio 2012.

To deploy the custom activity, you need to do a little bit of work, which is covered in detail in the next section. For now, assume you have already deployed the custom declarative activity, and take a look at Figure 18-2 to see how the custom activity behaves in SharePoint Designer 2013.

Figure 18-2. The custom declarative activity in the designer of SharePoint Designer 2013.

The sample illustrated in Figure 18-2 defines a simple site workflow, which is defined just to test the custom declarative activity. As you can see, the activity is described using the following sentence:

Lookup for customer with CustomerID in Northwind (Output to: Variable: CompanyName, Variable:
ContactName, Variable: ContactTitle, Variable: Country).

The CustomerID token represents an input argument, while the CompanyName, ContactName, ContactTitle, and Country arguments are the output values that will be saved in workflow variables. Notice that inserting the action in the designer will automatically create the target variables for holding the output values. In the next section, you will learn how to achieve this automatic behavior.

From a deployment and provisioning viewpoint, workflow actions and activities are defined in specific files with an .actions4 extension, which vary by language and which can be installed onto the SharePoint servers in the folder SharePoint15_RootTEMPLATELanguage LCIDWorkflow. The Language LCID represents the locale ID of the target language. For example, the English (LCID: 1033) version of the .actions4 files will be installed in the folder SharePoint15_RootTEMPLATE1033Workflow.

In the same folder, you will also find some .actions files. However, those files are related to SharePoint 2010 and the legacy WF 3.x workflow engine, and you should not bother with them in this chapter. The .actions4 files can also be provisioned using sandboxed solutions, if you want to deploy custom declarative activities in Microsoft Office 365. A code excerpt of the workflow15.actions4 file for defining an action shows a code excerpt of the default workflow15.actions4 file, which contains the same out-of-the-box actions you saw while making your first workflow with SharePoint Designer 2013 in Chapter 16 A code excerpt of the workflow15.actions4 file for defining an action defines the native Set Field in Current Item action.

<Action Name="Set Field in Current Item"
  ClassName="Microsoft.SharePoint.WorkflowServices.Activities.SetField"
  AppliesTo="list" UsesCurrentItem="true" Category="List Actions">
  <RuleDesigner Sentence="Set %1 to %2">
    <FieldBind Field="FieldName" Text="field" Id="1"
        DesignerType="WritableFieldNames" DisplayName="Field" />
    <FieldBind Field="FieldValue" Text="value" Id="2"
        TypeFrom="FieldName" DesignerType="Dependent" DisplayName="Value" />
  </RuleDesigner>
  <Parameters>
    <Parameter Name="FieldName" Type="System.String, mscorlib" Direction="In"
        DesignerType="WritableFieldNames" 
        Description="Field to set the value of." />
    <Parameter Name="FieldValue" Type="System.Object, mscorlib" Direction="In"
        DesignerType="Dependent" Description="Value to set the field to." />
  </Parameters>
</Action>

As you can see, the excerpt defines an Action element, which is the root element for any action definition. This element requires a ClassName attribute, which defines the underlying .NET type that effectively implements the action. The most common attributes of the Action element are illustrated in Table 18-2.

The main child elements of the Actions element are RuleDesigner and Parameters. The former defines the behavior of the custom action within SharePoint Designer 2013, and declares the sentence to prompt to the user designing the workflow, as well as any field to ask for. Reading A code excerpt of the workflow15.actions4 file for defining an action, you can see that the RuleDesigner element accepts a Sentence attribute, which defines a tokenized string. For example, the sentence for the Set Field in Current Item action is the following:

Set %1 to %2

where %1 and %2 correspond to two occurrences of children FieldBind elements. Every FieldBind element defines a field that matches a token in the sentence. The FieldBind element accepts a wide range of attributes, which are illustrated in Table 18-3.

The Parameters element of the .actions4 file behaves similarly to the RuleDesigner element. In fact, the Parameters element is the parent of a set of Parameter elements, where each one describes a single parameter with a direction (input, output, or optional), name, type, and designer behavior. Table 18-4 lists the main attributes available for configuring each Parameter element.

Each Parameter element can be referenced by name in the FieldBind elements. In The content of the NWCustomerLookup.actions4 file for defining the NWCustomerLookup declarative activity, you can see the NWCustomerLookup.actions4 file, which defines the custom NWCustomerLookup declarative activity you created in the previous section.

<Action Name="Northwind customer lookup"
  ClassName="DevLeap.SP2013.DeclarativeAction.NWCustomerLookup" Category="DevLeap" AppliesTo="all">
  <RuleDesigner
 Sentence="Lookup for customer with %1 in Northwind (Output to: %2, %3, %4, %5)">
    <FieldBind Field="CustomerID" DesignerType="TextBox" Id="1" Text="CustomerID"
      DisplayName="CustomerID" />
    <FieldBind Field="CompanyName" DesignerType="ParameterNames" Id="2" Text="CompanyName" DisplayName="CompanyName" />
    <FieldBind Field="ContactName" DesignerType="ParameterNames" Id="3" Text="ContactName" DisplayName="ContactName" />
    <FieldBind Field="ContactTitle" DesignerType="ParameterNames" Id="4"
      Text="ContactTitle" DisplayName="ContactTitle" />
    <FieldBind Field="Country" DesignerType="ParameterNames" Id="5" Text="Country" DisplayName="Country" />
  </RuleDesigner>
  <Parameters>
    <Parameter Name="CustomerID" Type="System.String, mscorlib" Direction="In"
      DesignerType="TextArea" Description="The ID of the customer to lookup" />
    <Parameter Name="CompanyName" Type="System.String, mscorlib" Direction="Out"
      DesignerType="ParameterNames" 
Description="The ID of the customer to lookup" />
    <Parameter Name="ContactName" Type="System.String, mscorlib" Direction="Out"
      DesignerType="ParameterNames" 
Description="The ID of the customer to lookup" />
    <Parameter Name="ContactTitle" Type="System.String, mscorlib" Direction="Out"
      DesignerType="ParameterNames" 
Description="The ID of the customer to lookup" />
    <Parameter Name="Country" Type="System.String, mscorlib" Direction="Out"
      DesignerType="ParameterNames" 
Description="The ID of the customer to lookup" />
  </Parameters>
</Action>

To deploy the current custom activity, you simply need to package the resulting WSP file and upload the sandboxed solution to the target site collection. Visual Studio 2012 already does this for you, and also creates an .actions4 file in the project. That .actions4 file will be almost empty, however, so you will have to compile it manually, and without any kind of IntelliSense or syntax check. In case you are creating a declarative activity within a sandboxed solution, the .actions4 file, the XAML file, and any other elements are deployed to the content database of the target site collection through a sandboxed solution. Because you don’t need physical access to the file system of the target server farm, the declarative activities are the first choice for extending native activities in the context of a Office 365 cloud-hosted solution.

While compiling the .actions4 file, you must provide values for a variety of settings. For example, the DesignerType attribute accepts a long list of possible values. The most interesting and frequently used of these values are the following:

A code activity, which is suitable only for on-premises scenarios, can be based on one or more code files. Let’s start with a simple example of a custom credit card validator activity. You can inherit from the base CodeActivity<T>, where the type of T will be Boolean and will return true if the argument named CreditCard, which is of type InArgument<String>, represents a real credit card number.

Create a new Visual Studio 2012 project of type Activity Library and add a new item of type Code Activity with the name CreditCardValidationActivity. The code template for a code activity item already includes a property of type InArgument<String> and overrides the Execute method of the base CodeActivity class. Change the base class of the CreditCardValidationActivity class to inherit from CodeActivity<Boolean>, and refresh the signature of the method overriding the Execute method of the base class. Now you are ready to implement the business logic of the custom code activity. The source code of the custom code activity for validating credit card numbers provides the code for implementing the custom activity, which internally uses the .NET 4.5 data validation framework to check the credit card number. For this purpose, you will need to reference the assembly System.ComponentModel.DataAnnotations with version 4.0.0.0.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Activities;
using System.ComponentModel.DataAnnotations;
namespace DevLeap.SP2013.CustomActivities {
    public sealed class CreditCardValidationActivity : CodeActivity<Boolean> {
        [RequiredArgument]
        public InArgument<String> CreditCard { get; set; }
        protected override bool Execute(CodeActivityContext context) {
            CreditCardAttribute cc = new CreditCardAttribute();
            return (cc.IsValid(this.CreditCard.Get(context)));
        }
    }
}

As you can see, the custom code activity itself is very simple, in order to keep the focus on implementation and deployment.

You can define a real custom activity with all the arguments that you like, whether they are of type InArgument<T>, OutArgument<T>, or InOutArgument<T>. You can implement the business logic with as much complexity as you like, but sooner or later you will need to deploy the activity.

The first step is still the creation of an .actions4 file. The content of the CreditCardValidationActivity.actions4 file for defining the CreditCardValidationActivity contains the .actions4 file for the CreditCardValidationActivity.

<?xml version="1.0" encoding="utf-8" ?>
<WorkflowInfo Language="en-us">
  <Actions>
    <Action Name="Validate Credit Card"
        ClassName="DevLeap.SP2013.CustomActivities.CreditCardValidationActivity"
        Assembly="DevLeap.SP2013.CustomActivities, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bbaf2a8a1431fb28"
        Category="DevLeap" AppliesTo="all">
      <RuleDesigner Sentence="Validate credit card number %1 (Output to: %2)">
        <FieldBind Field="CreditCard" DesignerType="TextBox" Id="1" Text="CreditCard" DisplayName="CreditCard" />
        <FieldBind Field="ValidationResult" DesignerType="ParameterNames" Id="2"
            Text="Result" DisplayName="Result" />
      </RuleDesigner>
      <Parameters>
        <Parameter Name="CreditCard" Type="System.String, mscorlib" 
        Direction="In"
            DesignerType="TextArea" Description="The credit card number" />
        <Parameter Name="ValidationResult" Type="System.Boolean, mscorlib" 
        Direction="Out"
            DesignerType="ParameterNames" Description="The validation result" />
      </Parameters>
    </Action>
  </Actions>
</WorkflowInfo>

As you can see, the file is almost the same as the one defined in The content of the NWCustomerLookup.actions4 file for defining the NWCustomerLookup declarative activity. However, this time, the Action element is wrapped in an Actions parent element, and the XML file has a WorkflowInfo root element. Moreover, the Action element declares the Assembly attribute, which references the strong name of the assembly providing the custom activity class. The assembly will need to be strongly named, because it will have to be deployed in the GAC (Global Assembly Cache) of the SharePoint servers. This time, the custom .actions4 file will go to the file system, not to the content database of the target site collection through a sandboxed solution.

While developing custom code activities, you must define a second XML file, called AllowedTypes.xml, which declares the types allowed for loading in the Workflow Manager engine. The AllowedTypes.xml file defined for the CreditCardValidationActivity defines that file for the sample CreditCardValidationActivity class.

<?xml version="1.0" encoding="utf-8" ?>
<AllowedTypes>
  <Assembly Name="DevLeap.SP2013.CustomActivities">
    <Namespace Name="DevLeap.SP2013.CustomActivities">
      <Type>CreditCardValidationActivity</Type>
    </Namespace>
  </Assembly>
</AllowedTypes>

The file is simple, and declares the assembly, namespace, and class name of the types allowed to run in the workflow engine.

The following are the steps for deploying the custom code activity to Workflow Manager.

In the case of multiserver deployment, you must execute the preceding steps on each server of the farm.

Now you are ready to play with your new custom activity in SharePoint Designer 2013.

Because some of the files have to be copied outside of the SharePoint15_Root path (that is, C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions15), you cannot create an automated setup-and-deployment process that uses a WSP file. Unfortunately, you will need to create a PowerShell file, or something similar, to replicate and automate the installation process. Nevertheless, for the SharePoint side of the deployment, you can use a farm-level solution—which will be capable of deploying the assembly to the GAC—to copy the .actions4 file to the Workflow folder of SharePoint 2013, as well as to recycle the IIS application pool process.

After deploying the custom code activity, you will be able to find it in SharePoint Designer 2013, as shown in Figure 18-3 (see the red outline).

Figure 18-3. The custom code activity in the list of available actions in the designer of SharePoint Designer 2013.

Figure 18-4 shows the behavior of the custom code activity in SharePoint Designer 2013. From an end-user viewpoint, a custom activity is presented the same way whether it is declarative or code based. Behind the scenes, however, the deployment process is different, and the potentials are completely different, too. While a declarative action can use already existing actions only, a code-based activity can do whatever you want, because it uses custom code.

Figure 18-4. The custom code activity in the designer of SharePoint Designer 2013.

Let’s investigate how to use this new API while working on the client side. To execute the necessary code excerpts, first create a new console application in Visual Studio 2012 and reference at least the following assemblies:

To practice working with the Workflow Services Manager API, take a look at how to accomplish such common tasks as retrieving the workflow definitions associated with a target list or library, associating a workflow with a target, terminating a workflow, and publishing a custom workflow through XAML.

For example, A CSOM code excerpt for retrieving the list of workflow definitions associated with a target library enumerates the workflows associated with a specific target library.

private static void EnumerateWorkflowSubscriptions() {
    ClientContext ctx = new 
ClientContext("http://devbook.sp2013.local/sites/Workflows/");
    Web web = ctx.Web;
    ctx.Load(web);
    List documents = web.Lists.GetByTitle("Documents");
    ctx.Load(documents);
    ctx.ExecuteQuery();
    WorkflowServicesManager wfManager = new WorkflowServicesManager(ctx, web);
    WorkflowSubscriptionService subscriptionService =
        wfManager.GetWorkflowSubscriptionService();
    ctx.Load(subscriptionService);
    WorkflowSubscriptionCollection subscriptions =
        subscriptionService.EnumerateSubscriptionsByList(documents.Id);
    ctx.Load(subscriptions);
    ctx.ExecuteQuery();
    foreach (var s in subscriptions) {
        Console.WriteLine("******************************************");
        Console.WriteLine("Id: {0}", s.Id);
        Console.WriteLine("Name: {0}", s.Name);
        Console.WriteLine("DefinitionId: {0}", s.DefinitionId);
        Console.WriteLine("Enabled: {0}", s.Enabled);
        Console.WriteLine("EventSourceId: {0}", s.EventSourceId);
        Console.WriteLine("EventTypes");
        foreach (var e in s.EventTypes) {
            Console.WriteLine("EventType: {0}", e);
        }
        Console.WriteLine("ManualStartBypassesActivationLimit: {0}",
            s.ManualStartBypassesActivationLimit);
        Console.WriteLine("PropertyDefinitions");
        foreach (var p in s.PropertyDefinitions) {
            Console.WriteLine("Property: {0} - Value: {1}", p.Key, p.Value);
        }
        Console.WriteLine("StatusFieldName: {0}", s.StatusFieldName);
    }
}

Highlighted in bold, the code uses the Subscription service to retrieve the list of workflow subscriptions associated with the library with the title “Documents” in the target SharePoint site. Notice that the WorkflowServicesManager class must be created to provide the current instance of the ClientContext, as well as the target object of type Web. Through the WorkflowServicesManager class instance, you get access to the current Subscription service instance. In fact, the WorkflowServicesManager type provides all the useful entry points for using the whole Workflow Services Manager engine. Table 18-5 lists the main members of the WorkflowServicesManager type.

Each service type provides a rich set of methods and properties to manage deployment, instances, interoperability, subscriptions, and messaging.

For example in A CSOM code excerpt for retrieving the list of workflow definitions associated with a target library, the code excerpt retrieves an instance of the WorkflowSubscriptionService class, in order to get the currently defined subscriptions for a target library, using the EnumerateSubscriptionsByList method. Each subscription is represented by an instance of the WorkflowSubscription type, which can be used not only for reading a subscription, but also for associating a new subscription to a target. Later in this section, you will learn more about creating workflow associations. In Table 18-6, you can see the main members of the WorkflowSubscription type.

Through an instance of the WorkflowSubscriptionService class and with objects of type WorkflowSubscription, you can do many things. For example, the code excerpt of a workflow association page in A code excerpt taken from a workflow association page based on the JSOM takes advantage of the JSOM implementation of Workflow Services Manager to associate a workflow definition with a target.

function associateWorkflow() {
    ctx = SP.ClientContext.get_current();
    wfManager = SP.WorkflowServices.WorkflowServicesManager.newObject(ctx, 
ctx.get_web());
    var depService = wfManager.getWorkflowDeploymentService();
    subscriptionService = wfManager.getWorkflowSubscriptionService();
    ctx.load(subscriptionService);
    definitionId = $('input[name=WorkflowDefinition]').val();
    definitionName = $('input[name=WorkflowName]').val();
    taskListId = $('input[name=TaskListWF4').val();
    historyListId = $('input[name=HistoryList').val();
    allowManual = $('input[name=AllowManual').val();
    autoStartCreate = $('input[name=AutoStartCreate').val();
    autoStartChange = $('input[name=AutoStartChange').val();
    associatedListId = getUrlParams()["AssociatedList"];
    subscription = SP.WorkflowServices.WorkflowSubscription.newObject(ctx);
    subscription.set_definitionId(definitionId);
    subscription.set_name(definitionName);
    subscription.set_enabled(true);
    subscription.set_eventSourceId(associatedListId);
    // Define event types
    eventTypes = new Array();
    eventTypesIndex = 0;
    if (allowManual == "ON") {
        eventTypes[eventTypesIndex] = "WorkflowStart";
        eventTypesIndex = eventTypesIndex + 1;
    }
    if (autoStartCreate == "ON") {
        eventTypes[eventTypesIndex] = "ItemAdded";
        eventTypesIndex = eventTypesIndex + 1;
    }
    if (autoStartChange == "ON") {
        eventTypes[eventTypesIndex] = "ItemUpdated";
        eventTypesIndex = eventTypesIndex + 1;
    }
    subscription.set_eventTypes(eventTypes);

    // Configure Status Field Name
    subscription.set_statusFieldName("OrdersWorkflowStatus");
    subscription.setProperty("StatusColumnCreated", "1");

    // Configure properties
    subscription.setProperty("ApprovalTaskDueDays", 
    $("#ApprovalTaskDueDays").val());
    subscription.setProperty("ApprovalRequestMessage", 
        $("#ApprovalRequestMessage").val());
    subscription.setProperty("TargetApprover",  getUserKeys("peoplePicker"));
    // Workflow Tasks List
    subscription.setProperty("TaskListId", taskListId);

    // Workflow History List
    subscription.setProperty("HistoryListId", historyListId);

    // Publish the WorkflowSubscription
    subscriptionService.publishSubscriptionForList(subscription, 
    associatedListId);

    ctx.executeQueryAsync(
        function (sender, args) {
            redirFromInitForm();
        },
        function (sender, args) {
            alert("Something went wrong while associating workflow: " +
                args.get_message());
            redirFromInitForm();
        }
    );
}

To create a new instance of the WorkflowSubscription type, A code excerpt taken from a workflow association page based on the JSOM configures all the main properties (highlighted in bold) described in Table 18-6. The most important part of the code excerpt is the invocation of the publishSubscriptionForList method, which accepts the subscription and the ID of the associated list or library. As you might guess from the name of the method, it is suitable only for publishing subscriptions for lists or libraries. If you want to publish a subscription for a site workflow, use the publishSubscription method instead.

Another interesting use case is the starting of a new workflow instance. First, to create a new instance of a workflow definition, use the GetWorkflowInstanceService method of the WorkflowServicesManager class to reference an object of type WorkflowInstanceService. Next, as you learned in Chapter 17, you can use the StartWorkflow or the StartWorkflowOnListItem methods. The WorkflowInstanceService class provides many other helpful members, as well. Table 18-7 lists the most commonly used methods.

For example, A CSOM code excerpt of a function that forcibly terminates all the workflow instances running on the items of a list contains a code excerpt of a function that forcibly terminates all the workflow instances running on the items of a target library.

private static void TerminateAllWorkflowInstances() {
    ClientContext ctx = new ClientContext(
    "http://devbook.sp2013.local/sites/Workflows/");
    Web web = ctx.Web;
    ctx.Load(web);
    List documents = web.Lists.GetByTitle("Documents");
    ctx.Load(documents);
    ctx.ExecuteQuery();
    WorkflowServicesManager wfManager = new WorkflowServicesManager(ctx, web);
    WorkflowInstanceService instanceService = wfManager.
    GetWorkflowInstanceService();
    ListItemCollection items = documents.GetItems(
    CamlQuery.CreateAllItemsQuery());
    ctx.Load(items);
    ctx.ExecuteQuery();
    foreach (ListItem item in items) {
        WorkflowInstanceCollection instances =
            instanceService.EnumerateInstancesForListItem(documents.Id, item.Id);
        ctx.Load(instances);
        ctx.ExecuteQuery();
        foreach (var instance in instances) {
            if (instance.Status == WorkflowStatus.Started ||
                instance.Status == WorkflowStatus.Suspended)
                instanceService.TerminateWorkflow(instance);
        }
        ctx.ExecuteQuery();
    }
}

The WorkflowDeploymentService class is also interesting. Through this service, you can deploy and manage the workflow definitions. Table 18-8 lists its main methods.

A CSOM code excerpt of a function that published the XAML of a workflow definition to the workflow store shows a code excerpt of a sample procedure for publishing the XAML of a workflow definition to the workflow store.

private static void PublishXamlWorkflowToWorkflowStore(String xaml) {
    ClientContext ctx = new 
    ClientContext("http://devbook.sp2013.local/sites/Workflows/");
    Web web = ctx.Web;
    ctx.Load(web);
    List documents = web.Lists.GetByTitle("Documents");
    ctx.Load(documents);
    ctx.ExecuteQuery();
    WorkflowServicesManager wfManager = new WorkflowServicesManager(ctx, web);
    WorkflowDeploymentService deploymentService =
        wfManager.GetWorkflowDeploymentService();
    var validationResult = deploymentService.ValidateActivity(xaml);
    ctx.ExecuteQuery();
    WorkflowDefinition definition = new WorkflowDefinition(ctx);
    definition.Xaml = xaml;
    definition.DisplayName = "Sample XAML based Workflow";
    definition.Description = "Workflow saved by code";
    deploymentService.SaveDefinition(definition);
    ctx.ExecuteQuery();
}

A CSOM code excerpt of a function that published the XAML of a workflow definition to the workflow store validates the XAML code, which is provided as an argument of type String to the sample PublishXamlWorkflowToWorkflowStore method, and then saves the workflow definition to the workflow store. After executing that code and providing a valid XAML workflow definition, you will find a new workflow definition available in SharePoint Designer 2013 for adding in the target SharePoint site.

The WorkflowInteropService class simply provides methods to start or cancel a legacy SharePoint 2010 and WF 3.x workflow instance. In particular, the StartWorkflow method accepts all the arguments useful to start a new workflow instance—which are the association name, the correlation ID, the target list ID, and the target item GUID—as well as any additional arguments or parameters for running the workflow. Meanwhile, the CancelWorkflow method accepts the GUID of the workflow instance to cancel. Lastly, the WorkflowMessagingService class, which is available only on the Server Object Model, provides the PublishEvent method, which allows publishing a message to the Service Bus, providing the GUID of the event source, the name of the event, and a collection of key/value pairs for providing a payload to the target subscribers of the event. Typically, the event source GUID should be the ID of the list, or of the site depending on the kind of workflow you are running, and the name of the event is the fully qualified name of the event.