Show TOC

 Background Information

The following topic provides additional background information to describe how infotype records are written.

If your class will not write data to the buffer, then no technical limitations exist to prevent it from inheriting the properties of the standard check class (or “superclass”) CL_HRPA_INFOTYPE_NNNN , as described in the topic Creating Country-Specific Check Classes . However, if your class will indeed write data to the buffer, then it must instead inherit the properties of the superclass CL_HRPA_INFTY_NNNN , as noted in the topic Creating Single Check Classes . This technical limitation exists because classes that inherit their properties from superclass CL_HRPA_INFOTYPE_NNNN are required to run in conjunction with buffer PS; however, only classes that inherit their properties from superclass CL_HRPA_INFTY_NNNN can write to the actual buffer.

Caution Caution

Check classes that inherit their properties from superclass CL_HRPA_INFOTYPE_NNNN and subsequently write data to the buffer are likely to cause system short dumps.

End of the caution.

Two routes are available for accessing the buffer – either direct access, through which the system bypasses processing the business logic (including checks) of the other infotype(s) to write data to the buffer, or indirect access, through which the system first processes the business logic (and checks) of the other infotype(s), then writes data to the buffer.

Indirect access, however, may fail for several reasons, including the following:

  • If indirect access is used to process your own infotype, endless recursion may result. In this case, indirect access must be avoided.

  • If unacceptable input causes the checks of the other infotype(s) to fail, then indirect access may fail, too. Indirect access nonetheless can be applied in this case, but the caller must be available to handle the situation.

  • If retrocalculation or authorization checks fail, then the other infotype(s) may not be written, and indirect access may fail. Indirect access can still be applied in these cases, but the caller must be available to handle the situation.

Given the potential failures summarized above, if you choose to employ indirect access within your infotype, it is important to consider the appropriate response if indirect access should fail. Simply issuing the error message(s) from another infotype, for example, is inappropriate, because such messages generally apply to dialog users, rather than end users. (End users, in any event, cannot take note that updates have been performed without their knowledge.) Simply disabling retrocalculation and authorization checks or refraining from the use of indirect access – and thus bypassing the business logic (including checks) of all other infotypes – is also inappropriate in most cases. On balance, you are therefore advised to evaluate the IS_OK statement, then issue an appropriate message from within your own infotype.

Note Note

As you consider the appropriate message(s) to issue, remember to provide business logic with sufficient processing instructions for your own infotype as well. In other words, if you cannot update the other infotype(s), you may wish to update your infotype just the same; in this case, you would write the statement IS_OK = true and not issue error messages. Conversely, if you cannot update the other infotype(s) and do not wish to update yours either, then you would write the statement IS_OK = false and create a suitable error message.

End of the note.