Customize Exits
Information
- If a reference to another data table (external ID) exists in a data table, attributes of this relation can be fetched into this data table through a fetch exit (In SQL, join is used here).
- A fetch exit can be used to read values from the data table, which otherwise could not be found (or only in a cumbersome and run-time-intensive manner by reference to the module design), and to display them in data areas.
Customizing and Using Fetch Exists
- Create a data item (target DI) in the data table in which a value from another table is to be fetched (target DT).
- Build a fetch exit in the Exits module and store it on the target DI in the EXIT field.
- In the exit, the following parameters are to be defined:
- Fetch DI: data item the value of which is to be fetched to another table.
- Fetch DT : data table in which the fetch DI is located.
- Source DI: data item (in the target data table) via which the fetch exit data table is referenced (addressed).
- Source DT: data table in which the source DI is located. Therefore target DT and source DT are always the same.
- Class = 1 (means fetch exit)
- Option = 0 (means fetch exit)
- In the exit, the following parameters are to be defined:
Example
- The task table (DT463) contains the external ID project (DI001097). Here, every task belongs to exactly one project. Via this external ID, attributes of the corresponding project can now be fetched from the table project (DT461) in order to have them displayed in the module e.g. within the task record.
- In order to have the project name displayed within the task, you have to
- customize a fetch exit as follows:
- Fetch DT = 461 (data table which is referenced)
- Fetch DI = 000690 Project name (DI in DT461, the value of which is to be read)
- Source DI = 001097 Project (equates to the primary key of DT461 in which is to be searched)
- Source DT = 463 (at the same time it is the source table in which a source DI is created below)
- Class = 1
- Option = 0
- Create a new DI in DT463 which has the same DI parameters like DI000690 Project name in DT461.
- The exit is assigned to this DI.
- customize a fetch exit as follows:
Note
- If I-texts are to be fetched via exit, the virtual DI must have no class, and the PPMS type must be AL or ALG.
Automatic Creation of Target Data Items with Exits
Create target data items and their corresponding exits automatically
- Open the Data Dictionary module.
- Right-click on the required source data item and select the Define incarnation/fetch exit command
- The Define Incarnation/Fetch Exit module will be opened.
- Fill the data fields as follows:
- DT for exit of the CO DIs of the incarnation / Fetch DT: data table from which a data item value is to be fetched.
- DI for exit of the CO DIs of the incarnation / Fetch DI: data item the value of which is to be fetched to the target data item.
- When opening the module, the following fields are automatically filled with the data table and the DI from which the context menu command was executed.
- DT of the incarnation / Source DT: data table in which the source DI is located.
- ID DI of the incarnation / Source DI: data item of the source data table via which the fetch data table is referenced to fetch the required value.
- Fill the data fields as follows:
- Click on the Create fetch exit
- The target data item is automatically created in the target data table which contains the exit (which is the source data table at the same time).
Fetch Exits with Composite Idents
Information
- If the target table ident consists of more than one DI, the software automatically completes the key it uses for searching.
- For this purpose the IDs have to be in the same order (one after another) as in the source table. Here, the DB pos is decisive.
- Tip: If the IDs of the DIs stand one after another, a virtual DI can be created, in which the IDs stand one after another.
Example
- The task name is to be fetched from DT463 Task to DT464 Task note.
- For this purpose, a new exit is constructed
- If the software searched in DT463 only using the source ID (e.g., Project 1001), it would find several task records and the search would not yield unique results. For this reason, the software automatically complements the ID it uses for searching by adding the task, so that the correct record is found. In this example, the software does not only read DI001178 but also DI001179.
Multi-Level Fetch Exits
Information
- The following example is for illustration only since such a construction is not required here (TA name can be fetched directly). This functionality is sometimes required in individual databases.
Example
- The task name from DT463 Task is to be fetched to DT472 Load in two steps.
Procedure
- Firstly, the task name must be fetched into a virtual DI of DT466 via fetch exit.
- Then the value of this DI must be fetched via exit from DT466 into data table DT472.
Note
- This functionality is only available for module designs that map the existing relationships between data tables.
Cross-Relation Fetch Exit
Information
- Cross-relation fetch exits can also be customized.
Example
- An exit is to be used to fetch a DI from data table A into data table C. This is possible by means of a cross-relation exit, because the N:1 ident relationship between data table A and data table B equals the 1:1 ident of data table C in part, and the application logic means that there is only one record in data table C for every record in data table A.
Procedure
- The new exit in data table A must be defined with the following parameters:
- Data table C (data table from which data is to be read)
- Source DI = xyz (DI which must have values like a DI in the 1:1 ident part of data table C and must possess the same parameters)
- Fetch DI = abc (DI which is to be read from data table C)
- Grid = x (relation which is to be used for the search in <DT>. E.g. the relationship to data table B is used here to search in data table C)
Fetch Exit via 1:1 Idents from Several Data Items
Objective
- Fetch a value from a data table (source) which
- consists of several data items in the 1:1 ident
- in the data dictionary, the source DIs in the destination data table are not in the same sequence as the 1:1 idents in the source data table
Procedure
- In the target data table:
- all component idents of the source data table (DIs) must be present.
- the ident components must have the same order as the 1:1 ident of the source data table For this purpose, Value Ranges must be created.
Implicit Fetch Exits
Information
- In case data from parent data tables is to be displayed, no exit must be customized. The data item itself can be included in the data area. This is called an implicit fetch exit.
Note
- You cannot group by this field.
Caution
- For performance reasons, implicit fetch exits should not be used in modules with huge amounts of data. For further information on performance enhancing measures, please click here.