Business process modeling has many of the same characteristics as the traditional procedural programming model such as C... more

Business process modeling has many of the same characteristics as the traditional procedural programming model such as C#. However, it also exhibits characteristics that are fundamentally different from the traditional procedural programming model. This mismatch between the two models has always been the main stumbling block in workflow programming. This chapter first covers those characteristics that business process modeling has in common with the traditional procedural programming model such as C#. Then it dives into their main differences. Finally, the chapter discusses different types of custom activities that you can develop and shows you how to implement each type of custom activity.

... less

The previous chapter provided you with an overview of activity development. It also briefly showed you how to implement a... more

The previous chapter provided you with an overview of activity development. It also briefly showed you how to implement a workflow that uses your custom activities. This chapter provides the details of SharePoint workflow programming.

... less

SharePoint workflow programming is built on top of Windows Workflow Foundation (WF). One of the great things about WF is... more

SharePoint workflow programming is built on top of Windows Workflow Foundation (WF). One of the great things about WF is its extensibility model, which enables it to work in different hosting scenarios. This chapter begins by taking you under the hood of the SharePoint workflow programming infrastructure to help you see how SharePoint takes full advantage of the WF extensibility model. Then I'll dive into the details of the SharePoint-specific external data exchange services that SharePoint registers with the workflow run time when it starts the run time. These services play a central role in SharePoint workflow programming. Finally, you’ll learn how to implement custom composite activities that take advantage of these services.

... less

As shown in a previous chapter, SharePoint provides four external data exchange service interfaces: ITaskService, ISharePointService... more

As shown in a previous chapter, SharePoint provides four external data exchange service interfaces: ITaskService, ISharePointService, IListItemService, and IWorkflowModificationService. A workflow can use CallExternalMethodActivity to invoke the methods of these SharePoint external data exchange services, and HandleExternalEventActivity to wait for these services to fire their events.

The main problem with CallExternalMethodActivity and HandleExternalEventActivity is that they are not strongly typed. As such, they expose generic properties such as InterfaceType, MethodName, and EventName that must be set in a weakly typed manner. SharePoint comes with a standard set of activities that inherit from CallExternalMethodActivity and HandleExternalEventActivity that enable you to invoke the methods of standard SharePoint external data exchange services and to respond to the events of these standard services in strongly typed fashion.

This chapter covers those SharePoint activities that inherit from CallExternalMethodActivity. The next chapter covers those SharePoint activities that inherit from HandleExternalEventActivity.

... less

This chapter provides in-depth coverage of those SharePoint activities that inherit from HandleExternalEventActivity. You... more

This chapter provides in-depth coverage of those SharePoint activities that inherit from HandleExternalEventActivity. You will also learn how to use these activities to implement your own custom SharePoint workflows.

... less

This chapter covers the following three SharePoint workflow programming topics:... more

This chapter covers the following three SharePoint workflow programming topics:

• SPWorkflowManager

• Workflow Security

• Fault Handling

... less

This chapter covers the following two SharePoint workflow programming topics:... more

This chapter covers the following two SharePoint workflow programming topics:

• Workflow modification

• Workflow task editing

... less

Office SharePoint Designer 2007 enables workflow designers to develop workflows in purely graphical fashion without any code... more

Office SharePoint Designer 2007 enables workflow designers to develop workflows in purely graphical fashion without any code. Office SharePoint Designer 2007 comes with a set of prebuilt actions and conditions that workflow developers can use out of the box. Oftentimes, modeling real-life business processes requires running custom code on the server that is not supported by any of the prebuilt actions and conditions shipped with Microsoft Office SharePoint Designer 2007.

This chapter shows you how to implement custom actions and conditions to encapsulate custom code, which can run on the server when these actions and conditions are executed, and how to import these custom actions and conditions to Office SharePoint Designer 2007 to enable workflow developers to use them in purely graphical fashion without any code.

... less

The previous chapter walked you through the implementation, deployment, and testing of an Office SharePoint Designer 2007... more

The previous chapter walked you through the implementation, deployment, and testing of an Office SharePoint Designer 2007 custom action and custom condition. As you saw, you must implement an .actions XML file to describe your custom WF activity and custom condition to Office SharePoint Designer 2007. You must use the workflow actions and conditions XML markup language to implement this XML file. In this chapter, we will dive into the details of this markup language.

An .actions XML document, like any other XML document, features a single XML element known as a document element. The document element in this case is an element named <WorkflowInfo>. This document element features a single optional attribute named Language. Set the value of this attribute to a language/culture pair:

<WorkflowInfo Language="en-us">

  . . .

</WorkflowInfo>

The <WorkflowInfo> document element features two child elements named <Actions> and <Conditions>. I discuss the <Conditions> element later in this chapter. The <Actions> element has two required attributes as follows:

• Sequential: Office SharePoint Designer 2007 displays this text in the rule designer sentence when users arrange two or more actions in sequential order. The default is “then.”

• Parallel: Office SharePoint Designer 2007 displays this text in the rule sentence when users arrange two or more actions in parallel. The default is “and.”

In the case of our example:

<WorkflowInfo Language="en-us">

  <Actions Sequential="then" Parallel="and">

    . . .

  </Actions>

</WorkflowInfo>

The <Actions> element supports two child elements named <Action> and <Default>. Use an <Action> element to describe your custom WF activity to Office SharePoint Designer 2007. The following sections cover the attributes and child elements of the <Action> element.

... less

The examples and recipes presented in the previous chapters did not use SharePoint solution packages for deployment. Instead... more

The examples and recipes presented in the previous chapters did not use SharePoint solution packages for deployment. Instead, they used a manual approach to make the steps involved in the deployment of SharePoint workflows explicit, so you can gain a better understanding of the process. For example, this manual approach requires you to directly create the required folders in the file system of the front-end web server and copy the required files into these folders.

This manual approach was taken for educational purposes. You should not use it to deploy your SharePoint workflows to a production machine because of its following downsides:

• The manual approach requires console access to the front-end web servers in the server farm. System administrators are very reluctant to provide such access to developers.

• This approach requires you to manually deploy the same deployment files to all front-end web servers in the server farm. This is prone to error and unmanageable in server farms that contain numerous web servers.

• The manual approach also requires you to manually deploy the same deployment files to all front-end web servers that will be added to the same server farm in the future. This is also prone to error and unmanageable.

Instead, you should use SharePoint solution packages. A SharePoint solution package automatically creates the specified folders and copies the specified files to these folders.

As you’ll see in this chapter, implementing a SharePoint solution package requires you to know what files you need to deploy and to which folders on the file system of each front-end web server in the server farm you should deploy them. Thanks to the manual approach taken in the previous chapters, you should now know what these files are and where they should be deployed. You’re now in a good position to dive into SharePoint solution packages.

... less