SharePoint Conference 09 Wrapup

It had been my intention to write daily blog posts from SPC09, but honestly there was just too much going, and I was tweeting all day anyway. I thought I would, however, post a summary of the things I saw and learned at the conference (well, the SharePoint things, not the “people acting silly” things 🙂 ). It was a great conference, well organized, and with lots of information – too much information actually, so much that I could not see all the sessions I wanted to and will have to wait for the videos to be posted.

There is a lot of new stuff coming in SharePoint 2010, and a lot of improvements to existing features. Before I get into my thoughts on the conference and SharePoint 2010 in general, I would like to recommend looking at this post. Tony Byrne makes some good points. For me, it can all be condensed down into one statement: No matter what the hype, no matter what fancy new features are there, always, ALWAYS, keep business needs front of mind – upgrade when there is a clear business reason, and not before. All of the features in the world will not help you if you do not know what you are building and why.

So, on to the good stuff! There are many things I saw at the conference which really make me excited about SharePoint 2010. The things that caught my interest can be broken down into the following groups:

  • General SharePoint features
  • Service Architecture
  • Office services
  • Development support and tools

General Features

I am not going to dwell too much on the general SharePoint features, as I am sure there will be lots of articles covering them. Obviously there are considerable user interface enhancements (though the design experts out there will no doubt crap on the overall UI). The ribbon interface is pretty impressive for things like editing pages, working with lists, and similar activities. I am not sure how well it applies in a more generic “web” world, and how it can be made to be non-intrusive in a highly customized deployment.

It is also nice to see a considerable amount of AJAX-like behaviour in the UI, thus greatly reducing the number of post backs and screen refreshes. This includes the new dialog framework – many of the actions which previously sent the user to a second page to collect information, and back again when the action was completed, are now done through layered dialogs (which are also customizable for consistency with your desired look and feel).

There have also been significant improvements to the capacity and scalability of SharePoint lists and document libraries.

Finally, it is nice to see SharePoint moving towards compliance with standards such as WCAG, XHTML, and CMIS.

Services Application Architecture

A major change in SharePoint 2010 is architectural – the introduction of the  Service Application Architecture. This is a replacement for the Shared Service Providers (SSPs) in SharePoint 2007. SSPs hosted such things as the User Profile Service, Search Services, and BDC Services. There were a number of deployment, scaling and manageability issues with SSPS, however.

Service Applications are a far more flexible approach. A Service Application can consist of a package of assemblies, databases, and other components which are deployed to a SharePoint App Server. The service is exposed via a proxy deployed to the WFE. This proxy knows how to talk to a custom WCF service on the App Server. The client (for example a Web Part) talk calls the proxy in order to consume the Service Application, without having to know where the Application Service is deployed – on the same farm or even another farm. The architecture also has built in round-robin load balancing.

Office Services

Among the services deployed in SharePoint 2010 are various office services:

  • Improved Excel Services
  • Improved InfoPath Forms Services
  • Visio Services
  • Access Services

I know there are some great improvements in Excel and Excel Services from the keynote. Excel rendering is improved, as in the interaction experience. Additionally, Excel Services now exposes REST interfaces, making it easier to consume server-based calculations and charts from other pages or web applications.

Something that specifically caught my interest is PowerPivot – which allows Excel to work with huge datasets in an effective way (the keynote showed it working with 100+ million rows – but that of course was a demo). I did not get a chance to go to the PowerPoint sessions, but will definitely have a look at the recordings when they are available. In the meantime, have a look here.

Something new which has been added in SharePoint 2010 are Visio Services allowing for the rendering of Visio diagrams in the browser, with interactivity and data binding. The Visio diagrams are rendered in a SharePoint web part using Silverlight technology. I already have a few ideas for how this could be applied to projects on which I am working.

Also added are SharePoint Access Services. This allows the publication of Access Solutions to a SharePoint where they can be centrally managed, and provides multiuser access and distribution difficult to achieve with an Access desktop solution.

There are a lot of improvements for developers in SharePoint 2010 and Visual Studio 2010.  So much so that I am going to do a completely separate post to cover them. To summarize:

  • Many new and improved templates in VS 2010
  • Visual designers in VS2010
  • Support for Features and Packaging in VS2010
  • Improved APIs (way too much to get into here)
  • Developer Dashboard view
  • Development support on 64-bit Vista/Windows 7
  • Improved tools in SharePoint Designer

