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!
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.
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 nblackpearl], 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.
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?
