Decoupled Infotypes. What is it?
Technology doesn’t stand still, and even in such a “stable” area as personnel administration, tightly wrapped in a layer of mothballs, new “trends” appear that, over time, you start to learn and use. So, Decoupled Infotypes — what is it?
Sorry, what?
As of today, there are two methods of creating a PA infotype (and here's where it gets a bit funny): the old method and the new one. The old method means that the business logic and user interface of the infotype are located in the same place, namely, in a module pool. The new method means separating the business logic and user interface of the infotype. This new method is called "decoupled".
See: Decoupling Infotypes (help.sap.com)
"There is an old method and a new method for creating and defining infotypes.
The new method does away with the previous close link between the business logic and the user interface, that is, the visual display of the data (ABAP screens).
Infotypes that are created using the new method are also known as 'decoupled' infotypes."
Instead of a module pool, when working with the new method of creating infotypes, you must use conversion classes.
See: Decoupling Infotypes (help.sap.com)
"The infotype-specific business logic for decoupled infotypes is programmed in ABAP Objects classes instead of in the module pool.
A check class is created for each infotype; the check class is addressed by the infotype framework.
For the interface-relevant elements of the infotype, a conversion class is created that formats the business logic data for display in the user interface."
Thus, the so-called conversion class now acts as a mediator between the business logic and the user interface (i.e., between the backend and the frontend).
See: Conversion Class (help.sap.com)
Example: Conversion of a date for display on forms, e.g., into three separate fields:
- Current Date
- Name of the Month
- Year
Important: some Employee Self-Service (ESS) applications in newer system versions, as well as services used in the functionality of HR Administrative Services, already work only with the new types of personnel infotypes, as confirmed by the official SAP documentation.
See: Decoupling Infotypes (help.sap.com)
"However, newer applications such as some ESS scenarios or the HR Administrative Services are based on the decoupled infotype framework and can only process decoupled infotypes.
This means that if you want to use a customer-specific infotype within this framework, the infotype must be decoupled.
When you create a new infotype, you should therefore always create a decoupled infotype."
The conversion class for an infotype is called at runtime by various applications, such as the XSS adapter for self-service scenarios or the HR Administrative Services adapter.
Each infotype uses at least one conversion class. Different country versions may use different conversion classes.
How to create a decoupled infotype?
You can create a decoupled infotype via transaction PM01 by activating the "Check Class (BAdI)" option on the selection screen.
Press the button Generate Objects to create new objects and confirm.
Define the fields of the new infotype by filling in the PS structure*.
Check for an entry about the new infotype in the configuration table T582A.
Also, check for an entry in the table T588UICONVCLAS.
Overall, everything should now be ready, as confirmed by the successful creation of the new infotype via transaction PA30.
What to do next?
Next, you need to dive into the documentation kindly provided by SAP:
See: UI Programming Guidelines for Infotypes
See: Business Logic Guidelines for Creating and Migrating Infotypes
Big hugs! Yours, Ignatov.