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).
  • Assign the same DI parameters (DB length, DB type,... except if it is virtual) which the data item the value of which is to be fetched (fetch DI) has in the other data table (fetch 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)

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.

Note

• If I-texts are to be fetched via exit, the virtual DI must have no class, and the PPMS type must either be AL or ALG.

Automatic Creation of Target Data Items with Exits

Automatically create target data item and the corresponding exits

Fetch Exits with Composite IDs

Information

• If the target table ID consists of more than one DI, PPMS 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
  • Class = 1
  • Option = 0
  • DT = 463 (Task)
  • Source DI = 001178 (Project from the N:1 relation to DT463)
  • Fetch DI = 000807 (Task name in DT463)
• If PPMS were to search in DT463 using the source ID only (e.g., Project 1001) , it would find several task records and the search would not yield unique results. For this reason, PPMS automatically extends the ID it uses for searching by adding the task, so that the correct record is found. In this example, PPMS reads not only 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

• First of all, 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-Relationship Fetch Exit

Information

• Cross-relationship 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 through a cross-relationship exit, because the N:1 ID 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:
  • Class = 1
  • Option = 0
• 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 using 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 IDs in the destination data table are not in the same sequence as the 1:1 idents in the source data table

Procedure

• In the destination data table:
  • all the component IDs 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 imlicit fetch exit.

Note

• You cannot group by this field.

Attention

• 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.