I will be posting another write up later today specifically focused on the development improvements.

The Microsoft SharePoint Team Blog has a post summarizing these and many other features I have not gotten into here.

What’s Wrong with SharePoint?

So, I am watching Twitter updates go by (as I always do, even on a Saturday night), including my search that shows me all the tweets with “sharepoint” in them. As anyone knows who watches any amount of SharePoint commentary go by, there is a fairly constant flow of comments of the “SharePoint sucks” variety.

So this evening this led me to ask the question “What is wrong with SharePoint?” No, I do not mean I want a list of every nit picking, annoying little defect – every platform has defects and annoyances. I also do not want to know why SharePoint is note good for everything – no platform is good for everything. I also do not give a crap if your opinion is “it comes from Microsoft therefore it MUST suck” – it that is as deep as your analysis can go, well, you’re a moron.

What I want to see from SOMEONE is an intelligent, well thought out description of why SharePoint sucks. Why is it a bad choice for anything? Why should you perform an exorcism on all servers running any version of SharePoint?

I did a web search (notice I did not say “google” – contrary to popular usage, google is not a verb) for “what is wrong with SharePoint?” The only relevant results I found on either Google or Bing were written in 2005 or before, and hence are not particularly relevant at this point. For example, the post Five Things Wrong with SharePoint from back in 2005 tries to talk about what is actually wrong  with SharePoint. Even though I disagree with a lot of what it says, I will not refute it since it is so old.

So – if SharePoint is so bad…if all the otherwise intelligent people implementing solutions over SharePoint are wrong – where the heck are the statements as to what is wrong with it. So tell me – WHAT IS WRONG WITH SHAREPOINT? I really want to know, and to share it with others.

Working with Association Data in MOSS Workflows

I received a couple of comments in response to me previous post on Custom Association and Custom Initiation forms regarding how to use the Association and Initiation data collected, from within the workflow code. I had answered in my responses that you just access the AssociationData and InitiationData members of the WorkflowProperties, which return the data as XML strings. You then just work with that XML as required.

Here I will present some sample code for actually working with the XML coming from the custom AssociationData.

First, I would like to step back though and look at designing the Association Data. Typically when working with any InfoPath form, I start from the data side, and develop an XML Schema for the data (ideally, this is done as part of the overall design of the solution being developed, and includes all of the data design for the solution). The code snippet below shows the schema I developed for this example.

<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="http://t4g.com/TestSchema.xsd"
           elementFormDefault="qualified"
           xmlns="http://t4g.com/TestSchema.xsd"
           xmlns:mstns="http://t4g.com/TestSchema.xsd"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
>
   <xs:element name="AssociationInitiationData" type="AssociationInitiationDataType" />
   <xs:complexType name="AssociationInitiationDataType">
      <xs:sequence>
         <xs:element name="TaskDescription" type="xs:string" />
         <xs:element name="AssignTo" type="xs:string" />
      </xs:sequence>
   </xs:complexType>
</xs:schema>

Note that this schema represents both the Association Data structure, as well as the Initiation Data. It is necessary for these two to share a schema and namespace, though the Association form need not populate all of the fields.

A Custom Association Form can then be developed in InfoPath based upon this schema, and deployed as described in my previous post.

Now, how do we access this Association Data from within our workflow?

I implemented a simple serializable class matching the schema, as shown below.

[Serializable()]
public class AssociationData
{
   private String _TaskDescription;
   private String _AssignTo;

   public String TaskDescription
   {
      get
      {
         return this._TaskDescription;
      }
      set
      {
         this._TaskDescription = value;
      }
   }

   public String AssignTo
   {
      get
      {
         return this._AssignTo;
      }

      set
      {
         this._AssignTo = value;
      }
   }
}

I also implemented a helper class (creatively named) to support loading the Association Data into this class (note that this helper handles both the Initiation and Association data):

public class Helper
{
   public static InitiationData DeserializeInitiationData(string xmlString)
   {
      using (MemoryStream stream =
         new MemoryStream(Encoding.UTF8.GetBytes(xmlString)))
      {
         XmlSerializer serializer =
            new XmlSerializer(typeof(InitiationData), "http://t4g.com/TestSchema.xsd");
            InitiationData data = (InitiationData)serializer.Deserialize(stream);
            return data;
      }
   }

