HCM Processes & Forms - HowTo: Generic Basic Service (self-service backend)

Whenever sufficient operations, values, default values of the standard equipment or backend services like the SAP_PA not to reflect customer-specific functions, it uses to develop its own back-end services. In essence, the BS is a generic BAdI dar. Before we got into the actual development, first, some basics are addressed over the life cycle of the P & F. There are 2 basic things: INITIALIZE and CHECK. This example can be seen also quite fast in the P & F RPASR_TEST_PROCESS_EXECUTION Test Report:

This results in the life cycle roughly as follows:

Form Usage - Initialize: Set defaults and field values helps Submit - Check: Run the BS and operations of the decoupled infotype framework for testing Send: Call of the decoupled infotype framework for writing

For the generic BS but only INITIALIZE and CHECK are interesting. Furthermore, the decoupled infotype framework are also excluded because the BAdI is executed in advance. This limitation is also reflected in the to-implement methods that are defined by the interface associated with the BAdI IF_HRASR00GEN_SERVICE.

GET_FIELD_INFO: more concretely, the meta-Date of Service fields GET_OPERATIONS: Defines the list of service operations GET_SPECIAL_FIELDS: Defines Global fields of service GET_HELP_VALUES: Filled the suggested values of the fields INITIALIZE: Set default values of the service areas

In the lifecycle operations are called as follows:

Initialize o GET_SPECIAL_FIELDS o INITIALIZE o GET_HELP_VALUES Check o GET_SPECIAL_FIELDS o DO_OPERATIONS

GET_HELP_VALUES GET_SPECIAL_FIELDS

Send
o

Can now be described how the functions used to fill a form with customer scenario logic. There are no right and wrong. I have not received any documentation (IMG, SDN and SAP Help) to use as exact methods. I have therefore primarily based on existing examples to insert appropriate code. The end justifies even know the means. GET_OPERATIONS This method is primarily used for the P & F customizing, always created in the HRASR_DT, once you configure the service. In essence, fills you evaluate the parameter table with OPERATIONS.

GET_FIELD_INFO Like GET_OPERATIONS defines this method, the meta-information of the generic OS. It attributes this to the list of fields to be determined. It is used only for customizing the design time, more precisely, it fills the button with life. If you look at input and output, so even this method is quite simple.

Based on the input parameters SERVICE_FIELDS (field name as a string) DDIC similar information for the BS fields are set:

Field Name Data element Default Value and related fields to W & erthilfe to relevant fields

This may look something like this:

DATA TYPE field_info hrasr00gs_field_info. FIELD-SYMBOLS: TYPE fieldname. LOOP AT ASSIGNING service_fields . CASE . WHEN OBJPS '. field_info-fieldname = 'OBJPS'. field_info-field_data_element_name = 'OBJPS'. APPEND TO field_info field_infos. ENDCASE. ENDLOOP.

It is especially nice, of course, if you implement the assignment of constant class attributes. GET_SPECIAL_FIELDS The SPECIAL_FIELDS a generic service can be described as semi-constant global variables. You are in INITIALIZE and DO_OPERATIONS available but can not be changed. If all other fields by the DISPATCHERS in the INITIALIZE and in DO_OPERATIONS reset after failed test, this is not true for the SPECIAL_FIELDS. It binds them to the Adobe format, you can by user input (or form scripting) to be changed. About SPECIAL_FIELDS can also make fields available that were not defined by the operations. To fill the output table SPECIAL_FIELDS is quite manageable.

As already mentioned, it is checked in CL_HRASR00_DISPATCHER-> PROCESS_DATA_CONTAINER, which fields are retained or emptied. In addition to the BS-definable fields, it is still called Core Fields. The list of these fields is defined by a mapper class that implements the interface if_hrasr00_mapper. The assignment of mappers to-end services is defined in Table T5ASRFSCNSRV. For this is the class SAP_PA CL_HRASR00_PAITF_MAPPER. Here are hard-coded the following core set Fields:
field-infty = '0001 '. field-pa_fieldname = 'BTRTL'. APPEND TO field fields. field-pa_fieldname = 'PERSG'. APPEND TO field fields. field-pa_fieldname = 'PERSK'. APPEND TO field fields. field-pa_fieldname = 'WORK'. APPEND TO field fields. field-pa_fieldname = 'BUKRS'. APPEND TO field fields. field-pa_fieldname = 'PLAN'. APPEND TO field fields.

For Generic Services, this is by default the class CL_HRASR00_GENSERV_MAPPER. Here the method is not implemented get_core_fields_for_initialize, ie there are no core set Fields. Unfortunately, the class is not overloaded (FINAL), ie you can not give to its own core backend services fields. Also, you can hang in customizing any class of its

