Welcome to EMC Consulting Blogs

Disable form submission without digital signature

You may have a requirement that an InfoPath form cannot be submitted without a signature on it. This can be achieved very easily in InfoPath with the need for custom code.

1.       Create a section and enable digital signature on that section.

2.       Add a submit button to the form.

3.       Add a rule of formatting type on the submit button.

a.       In the rule you will see the name of the signature section. Set up a rule such that when the section is not signed, disable the button.

Programmatically clear digital signatures

                Another common requirement that you may see in the context of digital signatures and workflows is that when an approver rejects an InfoPath form and sends it back to submitter for rework, all the digital signatures have to be erased from the form. This can be done in code.

                A digital signature on InfoPath form is nothing but an xml node with encrypted data in it. Removing digital signature can be achieved by deleting the signature node. You can get a reference to the signatures on the form with SignedDataBlockCollection. A signature block can contain one or more signatures.

So to delete signatures:

if (this.Signed)

                {

                    SignedDataBlockCollection blocks = this.SignedDataBlocks;

                    foreach (SignedDataBlock block in blocks)

                    {

                        SignatureCollection signs = block.Signatures;

                        if (signs.Count > 0)

                        {

                            foreach (Signature sign in signs)

                            {

                                XPathNavigator nav = sign.SignatureBlockXmlNode;

                                nav.DeleteSelf();

                                this.CurrentView.ForceUpdate();

                                MessageBox.Show("Signature removed");   

                            }

                        }

                    }

                }

If you have spent several years developing custom SharePoint workflows and then started working with K2 blackpearl, you would notice some big differences in developing workflows using these two technologies.

One key thing to remember here is that k2 blackpearl is an enterprise workflow engine. SharePoint is not a pre-requisite for K2 blackpearl. K2 can be deployed in environments without SharePoint. However, K2 provides first class support for SharePoint. That being said let’s look at some key differences between these two technologies.

#1: Worklist items Vs SharePoint Tasks

We all know that in SharePoint world Workflow task is the corner stone of any SharePoint workflow. When we need to get end user’s input, say an approval, we create a task and assign the task to the user. In K2, this concept is achieved by using Client events. A client event creates a Worklist item for the user. This worklist item is similar to SharePoint task. But unlike SharePoint task, a worklist item is created within K2’s database.

In a normal K2 process, K2 does not create tasks in any SharePoint tasks lists. However, we can design a workflow that is centered on SharePoint tasks. But we will miss on some of the nice features of K2. They are Escalations, reporting, working hours etc.  K2 has a powerful reporting engine. In fact SSRS is a pre-requisite for K2 installation. Since the K2 worklist items are created within K2 database you can create very complex reports on how much time a person is taking to finish a task. If the workflow is mission critical one, then you can derive several business metrics from the worklist item execution patterns.

However there are some drawbacks when you compare a worklist item to a SharePoint task. In SharePoint, we can easily extend the metadata of the task. All you have to do is create new columns in the SharePoint task list. We cannot easily extend the metadata of the worklist item in K2.

In regular workflows, you may not need custom properties on a worklist item. But consider this scenario:

You designed a workflow to automate the invoice process for sales. A sales person is assigned 14 customers. Each customer is in a different region. Now you want a count of all the pending invoice approval tasks in say North East region. If you don’t have metadata on the worklist item, then it is not possible to build such reports.    

As far as I know, the only property of worklist item available for customization is “Folio”. Rest of the properties/fields cannot be modified. K2 worklist item Folio is a text property which is like Title property of the SharePoint list item.  You can use this field to embed some metadata to the worklist item. For the above example, we can set Folio as Region_CustomerName_CurrentDate.

K2 has a standard web part that displays the pending or open worklist items. While this web part is enough for most scenarios and does its main job – which is to display the pending tasks, this web part may not be suited for all your business scenarios and you may have to develop custom web part using K2 API.