   public static AssociationData DeserializeAssociationData(string xmlString)
   {
      using (MemoryStream stream =
         new MemoryStream(Encoding.UTF8.GetBytes(xmlString)))
      {
         XmlSerializer serializer = new XmlSerializer(typeof(AssociationData), "http://t4g.com/TestSchema.xsd");
         AssociationData data = (AssociationData)serializer.Deserialize(stream);
         return data;
       }
   }
}

Given these two classes, it is then simple to access the Association Data from within the workflow. For example, add a private member to the workflow class:

private AssociationData _associationData;

Then from within the onWorkflowActivated activity, add the following code:

String AssociationDataXml = workflowProperties.AssociationData;
_associationData = Helper.DeserializeAssociationData(AssociationDataXml);

The association data can then be accessed from within our _associationData object as required. The Schema, and the AssociationData class definition, can be modified as required to add additional fields.

I was considering another post about doing the same thing for InitiationData, but it works exactly the same way. So unless someone really insists, I will not bother.

First look at SharePoint 2010 for Developers

The past week has seen quite a bit of new information being published by Microsoft regarding Office 2010 and SharePoint 2010. This is just the start, I am sure, and by the time Office 2010 is released next year, we will probably all be getting sick of hearing about it (jk). A good place to start getting a feel for SharePoint 2010 is to look at SharePoint 2010 Sneak Peek videos recently posted by Microsoft.

I had a look late last week at the new features from a general perspective – see my column over at Legal IT Professionals. In this post I want to have a look at some of the new features for developers. I will give my take on what I saw in the videos, and also mention a few things that I was hoping to see but didn’t.

The Developer Sneak Peek Video covers a number of features of SharePoint 201 for developers:

  • Visual Studio 2010 SharePoint tools
  • Language Integrated Query (LINQ) for SharePoint
  • Developer Dashboard
  • Business Connectivity Services
  • Client Object Model (OM)
  • Silverlight Web Part

The Visual Studio SharePoint tools are intended to improve programmer productivity when developing for SharePoint. A major new feature is the Visual Web Part Designer. As the name implies, this tool lets you visually design your web part UI, rather than coding it or using something like SmartPart. While the demonstration in the video is extremely simple, this tool should greatly improve the process of developing Web Parts for SharePoint 2010.

The support for Feature and Solution packaging seems to be greatly improved as well, and actually looks like it is a real Visual Studio tool rather than an afterthought.

Microsoft has also added a SharePoint node to the Server Explorer in Visual Studio. This allows you to look at the structure and content of the SharePoint site you are targeting without having to bounce back and forth between IE and Visual Studio.

Another big feature is the Business Connectivity Services design tools for Visual Studio. This is a set of tools for implementing BCS entities from within Visual Studio, allowing a developer to do more sophisticated BCS development than is possible from SharePoint Designer.

Moving beyond Visual Studio, there are a number of other important enhancements for developers.

One of these enhancements is the Developer Dashboard. This is a component which is enabled by a sight administrator, and can be added to any SharePoint page to support development and debugging. It provides diagnostic information regarding including the detailed page request, timing information, information on Stored procedures called, as well as details regarding resource usage, authenticated user, web part timings, etc. This should be a big help in troubleshooting issues.

Another addition is the addition of the Client Object Model, a client-side API for interacting with data on the SharePoint server using JavaScript, .NET code, or Silverlight.

Speaking of Silverlight, there is now a built-in Silverlight Web Part to facilitate deployment of rich UI components. The video shows a nice demonstration using Silverlight, the Silverlight Web Part, and the Client Object Model.  

