How can we monitor efficiently our farm? How can we monitor a farm as a global entity? What is the simplest approach? How can we receive alerts when things are going wrong?

Solutions

There are 3 different ways to monitor your SharePoint farm servers:

1. Using the Windows Event Views
2. Using the SharePoint ULS (Unified Logging Service) logs
3. The new SPS 2010 Health Center

Solution 1: Windows Event Viewers

• Advantages: This is a robust solution that is used other the places; Most of the time in large companies you have dedicated tools in place to monitor these information (see: SCOM; Monitor;…); Easy to log event from your application
• Disadvantages: This requires additional tools to monitor the event and therefore is more complex to manage; No out of the box global farm vision except by using third party tools

Solution 2: ULS

• Advantages: Easy to log event from your application; Free third party tool to read the content; Out of the box SharePoint solution
• Disadvantages: No out of the box global farm vision except by using third party tools

Solution 3: Health Center

• Advantages: Out of the box feature; Global to the farm
• Disadvantages: Not really easy to extend; More dedicated to the farm health and not our application

My solution

I have decided to use the ULS solution as I had a short dead line. The idea was to receive a email every time something wrong happen on the application and on on one of the front end server.

Step 1: Access the logs on each farm server.

The solution was simple, just ask the farm administrator to share the logs folders by giving read access to a specific service account

Step 2: Write a simple console application that analyze the logs on each frond end server, consolidate the results and send it by email.

https://skydrive.live.com/embedicon.aspx/WordPress/LogsMonitoring.zip?cid=727fafcfc60443c9&sc=documents

Step 3: Create a scheduled task.

At the end, you will receive a mail with the logs attached:

How can we monitor efficiently our farm? How can we monitor a farm as a global entity? What is the simplest approach? How can we receive alerts when things are going wrong?

Solutions

There are 3 different ways to monitor your SharePoint farm servers:

1. Using the Windows Event Views
2. Using the SharePoint ULS (Unified Logging Service) logs
3. The new SPS 2010 Health Center

Solution 1: Windows Event Viewers

• Advantages: This is a robust solution that is used other the places; Most of the time in large companies you have dedicated tools in place to monitor these information (see: SCOM; Monitor;…); Easy to log event from your application
• Disadvantages: This requires additional tools to monitor the event and therefore is more complex to manage; No out of the box global farm vision except by using third party tools

Solution 2: ULS

• Advantages: Easy to log event from your application; Free third party tool to read the content; Out of the box SharePoint solution
• Disadvantages: No out of the box global farm vision except by using third party tools

Solution 3: Health Center

• Advantages: Out of the box feature; Global to the farm
• Disadvantages: Not really easy to extend; More dedicated to the farm health and not our application

My solution

I have decided to use the ULS solution and I had a short dead line. The idea was to receive a email every time something wrong happen on the application and on on one of the front end server.

Step 1: Access the logs on each farm server.

The solution was simple, just ask the farm administrator to share the logs folders by giving read access to a specific service account

Step 2: Write a simple console application that analyze the logs on each frond end server, consolidate the results and send it by email.

Project File

Step 3: Create a scheduled task.

At the end, you will receive a mail with the logs attached:

1. Create the global Workflow with Visio 2010
2. Import and customize it within SharePoint Designer 2010
3. Add some advanced logics with Visual Studio 2010
4. Display the Workflow current state with Visio 2010

The goal is to create requests and copy travel request to a new list called “Travel requests”.

Create the requirements lists

Video 1: Lists creation

Step 1: Create the workflow with Visio

Remark: The workflow is simple and is just used to demonstrate the new capabilities.

Video 1: Create the workflow

Video 2: Export the workflow

Step 2: Import and update the workflow in SharePoint Designer

For this example, the workflow is attached directly to the “Requests” list.

Video 1: Import the Visio created workflow

Video 2: Update the logic

Test the workflow

Create some requests and see if the logic works.

Video1: Testing the workflow

Update the workflow logic

The goal is to upgrade the logic by adding a new task step and retrofit the modification to Visio.

Video 1: Updating the logic inside SharePoint Designer

Video 2: Exporting the modification to Visio

Visio visualization

SharePoint Enterprise allows visualizing the workflow status in real time.

