On my current project we wanted to add documents which come in as attachment through a webservice to a sharepoint document library to store them.

We used Biztalk 2006 to receive the file, get the different files from the xml and then send them to SharePoint. In this blogpost I’ll explain how to do this with a small POC I made.

First off we started with a receive port which is able to receive the xml message (the binary port on the picture) we receive this message into a BinaryMessage message which is linked to the following schema

An example message is looking like this: (where the <document> should have the attachments as a base64binary string.

After receiving the message we want to loop through all the messages in the document so I created a foreach to read all the document elements from the xml.

The code to build the loop is the following:

InitializeLoop :

iteration = 1;

documentCount = xpath(BinaryFile,"count(/*[local-name()='BinaryFileToSharePointTest' and namespace-uri()='']/*[local-name()='Document' and namespace-uri()=''])");

first I set the iteration variable to 1 and I set the documentCount to the amount of document elements that are in the incoming xml file.

Message assignment

BinaryFileWithMetadata = BinaryFile;

binaryMessageCreator = new BinaryToSharePoint.Helper.BinaryMessageCreator();

selectXpath = "string(/*[local-name()='BinaryFileToSharePointTest' and namespace-uri()='']/*[local-name()='Document' and namespace-uri()='']["+ System.Convert.ToString(iteration)+"]/text())";

base64String = xpath(BinaryFile,selectXpath);

binaryMessageCreator.CreateBinaryMessage(BinaryFileWithMetadata,base64String);

configProperties = new VdCruijsenNet.Utilities.Sharepoint.ConfigPropertiesXML();

configProperties.AddProperty("Title","test");

BinaryFileWithMetadata(WSS.ConfigPropertiesXml) = configProperties.ToString();

BinaryFileWithMetadata(WSS.Filename) = "bestandsnaamTest "+System.Convert.ToString(iteration)+".pdf";

In the message assignment we first Create the new outgoing message for each of the documents in the incoming xml file. Then we select the base64binary string with an xpath expression and send it to the binaryMessageCreator.

The binaryMessageCreator creates a new System.Xml.Document (which isn’t a xml file but biztalk doesn’t know that :) from the base64binary string. For the source of the BinaryStreamFactory see below:

After creating the new Message of the type System.Xml.Document, which is actually a byte[] containing the file we add a filename and some metadata which can be stored in SharePoint we send the message with the send shape to sharepoint.

The SendPort is a “Windows SharePoint service” sendport which can automatically add the file to a sharepoint document library.

Sendport

Receiveport

As you can see it’s pretty easy to get the binary files from an xml file in Biztalk after you know how you can do it.

Happy Coding

Geert van der Cruijsen

The last 2 days my MOSS environment was driving me crazy because an already existing workflow didn't want to start in a new document library in a new subsite. I made this workflow in Visual Studio 2005 and deployed it as a feature to my SharePoint Site. I connected the workflow to a content type and told it to run on new items of this type or whenever an item changes. This workflow worked fine for 2 months in this particular document library.

After 2 months my client asked for a new subsite with a new document library where this workflow should also run. I installed this workflow here and expected everything would go as planned. When I tried to test the workflow I didn't see anything happen so I tried creating new items, changing them, even manually starting the workflow. Nothing happened. The metadata field which contains the workflow status was staying empty. When checking the log files I didn't see anything either.

I tried to reinstall the workflow. Deleted and recreated the site nothing seemed to help. During all this the workflow still worked fine in the other subsite and document library. When I recreated the workflow and checked the logfile again I finally found an error. (it seems Sharepoint only logs this error the first time you start the workflow and after that it doesn't do anything)

The error message in the logfile was the following:

Workflow Infrastructure        72fv Unexpected AutoStart Workflow: System.ArgumentException: De aangevraagde werkstroomtaakinhoudstype is niet gevonden op SPWeb.     at Microsoft.SharePoint.SPList.PrepForWorkflowTemplate(SPWorkflowTemplate wt)     at Microsoft.SharePoint.Workflow.SPWorkflowManager.StartWorkflowElev(SPListItem item, SPFile file, SPWorkflowAssociation association, SPWorkflowEvent startEvent, Boolean bAutoStart, Boolean bCreateOnly)     at Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver.AutoStartWorkflow(SPItemEventProperties properties, Boolean bCreate, Boolean bChange, AssocType atyp)

this Dutch error (I really hate Dutch errors. you can't look them up on Google/MSDN:( )translated in English is 'The requested workflow task content type was not found on the SPWeb'. I found the exact translation because I was lucky and when I had the English error this gave me new hope to find a weblog with the answer (since weblogs seem the primary documentation for SharePoint 2007 ;) )

I searched for the error and everything I could find was reinstalling the OffWFCommon feature. I tried this with the following commands but nothing changed. I also tried to uninstall and reinstall but this didn't help either

stsadm -o installfeature -filename OffWFCommon\feature.xml
stsadm -o activatefeature -filename OffWFCommon\feature.xml -url http://localhost/

This weblog told me the exact thing that was going on. the TaskListContentType wasn't installed on my tasks documentlibrary when I checked it by enabling content types chaning in the advanced settings of the tasks list. The ID of this content type is 0x01080100C9C9515DE4E24001905074F980F93160 which is the same as the OffWFCommon feature so it definitely had something to do with it. When I checked the content types of my task doclib that was working I noticed it had 2 content types attached. 1 called "Task" and 1 called "Workflow task content type" my Tasks library that wasn't working had a content type called "Tasks". I couldn't find any way how to add these content types because these are system content types and thus hidden.

Solution/Workaround:

Since I already wasted 1 and a half day on this problem my next try was to save the Tasks documentlibrary of the workflow that was working as a template. After that I deleted the workflow in the new document library and also deleted the Tasks list there. I added a new Tasks list by using the template I made and installed the workflow again for this documentlibrary. I tested it and guess what.. everything seemed to work fine. The solution isn't that pretty but I was glad it finally worked!

Hopefully someone with the same problem reads this before they waste to much time on this really awful problem. Also if you know  a better solution please let me know because I would really like to know how to really solve this problem.

Geert van der Cruijsen

On my current project I ran into a problem with a custom SharePoint workflow because the workflow sometimes failed to run and sometimes it worked like a charm. When I cancelled a workflow which gave an error and restarted it by hand it finished without any problems.

When I looked in the SharePoint logfiles what was causing my workflows to crash it showed that the workflow couldn’t find values for some settings in the web.config. I couldn’t think off any reason why the workflow couldn’t read these settings about 50% of the times a workflow was started.

The workflow I created is automatically started after the change of an item in a specific document library. After some testing I found out that all workflows that I started by changing the item with the sharepoint webinterface worked fine but the items that were changed by an external source (a custom webservice I created but also the biztalk SharePoint Adapter webservice) crashed with the error that they couldn’t read the web.config.

The webservices that are causing the workflow to crash are in a different sharepoint webapplication and thus use a different web.config. When I added my settings in the web.config of this webapplication the workflows stopped crashing.

So it seems that the WF workflows are running in the process which changed the item in the sharepoint list which caused the workflow to start instead of the standard w3p process of SharePoint which I thought always was the case.

Happy coding!

So after my first month off having my own development blog I already start to slack on making new posts. Not a good sign ;) Well here’s an update again about a weird error I came across in SharePoint today. I'll try to make more posts in the near future but lately I didn't see any cool things to blog about. I also spend most of my free time to study for my MCPD exam next week.

I was working on a SharePoint Solution using the Business Data Catalog to retrieve data from a mssql database and to show this data in a BDC list view. On my development machine everything was working fine so I uploaded it to my test environment and what happened.

The following error came up: "An unhandled exception has occurred: There was an error in the callback"

I checked the trace log and the event viewer. Both didn’t show anything about any error involving the Business data catalog. Google didn’t result in anything useful either so I asked around at some colleagues. Finally one of them gave me the following link:

http://discuss.joelonsoftware.com/default.asp?dotnet.12.506335.2

The people at this page have a slightly different problem but I didn’t have any other solutions so I thought I might give it a try. And after I tried it I was stunned. The Data List view actually worked.

So what was the solution? Adding a Search box web part to the page containing the BDC data list view did the trick. You can set the search box to invisible if you don’t want it visible on your page.

I haven’t looked why this search box webpart is connected to the data list view yet but I would really like to know why. It took quite some time to figure this one out so in the end I was happy it worked.

For anyone of you who encounter the same problem as I did I hope you find this post faster as I found my answer today.

Enjoy!

Geert van der Cruijsen

The SharePoint Keywordquery and Fulltextsearch are good ways to search metadata programmatically. This option is only available for MOSS 2007 because you don’t have a server context object in WSS 3.0.

When you Create a keyword query instance the metadata properties that will be returned will only be the basic SharePoint metadata fields like name, title etc. When you want to get your own created columns in the results you’ll have to add the property names to the to the SelectProperties object from the keywordquery.

// Set result properties
kwq.SelectProperties.Add("ProductID");

To search custom SharePoint properties you’ll have to set these properties as Managed Metadata first. After you’ve done this it’s pretty easy. You can just put “propertyname:value” as QueryText and then the search will search the property “propertyname” which contain “value”. You’ll have to put quotes around the search value because otherwise the search will also show results where the value is only a part of the property value.

Below is a full example how to create a KeywordQuery in code for in example your custom webparts.

string SSP = ConfigurationManager.AppSettings["SSP"].ToString(); 
ServerContext context = ServerContext.GetContext(SSP);
KeywordQuery kwq = new KeywordQuery(context);

// Set properties for the query before executing
kwq.ResultTypes = ResultType.RelevantResults;
kwq.EnableStemming = true;
kwq.TrimDuplicates = true;

// Set result properties
kwq.SelectProperties.Add("ProductID"); 

kwq.QueryText = column + ":" + value;
// Fetch data
ResultTableCollection results = kwq.Execute();
ResultTable resultTable = results[ResultType.RelevantResults];

// Load data into a DataTable
DataTable tbl = new DataTable();
tbl.Load(resultTable, LoadOption.OverwriteChanges);

return tbl;

Hope this will help you building your own custom search webparts in MOSS 2007

Geert van der Cruijsen

This week i ran into a problem after deploying a feature in SharePoint. I ran the stdadm command to install and activate a feature, the command returned without any errors so i thought everything was ok. When i tried to open up SharePoint in the browser all the pages gave a "403 forbidden" error

My first thoughts where that there was something wrong with the feature but this couldn't be the case because this feature was installed on multiple envoirments and they were all working ok.

After some research i found out that SharePoint didnt have enough rights in the feature directory in "program files\common files\microsoft shared\web server extensions\12\templates\features\$feature name dir"

This error can occur when you manually create a directory in the "features" directory of SharePoint. You can easily fix it by right clicking the folder, click properties, security and then Advanced. On the permissions tab delete the "Uninhereted permissions from the folder". Another option is to manually give the right users the rights to the directory.

Geert van der Cruijsen