Storing Business Data on Process Instance

  • 26 July 2007
  • 4 replies
  • 3 views
D
Badge +5

Our client requires the ability to store business imformation on a process instance in order for this to be displayed on the workitem list.


I guess there are 2 ways of doing this store the information in process datafields as free text or store the ID of the business data in process datafields and when the workitem list is retrieved look up the ID's text in the application database.


Both ways pose issues;


1) If we store the information as hardcoded text as process datafields we will need to ensure this is kept updated if the business data changes and there is also an issue that audit history will never be updated.


2) If we store the information as ID's mapped to data in our application database there is the overhead of looking up the ID's when we retrieve the workitem list to display the data to the user.


Does K2 offer any other ways of providing this or is the general rule to only store workflow routing data on the process instance?

4 replies

S
Badge

It sounds like the information being stored/displayed is static information (reference to "hardcoded"). Is that correct?


If the information is going to be the same static infomation across all process instances, you could also create String Table variables for each of the items that are to be hardcoded. You still have the problem with not being able to audit the values, but it makes updated the information easier (don't have to open the process, update the values, and export again).


Just a thought.


- Schap!

S
Badge +8

This is a very good question which every workflow developer should ask.


Unless you have very special requirements for the Business Data, my recommendation would be to store everything in K2 as Process/Activity Datafields for the following reasons:


1)     K2 will store the data in SQL, so whether you store it in an external table or in K2 Datafields, it’s stored in SQL


2)     You won’t have to make tough decisions on which fields will be in K2 (for routing/business logic) and which will be external – and during process design you won’t have to continuously move fields from K2 to external and vice versa as the requirements change.


3)     If the data is such that it can be represented in the simple data types (string, date etc) you can store the data in a K2 XML Process/Activity field.


4)      Business Data which already exists in external tables and which is used to populate drop-down etc. does not have to be duplicated in K2, with these you can store only the ID in K2 and use a data layer web service to get the details.


Note: String Table variables should only be used to store workflow configuration data. It is like a “process.config” file for K2 processes. You should not store business data in them.

J
Badge +9

Just to add my 2 cents here.  I would say it depends on your requirements.


 Storing the data in the workflow process has it benefits as mentioned by Smiddie.  However, storing too much data can be a performance issue later on for search reports.  If the data is stored in an existing external data store (e.g. finance or HR system), this could also lead to duplicate data in your network.


 Leaving the data outside in an external datasource helps to keep the processes lean and mean but has the downside of loss of K2 auditing capability and also you have to do a bit more work on the front end forms to pull the data.  However, have the data external has some advantages of making it easier to generate reports in certain cases.


In our next generation production, K2 [blackpearl], this will change drastically due to our introduction of the SmartObject architecture.  This allows us to easier pull data from configured business entities (aka SmartObjects) from within Forms or within the process.  This gives us the power to keep non-workflow related data external to the process while being able to easily pull the relevant data into work forms for use.

D
Badge +5

Storing ID's looks the best way however when you perform a K2ROM.OpenWorklist and display the work list items for each process/activity instance datafield which has an ID that maps to some data in the application database i.e UserID maps to UserName or Case ID maps to Case Name. There will be an overhead in performing this mapping for each worklist item.


I reasonably happy with this overhead but I would like to check that there is no clever way in K2 to perform these mappings or if there is a better solution to handle this?


 

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings