To get simplified access from customer applications to the data of an object, for each specification type an additional, individual database table can be created in the customer namespace, where the data of the related objects are stored in addition to the standard tables. This additional table is called info table. The generation of these database entries is called INFO update. The update takes place:

• automatically when saving the regulations

• via a report for re-supply or rebuilding

Function

There are two variants of how info tables can be created:

CDS Views

There are already QPPD CDS views that map the entities of the QPPD data tables in a structured way. Essentially, these are the views /SCT/QP_I_NODE and /SCT/QP_C_VAL. All fields from the regulation types, item categories, elements, and inspection characteristics are offered. Individual views can be built accordingly. An example is the CDS view for domains /SCT/QP_I_DOMAIN. The data is immediately available, no further activities are necessary.

INFO Datenbase Tables

Database tables with elements and fields from the regulations are created in the customer namespace. An example is the /SCT/QP_INFO1 table.  Info classes are implemented in the system, which performs the update to the tables and copies data from the QPPD database tables.

Evaluation CDS View / Datenbase Table

With CDS View, no data is duplicated. The memory consumption is lower. Even if the CD View is extended, the data is immediately available. When using extensive CDS views with many fields, performance is affected.
Database tables require more memory. The update is synchronous with storage and therefore also represents the current data. When extending the table, the resupply/rebuild must be taken into account. The performance also when using HANA is significantly better.
Recommendation: When using non-HANA databases, always use Info Database Tables. When using HANA, consider the size of the info tables and performance requirements. When used in the process with frequent selections, the INFO table is to be preferred. In the case of an info table for evaluation possibly with not-so-frequent use or info tables with less than 10 elements rather CDS views should be chosen.

The following how-to refers only to info database tables.

How to

1. Create database tables and ABAP Info-Classes.

The how-to can be found under INFO - Tables (P).

2. Link ABAP-Class to specification type 

Transaction /SCT/QP_CUST→Specification type. in the chapter "Specification type" the field"Info tab ABAP Class" at the ABAP-Class is linked

Activate the INFO follow-up process

for using the INFO follow-up process the customizing of the following FUPs has to be done:

1. SCT_INFO_WRITE

2. SCT_INFO_WRITE_BG

3. SCT_INFO_MARK

4. SCT_INFO_REWORK

This is described in Follow-Up Processes (H)

Application Update

If it should be necessary to regenerate or initially rebuild the INFO records, the report /SCT/QP_INFOWRITE can be used.

The select options are used to select the objects.

• The "Execute directly" option generates the INFO records for the selected objects in the same way as if they had just been saved. This means that they are updated either with the standard FUP "SCT_INFO_WRITE" or the individual FUP. This may also mean that all INFO records are updated synchronously, which can lead to longer runtimes for the report. Therefore, when using this variant, the report may have to be run in a job.

• The "Background Processing" option uses the "SCT_INFO_WRITE_BG" FUP to update the INFO records in the bgRFC. For this purpose, a bgRFC queue is created for each selected object.

• The "Display Info Status" option shows the status of the INFO update for all selected objects.