SharePoint Workflows Config alternative using InfoPath Forms

I recently wrote a workflow that will use the SharePoint Object Model to manipulate sites or just about anything you want. I seperated the functionality of the workflow from the actual sites manipulation into two assemblies. One for the SharePoint Sequential Workflow and one for the SharePoint sites manipulation. Iwanted my manipulatingassembly to incorporate a Config file. Where would I place the config file? the following is an alternative, that was useful in what I wanted to do with my config file.

   If you have ever developed workflows, you know that the assemblies are placed in the GAC. Well, the config files would have to be stored in the GAC as well. My workflow doesn't access the web.config for the site, and alternatives to map a config to a location on the local machine wasn't quite working either. I think it had issues with security. What I decided to do is store a 'Config' file in SharePoint.

   The biggest draw for doing this was to have an accessible file where specific users could actually edit the config file. What better place than a SharePoint Site. I also used InfoPath forms to create a more ascetically pleasing config file that non-technical users can edit.

   Step 1: create an info path form: this is a sample of the field that 

I stored as "Approvers"

this means that the key value pair looks like this:   key: Approvers   and value: "Approvers". (The Text field is actually called 'Approvers')

Not the best example because they are the same in this case but an authorized end user could change the group name of approvers to be the site 'Members' or any other created group name. When the workflow runs it will look at the value entered in this field to get the name of the Approvers group.

Step 2:  using XSD.exe you can create a class to serialize your infopath form. First, in InfoPath under file>>save as source. This will create a file called myschema.xsd.  Then using XSD.exe use the command:    xsd myschema.xsd /c

this will produce a class you simply rename, it looks like the following:( I renamed it 'workflowConfig')

You see that it has a property exposed to you. If you have multiple properties, more will be created for you. I used reflection to then be able to access the properties like you would a config file. 

this method is added to the class that was created for you by the XSD.exe. 

Step 3:  Access the Config file stored in SharePoint.

   this step requires you to access the root site and the Form Library that stores the config file and then deserialize  the form with your generated class.

As you can see, you have to send a rootURL of the site, and access the document Library called, "Configurations" and since there is only one entry in that Forms Library, you can just use the first entry in the library to access our config file.

Step 4: Use the Config File.

This static method was placed in the Manipulating DLL as you can see the Class is called "Create", but it access the local static method called "getConfig" which was posted earlier. Reflection gave us the ability to access the config file like a key value pair. this Method will give you the email of the first user in the "Approvers" group in SharePoint.  If you were to change the approver group, an end user can change the config file or InfoPath form in SharePoint and the code would read a new Group and therefore a different UserEmail. Also if the a different user is added to the group, the new user's email will be read by your code. 

Hopefully this helps, as you consider some alternatives to doing something similar. I know that there are details missing in this post but I will update this post when I have time and go through some of the detail that I missed. Any questions, let me know. 

 Good luck

Juan

Workflow InfoPath forms stuck on "Installing" issue fix

I receantly worked through a workflow that implented InfoPath forms. InfoPath forms are really handy because of the designer capabilites. You can drag and drop controls and no code is really required. The hosting SharePoint aspx page runs all the code and so you don't have to have the InforPath form doing any of the required code.
I was done with my workflow and I deployed my solution to the target site collection. When I tried to bind the workflow to a document library I would get an error. The error was saying that the infoPath form was not workflow enabled. I also changed my web.config file to spit out a stack trace and this is what I got.

Value cannot be null.
Parameter name: g at System.Guid..ctor(String g)
at Microsoft.Office.Workflow.WrkAssocPage.AssociationOnLoad(EventArgs ea)
at Microsoft.Office.Workflow.CstWrkflIPPage.OnLoad(EventArgs ea)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint,Boolean

includeStagesAfterAsyncPoint)


I soon figured out that either something was wrong with my WrkAssocPage.aspx or the hosting aspx pages or there was really no info path form sent to those hosting pages.

So, I checked SharePoing Central Admin to see the status of my InfoPath templates. Go to "SharePoint Central Admin >>Application Management>>" at the bottom of the page you will see Info path form Templates link. Check the status of your IP templates. Mine were stuck on status, "Installing" and they were marked as "NOT" workflow enabled.

If this is happening to you. This is what fixed it for me. Recall the steps you took to save the IP template.
1) you should have set the security setting to "domain".
2) you should have changed the controls ot only be web enabled. (controls that are not web enabled, ie. rich texbox field, will cause this problem)

3) and the MOST IMPORTANT, when you publish your IP you should save it to your Visual Studio project folder of your workflow. After you choose the location the publish wizard will ask you to enter an "access path". DO NOT FILL IT OUT! leave it blank, it will then give you a half error, just click 'OK', and finish with the wizard.

if you fill out an 'access path', well, the IP form will remain in that 'installing' state, and it will not be usable.

IF you have already deployed your solution and you are experiencing this problem there are a couple of things you have to do first.

1) deactivate the feature from the site collection
a) go to your site
b) go to 'Site Actions'
c) go to the 'Administration section' under 'Site Collection Features
d) find the feature(ie, your workflow feature) and deactivate it.
2) unistall the feature using stsadm.exe
a) stsadm.exe -o unistallfeature -filename


3)Delete the IP templates you published to the project folder
I just tired to republish the templates and it would not allow me to. Because it did not
ovewrite the old ones.
4) Publish the templates again to the project folder.


hope this saves you a lot of grief. The one thing I can suggest is to change the web config file of your site collection to spit out the stacktrace for better error reporting. I found a how to here:

http://www.sharepointblogs.com/michael/archive/2007/06/28/sharepoint-under-the-hood-see-real-error-description-and-callstack-stack-trace.aspx



Good luck

Juan