Skip to main content
A couple of hopefully simple questions here, and hopefully a pointer to where I can dig this type of info up myself in the future.

I am creating a new process instance leveraging startprocessinstance. I want to get the ID for the new process as soon as it is started. How can I go about this.

In addition, what is the best practice for accessing that process right after creation? I need to open it up and set a datafield value. I do not need to complete the worklist item that is currently active.

Pointers are greatly appreciated. I am finding the help a bit clumsy to navigate right now and searching the index is causing my .chm to close.
Hi,

To get the Process Instance ID, you can get the value by accessing the ID property of the ProcessInstance object AFTER calling the StartProcessInstance method of your Connection object.

For your second question it's a bit more difficult to answer as I'll need more info on exactly what you are trying to achieve. A couple of thoughts though:
1. If you need to populate a datafield, why not do it before you start the new process instance. I'm assuming that it will be user input since you want to keep it on the same page.

2. If you want to open the next Worklist item if point 1 is not relevant, you can achieve this by starting the new proc inst synchronously (the assumption is that the next item will go to the same user that started the process). Then, open the current user's Worklist and filter the items using possibly the Folio (or any unique values) and definitely the proc inst ID to get the next Worklist item. Use the next Worklist item's Data property to get the next URL to redirect to. More info on the syntax in the Help file, look at the Connection object's methods.

3. Investigate the feasibility of populating the required datafield in the process using a server event.
Hi Guy,

No hard and fast rules here, just guidelines based on experience.

The simplest methods I find are setup of K2 datafields at the time the process is initialised. Here you have the freedom to populate the fields with the data required. This will normally be data read from config files that is needed within the process but cannot be stored in the string table. Remember here that you can hide the fields from you user on both ASP.Net and Windows forms as a "trick".

The second method I use is to have an activity as the activity straight after the start activity. Here I put all the server events I need, including custom code, to populate whatever process instance variables with default values as required.

The descision which to use, or both more often than not, is usually based on the answers to such questions as: how much logic as custom code do I want within the process, the maintenace cost, the ease of configuration, limiting the uploading of new process versions, the cost od distributing new client applications, etc.

As you see, no real answer, just a set of guidelines!

Regards
Graham

Reply