Video 1: Activate the Visio Service at the farm level

Video 2: activate the Visio service on the site collection level

Video 3: Activate it on the workflow level

Video 4: Test if it works

The goal is to create several tasks inside a state and wait their completion before jumping to another state.

In this sample we work on 2 tasks but this can be easily extended to multiple one.

Usually when using state machine with SharePoint, we do the following steps inside the state:

1. Create the state initialization activity: Creating the task

   

2. Create the state event driven activity: Waiting the task update

   

3. Create the state finalization activity: Completing or deleting the task

   

We need to change these steps as following:

1. Create the state initialization activity: Creating both tasks

   

2. Create one state event driven activity for the first task: Waiting the first task update

   See the explanation below

3. Create on state event driven activity for the second task: Waiting the second task update

   See the explanation below

The event driven activity

Both of the event driven activities have the same template:

The trick is to use boolean (or Dictionary) to save the state of the process. When the first task is completed, a boolean is used to mark it as completed:

   1: private void onTaskChangedTU2_Invoked(object sender, ExternalDataEventArgs e)

   2: {

   3:     IsTU2AlreadyApproved = true;

   4: }

The same logic is used for the second task. On the branch condition, we test if all the task have been completed:

   1: private void AllTaskCompleted(object sender, ConditionalEventArgs e)

   2: {

   3:     //If all other tasks completed then

   4:     e.Result = true;

   5:     //Else

   6:     e.Result = false;

   7: }

If all the other task have been completed then we jump to the new state and if not we stay at the same state.

When a task is created by the workflow, it’s stored in the associate task list. When we click on it, it’s redirect to the “WrkTaskIP.aspx” that displays the task form. This page used the “XmlFormView” to display the associated task form:

Remark: All these steps are not addressed in this post.

A document library storing Infopath Forms is associated to the workflow. On the site library advanced settings, the “Display as Web page” functionality is activated.

Settings:

Opened form:

That means the InfoPath forms are opened inside the web explorer using the “Forms Service”. Imagine that the workflow has been started and one task has been created. When clicking on the task link, the “WrkTaskIP.aspx” is displayed for the approval process. On this page, a link to the targeted document exists:

When clicking on this link, we expect to see the form opened by the browser. It’s not the case and it’s a simple link to the document. The InfoPath client application is started instead of the browser:

Issue

This is the issue. This page doesn’t look at the source library settings in order to update the link and displays as expected a URL like:

http://vpcmoss/_layouts/WrkTaskIP.aspx?List=b3983e69%2D71c0%2D4348%2Db22b%2D5ae09f686b29&ID=1

Solution

No it’s time to find a solution. The first reflex is use our favorite search engine. The result is that there are not so many answer. Maybe there is another solution existing on the web but anyway, this post shows a global approach on “how find solution on SharePoint“.

Step 1

First we need to understand how is working the “WrkTaskIP.aspx” page to build this link. Start by opening this page to look at the HTML and page directive.

The HTML generated for the document link is stored in the “m_pageDescription” field (sooooooo lovely ).

Step 2

Next step, discover how the HTML data is generated. As many people said, Reflector is our friend. We looked at the aspx page directive to find the associated class:

<%@ Page Language=”C#” Inherits=”Microsoft.Office.Workflow.WrkTaskIPPage“

We open Reflector and look at this class. All the code is in the “OnLoad” method.

Reflector view:

The HTML link building:

Step 3

We just have to create a copy of the “WrkTaskIP.aspx” page, update the code. We can use the code below:

Step 4

We need to replace the “WrkTaskIP.aspx” by the created one when clicking on the task. This can easily be done using a “ContentType” and by updating the xml workflow file.

New updated task “ContentType”:

Update the workflow configuration file by updating the “TaskListContentTypeId” id.

Step 5

The last step is to encapsulate these modifications using a solution (wsp file) that will:

• Deploy your CententType feature
• Deploy your Workflow feature
• Copy the assembly to the GAC
• Copy the updated layout page

And that’s done !!!

To conclude on this post, when you need to develop something on SharePoint:

• looked at the existing SharePoint code
• use and reuse Reflector

Update: 05/03/2008

You can find below a link to the feature (part of the complete feature).

DemoFeature

Hope that it’s not so bad for a first post