Data Fields and Workflow Versions

05 Jul

Here’s our scenario… We have live workflows deployed and a fairly complex ASP.Net app as a front end. In our latest deployment we have added a few process level data fields and now the application expects to be able to read and write to those data fields. However, existing live processes won’t have those data fields so we will be looking at getting exceptions when we try access them. So what to do?

I figured there would be 2 ways of dealing with this sort of versioning. The first option is to have the process version stored in a data field which we could read and then the value of this version would tell us whether or not we can expect the data field to exist. This is fine in theory, but in practice I see there being problems further down the line, plus it means 2 reads instead of 1.

The option I decided on is to create a WorkflowDataField class and return this instead of just a string. This WorkflowDataField would not only contain the value of the data field but it would also have a result type so the calling code could check if there were errors.

Here’s my WorkflowDataField class:

    public enum ResultType

    public class WorkflowDataField
        private string m_value;

        public ResultType QueryResultType { get; set; }

        public string Value
            get { return m_value; }
            set { m_value = value; }

        public int IntValue
            get { return Convert.ToInt32(m_value); }
            set { m_value = value.ToString(); }

        // etc...

        public override string ToString()
            return Value;

Pretty simple, nothing fancy. Now when I query the data field I do something like this:

var workflowDataField = new WorkflowDataField();
    workflowDataField.Value = processInstance.DataFields[key].Value.ToString();
    workflowDataField.QueryResultType = ResultType.Success;
catch (Exception e)
    workflowDataField.QueryResultType = ResultType.DataFieldDoesNotExist;
    workflowDataField.Value = e.Message;
return workflowDataField;

Unfortunately the exception thrown is nothing more specific than System.Exception so if you want to be sure that the exception is being thrown because of a missing data field then you have to parse the exception message for ‘does not exist’.

I am a firm believer in the philosophy of not using exceptions to control program flow, but in this case I made an exception (sorry for the pun). The reasons I’m allowing myself to do this are:
1. It’s not a system exception, it’s expected.
2. Exceptions are slow and expensive, but we’d only be catching exceptions while the old instances are alive. As time goes on we’d get fewer and fewer, so in the long run it would be better performance than doing 2 reads each time.

Hope that helps someone…

1 Comment

Posted by on July 5, 2012 in K2 API, K2 Workflows


One Response to Data Fields and Workflow Versions


    August 29, 2018 at 12:23 pm

    I simply had to thank you so much yet again. I am not sure the things I would’ve used without the creative concepts discussed by you regarding that situation. This was a very traumatic situation in my view, however , noticing the very professional strategy you processed that forced me to leap for fulfillment. I will be grateful for this service and thus sincerely hope you find out what a powerful job you have been doing educating the others by way of your website. I am sure you haven’t encountered all of us.


Leave a Reply

Your email address will not be published. Required fields are marked *