Browse Prior Art Database

System and method for the dynamic optimization of query tables

IP.com Disclosure Number: IPCOM000197961D
Publication Date: 2010-Jul-23
Document File: 2 page(s) / 34K

Publishing Venue

The IP.com Prior Art Database

Abstract

Query Tables are a means to describe logical views onto a Business Process or Human Task Management System that are used by client applications of these systems. Query tables allow to decouple that logical view from a physical representation, increasing the flexibility of such a system by allowing to change this representation independent from a client application. This article describes a system and method for administrative selection or autonomous adaptation of the physical representation of a query table based on the requirements of the client applications and the properties of the underlying infrastructure.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Page 1 of 2

System and method for the dynamic optimization of query tables

Query Tables are used as a contract between a client application and a Business Process Management System (BPMS) or Human Task Management System (HTMS) to specify lists of business processes and human tasks. The client application retrieves a particular list by querying the Query Table. Query Tables provide an abstract specification, allowing for various physical representations. The optimal physical representation of a given query table depends on many factors, such as runtime requirements regarding the average or maximum response time of a particular query, the required currency of the data, the allowed storage space, and others. In the current state of the art, the abstract specification of such query tables is combined with their physical representation, creating inflexible systems that require manual and tedious optimization.

We propose a mechanism that decouples the definition of the Query Table from a particular physical representation and implementation. Rather we suggest a method that can be applied at the runtime of an application. As part of this method an administrator or the autonomous system itself can analyze an application, and based on certain criteria chose the Query Table implementation that best fits the requirements of client applications using that Query Table. The binding of the implementation of a Query Table and the Query Table definition occurs dynamically and can flexibly changed in the running system.

When designing a client application for Business Process Management System (BPMS) or Human Task Management System (HTMS) that has a need for showing a list of human tasks or business processes, the client developer checks if a Query Table definition is available that satisfies his needs, i.e., it has all the columns with human task and process data the client application needs to show on its UI. If that is the case the client developer uses this Query Table in his client application. If no Query Table definition is available yet he designs the Query Table, e.g., by using a Query Table design tool that lets him pick and chose the data columns provided by the system that match his needs. For example for a list of to-dos represented by human tasks he would pick the id of the human task, its display name and description, the priority of the human task and maybe some data from the human task's business context like a customer id or purchase request number.

When the client application is ready, it can be deployed into the runtime infrastructure of a Business Process Management System (BPMS) or Human Task Management System (HTMS). Deployment of the application assumes that the Query Tables it references are available in the execution environment. To provide for that, an administrator must have deployed the query table, while a particular implementation type is chosen by the system (either a default, or based on certain criteria) or the administrator....