However, the default display behavior of the Visio Web Access part is a bit nasty, especially when you try to display information inline of the page. The content position of the Visio document is positioned completely wrong and the user has to correct the zoom or even has to drag the information. As you can see in the example below, my Visio information is shown incorrectly.

This problem can be fixed by modifying the XML configuration of the web part. Before you can modify the XML configuration, make sure you enable the checkbox of the web part option “Override the Web Drawing’s default initial view using the web part’s current page, pan and zoom”. Never turn off this option again, because it will completely reset the view settings in the xml.

After you have saved the web part with the override setting, export it to your desktop and open it in an editor. Notepad will do fine. Search inside the XML for a property called “ViewSettings”.

This property allows you to alter the default display option of the web part, but only when the property “OverrideViewSettings” is set to true. Try to play around with the X and Y setting and perhaps the zoomValue. Save the web part file and import it again to your page. You might have to repeat the process a few times to get it right, but after a few tries the web part will show your information correctly. This way Visio is a great option to show KPI information.

The problem with normal workflow actions is that they are designed to work inside a single web. It is not possible, for example, to create a new list item in a different web. Creating list items in different webs is a very powerful feature, because it allows us to interact with different site areas and we might also want to initiate new workflows over there.

To overcome the short come of these standard workflow actions, we can use the SharePoint web services. But there is one major problem: SharePoint Designer Workflows don’t have a workflow action that allows you to call SharePoint web services.

Luckily I found a project at CodePlex which allows us to do just that. The iLoveSharePoint project contains a subproject with the name SharePoint Designer Actions V1.0. Download this expansion for SharePoint Designer and install it at your SharePoint farm.

Below I will provide a few demonstration steps that will use the following new SharePoint Designer Actions from iLoveSharePoint:

• Call a WebService
• Query XML

The “Call a WebService” action will allow us to communicate with the Microsoft SharePoint web services and provides us with an almost unlimited range of extra development possibilities. The small downside is that these actions are advanced and that it takes some time to configure them.

Step 1: Create the required sites and lists
For this demo we have to prepare the SharePoint environment with 2 blank sites.

Create a site which will function as the parent site. Give it the name “Demo” and create a standard list with the name “SourceList”.

Continue with the creation of a second site. This site should be a sub site of the demo site. Give it the name “Sub Site”.  Add a new standard list with the name “TargetList” and also add an extra column with the name “Information”.

In my demo the urls are

• http://moss2007dev/Demo
• http://moss2007dev/Demo/SubSite

Step 2: Use SharePoint Designer to create a new workflow

Start SharePoint Designer and open the Demo site we just created.

From the file menu choose to create a new workflow.

Name our workflow “WebServiceDemo” and attach it to the “SourceList”.

Choose to start the workflow manually and when a new item is created.

Step 3: Create the first step

We will now add our first step. During this first step we will call the lists.asmx web service and create a new item in the Sub site “TargetList” list.

Give a name to the first step like “Create an item in the Sub Site target list.”

SharePoint designer won’t be able to create an item in the “TargetList” because it is not located in the Demo site. To work around this issue we will use the SharePoint Web services.

Add a new action to the first step and search for the “Call a Web Service” action. This action should be available if you installed the iLoveSharePoint SharePoint Designer actions.

The “Call a Web Service” action accepts a few parameters:

• Address – Url to the web services
• SOAP Version – Soap version to use
• SOAP Action – Redundant in our case
• Envelope – The XML message we’ll send to the web service
• Response – The XML message returned from the web service
• User – Username
• Password – Password for the specified user

In all our web service calls we will not specify the SOAP Action and the User/Password combination. Without any provided credentials the web service will be executed using the service account.

I do also always specify the SOAP Version as 1.2.

Now let’s provide the parameters with some data:

Address
http://moss2007dev/Demo/SubSite/_vti_bin/lists.asmx

SOAP Version
Soap 1.2

Envelope

Response
Store the response in a string variable called “WorkflowResponse”.

We have now completed the first step in our workflow and we should be able to create a list item in the “Sub Site” by adding a new item in the “SourceList” list located at the Demo site.