While I definitely like what I see for developers in SharePoint 2010, there are a number of things I want to see but didn’t:

  1. The Visual Web Part Designer is great. I am curious, though, whether this tool will have any support for developing connectable web parts more easily? Creating the visual part of the Web Part is wonderful, but most useful web parts need to provide or consume connections.
  2. Another thought on the Web Part Designer – does it have support for developing async behaviours, or does it still have to be duck-taped together?
  3. Is there better support for development of Site Definitions, List Definitions, Content Types, etc.? This has remained a manual, tedious, and hence error-prone process. Similarly, is there support for editing of CAML for queries, etc.?
  4. SharePoint Workflow development support. The tools for workflow development in SharePoint 2007 are “ok” as far as they go, but there remain a fair number of very manual, very “cludgey” steps that make it non-trivial to implement real-world workflows, including the mechanisms for developing and using custom ASP.NET association, initiation, and task forms.
  5. Speaking of workflow, the execution environment for workflow in SharePoint is missing some pieces, most notably the tracking service. What has been added?
  6. Rumour has it that SharePoint 2010 will be running over .NET 3.5, not .NET 4.0. Say it ain’t so! So SharePoint Workflow will not take advantage of the performance improvements in .NET 4.0 – what’s the point?
  7. Does the Silverlight Web Part support connections? Or must any data flow into or out of the web part be done from within the Silverlight?

Well, those are my first thoughts on SharePoint 2010 for developers. I can’t wait to see/learn more over the coming months.

Coming soon…MOSS Workflow Examples – Custom Task Forms (using InfoPath)

The next post in this series will be coming soon, I hope – maybe the end of April.

UPDATE: Still working on this – billable work is getting in the way 🙂 I am also working on doing the next one as a webcast rather than a long text tutorial. I am curious, what do you think is the best approach to this, text or video?

 

MOSS Workflow Examples – Custom Initiation/Instantiation Form (using InfoPath)

Previously, I posted a guide to creating and deploying a very simple custom Association form for a MOSS workflow. This time, I will walk through the steps to create a custom Initiation form, and also a bit of detail on consuming the data from the Initiation form from your workflow code. To reiterate what I said in the Association form walkthrough, what I am creating here is not a form you would use in a real workflow – the intent is to demonstrate the process with as much noise and detail stripped away as possible.
As I describe in my other post, the Association form is displayed when you connect your Workflow Template to a document/form library, list, or content type (the action known as creating an association). The Initiation form is displayed when the user actual starts or instantiates the workflow on an item in a list or document library. The intent is to collect startup information for the workflow. The information collected by the Instantiation form may be the same as on the Association form (allowing the user to override the defaults) or it may be completely different information. Have a look at  http://msdn.microsoft.com/en-us/library/ms481192.aspx if you would like to see Microsoft’s definitions.
Before we start, have a look at my previous post describing my base environment for creating these examples.
1) Create a new site
I used a new web application, and a new site collection created using the Team Site template. I named my site InitiationFormDemo;
2) Create Form Library
On this new site, create a Form Library (which I named Workflow Form Library);
3) Create Task List
Also create a new Task List. I called mine Workflow Tasks. At this point, your site home page should look something like the picture below.
Initiation Form Demo Site
4) Create Workflow Project
Launch Visual Studio 2008. Create a new project. Expand the C# project tree, select Workflow, and select the SharePoint 2007 Sequential Workflow. Name the project “MyWorkflow”. The create project dialog should look like the picture below.
Create Workflow Project
5) Set the properties for the project as shown below
Workflow Project Settings 1
Workflow Project Settings 2
Workflow Project Settings 3
6) Finish Creating Workflow Project
Click finish. Normally, we would change the workflow name in the project, add some activities, some code, etc., but this is not necessary for this example. The project should look something like this.
Workflow Project
7) Create Custom Initiation Form in InfoPath
Now we will create the InfoPath Initiation Form. Launch InfoPath and select Design a Form Template. Select the settings as shown below (Form Template, Blank, Enable browser-compatible features only).
InfoPath 1
8 ) Design the Custom Initiation Form – Create Data Source for Submission
In the InfoPath Designer, select Tools | Data Connections… and click the Add button. Create the new data connection as shown in the following pictures.
InfoPath 2
InfoPath 3
InfoPath 4
Click Finish and Close to get back to the main InfoPath window.
9) Create a Custom Field for the Form
In the Task Pane, under Design Tasks, click on Data Source. Right click on myFields, and select Add to add a new field to the schema. Create a new field as shown below, and click Ok.
InfoPath 5
10) Add the Custom Field to the Form
Drag and drop the My Setting field onto the design surface, to create label and text box for it. Also add a Button control, and change its label to “Submit”. Your form should look something like the picture below.
InfoPath 6
11) Add Logic to the Submit Button
Double click on your Submit button to display the Button Properties dialog. Click on the Rules… button, and click Add and then Add Action. Select options as shown below, and click Ok.
InfoPath 7
Click Add Action again, and set the options as shown below, and click Ok.
InfoPath 8
You should now have two actions, as shown below.
InfoPath 9
12) Set Form Security Level
Finally, we must set the form trust to Domain. Select Tools | Form Options…, and select Security and Trust. Unselect the checkbox Automatically determine security level (recommended), and click the Domain radio button, as shown below, and click Ok.
InfoPath 10
13) Save the Form Template
Save the form to disk (File | Save). You can save it anywhere you want, as long as it is not your Visual Studio project folder. I just save mine to a Forms folder in My Documents. Name the form MyInitiationForm.xsn for this example (in practice you can name it whatever makes sense).
14) Publish the Form Template
Now we want to publish the form. This did not entirely make sense to me, but when you select File | Publish…, on the first page of the publish dialog we will select To a Network Location even though we will actually publish it to our Visual Studio workflow project folder.
Publish 1
Click Next, and then browse to the location where you will publish the form. In this case, we want to publish to your workflow project folder, as shown.
Publish 2
Type a name for your form (I used MyInitiationForm.xsn), click Ok, and Next. On the next form, clear the text box and click Next (this is important, the form will not work if you do not clear that text box!)
Publish 3
When you click Next, a warning will pop up, as shown below. Click Ok to continue.
Publish 4
Click Publish and Close, and then exit InfoPath.
15) Retrieve Form ID to Use in Workflow Project
In Windows Explorer, navigate to your workflow project folder, right click on the InfoPath form you just published there, and select Design. When the form opens in design mode, select File | Properties… to display the properties dialog shown below.
Get Form ID
Select the ID as shown, and copy it to the clipboard. Click Ok and exit InfoPath.
16) Modify Workflow Project to Reference Custom Initiation Form
Go back to Visual Studio 2008, and open you workflow project if it is not still open. Open the workflow.xml file. The default file looks like this:
<?xml version="1.0" encoding="utf-8" ?>

