The K2 Pirate

Hello, it’s your friendly neighborhood training-content guy again with some bedtime reading

One of the benefits of this gig is that I get to investigate those things that have always bugged me in the field, like “what are those XML fields that are added to a process by the SharePoint wizards, and what’s inside them?”

The following write-up is extracted from a new learning module that will be available shortly (300.HLP K2 and Microsoft SharePoint Content Management). I thought it would be good to share what I’ve discovered since you may need to use this info in real projects sometime.

So without further ado, a breakdown of the various XML datafields added by the SharePoint Workflow process, SharePoint Events process and Item Reference event wizards:

When you use the SharePoint Workflow Integration wizard to expose a K2 workflow as a SharePoint workflow, K2 will create 4 XML datafields in the process automatically.

This (hidden) datafield is very useful to know about, since the comments entered by users during Client Events are saved into the XML field. If you wanted to include comments from the manager as to why the request was rejected, for example, you can find the manager’s comments in this XML structure. The table below describes the values saved in this XML datafield.

Showing hidden fields and the SPComments datafield

The SharePoint_Item XML datafield stores all the metadata values for the item based on the item content type. The structure of this XML datafield will vary between different lists, so we won’t list the fields in the structure here. For reference, the screenshot below just shows the type of data saved in the SharePoint_Item datafield:

Structure of the SharePoint_Item XML datafield

The SPIntegraiotn XML datafield is used by K2 to store the details relating to the K2/SharePoint Workflow integration.

The Screenshot below shows the structure of this field., and the table following describes the fields in this XML strcuture:

The SPIntegrationData XML Field Structure

The WFIProcessField XML datafield added by the wizard is a standard Content Field/Item Reference Field. The screenshot below shows the structure of this XML field, and the table following describes the fields in this structure.

The structure of the WFIProcessField

When you run the SharePoint Events process wizard, you may elect to save the metadata of the list item that started the workflow into a Process-level XML datafield.

Selecting whether to save the metadata of the item that started the workflow

The structure of this data field will depend on the definition of the list or library where the item is created, so we cannot provide a definitive screenshot or explanation of the structure. However, the screenshot and table below describe an example of this XML datafield for a sample list.

A sample XML Datafield representing the Metadata of a List Item

Note: each field has two sub-properties: Title and Name. Title is the display name of the property in SharePoint, and Name is the internal system name for the property in SharePoint.

When you use the SharePoint Events Process wizard to associate a K2 workflow with a SharePoint event, K2 will create two XML datafields in the process automatically. It is valuable to know about these datafields, since you may need to use these fields when interacting with the list item at a later stage of the workflow.

The SPEventsField XML datafield added by the wizard is a standard Content Field/Item Reference Field. The screenshot below shows the structure of this XML field, and the table following describes the fields in this structure.

The structure of the SPEventsField

The EventDetails XML datafield added by the wizard represents details about the event that caused the workflow to start. The structure of this XML field is shown in the screenshot below, and the table following describes the fields:

The structure of the EventDetails Field

Structure of the Content Field/Item Reference Field

I got this question from another client.  Now, we all know that code is the way forward here.  As it’s Friday I thought I’d have a bash at doing it with no-code, and in fairness, it’s not so bad… and with some of the conditional events techniques it could be combined into a single activity too.  Performance is 1 SmO call per table cell + 1 – i.e. not good.

There is a another method using XSL that is much better performing – I will make a blog abou that too.

And a couple of screenshots:

Note – that behind the scenes of the first activity you need to configure an advanced destination rule “plan per slot” to configure the multiple instances (loop).

The basic principle of operation for this method is that the first activity runs onces for each row of the table – each time it runs it adds to the HTML table datafield, then the second activity adds some extra html around the main table body, and sends the email.

First data event:

Second data event:

Mail event:

Result:

Happy no-coding.