Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
Hello Fellow Developers,

Let me directly dive into the requirement, We are currently hosting Fiori on top of ECC backend. The requirement came while enabling the PO approval using My Inbox.

The first part of customization comes on the Forward Button. As per the approval matrix the approvers were maintained in the PPOME structure. The problem occurred when the approver was forwarding the PO to another approver. However, on clicking the Forward button it was displaying all the list of Users from SU01. This was creating a lot of confusion for the approvers. So the initial requirement came as to fix the list that was appearing on clicking the Forward Button.

I will be displaying the 2 possible approach for Forward Button customization from the Backend.

Approach 1 – Creating the custom class and attaching it in Service Implementation.

Approach 2 – Implement the BADI to change the values fetched from the Standard.

Let’s start with the first approach.

The standard ODATA for PO approval is GBAPP_POAPPROVAL.

Step 1 . Open your Gateway system -> Execute /IWBEP/REG_SERVICE and maintain the service details


Step 2 Maintain the Class name in DPC.


Note : Creating of the class would be in the Backend System

Step 3 Open Backend System and Create the class maintained in Gateway system.

You can copy/maintain the redefinition of the methods as per your need. Super class should be maintained as the /IWBEP/CL_MGW_PUSH_ABS_DATA. This will redirect the data flow of standard Odata call into the Custom Implementation.


I have copied all the methods from the standard class into my custom class to avoid any discrepancies. My requirement is also very small that’s why I didn’t wanted to touch other functionality so copying worked for me.


Just for showing from where the whole list of users were displaying. Please follow through as this is kind of RCA.

If you drill down into the GET_ENTITYSET. You may find this
WHEN cl_gbapp_apv_po_mdp=>cty_entities-agent.


This gets triggered for the event of Forwarding the work item to another approver. However, if you go into GET_AGENT_LIST method. You may find

CALL METHOD lo_cmn->get_users_for_forwarding.

This method is responsible for displaying all the lists of user from SU01 which is kind of misleading in our case.


 

Step 4 Modify the Approver List

So to suffice this requirement you can write your own logic and bypass the GET_AGENT_LIST method at the following place and the new list will be forwarded to the UI again as the output.

Create the list of approvers which you want to show and pass the list in lt_forward_users.


This is a long way approach where a lot of customization can be done as per your requirements.

 

Approach 2 – BADI Extensibility Approach

Normally for any custom enhancements we can directly enhance the ODATA however for the case of PO Approver app SAP has provided an option for BADI Extensibility for PO Approve application.

Step 1

Go to SE18 in the backed system.


Step 2 Create Implementation under Definition GBAPP_APV_PO_RDP

 

If you are not familiar with creating implementations follow through / skip to next step.

Right click on implementation -> Create Badi Implementation -> Specify the Enhancement Implementation & Short Text.



Once you specify the Enhancement Implementation system will ask for BADI Implementation.

Maintain them.



 



Note : You can reuse the same enhancement implementation for other requirements as well related to PO approve applications extensibility . No need to create every time.

 

Step 3 – Implementation of Class

In the Implementing class you may find all the lists of methods present.



The first method IF_GBAPP_EX_APV_PO_RDP~CHANGE_AGENT_LIST_API is the one which is used to modify the list of Approvers. Modify this method as per you requirement.

Incase of my requirement the approvers were maintained in PPOME under the Organizational structure. The data is maintained in HRP1001 table. I have deleted the approvers which are not maintained in PPOME here .

It is easier to go for 1st approach however I chose this because there are furthermore modification as part of different requirement in various methods present here. So I thought to consolidate all my changes at once for ease of understanding.


METHOD IF_GBAPP_EX_APV_PO_RDP~CHANGE_AGENT_LIST_API.
* Intended use:
* Customer uses the BAdI Enhancement Framework for own content / logik

* Here you can change/enhance the data, which is retrieved for the GET call for
* the results list of the Search for Forwarding Agents.

* Note:
* If you want to have a employee image to be displayed on the UI list
* of Forwarding Agents you need to do the following steps.
* - In this method:
*   Fill the field MIME_TYPE with the MIMETYPE of the image.
*   This will trigger the execution of method 'get_image_binary_file'
*   for retrieval of the binary data for the image.
* - In method 'get_user_image_binary_file':
*   Implement the retrieval of binary image data.
*  BREAK-POINT.
TYPES : BEGIN OF gty_usr,
SOBID TYPE HRP1001-SOBID,
END OF gty_usr.

data : lwa_user TYPE GBAPPS_APV_USER_FORWARDING,
lwa_ppome TYPE hrp1001,
lt_ppome TYPE STANDARD TABLE OF hrp1001,
lt_usr TYPE STANDARD TABLE OF gty_usr,
lwa_usr TYPE gty_usr.

LOOP AT ct_user INTO lwa_user.
lwa_usr-SOBID = lwa_user-USER_ID.
APPEND lwa_usr to lt_usr.
CLEAR lwa_usr.
ENDLOOP.

select * from hrp1001 into TABLE lt_ppome FOR ALL ENTRIES IN lt_usr
where SOBID = lt_usr-SOBID.

sort lt_ppome by SOBID.

LOOP AT ct_user INTO lwa_user.
READ TABLE lt_ppome INTO lwa_ppome with key SOBID = lwa_user-USER_ID BINARY SEARCH.
IF sy-subrc ne '0'.
delete ct_user where USER_ID = lwa_user-USER_ID.
*        delete ct_user from lwa_user.
ENDIF.
ENDLOOP.

ENDMETHOD.  

 
Labels in this area