Sep 22, 2008


The EventHandlingScopeActivity is a dramatically different type of event handling activity. It has two discrete sections: a main line child activity and a set of event handling activities. The single main line child activity executes in a normal manner. When the main line activity completes, the entire EventHandlingScopeActivity comes to an end. In addition to the main line child activity, event handling activites are contained within a single EventHandlersActivity that is a child of EventHandlingScopeActivity. The EventHandlerActivity is the parent for one or more EventDrivenActivity instances, with each one activing as a seperate branch of execution. Each EventDrivenActivity contains one or more child activities, but the first child must implement IEventActivity(e.g. HandlingExternalEventActivity) in order to start execution of the branch. When an event is received, the activites within EventDrivenActivty are executed. However, unlike the more common event handling of ListenActivity, the order event branch are all still alive. They can also receive their events and execute the activities within their execution branch. The orginal branch that recived its event cal even receive it again.

These activities are used in advanced scenarios where you need to concurrently handle multiple events and execute a main line set of activities at the same time. In the example that follows, you will implement a workflow using the EventHandlingScopeActivity. It contains a main line set of activities that execute while a condition is true. It also handles three external events, one of which is being used to set the condition for the main line activities.

Manually controlling correlation

In the previous examples, you’ve seen that as local service events are raised, they are routed to the correct workflow instance. The magic that accomplishes this is the workflow instance ID that is passed with the ExternalDataEventArgs. The InstanceId property of ExternalDataEventArgs identifies the workflow instance that should receive the event. It is common for a workflow to wait for multiple events, using a different HandleExternalEventActivity instance to wait for each event. The standard event routing also handles this situation, passing the event to the correct HandleExternalEventActivity instance in the workflow. When one event is received, all other EventDrivenActivity branches are canceled.

This type of event routing is sufficient for most situations. However, what happens if a workflow must handle multiple instances of the same event? This might be the case if the workflow includes an activity such as a ParallelActivity that permits multiple branches of execution. Each execution branch may be waiting for the same type of event. The standard event routing will identify the correct workflow instance, but how do you determine which activity should receive the event?

The solution to this probelm is to manually control the event routing using a set of correlation attributes. These are attributes that you apply to the local service interface. They identify a prameter that is used to correlate an event back to the correct activity within a workflow

            public interface ICorrelationExample

            void StartDemonstration(Int32 branchId);

            [CorrelationAlias("branchId", "e.BranchId")]
            event EventHandler EventReceived;


Using HandleExternalEventActivity

Implement the class that will be used as the vent arguements,this argument must derived from ExternalDataEventArgs.

Define the evetn in a local service interface. A local service interface is one that has been decorated with the ExternalDataExchangeAttribute and implemented by a local service class.

Implement the event a local service class.

Add an instance of the ListenActivity to a workflow. This create an initial set of two EventDrivenActivity instance as children of the ListenActivity. Each EventDrivenActivity represent a seperate exectuion branch that must be started by an activity implementing IEventActivity.

Add the HandleExternalEventActivity to one of the EventDrivenActivity branches. The HandleExternalEventActivity has a number of properties that must be set a design time. You first select the interface that identifies the local service. After selecting an interface, you must select the event that you wish to handle from a list of availabe events.

Complete the second EventDrivenActivity instance by adding an activity that implements IEventActivity. If you don't have another external event that you wish to handle, you can use a DelayActivity.

You must also decide how you want to handle the event arguments when the event is received. Presumably, the event arguments carry data that the workflow requires in order to continue processing. One option is to define a parameter binding that sets a workflow property to the value of the event arguments when they are received. You can then use the event arguments elsewhere in your workflow by referencing the workflow property. Another option is to add a code handler to the Invoked event of the HandleExternalEventActivity. This enables you to work with the event arguments directly in this handler as they are received.


Event-Driven Activities

