Workflow Development in Share Point Designer

  • Published on
    29-May-2018

  • View
    213

  • Download
    0

Embed Size (px)

Transcript

  • 8/9/2019 Workflow Development in Share Point Designer

    1/3

    Workflow Development in SharePoint Designer

    Updated: May 2010

    When you author a workflow in a declarative rules-based, code-free workflow editor, such as Microsoft

    SharePoint Designer 2010, you are authoring that workflow directly against, and data-binding it to, a

    specific list or document library in Microsoft SharePoint Foundation 2010. You are using a predefined list

    of workflow activities, and are not using any code. The workflow you design is not compiled as an

    assembly, but is stored as source files until SharePoint Foundation 2010 compiles the workflow the first

    time it runs.

    This approach provides the following advantages:

    y Workflows can be developed and tested rapidly.y Because the workflow is specific to a given list, the following are simplified:

    o The deployment processo Security issues management

    y Because workflows are not compiled into assemblies, workflows created in a declarative rules-based, code-free workflow editor such as SharePoint Designer 2010 can be deployed to servers

    where administrative policy prohibits custom code assemblies.

    NoteWorkflows authored in SharePoint Designer 2010 are assembled from a "safe list" of predefined activitie

    servers.

    y Workflows can be created by users with less developer experience, such as Web designers orknowledge workers.

    Because you author the workflow directly against and data-bind it to a document library, workflows

    authored in SharePoint Designer 2010 differ from those created using the Visual Studio Designer in the

    following important ways:

    y You cannot deploy a workflow authored in SharePoint Designer 2010 to multiple lists. It is onlyvalid for the list for which you created it.

    y Because you are authoring the workflow directly against a list, the workflow is associated with thelist at design time. Therefore, there is no association stage with workflows authored in SharePoint

    Designer 2010.

    y You cannot modify workflows authored in SharePoint Designer 2010.y You cannot author against a content type in SharePoint Designer 2010.

    For a detailed comparison of SharePoint Designer 2010 and Visual Studio Designer, see Workflow

    Development Tools Comparison.

    Running Uncompiled Workflows

  • 8/9/2019 Workflow Development in Share Point Designer

    2/3

    Because they contain no custom code, workflows authored in a declarative rules-based, code-free

    workflow editor such as SharePoint Designer 2010 are not compiled and deployed as assemblies. They are

    stored as their source files within SharePoint Foundation 2010, and only compiled into memory when

    needed.

    For each site, the workflows of this type are stored in a separate document library. This document library

    contains a folder for each workflow authored in SharePoint Designer 2010. The folder contains all the

    source files necessary for the workflow, including the following:

    y The workflow markup filey The workflow rules filey ASPX forms for any custom workflow forms that are needed

    SharePoint Foundation 2010 includes a just-in-time compiler to compile the source files into a workflow

    the first time that workflow is started on an item. SharePoint Foundation 2010 retains the compiled

    workflow in memory until it is called again, much like servers caches compiled ASPX pages to speedexecution performance the next time the page is called.

    Each time a workflow is started on an item, SharePoint Foundation 2010 determines whether the workflow

    was deployed as an assembly or as source files. If a workflow assembly exists, SharePoint Foundation 2010

    calls that assembly to create the workflow instance. If the workflow was deployed as source files,

    SharePoint Foundation 2010 next determines whether or not it already has a workflow compiled from

    those source files in memory. If it has, then SharePoint Foundation 2010 calls the in-memory complied

    workflow to create the workflow instance. If not, SharePoint Foundation 2010 uses its just-in-time

    compiler to compile the source files into an in-memory workflow, which it then calls to create the

    workflow instance.

    Authoring Workflows Using SharePoint Designer

    SharePoint Designer 2010 uses a wizard-driven interface that enables users to assemble sequential

    workflows from predefined activities. Users select activities from a predetermined list, and configure those

    activities using the SharePoint Designer 2010 interface. These activities can be the same activities that are

    present in the Visual Studio 2010 Workflow Designer; there is no difference in activities between the two

    tools.

    In SharePoint Designer 2010, however, each activity appears as an action, represented by a sentence that

    contains variables that the user can configure using drop-down menus and lookup dialog boxes. Userscan also select conditions, which are configurable conditional clauses that direct the flow of the workflow.

    As the user is selecting and configuring conditions and actions in the workflow interface, SharePoint

    Designer 2010 generates the two files that actually represent the workflow class:

    y The workflow markup file, which contains markup language that describes the activities includedin the workflow.

  • 8/9/2019 Workflow Development in Share Point Designer

    3/3

    y The workflow rules file, which contains the business logic of the workflow in declarative rulesform, rather than as code.

    Adding Custom Activities and Conditions

    Because workflow authors in SharePoint Designer 2010 cannot create custom activities for use in their

    workflows, they are limited to the activities and conditions that the developer makes available on the safe

    list (which should also be approved by a server administrator) that appears in SharePoint Designer 2010.

    Developers can create custom activities and conditions, and make them available on the safe list.

    A condition is a custom assembly with a static method that when called, evaluates condition and returns a

    Boolean value.

    To make activities and conditions available on the safe list:

    1. Create the activity or condition, compile it as a strong-named assembly, and deploy it to theglobal assembly cache.

    2. Add the activity or condition to the action safe list in the web.config file.3. In the WSS.Actions file, located in the workflow folder, add rules and parameters for the sentence

    that represents the activity or condition in the SharePoint Designer 2010 user interface. This is

    markup language that specifies how the activity or condition appears and performs in the

    interface, because this information is not present in the activity or condition assembly itself.

    For more information about deploying custom activities and conditions, see the SharePoint Designer 2010

    help.

    Generating ASP.NET Forms in SharePoint Designer

    You can create an initiation stage for your workflow in SharePoint Designer 2010. If you do, SharePointDesigner 2010 uses ASP.NET to automatically generate an initiation form according to your initiation

    specifications.

    Similarly, you can create custom Microsoft SharePoint Foundation 2010 tasks for your workflow. Again,

    SharePoint Designer 2010 automatically generates an ASP.NET form for the task, according to your

    specifications.

    These ASPX forms are stored on the SharePoint site with the workflow source files. You can open and

    customize them as you would any other ASPX form.

    See Also