Usage of DAS routines

Creation and usage of DAS is described in "T24 Application Development". The advantage besides standardization is the caching of the results. As an alternative you can use a call to EB.QUERY.BUILDER with it's 12 parameters to dynamically create a select statement (the result will be chached also).

Step 5 – Creating the Data Access Service

Introduction

All queries (i.e. SELECT operations) that are performed against a table are consolidated into a Data Access Service (DAS) for the application. This centralises all query processing for a given table in one place and removes any query language from the code. Each query is expressed in a simple meta- query language (as per ENQUIRY) that defines the fields, operands, data and joins between criteria (AND / OR).

When executed, the meta-query language generates the specific query language depending on the target database (JQL, SQL, xQuery, etc.)

This approach allows control on the DAS routines and prevents poor queries being defined. Each query in the DAS is named and has a description, and the DAS itself allows discovery of the queries that are supported. There is also a facility to cache the results of static data.

The name of the DAS is DAS.MYAPPLICATION, where MYAPPLICATION is the name of the application, e.g. DAS.EB.LOOKUP

Defining the Queries

Each query definition has two parts – the name of the query and a description of the query.

The name of the query is a simple numeric equate and is stored in I_DAS.MYAPPLICATION:


Each query name must be equated to a unique integer, as this is the pointer used in the caching mechanism. The name of the query must be prefixed with DAS.MYAPPLICATION$, and then followed by a meaningful name.

The description of the query is held in I_DAS.MYAPPLICATION.NOTES, which should be created from the template I_DAS.TEMPLATE.NOTES as it must contain a dimensioned array for the cache and the notes.
Implementing the Queries

The implementation of each query is in the DAS subroutine itself. This must be created from the template DAS.TEMPLATE, and each query is an additional CASE statement based on MY.CMD, which holds the name of the query.

In addition to the queries defined specifically for the application, the generic query DAS$ALL.IDS is defined to return all the keys on the table. It is only necessary to include this query in the DAS if this list can be cached, i.e. the contents of the table are static at run time.

Simple queries define the fields, operands and the data to query. The data may be literals:
Common variables:
Or use variable criteria that is supplied when the DAS is invoked:
More complex queries are defined by adding fields to the arrays, and specifying the MY.JOINS array:
Caching Query Results

The DAS infrastructure allows the caching of results by setting:

Once the query results have been returned, they are added to the cache mechanism and further invocation of the named select will always use the cached results. The cache must ONLY be used where the result of the query is static at run time, e.g. CATEGORY or COMPANY. Caching must NOT be used where variable data is used in the selection.

Testing the DAS

By invoking the DAS in discover mode, every query that is defined is exercised and dummy query statements are created, though not exercised:

jsh r06 -->TEST.DAS EXAMPLE All interest schedules.

SELECT F.EXAMPLE WITH SCHEDULE.TYPE EQ INTEREST



All schedules with today’s date.

SELECT F.EXAMPLE WITH SCHEDULE.DATE EQ 20060426



All deals with the supplied DEAL.TYPE SELECT F.EXAMPLE WITH DEAL.TYPE EQ ARG1



Deals that have the supplied customer AND the supplied currency

SELECT F.EXAMPLE WITH CUSTOMER EQ ARG1 AND CURRENCY EQ ARG2

jsh r06 -->

Invoking the DAS

The public API for each Data Access Service is the subroutine DAS. For full details, refer to the documentation of that routine. However, here is an example of a DAS being invoked: