In the SAP Fiori Apps Reference Library, you have to select the target system on which the app is to be installed. You can choose between different major releases and also between different FPS’s.
These feature packs are smaller, targeted updates delivered between major releases of S/4HANA. To check if a Feature Pack is installed on your system, go to
System → Status → Button Product version → Tab Installed Product versions → Column SP / FTP Stack
When testing API Endpoints of applications running on BTP, it can be necessary to authenticate using the right S-User credentials. In such a scenario, the Universal ID password will not help.
Universal ID password can be changed via https://accounts.sap.com (will forward to the Standard SAP ID Service)
A specific S-User password can be changed via https://account.sap.com (will forward to Manage my Account, where you see the different S-User and P-User, linked to your Universal ID)
Recently, I had the task of assigning a workflow decision step to some users that were customized in a Z-Table. Normally I would have done this, by creating a container element “Actors”, a task that calls a method to return these Actors and use these Actors in the decision step. But this time I tried a custom AC Rule for the first time and I must say it was much easier than expected.
To begin, simply create a function module. The function module only needs two table parameters, AC_CONTAINER and ACTOR_TAB. They can be copied from RH_GET_ACTORS or GM_GET_RESP_FROM_INTERNAL. There you can also check, how to access the AC_CONTAINER table, if you need any input values from the WF. In my case, I just had to read the Z-Table and return the result via ACTOR_TAB.
SELECT * FROM ztable INTO TABLE @DATA(lt_table).
LOOP at lt_table INTO DATA(ls_table).
"you can also check if the provided user exists by using function module 'SUSR_USER_CHECK_EXISTENCE'
APPEND VALUE #( otype = 'US' objid = ls_table-userid ) TO actor_tab.
ENDLOOP.
IF lines( actor_tab) = 0.
RAISE nobody_found.
ENDIF.
Then simply go to tcode PFAC, create a rule, provide the function module and check the flag box at the end.
In the PFAC transaction, you can also simulate the rule resolution.
If everything works fine, add the new created rule to the decision step.
CALL FUNCTION 'DATE_CHECK_PLAUSIBILITY'
EXPORTING
date = '20250231' " invalid date
EXCEPTIONS
plausibility_check_failed = 1
OTHERS = 2.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
If you’re not interested in a specific error message, you can also use the following method to get the result as boolean.
DATA ls_return TYPE bapireturn.
CALL FUNCTION 'BAPI_EMPLOYEE_CHECKEXISTENCE'
EXPORTING
number = 99999999
IMPORTING
return = ls_return.
IF ls_return-type = 'E'.
MESSAGE ls_return-message TYPE ls_return-type.
ENDIF.
On newer systems there is also class CL_HRPA_MAINTAIN_EMPLOYEE with method PERSONNEL_NUMBER_EXISTS. Or class CL_HRPA_MAINTAIN_EMPLOYEE_UTIL and method EXIST_EMPLOYEE.
I recently had to rewrite a Report where I saw code that looked similar to this.
TYPES:
BEGIN OF ty_employee,
vorna TYPE vorna,
nachn TYPE nachn,
END OF ty_employee,
tt_employee TYPE TABLE OF ty_employee WITH DEFAULT KEY,
BEGIN OF ty_source,
col1 TYPE c LENGTH 2,
col2 TYPE c LENGTH 2,
col3 TYPE c LENGTH 2,
col4 TYPE c LENGTH 2,
END OF ty_source,
tt_source TYPE TABLE OF ty_source WITH DEFAULT KEY,
BEGIN OF ty_target,
col1 TYPE c LENGTH 2,
col2 TYPE c LENGTH 2,
col3 TYPE c LENGTH 2,
col4_vorna TYPE vorna,
col5_nachn TYPE nachn,
END OF ty_target,
tt_target TYPE TABLE OF ty_target WITH DEFAULT KEY.
* Test employees
DATA(employees) = VALUE tt_employee( ( vorna = 'Max' nachn = 'Mustermann' )
( vorna = 'Erika' nachn = 'Mustermann' ) ).
* In reallity, this table changed per employee
DATA(source_tab) = VALUE tt_source( ( col1 = 'a1' col2 = 'b1' col3 = 'c1' col4 = 'd1' )
( col1 = 'a2' col2 = 'b2' col3 = 'c2' col4 = 'd2' )
( col1 = 'a3' col2 = 'b3' col3 = 'c3' col4 = 'd3' ) ).
* Actual logic
DATA target_line TYPE ty_target.
DATA target_tab1 TYPE tt_target.
LOOP AT employees INTO DATA(employee).
LOOP AT source_tab INTO DATA(source_line).
CLEAR target_line.
target_line-col4_vorna = employee-vorna.
target_line-col5_nachn = employee-nachn.
MOVE-CORRESPONDING source_line TO target_line.
APPEND target_line TO target_tab1.
ENDLOOP.
ENDLOOP.
cl_demo_output=>write( employees ).
cl_demo_output=>write( source_tab ).
cl_demo_output=>write( target_tab1 ).
cl_demo_output=>display( ).
I spend some time thinking, how I could improve the actual logic by using some “new” ABAP syntax elements. I came up with the following result.
DATA target_tab2 TYPE tt_target.
LOOP AT employees INTO employee.
target_tab2 = VALUE #( BASE CORRESPONDING #( target_tab2 )
FOR line IN source_tab (
VALUE #( BASE CORRESPONDING #( line )
col4_vorna = employee-vorna
col5_nachn = employee-nachn ) ) ).
ENDLOOP.
But I must say, that in this case I prefer using nested LOOP’s like this
DATA target_tab3 TYPE tt_target.
LOOP AT employees INTO employee.
LOOP AT source_tab INTO source_line.
DATA(t_line) = CORRESPONDING ty_target( source_line ).
t_line-col4_vorna = employee-vorna.
t_line-col5_nachn = employee-nachn.
APPEND t_line TO target_tab3.
ENDLOOP.
ENDLOOP.
or this
DATA target_tab4 TYPE tt_target.
LOOP AT employees INTO employee.
LOOP AT source_tab INTO source_line.
APPEND VALUE #( BASE CORRESPONDING #( source_line )
col4_vorna = employee-vorna
col5_nachn = employee-nachn ) TO target_tab4.
ENDLOOP.
ENDLOOP.