In my scenario, business wanted a count of all pending tasks grouped by region. I developed a custom web part that parses the folio field and displayed the counts.

#2:  InfoPath form submission

In a normal SharePoint workflow, a user fills an InfoPath form. Upon submission, using InfoPath form’s data connections, you would save InfoPath form to the form library. Workflow will be triggered because a new item is added to the library or modified. 

In K2, after the end user fills in the form, the form has to be submitted to K2 workflow engine. Not to a form library. This is done by K2 web service. When you use InfoPath Process integration wizard, K2 adds a data connection to this web service. The job of this web service is to take the xml of the InfoPath and give to workflow engine.

If you want to save the xml in a form library, what you can do is, in the workflow you can extract the InfoPath’s xml and then save that as a file using SharePoint Document or List item event. You don’t need to write any custom code to do that.

#3: Use smartobjects where ever you can

Normally in a SharePoint workflow, when you have to reference data from a line of business system, you would develop a web service and then call that web service in the workflow. In K2, this can be achieved using smartobjects. Smartobject technology is a very powerful integration technology. In simple terms, smartobjects surface out data from various data sources. The technology is similar to BDC/BCS but not same. With BDC/BCS, you have to create an external list to bring the data from external system into SharePoint’s context. Then you can reference this data in workflows. With smartobjects, you can use Smartobject events within workflow and then call any method on the smartobject directly within workflow.

So, before you jump into Visual Studio to develop a custom web service, see how you can use smartobjects.  Using smartobjects will reduce the amount of custom code to maintain.

In my previous blog post I touched upon some building blocks of K2 blackpearl. I will touch upon some more K2 blackpearl concepts.

Client Events:

A client event is similar to a task in SharePoint world. When we need the user’s input in a SharePoint workflow, we create a task and associate a task form to that task. In a similar fashion, when we need user’s input in K2 blackpearl workflow, we use a client event.

A client event generates a “Worklist item”. This is similar to a Workflow task in SharePoint world. Worklist item represents a unit of work that needs to be performed by the workflow actor.

K2 provides 3 types of client event wizards:

InfoPath client event wizard:  

This wizard allows you to specify an InfoPath form that acts as the user interface to the worklist item. End users will action his or her task using the InfoPath form.  Note that this wizard is similar to but not same as InfoPath Process Wizard. In the InfoPath process wizard, you would specify how to start the workflow when the form is submitted. But in the client event wizard, you specify how to take action on the task.

Forms generation client event wizard:

If you use this wizard as the client event, then K2 will generate a standard aspx page that acts as the UI for the worklist item. K2 generates code-behind file also for this aspx page. This aspx page can be customized and so is the code in the c# file.

Default client event wizard:

You can specify a custom form as the UI for the worklist item. The custom form can be a custom aspx page, a mobile web page or even an Exchange form. Of course you would be using K2 API and write custom code to send the user’s action to the worklist item.

Lines and line rules:

Lines in a K2 process dictate the process flow. Activities are connected using lines. Lines have rules called as Line Rules. These rules are nothing but logical expressions that evaluate to true or false. When the line rule is true, workflow execution takes that path.  

Escalations:

Task escalation is a very common requirement that we hear in workflow projects.  Escalations are not available out of the box in SharePoint workflows and you need to build them. K2 provides excellent support for escalations.  When a worklist item is not completed in certain amount of time, you can take a special action. This special action can be one of several things like: Send an email, Go to another activity, expire the activity.

Working Hours:

Another cool thing built into K2 blackpearl is the concept of working hours. Many workflows are time sensitive and certain actions need to be completed in fixed amount of time. But at the same time, if a user does not complete his or her task, escalation clock should not start in the middle of the night and send an email to his boss saying that the user did not complete his task.

Working hours help in starting the escalations and notifications based on business and non-business hours. An administrator can setup working hours based on time zones. K2 will take into account the user’s business hours and calculate escalations based on the time zone.