Save and publish the workflow.

Step 4: Check and run the workflow.

Navigate to the Demo site and open the “SourceList” list. Create a new item and provide the value “Hello World” as Title, because every demo should include a “Hello World” example, right?

If everything works correctly the “SourceList” list should show a “WebServiceDemo” column with the value “Completed”.

Navigate to our “Sub Site” en open the “TargetList” list. Our new list item should be shown here!

Step 5: Create a demo workflow in the “Sub Site” site

An interesting scenario would be that we trigger a new workflow when an item is created in the “TargetList” list. To demonstrate this open the “Sub site” site in SharePoint designer and create a new workflow on the “TargetList” list.

Name the workflow “UpdateTitleField” and attach it to the “TargetList” list.

Choose to start the workflow manually and when a new item is created.

Step 6: Configure the first step to update the Title field

Give a name to the first step like “Update the title field”.

Add a new action to the step and search for the “Set Field in Current Item” action.

Configure the action to update the “Title” field and set the value to “Updated by Workflow”.

Save the new workflow.

Step 7: Test the “UpdateTitleField” workflow

Navigate to the “TargetList” list and open the item menu of our first created item.

Choose the option “Workflows”.

You will now see a screen with all available workflows. Click the “UpdateTitleField” workflow and start the workflow.

The workflow should complete and update the title field of the item.

Step 8: Test the complete flow

We have now completed our flow:

1. An item is manually created in the “SourceList” list
2. The “WebServiceDemo” workflow is triggered
3. An information list item is created via the web service call in the “TargetList” list
4. The “UpdateTitleField” workflow should be triggered
5. The title of the list item is updated

So let’s start by creating the manual item at the Demo site. Now quickly navigate to the “Sub site” to see the result. But you’ll probably see that step 4 of our flow didn’t trigger! It didn’t work as it should.

If it did work correctly you are in luck because your AppPool identity was differently configured. In most cases the service account is not allowed to auto start workflows.

This behavior is explained by Microsoft in KB947284:

“This behavior occurs because a security fix in Windows SharePoint Services 3.0 SP1 prevents declarative workflows from starting automatically under the system account.”

Step 9: Collect the item url of the newly created item

To overcome the auto start problem we can trigger the workflow with a web service call.

For this call we need the path of the new item and the templateID of the workflow. In this demo we will retrieve the templateID in the workflow, but once you know the templateId you can of course hardcode it in your web service call to minimize the system load.

Create a new step in the “WebServiceDemo” workflow and name it “Collect WF parameters”.

Add a new action. This time we will use the iLoveSharepoint “Query XML” action.

The “Query XML” action accepts 3 parameters:

• XML Input – the XML to be processed
• XPath – The XPath query to run
• Result – The variable in which the result will be stored

Let’s provide the parameters with some data:

XML Input
Variable: WorkflowResponse

XPath
//@ows_EncodedAbsUrl

Result
Create a new string variable with the name “ItemUrl”

To be able to analyze any result, add a second action of the type “Log to History List”. This action will write given information into the workflow history list. Configure the action to log the variable “ItemUrl”.

Save the workflow with our latest changes.

Step 10: Run the workflow and see if the new item url is collected

We will now check if the item url is logged in workflow history.

Navigate to the “SourceList” list and create a new item.

After submit wait until the workflow “WebServiceDemo” is completed and then click the completed link.

You will find the workflow history on this page and you should see the url of the new item.

Step 11: Collect the TemplateID of the workflow

To retrieve the TemplateID of a workflow we can use workflow.asmx web service.

Open the “WebServiceDemo” again in SharePoint designer and load the “Collect WF parameters” step.

Add a new “Call a Web Service” action and provide the following parameters:

Address
http://moss2007dev/Demo/SubSite/_vti_bin/workflow.asmx

SOAP Version
Soap 1.2

Envelope

Response
Store the response in the existing variable called “WorkflowResponse”.

To query the Workflow Template Id add a new “Query XML” action and use the following parameters:

XML Input
Variable: WorkflowResponse

XPath
//@TemplateId[1]

Result
Create a new string variable with the name “WFTemplateID”.

Note that the workflow result is returning namespaces. Because of the namespaces it is quite difficult to do a full XPath query. The //@TemplateId XPath works but when you have more as 1 workflow on the list, play with the [index] option to find the correct templateID.

Finish the “Collect WF parameters” step by logging the “WFTemplateID” into the history list.

Step 12: Check the workflow history for the Workflow Template ID

We will now check if the workflow TemplateID is logged in workflow history.

Navigate to the “SourceList” list and create a new item.

After submit wait until the workflow “WebServiceDemo” is completed and then click the completed link.

You will find the workflow history on this page and you should see the ID of the Workflow Template ID.

Step 13: Start the “UpdateTitleField” workflow via a web service call

We now have all the information required to start the “UpdateTitleField” workflow on the automatically created items.

Open the “WebServiceDemo” workflow again in SharePoint designer and add a third step with the name “Start UpdateTitleField workflow”.

We only need to add a single workflow action here of the type “Call a Web Service”.

We configure the parameters to use the “StartWorkflow” action of the workflows.asmx web service:

Address
http://moss2007dev/Demo/SubSite/_vti_bin/workflow.asmx

SOAP Version
Soap 1.2

Envelope

Save the workflow when you are finished configuring the action.

Step 14: Run the final test

We should now have really completed our flow.

1. An list item is manually created in the “SourceList” list
2. The “WebServiceDemo” workflow is triggered
3. An information list item is created via the web service call in the “TargetList” list
4. The “UpdateTitleField” workflow should be triggered
5. The title of the list item is updated

So let’s try it again. Navigate to the “SourceList” list and create a new item. Check if the “UpdateTitleField” workflow completes successfully and then navigate to the “Sub site” and the “TargetList” list to check the result.

If the configuration was successful you will now see that all the steps in our flow completed successfully!

This demonstration showed you how to

• Call web services from SharePoint designer
• Extract xml values from the web service responses
• Trigger a workflow via a web service call

Thanks to the iLoveSharePoint SharePoint Designer Actions you have a lot of new workflow possibilities. Enjoy and be creative!

For some of the Infopath forms we received an error while upgrading the form to a newer version. The error statement told us that we could not update the form because of an object in the database with the same ID.

To resolve the error we tried to remove the existing form, but instead of removing the form, SharePoint decided to do the opposite and it tried to start some kind of upgrade process. We had no more options to upgrade or even delete the existing form.

We knew that SharePoint generates a WSP for each InfoPath form that is published in the Central Administration. The deployment status of each WSP file can be seen in the Solution Management section. Right here we found the source of our problem. The Solution Management page informed us that the WSP package of the forms where Globally deployed, but they gave an Error status. The error status blocked every option to retract or re-deploy the WSP. Looking at the error details the following message was displayed:

Somehow the environment was thinking that the content of the missing WSP package was deployed.

Finally the IT Pro of our client found the solution for the problem in KB939308. It turns out that after a database restore, the contents of the file system cache on the front-end servers can be different from that of the contents of the configuration database.

The only way to fix this is by performing some manual steps:

1. All the XML configuration files have to be removed from the SharePoint config directory.
2. The contents of the cache.ini file has to be cleared.
3. The Windows SharePoint Services Timer has to be restarted.

A detailed guide of these steps is provided in the description of KB939308.

So next time if you have to do a database restore of your SharePoint Server, keep in mind some cache problems might occur.

The line

returned the error statement:

At first I assumed that the error was caused by invalid user rights, but after some searching this forum post at Microsoft Technet came up with the right solution.

By default the console project is build for the .Net 4 framework and and the x86 platform. Because SharePoint is only available as a 64bit version, the console app should also be compiled for the 64bit platform.

By changing the framework to .Net 3.5 and the target platform to x64 the issue was resolved.

The mobile rendering engine of SharePoint provides mobile users access to the sites with a completely stripped interface. Its main function is to list all libraries and to provide basic access to them. For wiki and blog sites the rendering engine also provides some content rendering.

