Tau Adaptor High Level Data Objects
High Level Data Objects (HLDOs) are intended to be a machine and human readable format that documents each available database table,
stored procedure, and view in the database. They are prepared and edited in the form of Excel spreadsheets, where they are human readable,
but are automatically converted to and from XML metadata which can be loaded into ADO memory tables for efficient execution.
In this page, we will examine how the “Customer” record in code lines such as
BHinst = MXPclass("Customer","BellHawk")
are defined.
The definition process for High Level Data Object (HLDO) keywords such as “Customer” in a database such as BellHawk starts out as an Excel spreadsheet,
such as that shown below:
This spreadsheet consists of two parts the KEYHEADER and the KEYPARAMS, with one entry per name:value parameter.
The KEYHEADER contains the Keyword Name (1) and the corresponding Table Name (2) in the database.
It also controls whether the database table can be read and/or written or whether the Table Name is, in reality,
the name of a stored procedure or view in the database that can be Run.
The KEYPARAMS sections contains:
- The Field/Column names (3) in the database
- The corresponding JSON string names (4) used by Python scripts
- The corresponding Field Type in the database record (5)
- Whether the field is required
(6)– translates to True/False in Python
- Whether this is a Lookup Parameter “P” or is simply a data entry “D” (7)
Things to note:
- The parameter names, which are used in JSON strings and dictionary structures, do not have to be the same as the database field names
and can be more user friendly. This is especially true with fields in the database table that are indirect and may have obscure names as a result.
These indirections are resolved in the Tau Adaptor layer to a simple value for the parameter.
- While Python is a Dynamically typed language, it is still strongly typed.
The different types of data being looked up from the database or stored in the database, correspond to those listed in
"The High Level Data Object User Manual"
For automatically resolved indirect references, the data type is for the resolved parameter, which is retrieved indirectly.
- When performing a database lookup, as in BHInst.Lookup(ParVal1, ParVal2, ParVal3) the parameters are specified
in Column (7) above as “P” entries and up to 3 parameter values may be specified, in the order shown in Column (7).
In the example of our “Customer” record there is only one entry, but for “Customer Addresses” there are 2 parameters,
one for the Customer Number and one for the Customer Address Code.
- If a parameter “P” value is not specified, or is an empty string, in the Lookup then ALL values for that parameter are returned.
- When performing a Store into the database, the fields shown as in Column (6) above as IsRequired = 1 must be defined but other fields are optional
and will be replaced with Null values as appropriate.
- The Tau Adaptor layer will generate a database record Insert or Update as appropriate, depending whether a record exists
with the specified parameter values. In the case of “Update” it may create a new record “C” or modify only changed fields as in
DEXinst.Store(json.dumps(DEXfac), "M").
There are other entries in this spreadsheet, as described in
The High Level
Data Object User Manual but for creating Python scripts, and the like, the one’s listed above are the most important.
Data Types recognized in HLDO definitions are also listed in this document.
While Systems Administrators can create their own HLDO definitions, the
predominant use of BellHawk is to Lookup the pre-defined HLDO names and
parameters for the BellHawk database.
Copyright © SmartOpsMgt LLC 2026