WF includes a group of activites that work together to provide event handling within workflow. Some of these activites wait for an external event(eg HandleExternalEventActivity), while others trigger and handle an event internally( DelayActivity) In both case, the activites implment the IEventActivity interface, which is a requirement for any activity that handles an event. Other activity are composites that act as containers for these event handler activities. EventDrivenActivity is similar to SequenceActivity in that it contains a set of child activites that are executed in sequence. However, EventDrivenActivity requires that first activity implment IEventActivity. When this first child executes, it immediately begins waiting for its event. Execution of the entire EventDrivenActivity is suspended until the event is received or the activity is canceled.

Other actvities , such as ListenActivity as as containers for multiple instance of EventDrivenActivity. Each EventDrivenActivity represents a branch of execution that is triggered by a different event. The EventDrvienActivity is the only child activity permitted by the ListenActivity.


Sep 21, 2008

Adding Workflow persistence service

This can be done programatically or declaratively. Below is section of code that do it programtically.

            private static void AddServices(WorkflowRuntime instance)
            String connStringPersistence = String.Format(
            "Initial Catalog={0};Data Source={1};Integrated Security={2};",
            "workflow", @".", "SSPI");

            new SqlWorkflowPersistenceService(connStringPersistence, true,
            new TimeSpan(0, 2, 0), new TimeSpan(0, 0, 5)));

To do it declaratively, you need to change your code and the configuration file as well. Here is a section of code

//here you use a constructor to specify the configSectionName WorkflowRuntime runtime = new WorkflowRuntime("WorkflowRuntime")

You should add you configsection in the config file. Please note that the name of the section does not necessary to be "WorkflowRuntime"

Adding Local service in WF

There are two ways to add local service to workflow runtime, programatically or declaratively. Below is section of code that do it programatically.

            private static void AddServices(WorkflowRuntime instance)
            //add the external data exchange service to the runtime
            ExternalDataExchangeService exchangeService
            = new ExternalDataExchangeService();

            //add our custom local service
            //to the external data exchange service
            exchangeService.AddService(new AccountService());


Or you can do it using config file. Below is section of the configuration file.

Local service(Data Exchange Service)

WF also supports another kind of service known as a local service (sometimes called a data exchange service). This is a service that you design and implement yourself. A local service can serve just about any purpose, but one general use is to facilitate communications between workflow instances and the host application. In contrast with this, core workflow services each have a purpose (e.g., persistence, tracking) that has been defined by Microsoft. You can develop alternate implementations for each core service, but that doesn’t change their defined purpose.

A local service can be created via code or from entries in an application configuration file. There are three different ways to use a local service. 1. used directly from code in workflow class 2. used in custom activity 3. CallExternalMethodActivity



This Activity is like the combination of ParallelActivity and WhileActivity. The parent is ParallelActivity and the child is WhileActivity.

You use the ConditionedActivityGroup by adding one or more child activities that you wish to execute. Like the ParallelActivity, child activities are executed from left to right and each child activity is given a turn at execution. If the child is a composite, only one of its children is executed during any given turn. Each child activity can optionally declare a WhenCondition. This can be a code or rule condition that determines whether the child activity should execute. If a condition is defined and it evaluates to true, the child is executed once during its next turn. The child activity will continue to execute once during its turn until the WhenCondition evaluates to false. If no WhenCondition is defined, the child activity is executed only once

The ConditionedActivityGroup also supports an optional UntilCondition. Like the other condition properties, this can be a code or a rule condition. If defined, this property specifies a condition that causes the CAG to end execution early. If the UntilCondition is not defined, the CAG completes when all of its children have completed and no WhenCondition evaluates to true. With the UntilCondition defined, the CAG will end when the UntilCondition is true, or when all child activities have completed normally.


Sep 14, 2008

Workflow Property

Parameters can be defined for a workflow (or custom activity) in two ways. You can implement a normal .NET class property, or you can use a dependency property. The property value for a dependency property is stored in a central repository, rather than being implemented as a normal instance variable in your class.

The primary advantage to dependency properties is that they allow binding of property values to instance data at runtime. For example, you can bind the input property of one activity to an output property of another. The actual property values resulting from the binding is determined at runtime. Dependency properties are required when you want to bind properties from one activity to another. However, if you are binding an activity property to a workflow property, the workflow property is not required to be a dependency property.

Sep 3, 2008