To keep the amount of data as low as possible, almost all web parts are completely stripped from the mobile site. Only when a web part developer provided a special mobile version of the web part, the web part will be accessible in the interface and to keep the mobile screen as empty as possible, the user must first expand the web part via its title to see it.

Documentation about SharePoint Mobile development is provided at MSDN. At first it all looks quite complex, but building a mobile version of a web part is actually not that hard. Below I will explain the required steps with a ‘Hello world’ example. For this sample I will not rename the default object names provided by the Visual Studio templates.

Create a sample site

In this sample we begin with a fresh empty site. Create a new “Blank Site” and call it “Mobile Demo”.

Create a Visual Studio 2010 Visual Web Part Project

Visual studio 2010 includes a full set of SharePoint templates. These templates automatically publish and debug the project to your SharePoint environment.

Start a new “Visual Web Part Project” and name it “MobileWebPartDemo”.

Add a literal with the “hello world” message

We will now create the normal SharePoint web part. We only show a sample message by adding a literal to the web part controls.

Open the class file “VisualWebPart1UserControl.ascx.cs” and add the following code to the load event:

Build and add the web part to the page

Press F5 to compile and build the web part. Internet explorer will start. Browse to the “Mobile demo” sample site and open the default page in edit mode. Add a new web part. Inside the “Custom” category you will find our demo web part. Add “VisualWebPart1” to the page.

Preview the site

Exit the edit mode of the page. You will now see your site and the web part as normal users will see it.

Preview the mobile site

To view the web site in mobile view, type a “/m” after the normal site url. For example: “http://localhost/mobiledemo/m/”.

At this moment the website is rendered in the mobile view. But hey! We don’t see the web part we just published. This is because the engine strips all normal web parts to keep the data transfer as low as possible. Only mobile optimized web parts will be shown.

Create the mobile (adapter) version of our web part

To add our web part to the mobile version of the site we must provide SharePoint with a mobile optimized version of our web part. We do this by adding a new class. Microsoft calls this class an adapter.

Add a new class and name it “VisualWebPart1MobileAdapter.cs”. Note that we added the name of our web part in front and added the text “MobileAdapter” at the end.

Microsoft recommends to use the namespace “SharePoint. WebPartPages.MobileAdapters” so modify the namespace to use “MobileWebPartDemo.SharePoint.WebPartPages .MobileAdapters”.

Our class should inherit the “WebPartMobileAdapter” class.

The adapter does not use the “OnLoad” event. Instead it uses the “CreateControlsForDetailView” to render. Override this class and add the following code:

Add the adapter to the safe controls

SharePoint should know that the adapter web part is a safe control. We did not have to add the normal web part as safe control, because the project template already fixed this for use. However, we still have to add the mobile version.

Open the web.config file of your SharePoint IIS site (example: C:\inetpub\wwwroot\wss\VirtualDirectories\80) and add the line below into the safecontrols section. Replace the PublicKeyToken with your own key!

Configure the compat.browser file to use our mobile web part

SharePoint must be told that there is a mobile optimized version available for our web part. Basically we are going to tell SharePoint that if there is web part “Normal” on the page, it should load version “Mobile”. Without this configuration SharePoint would just strip our web part like before.

Inside your SharePoint IIS directory you will see a directory “App_Browsers” and inside that directory is a file called “compat.browser”. Load this file in the editor.

At the top of this file you will find a “controlAdapters” section. Add the line below to this section:

Again, replace the PublicKeyToken with your own key! Safe the configuration and exit the file.

Rebuild the project and reload the mobile demo site

We finished the required steps to provide SharePoint with a web part that is optimized for the mobile page. Press F5 to build and deploy our project and re-open the mobile view of our demo site. And wow it’s almost magic! The title of our web part has suddenly appeared.

Expand the web part

To keep the mobile screen as empty as possible, not all web parts are automatically visible. Just click the title of the web part and it will be rendered.

And that’s it. This is all the information required to start developing web parts for the SharePoint Mobile pages. Enjoy!