There is a way to access the K2 API from the reference event, although I will make the disclaimer that this is not supported in blackpoint. I will go over the steps of calling the GoToActivity method of the API from a reference event within the K2 designer.

Within K2 designer, you will need to drag a reference event onto the workspace.

 

Configure an event name for the event, and after clicking next, you will come to a screen within the wizard to add a Constructor.

The next wizard you will want to click the "Add Reference” button and browse to “C:\Program Files (x86)\K2 blackpearl\Bin\SourceCode.Workflow.Management.dll” (if using a 64bit server). Select this DLL and add it to the list of available managed process references.

Click finish and then on the wizard where you select the constructor, expand the nodes as follows: SourceCode.Workflow.Management – SourceCode.Workflow.Management       – WorkflowManagementServer  select Constructor(String host, UInt32 port).

For the configuration properties of the constructor, enter the following: host: value is the server name of K2 port: value is the port that the K2 server is running on (typically 5555)

Once this constructor has been added, you will be brought back to the main wizard screen for the reference event and now it will allow you to add a Method event.

After you click the add method option, you will need to expand the WorkflowManagementServer node and scroll down and find the method Open()

Select Next and leave the default values for the configure properties and click Finish

Once more on the reference event main screen, click Add Method and expand out WorkflowManagementServer and find the method GoToActivity(Int32 procInstID, String activityName) : Boolean

After clicking next, you will need to configure the method. The only values you need to worry about populating are the procInstID and activityName. procInstID – identifies the K2 process ID that you want to perform the GoToActivity method request. This values can be accessed many different ways. For my example, I stored the K2 process ID of my workflow in a SharePoint list and I called this workflow on the update of the list item (using the SharePoint event integration process within K2) and stored the ID in a data field. activityName – this field refers to the Activity in question that you want to “Go To”. If you reference the correct process ID, you can call an activity in any K2 process as long as you have the activity name correct. Click Next after configuring these 2 values, leave the connection properties as default (empty) and click Finish

At this point, you are done configuring your Reference event and it should look like the screenshot to the left. Click Finish and you are done with the reference to the K2 API. Build and Deploy your process and test it out.

Sometimes, when using K2 blackpoint or K2 blackpearl, you encounter InfoPath forms that you only have one choice in the workflow. For example, you have an InfoPath form that the originator fills out and submits to IT. Then, IT fills out the required information and submits the form to accounting. No decision is made, just filling out the information needed and submitting the form. With the InfoPath client event, you need to specify a task action field to direct the outcome of the process. Usually, the client event wants you to bind to a drop down, but if you already know the outcome, this isn’t necessary.

The solution:

Open up the InfoPath form in design mode from K2. Add a new field to the data source of data type string (ie. TaskActionSubmit). Set the Default value to Submit. Save the form and close it. Once K2 has let you know the form template has been updated, go to your InfoPath client event and below in the Task Action field, select the field you just created.

When you click Next, a popup will ask you if you want to change the drop down configuration. Select NO.

Click Next through the wizard until the Actions screen. Add an action called Submit (the same value you put in the default value field for the node you created in the data source of the InfoPath form). Check the box for generating a line for outcomes. Do the same for the outcomes screen. Then click Finish.

At this point, when you run the form, when the user clicks the submit button of the form, it will use the action field that you bound to direct the workflow.

From my own personal experience and hearing the frustration of others, there are some times when integrating an InfoPath form that it won’t display the correct view on certain activities. Usually, this is a random occurrence and will result in the form displaying the default view instead of the desired one.

Well, now, this problem can be resolved with a very easy fix! More then likely, at one point in the process, you were creating views, and either created, renamed or deleted a view. As a result of this, entries should be either modified in the manifest.xsf of the Form template. However, for some reason, this doesn’t always occur and will cause inconsistencies.

If you are experiencing the problem of the correct view not displaying, more then likely a RULE is not configured properly in the open behavior of the form. To verify this, you can go to the form option and select the Open and Save category from the options and select the Rules button in the Open behavior section. This will give you a list of rules that will fire upon opening of the form. K2 sets these rules based upon your configuring of the InfoPath client event in each activity.  While you have these rules open, copy the template file from the K2 InfoPath Form Template folder and rename it with a .cab extensions. This way, you can extract out the manifest.xsf file locally.  Search for the ruleSet section named "ruleSet_OnLoad” and you will more then likely see a discrepency between the rules displaying in the form options and the ones in the manifest.xsf.

The Fix (K2 blackpearl or K2 blackpoint)

Here are the steps you need to take to resolve the problem:

• Open up the InfoPath Integration process wizard in either K2 blackpearl or blackpoint
• Click on the Design button
• When the form loads, go to Tools/Form Options select the category Open and Save
• Click the Rules button under the Open behavior section
• Select one of the rules and select “Modify”.
• Click OK
• Click OK again until you are out of the Form Options
• Save the form
• Close the form
• K2 will tell you the form template has been successfully been updated

