Relational Replication enquiry FAQs

What types of enquiries should be designed using RR? If any of the following apply:

The enquiry has multiple selections:

The enquiry has multiple sorts.

The enquiry uses a large base file with data being selected from a very large base.

Then the enquiry will probably run more efficiently if RR is used.

What types of enquiries should not be designed using RR? If any of the following apply, RR should not be used:

Enquiries that need real-time (or very close to real-time) information. RR uses a copying process and is not real-time.

Enquiries using only text fields (for example CLOB data). In such a case, RR enquiries are no faster than normal enquiries. So there is no advantage in using RR.

Enquiries that do selection or sort on a multi-value or sub-value field, in TAFC, as the read happens. This works very efficiently in TAFJ so there is no need to use RR to speed things up.

Enquiries using MATCHES criteria on a numerical field. This is less efficient using RR.

Enquiries that update data in the transactional live database as part of an enquiry boundary. These can cause data integrity issues as RR is not real-time.

Enquiries with conditions such as NOT EQUAL TO. These will take longer with RR as a full database scan is performed.

Can I build NOFILE enquiries using RR? NOFILE enquiries can be built using RR (apart from file enquiries).
If the required file is replicated on RR, then use API RR.REPORTINGDB.OPF. This API will read the file from the RR database if it is there. Failing that, it will read it from the live database. The file opened by this API should be used for any F.READ from the RR database. Note that NOFILE does selection and data building for page output upfront. This means that it is generally less efficient that normal file enquiries. You should only use NOFILE to collect data from multiple independent sources. As a good practice check if NO.SORT.OPTION is included in enquiry design. If present then use SELECT. Otherwise, only use SELECT for a desired order of display in correct sorting order.

Are all the design features of enquiries on the live database also applicable for enquiries based on RR. Or are there any limitations? There is no known limitation when using RR.
All enquiry features are applicable to RR. This includes build routines, ‘R’ hook routines, conversions, display breaks, header data position and zero record display.

Should we apply “Link Conversion” from RR to the live database to take data from another table? This can be used for a single link for a single field. It will then be more efficient.
This should not be used for multiple links or multiple fields from the same application. In such a case, use a conversion routine. This is to avoid connecting to the RR database for every field.

Is it possible to limit the number of keys selected for given matching criteria? Yes. In SPF use field SAMPLE.SIZE to limit the number of keys to be retrieved. This applies system wide. Refer to the field help text for more information.

Can we use enquiries based on RR product in an enquiry report? Yes. RR based enquiries can be used in a enquiry report in a similar way to enquiries on a live database.

When the main file enquiry is based on RR, should I also change drill down enquiries to use RR? You can base drill-down enquiries on RR, or they can access the live database.

Can RR be used if a bank has a DL product and files are present in a live and read only DLM database? Yes. Files from the live and DLM database will be replicated in the RR database. So you can enquire on data from both databases.

What are the pre-requisite to build a new enquiry using RR? Please refer to the RR user guide for configuration. Also make sure the following apply:

All data present in the database has been replicated in the RR database using the RR initial load processing service.

There are no data quality issues in the replicated file. Check there are no data size mismatches (for example, field length has been specified as 35 but the actual field length is 50). Correct any such issues in the live database using APIs such as F.WRITE and F.MATWRITE. When the data is correct, capture it and replicate it in the RR database.

RR error queues must be carefully monitored. Any exceptions must be corrected.

The enquiry data file name must be suffixed with $RR. For example STMT.ENTRY in the live database should be matched by STMT.ENTRY$RR in the RR database.

For all NOFILE enquiries, RR.REPORTINGDB.OPF must be used to open the file and F.READ or F.MATREAD must be used to read the data.

Normal enquiries can use selection criteria from multiple applications. Is this also possible with RR? Yes. You can use named views to do a direct database call. This is normally the fastest way to retrieve data. You can also use these views to retrieve data using multiple applications.
These views can be called using RR routines provided by the enquiry framework, and also in build routines. The retrieved keys can be passed in selection criteria. Note the following:

A view should be created for all companies where the table is configured to be replicated. VOC should be maintained to establish links.

Open and read should be performed using appropriate company-specific views.

If all the selection criteria are defined upfront at design time (as a fixed selection/sort), or if the selection involves local reference fields with fixed values, then the keys can be retrieved directly from the views. In such a case, to avoid selection from the enquiry framework, use the common variable ENQ$SKIP.SELECT.

If some of the selection criteria are not available at design time, then the user may be able to provide this information at run time. This can be done using the R routine to retrieve matching keys from the RR database.

In such a case, do not use ENQ$SKIP.SELECT. This is because actual selection can be done again by the enquiry framework using user-defined criteria on top of an active select set the the R routine.

Sort criteria can be applied using selection from the RR database.

Also please note:

This requires additional maintenance for views. Since these views are not automatically refreshed when a client upgrades, this information can get out of date. So only use this facility in exceptional circumstances.

Views should only be used to retrieve matching keys. Data cannot be read from named views as TAFC/TAFJ will also look for associated dictionaries and this ma cause the process to fail.

When sorting and sampling are used, which will be done first? Environment variable JEDI_XMLDRIVER_DISABLE_TOPN_QUERY determines which is done first.
This variable in only available from R18 onwards. For previous releases, SORT is always done first.

How is it determined which company an enquiry is run against? This is determined in the same way as for normal enquiries. Field COMP.FOR.ENQ determines the company name.

Do RR enquiries work for local development tables, or only for core tables? The enquiries can be run on any replicated table, be it core or local.

Does RR enquiries work on any channel? Yes. RR based enquiries work on all supported channels in a similar way Live database based enquiries e.g. Browser, OFS/interfaces, Desktop etc.
RR Enquiries can be built using IRIS API but this is not currently officially built and released by Temenos.

What enquiries monitor replication progress? The following enquiries do this:

RR.MONITOR Gives status of data in live, completed replication, errors if any etc

RR.ERROR.MONITOR List all errors due to load/transformation/data quality issues

Is there any datatype restriction in RR Enquiries? Yes. If the datatype is NUMERIC then you can only use EQUAL TO, GREATER THAN, GREATER THAN EQUAL TO, LESS THAN and LESS THAN EQUAL TO.

RR.MONITOR	Gives status of data in live, completed replication, errors if any etc
RR.ERROR.MONITOR	List all errors due to load/transformation/data quality issues