MSDN: Debugging SharePoint Server 2013 workflows
Microsoft has taken a different approach to workflows in SharePoint Server 2013 than in previous versions of SharePoint. The workflow team worked with the Windows Azure team to create a new product called Workflow Manager. Workflow Manager hosts the latest version of the Windows Workflow Foundation runtime and all the necessary services in an available and scalable way. It takes advantage of the Windows Azure Service Bus for performance and scalability, and when deployed, it runs exactly the same in an on-premises deployment as in the cloud, similar to Office 365. SharePoint 2013 is then connected and configured to hand off all workflow execution and related tasks to the Workflow Manager farm. This change in the architecture required some changes to the two primary workflow authoring tools (SharePoint Designer 2013 and Visual Studio 2012) customers used to create custom workflows. However, the debugging techniques employed by developers in SharePoint 2007 and SharePoint 2010 still apply. The new architecture allows for a new option for workflows created using either SharePoint Designer 2013 or Visual Studio 2012 in that Fiddler can be used to monitor traffic between SharePoint Server 2013 and Workflow Manager.
MSDN: Working with the SharePoint 2013 Workflow Services Client Side Object Model
This article touches on one of the things that Microsoft added to SharePoint 2013 to support the new style of creating custom workflow forms: the improvements to the CSOM and addition of the Workflow Services CSOM API.
SharePoint 2013 Workflow: Call an External Web Service
The sample workflow is bound to a list named Customers. After the user enters a value for CustomerID, they can manually run the workflow. The workflow uses the CustomerID to search for the customer using the public Northwind sample OData service (http://services.odata.org/Northwind/Northwind.svc/). When it finds the customer, it adds the details it retrieves from the service to the list item and then concludes.
SharePoint 2013 Workflow: Create a Custom Action
The sample workflow is bound to a list named Customers. After the user enters a value for CustomerID, they can manually run the workflow. The workflow uses the CustomerID to search for the customer using the public Northwind sample OData service (http://services.odata.org/Northwind/Northwind.svc/). When it finds the customer, it adds the details it retrieves from the service to the list item and then concludes. The part of the workflow that calls the web service and extracts the details from the response is contained within a custom activity.
SharePoint 2013 Workflow: Route Workflows to States Depending on Actions & Events
This sample allows a company, such as a cable company, to better manage is fleet of vehicles. A fleet manager workflow instant starts when a new vehicle is added to the fleet (as an item in a SharePoint list). Three months (simulated in the sample as three minutes, but easily changed) following the last maintenance cycle, the workflow instance takes the vehicle out of service and assigns a task to the maintenance department to do an oil change. When the task is completed, the vehicle is put back in service. If out-of-cycle maintenance is required on a vehicle, the app allows users to enter a maintenance request. This maintenance request page sends a custom event to the workflow to put the vehicle into maintenance.
SharePoint 2013 Workflow: Call a workflow in an app using a remote event receiver
This sample demonstrates two core concepts. First, it demonstrates how to create a remote event receiver that calls out to a remote service when a list item is created. It then demonstrates how the remote event receiver service can use the client object model (CSOM) to find a workflow association and start a new instance of the workflow on a specific list item while also passing values into the workflow.
SharePoint 2013 Workflow: Approval workflow that Uses a Custom Initiation Form
This basic workflow scenario supports a document review and approval/reject process. The workflow starts when a document is added to a specified “Drafts” SharePoint library. The workflow assigns a task to a reviewer, who evaluates the draft, makes comments as necessary, and then concludes the task by either routing the document back to the writer for revisions, or forwarding it to the editor for editing and release. Additional tasks are assigned, depending on the branch. If the document was returned to the writer for revisions, the writer completes the revision task, and the workflow loops back to the reviewer. When the document is forwarded to the editor, the task completion adds the finished doc to another document library named “manuscripts.”