SharePoint Form Authentication

Here is an article about SharePoint Form Configuration. Basically, you need to modify the web.config of the content site and central admin site. But you should keep the central admin's role provider . Then you need go to central admin to change the web application's Authentication. One web application may be accessed in different zone, for example intranet and internet zone. You can config intranet access site to use windows authentication, and config the internet access site to use form authentication. But The web.config files of all access site need be modified to know the information of form authentication.

One thing to note is that you need to enable the PeoplePickerWildcards like the following.

Another thing is make sure the application pool account can access the user database.

Sep 2, 2008

Page Layouts

What is page layouts. Let's see how page is used. First page layout is used to create page just like the Web Page template. But it has one more benefit "Field Control". Page Layout is inherit from Page directly or indirectly. To create a Page Layout you need to create a content type first, the parent content type of this content type is Page. Then you can add more column to this content type. Then you create Page layout based on the content type you just created, and the columns of that content type becomes field controls. You can add field controls to the page layout, you can add webpart zone the page layout. When creating page, you create page out of page layout instead of WebPart Page.

age layouts have a special relationship with contetn types within a publishing site. Each page layout must be associated with exactly one content type. This content type must inherit from the Page content found in the Publishing Content Types group. This content types may have fields(columns) , it may also have a special workflow associated with in defining a special approval process for the press release.

Keep in mind that content type only defines the schema and rules for the type of content; it does not address the presentation in any way. This is where page layouts come into play. Page layouts, when combined with a master page, define the rendering/look and feel of a requested page. In addition, developers can associate multiple page layouts iwth a single content type to give content owners the utmost control in selecting different rendering options for a particular page type.

Moreover, content owners are not restricted to the page layout that is selected at the time of page creation. At any point in the future, even after the page has been published, a content owner can edit the page and chage the selected page layout. The only limitation is that the only page layouts availabe are those associated with the content type selected when the page was created.

Deploy web part

1. Deploy the assembly containing the web part class to the site's hosting web application's bin folder or server's GAC

2. Add a entry to the site's hosting web application's web web.config, telling sharepoint the control has been approved to run in sharepoint sites hosted within that web application

3. Deploy any resource file used by web part.

4. Make web part discoverable within SharePoint so users can add it to SharePoint Pages within sites. A web Part defintion file must exist in one of two places: the web part gallery in a top-level site of of a site collection or the \wpcatalog folder, all sites iwth in all site collections iwthin the web application will have acess to the web part. However, if it is added to the web part gallery, a specail document library in the op-level site of a site collection, only the sites iwthin that site collection will be able to add web part to their pages.

Sep 1, 2008

Master Page Content Placeholders

The SharePoint default master page containes 32 different content placeholders used by the content pages throughout SharePoint sites. Not all of the 32 place holders are required in all custom master pages. In fact, the 8 provided master pages for publishing sites only contains 21 of 32 and one additional content place holder. They are

OSSConsole PlaceHolderAdditionalyPageHead PlaceHolderBodyAreaClass PlaceHolderBodyLeftBorder PlaceHolderBodyRightMargin PlaceHolderCalendarNavigator PlaceHolderLeftActions PlaceHolderNavBar PlaceHolderLeftNavBarTop PlaceHolderMain PlaceHolderMiniConsole PlaceHolderNavSpacer PlaceHolderPageDescription PlaceHolderPageImage PlaceHolderPageTitle PlaceHolderTitleInTitleArea PlaceHolderSearchArea PlaceHolderTitleAreaClass PlaceHolderTitleAreaSeparator PlaceHolderTitleBreadcrumb PlaceHolderTtileLeftBorder PlaceHolderTitleRightMargin

Some of the content placeholders listed in the preceding table, while included in the eight publishing master pages, are never rendered and shown, This is done by placing the content holders within ASP.NET panel and set the visibility to false. This technique enables site developers and site designers to include content placeholders that are included within content pages, but keep any of the content defined in the content pages from being rendered. This is a common re factoring technique when implementing a rebrading compain on a site. It enables designers to hide content placeholders with one simple action in the master page without going through all content pages to remove the content placeholder.