own, as the dispatcher for all generic services that value back to the default set. GET_HELP_VALUES This method is intended to set custom value aids. Here, simply fill in the parameters table HELP_DATASETS. Since value tools to be dependent on other form fields can be both SPECIAL_FIELDS SERVICE_FIELD_VALUES and the current form with all the available values. This is very helpful so far, because the form for each round trip again loses the input help.

The code for this is shown by the following example:

FIELD-SYMBOLS: TYPE STANDARD TABLE. SELECT atext Anred FROM t522t INTO CORRESPONDING FIELDS OF TABLE lt_t522t WHERE sprsl c_sprsl EQ. cw_help_dataset-keycolumnname = c_fi_anred_ddic. cw_help_dataset-value = columnName c_fi_atext_ddic. CREATE DATA-data cw_help_dataset TYPE STANDARD TABLE OF t522t. ASSIGN cw_help_dataset-data-> * TO . LOOP AT INTO lt_t522t lw_t522t. APPEND TO lw_t522t . ENDLOOP.

INITIALIZE This method is coupled to the INITIALIZE event form. The method can be used, for example, default value of form fields. The standards they set the new entries in the table SERVICE_FIELD_VALUES, the tuples of the format (field name, field value) contains. Thus, these values are applied to the form, you must assign the HRASR_DT the backend as the default service.

DO_OPERATIONS As the name suggests, here are the operations of a back-end services are

implemented. Namely, in this single method implements all operations. But there is no specific code for invoking an operation, but is defined for each operation, the method DO_OPERATIONS controlled. Typically, therefore, the implementation is designed with a loop over SERVICE_OPERATIONS itab. Here you will find that is configured for a back-end service operations (tab "Groups and Field Operations") associated with the field groups.

This may look something like this:

LOOP AT INTO service_operations service_operations_wa. CASE service_operations_wa-operation. WHEN MY_OPERATION '. IF service_operations_wa-field group = 'MY_FG'.

In the operation part is modified, then the parameter table SERVICE_DATASETS. This post contains so predict the variables of the form. If you look at the structure, one finds here the Tuppel (field group, name, value). Just then, the field group that is allowed to link fields and operations.

The method parameters again for review:

At least here again the character of a generic BAdI is clearly BS. He sounds quite powerful, it does not offer the ease of programming such as a WebDynrpo component controller. Interestingly, the development of generic Basic Services, if you want to have a feedback for user interaction. Here are operated safely then called user events in the following section are presented.

User Events The user events are defined for each scenario form. This is done under the tab 'Other Attributes'. Idea of user events, it is to respond to inputs in the form. An example is a simple button click, will be loaded on the data from the backend.

To create an event, we maintain it for now a field group (FIELD GROUP). This field groups have nothing in common but first with the FGs of BS operations. The Group field determines which fields of an event is triggered, but also which fields to the event processing in the BS transfer (very important). Field groups are also still associated with a scenario step. After defining the field groups can arrange one or more user events. In addition to the field group is still cultivates a unique name (OPERATION) and a processing type. The name is important, since it fired him in Formularskripting the event. The event takes place on the following coding of an ISR controls.
ISR Scripting xfa.record.CONTROL_PARAM.ISR_EVENT.value = " "; ContainerFoundation_JS.SendMessageToContainer (event.target, "submit", "", "", "", "");

If you look at the possible values of the processing type, you will meet old friends again:

INITIALIZE: INITIALIZE methods through all the back-end services is CHECK: Methods DO_OPERATIONS go through all the back-end services is

It falls quite quickly that there is no direct link between the event and coding there. Man I have so in the BAdI Coding pick out which event it was just because getriggerd. Unfortunately, there is no parameter that contains the event name. Therefore, one must make use of the field groups. As mentioned above, contains the SERVICE_DATASET the field group. Triggered by an event you DO_OPERATION, herein transferred are limited to the parameters that were defined in the Group field of the respective events. It also comes at the intersection of the field of event and BS groups operating in the BAdI. It is impractical but again, if this intersection is not unique. This is the case if certain fields are used by multiple operations.

These two possibilities of a workaround:

Generic fields defined in the operations ("IS_OP_XY"). These then define event in groups only if you want to run this event for a particular operation Set by scripting a check box and evaluate.

Finally, some comments on the user events

When Initialize is run DO_OPERATIONS unfortunately. This actually was the case for each round trip, even if clicked on, for example, an event field, but changed at all. There are two default user events that fire automatically the appropriate methods: USER_EVENT_CHECK & USER_EVENT_INITIALIZE

Overall, it therefore has no traditional event handling, as we know it from the GUI Programming ago. The whole is limited to the possibility of triggering a round trip from the form in which all operations are run through a scenario steps. It is the bottom line under the PAI and PBO. In this case, one defines therefore the name of the operation, and the associated fields. Code can look something like this:
init_fields_wa = c_fieldname_molga. APPEND TO init_fields_wa init_fields. operation-operation = "MY_OPERATION". operation-fieldnames = init_fields. APPEND TO surgery operations.