Show TOC

 Using Generic Interfaces

Use

To simplify implementations, the methods described in the topic Implementing Checks provide you with dynamically correctly typed Pnnnn structures. However, because generic interfaces also exist, these cannot be statically typed, and must therefore be typecast before they are used.

Example Example

Two possible approaches for implementing checks are illustrated in the following examples for the Recurring Payments/Deductions infotype (0014).

The following source code demonstrates the first approach.

DATA p0014 TYPE p0014.p0014 = pnnnn.( ... )pnnnn = p0014.

In this example, you would insert the source code, in lieu of ( ... ) , that is required to implement the check for the Recurring Payments/Deductions infotype (0014).

It is also feasible to follow a second approach, as demonstrated below.

FIELD-SYMBOLS <p0014> TYPE p0014.ASSIGN pnnnn to <p0014> casting.( ... )

As in the first example, you would insert the source code, in lieu of ( ... ) , that is required to implement the check for the Recurring Payments/Deductions infotype (0014).

End of the example.

Procedure

While both of the approaches described above are valid, each approach offers unique advantages and disadvantages. The first approach avoids field symbols entirely, and may therefore initially offer greater appeal. However, the second approach forestalls the possibility of forgetting to move the structure back again. Furthermore, this approach offers a minor performance advantage. For these reasons, we recommend that you pursue the second approach, rather than the first, although either approach, to reiterate, is valid.

Caution Caution

Under no circumstances should you implement external performs into existing reports, as the system will detect these and in response issue a short dump. If you need external functionality, then you must encapsulate this within classes or function modules.

End of the caution.

Finally, it is important to note that all check classes and check methods should be completely stateless. Do not use any attributes to keep track of subsequent changes to your records; such attributes are explicitly not supported by the standard system, and may cause your source code to become corrupt.