What this does is resets the rules for the form options and cleans out the ones that are empty in the manifest. (I actually added an generic rule and then went back and deleted it and this also force the form to refresh).

At this point, you can go back to the InfoPath client events and associate the event with the correct view and finish the wizards. If you go back and open the form, it should have the new rules associated with the views that you just associated with in the wizard.

Deploy the process as usual.

If you want to add a control to your InfoPath form to do an active directory lookup, then the Contact Selector Control will work for you. In order to add this control to your form, there are some certain guidelines that need to be followed.

DOs:

To add the control to your form, you first need to make it available in the custom control section of your design controls section. To do so, you need to do the following:

1. click on the Add or Remove Custom Controls … link
2. click Add when the dialog box appears
3. Select ActiveX Control and click Next
4. A list of controls will appear, scroll down until you find “Contact Selector” and click Next
5. Select the Don’t include a .cab file, click Next
6. Select the Value binding property and click Next
7. In the Field or group type dropdown, select Field or Group (any data type), click Finish

At this point, the control will appear in the Custom section of your controls. Drag the control to your form. You are now ready to configure the control.

If you right click on the contact selector and go to its properties, select the Items tab and it will show you the basic structure of how you need to set up the Data Source group. This is where InfoPath will get picky and will give you problems if you do not follow these guidelines exactly. The Data Source node should be as follows:

MyGroup       {group}
     Person                     {repeating group}
          DisplayName       {field – string}
          AccountId            {field – string}
          AccountType        {field – string}

MyGroup can actually be whatever you want to call it, but the other nodes, need to be spelled EXACTLY the same and are CASE-SENSITIVE!

One last item needs to be added to the form for the control to work. You need to create an empty text document and input the following line of xml into it:

<Context siteUrl=”http://myserver/” />

Save the file as Context.xml and make note of it’s location. Then proceed to create a new Receive web service data connection that points to the XML file you just created and name the Data connection as Context.

That is it, it is ready to go!

DON'Ts:

As mentioned above, the guidelines need to be followed exactly or you will run into problems with your InfoPath form. If you run your IP form against Design Checker, it will show you that there is no problems, but if you upload the form to SharePoint and try to access the form, you will get an error. Here are some factors that would cause your form to not render correctly if you’ve added the Contact Selector control to your form:

1. Misspelled one of the data source field nodes in the group your created
2. Fields are case-sensitive, and weren’t created with the correct case
3. NO EXTRA fields can be added to the group or repeating group.

If you were to do one of the above mentioned mistakes, you could possibly see this error when you upload your form to SharePoint and use it within a Form Library:

If you were to look at the SharePoint logs, you would see the following error:

Exception Type: System.NullReferenceException  Exception Message: Object reference not set to an instance of an object. 

If this is the case, check to see if you made one of the 3 mistakes above. If you did, make the appropriate change and you should then upload your form again and see it display correctly.

There will be times that you will find yourself wanting to update a particular value in a repeating table and/or populate details based upon a selected row in a repeating table. This can be done fairly easily by code.

Two of the ways that I accomplished this was either through adding a button to a column in the repeating table or on the “Changed” event of the control in the repeating table. In most of my cases, I had a line number for each row, so I just used that value to reference the row, but if you are wanting to pull certain details from that row, you will need to reference the applicable node.

For the button, btnAdd, click event, it only requires you to call the SelectSingleNode of the XPathNavigator to obtain the value needed in the current row.

   1: public void btnAdd_Clicked(object sender, ClickedEventArgs e)

   2: {

   3:     XPathNavigator DOM = e.Source.CreateNavigator();

   4:     iRow = DOM.SelectSingleNode("my:Item", NamespaceManager).Value;

   5: }

However, if you are trying to obtain the value from the Changed event of a control in a repeating table, it requires a little more code. One thing to note is that you need to check to see if the row is empty before checking for a value, or the call will throw an null reference error. In this example, I’m calling the changed event on a text control and checking to see if the InnerXML is empty. I use the MoveToParent method of the XPathNavigator to access the sibling of the current field in the row of the repeating table.

   1: public void it_totalCost_Changed(object sender, XmlEventArgs e)

   2: {

   3:     XPathNavigator DOM = e.Site.CreateNavigator();

   4:     DOM.MoveToParent();

   5:     if (e.Site.InnerXml != "")

   6:     {

   7:         int row = Convert.ToInt32(DOM.SelectSingleNode("my:it_Item", this.NamespaceManager).InnerXml);

   8:     }

   9: }

*One thing to note, that in the Changed event, the “e” event arg is an XmlEventArgs, which is different then the clicked events (ClickedEventArgs).