<!-- Customize the text in square brackets.
     Remove brackets when filling in, e.g.
     Name="[NAME]" ==> Name="MyWorkflow"
 -->

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
   <Workflow Name="MyWorkflow"
             Description="My SharePoint Workflow"
             Id="0d94af3a-45e7-4035-b351-9a10fc41018d"
             CodeBesideClass="MyWorkflow.Workflow1"
             CodeBesideAssembly="MyWorkflow, Version=1.0.0.0, Culture=neutral, PublicKeyToken=96c40524715e44e9">

      <Categories/>
      <MetaData>
         <!-- Tags to specify InfoPath forms for the workflow; delete tags for forms that you do not have -->
         <!--<Association_FormURN>[URN FOR ASSOCIATION FORM]</Association_FormURN>
         <Instantiation_FormURN>[URN FOR INSTANTIATION FORM]</Instantiation_FormURN>
         <Task0_FormURN>[URN FOR TASK (type 0) FORM]</Task0_FormURN>
         <Task1_FormURN>[URN FOR TASK (type 1) FORM]</Task1_FormURN>-->
         <!-- Modification forms: create a unique guid for each modification form -->
         <!--
         <Modification_[UNIQUE GUID]_FormURN>[URN FOR MODIFICATION FORM]</Modification_[UNIQUE GUID]_FormURN>
         <Modification_[UNIQUE GUID]_Name>[NAME OF MODIFICATION TO BE DISPLAYED AS A LINK ON WORKFLOW STATUS PAGE</Modification_[UNIQUE GUID]_Name>
         -->
         <StatusPageUrl>_layouts/WrkStat.aspx</StatusPageUrl>
      </MetaData>
   </Workflow>
</Elements>
Paste the ID from your InfoPath form properties into the <Instantiation_FormURN> element, and uncomment the element (be careful that the other commented out elements stay that way – or delete the ones you are not using as I did):
<Instantiation_FormURN>urn:schemas-microsoft-com:office:infopath:MyInitiationForm:-myXSD-2009-04-06T02-58-49</Instantiation_FormURN>
Of course, your actual URN will be different than mine.
Add the following new attribute to the <Workflow> element:
InstantiationUrl="_layouts/IniWrkflIP.aspx">
Your workflow.xml file should now look something like this:
<?xml version="1.0" encoding="utf-8" ?>
<!-- Customize the text in square brackets.
     Remove brackets when filling in, e.g.
     Name="[NAME]" ==> Name="MyWorkflow"
-->
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
   <Workflow Name="MyWorkflow"
             Description="My SharePoint Workflow"
             Id="0d94af3a-45e7-4035-b351-9a10fc41018d"
             CodeBesideClass="MyWorkflow.Workflow1"
             CodeBesideAssembly="MyWorkflow, Version=1.0.0.0, Culture=neutral, PublicKeyToken=96c40524715e44e9"
             InstantiationUrl="_layouts/IniWrkflIP.aspx">
      <Categories/>
      <MetaData>
         <!-- Tags to specify InfoPath forms for the workflow; delete tags for forms that you do not have -->
         <Instantiation_FormURN>urn:schemas-microsoft-com:office:infopath:MyInitiationForm:-myXSD-2009-04-06T02-58-49</Instantiation_FormURN>
         <StatusPageUrl>_layouts/WrkStat.aspx</StatusPageUrl>
      </MetaData>
   </Workflow>
</Elements>
Save the file and close it.
17) Make Sure the Custom Initiation Form will get Copied With the Workflow Feature
Next, open the feature.xml file. It will look something like
<?xml version="1.0" encoding="utf-8" ?>
<Feature Id="15fdd97f-db32-44c1-96cc-cab49acecd36"
         Title="MyWorkflow feature"
         Description="My SharePoint Workflow Feature"
         Version="12.0.0.0"
         Scope="Site"
         ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
         ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver"
         xmlns="http://schemas.microsoft.com/sharepoint/">
   <ElementManifests>
      <ElementManifest Location="workflow.xml" />
   </ElementManifests>
   <Properties>
      <Property Key="GloballyAvailable" Value="true" />
      <!-- Value for RegisterForms key indicates the path to the forms relative to feature file location -->
      <!-- if you don't have forms, use *.xsn -->
      <Property Key="RegisterForms" Value="*.xsn" />
   </Properties>
