This document aims to explain the concept behind Data on Demand, including best practices.

Overview
"Data on Demand" is a feature which minimizes the load placed on server resources when a large volume of data from the K2.net® 2003 database is requested by the K2.net® 2003 Server and Worklist.
 
When a process instance is loaded by the K2.net Server, (previously all process data associated with the process instance would be loaded at the same time) this creates a resource drain as not all the data fields are required at the same time to perform a step within the process. However, since all the data has been loaded, the system must manage the data contained within memory even though only a small portion of the data may be affected at that time.
 
If the "Data on Demand" feature is not enabled, or if an older version of K2.net 2003 is used, all the data is transferred to the K2.net Server and then to the IIS Server where the K2.net 2003 Workspace is hosted. It is not necessarily the amount of data in memory that can be problematic, the bandwidth limitations between K2.net 2003 Server and the SQL server can be the source of the problem.
 
To make use of the "Data on Demand" feature, it must be enabled when the field is created. When "Data on Demand" is active, only the fields required at that time will be returned by the server when the request for data is sent through to the server. In other words, the data must be "demanded" as an explicit call for it to be loaded into server memory and passed to the client application.
 
To illustrate: When the Worklist Items within Workspace are displayed on screen, what you see is now only a reference to the available Worklist Item/s. No data has been requested from the server as yet, and no data has been loaded into the appropriate objects. Once a Worklist Item is opened, then the values for the data fields required are populated and returned, making the data available for use.
 
To clarify this: When a process which has data fields with "Data on Demand" enabled, is loaded into memory, these data fields aren't loaded with it, but rather only "pointers" to the data are created. Once the data is requested, the server will make a call to the K2.net 2003 Database and return the data.
 
This feature then economizes bandwidth usage in that only the data required is requested and loaded by the client application into local system memory, rather then loading unnecessary data from the server, to the client application.
 
Shown in the diagram below, the data available in step 1 is not the same data available in step 2 as two separate requests for data were sent through to the server on two separate occasions and only the data requested was returned by the server.

  

 
The "Data on Demand" feature is helpful in cases where data fields store large amounts of binary data, XML or long string values. However, it is not recommended to use "Data on Demand" for data fields containing small amounts of data - this will minimize the amount of calls made to the K2.net 2003 Database by only making a single call when the process is loaded and loading the data fields along with the process.
 
We do recommend that in environments where large numbers of Worklist Items are expected the "Data on Demand" feature is used as this will limit the amount of data routed through IIS into the Worklist section of the K2.net 2003 Workspace.
 
Regarding custom work lists we recommend that the data fields you wish to expose should not have "Data on Demand" enabled.
 
How to enable "Data on Demand" for Data fields and XML fields
To create data fields and mark them for "Data on Demand", create the data field as normal in the K2.net 2003 Studio and check the "Data on Demand" checkbox located at the right bottom of the wizard screen.

  

  

 
Data on Demand - Best Practice
Use Data on Demand for:
  • Large, String or Data fields: Determining what is "large" mostly depends on factors such as the infrastructure, the number of possible Worklist Items etc. The idea with this is to minimize network traffic, so if thousands of Worklist Items are expected, then a string data field of 20kb could be set to be enabled for "Data on Demand", but in the case where only a few Worklist items are expected, it would not make sense to enable a 20kb string data field for "Data on Demand". Also, keep in mind the amount of network traffic the physical network can handle, as this should also play a part when deciding whether or not to use "Data on Demand"
  • XML fields
  • Files attached to processes using binary data fields
Note: It will never be necessary to use "Data on Demand" for any numerical data fields, as this will always be small amounts of data.