</Feature>
Find the <ElementManifests> tag, and under that, add a new <ElementFile> element inside it as shown:
<ElementManifests>
   <ElementManifest Location="workflow.xml" />
   <ElementFile Location="MyInitiationForm.xsn"/>
</ElementManifests>
Save the file and close it.
18 ) Rebuild your workflow solution, and deploy it.
19) Test it Out
Back in IE, navigate to your form library. Since I’ve not created a custom association form in this example, you can create the association using the default form (if you have set up your project to auto-associate, you will not need to do this manually).
Since we want to initiate a workflow, first we need to add a document to the library. I just clicked upload and selected a random file from my desktop. Hover over the file you uploaded and left-click to bring up the context menu. Select Workflow from the menu. Then click on MyWorkflow to start the workflow. This should bring up your custom instantiation form as shown below.
Start Workflow
Enter some text, and click Submit. You will see an animation showing that MOSS is working, and then you will be brought back to the Form Library page. The status of your workflow should show as complete, since the workflow does not actually do anything.
20) Accessing the Initiation Form data in your workflow
I will now quickly show how to access your initiation data from your workflow. We will simple pull out the string entered and log it.
Open your workflow project in Visual Studio, and open your workflow in design view. Add a new logToHistoryListActivity as shown below, and set the HistoryDescription property as shown (set it to a String Field named HistoryDescription in your workflow).
Add LogToHistoryList LogToHistoryList Properties
Right click your logToHistoryListActivity and select Generate Handlers. In the event handler, add code as show below:
public String HistoryDescription;
private void logToHistoryListActivity1_MethodInvoking(object sender, EventArgs e)
{
      String MySettingValue = workflowProperties.InitiationData;
      HistoryDescription = "Initiation String Entered: " + MySettingValue;
}
Rebuild and deploy your workflow, and execute it as in Step 19. Click on the Completed link as shown below.
In the Workflow Status you will now see a history event as shown below, and the initiation string is shown as an XML string, with a <MySetting> element and the string I entered. To use this data in a workflow, you would parse the XML and go from there (or generate a class from the schema and load the XML into that).
Workflow Status
Well, there it is. A custom Initiation form using InfoPath.
Next time – custom Task forms!