This is the twelfth part of a tutorial series about how to build your own SAP Fiori Approve Purchase Order app.
The purpose of this tutorial is to show you step-by-step how to build your own SAP Fiori Approve Purchase Orders app and provides additional insights into why certain aspects have been developed as they are.
Please see the introductory post (Tutorial: Build Your Own SAP Fiori Approve Purchase Order App) for background information regarding this tutorial.
Previously posted chapters can be find here:
In this chapter, we set up the app using the SAP Web IDE and ran the app using mock data.
In this chapter, we adapted the list screen of the app.
In this chapter, we adapted the detail screen of the app.
In this chapter, we enabled approve and reject buttons.
In this sixth chapter, we set up a new model that stores the global app state.
In this seventh chapter, we encapsulated approve / reject service calls.
In this eighth chapter, we mimicked the backend logic.
In this ninth chapter, we refreshed the master and detail screen.
In this tenth chapter, we implemented code to block the screen for further input, for example, to prevent a user from approving the same purchase order twice, and we also created an extension point.
In this eleventh chapter, we implemented the OData service used for the purchase approval app and created CDS views.
In this twelfth chapter, we’re going to register the current user as Enterprise Procurement Model (EPM) user.
Register current user as EPM user
As mentioned in the previous chapter, our CDS views assume that the current user is registered as an EPM employee. We cannot implement a self-registration mechanism on CDS level so we need to do this on OData level. The SAP Gateway Service Builder has already created a data provider extension class (DPC). We’ll place the registration logic in the constructor of this class. Additionally, we’ll use the constructor to get three handles of central EPM classes. These will be used once we implement the approve / reject functionality.
1. Expand Source Code Library --> Classes node of your project.
2. Double click <Your OData Service>_DPC_EXT class of your OData service.
3. In the private section, add three references:
PRIVATE SECTION.DATA:
MO_EPM_PO TYPE REF TO IF_EPM_PO,
MO_EPM_TXT TYPE REF TO IF_EPM_TEXT,
MO_EPM_MSG_BUFFER TYPE REF TO IF_EPM_MESSAGE_BUFFER.
4. In the public section, define a constructor for this class:
CLASS ZCL_Z_PO_TUTORIAL_DPC_EXT DEFINITION
PUBLIC
INHERITING FROM ZCL_Z_PO_TUTORIAL_DPC
CREATE PUBLIC .
PUBLIC SECTION.
METHODS CONSTRUCTOR.
5. Scroll down to the implementation section of this class and insert the coding for the constructor:
CLASS ZCL_Z_PO_TUTORIAL_DPC_EXT IMPLEMENTATION.
METHOD CONSTRUCTOR.
data: lv_employee type snwd_employees-node_key.
SUPER->CONSTRUCTOR( ).
" Get handle of central EPM classes
TRY.
MO_EPM_PO ?= CL_EPM_SERVICE_FACADE=>GET_BO( IF_EPM_PO=>GC_BO_NAME ).
MO_EPM_TXT ?= CL_EPM_SERVICE_FACADE=>GET_BO( IF_EPM_TEXT=>GC_BO_NAME ).
MO_EPM_MSG_BUFFER ?= CL_EPM_SERVICE_FACADE=>GET_MESSAGE_BUFFER( ).
CATCH CX_EPM_API_EXCEPTION.
" It is impossible to recover from this error at runtime
MESSAGE 'Failed to initialize EPM API' TYPE 'X' ##NO_TEXT.
ENDTRY.
" EPM uses business partner, check if current user is already registered.
SELECT SINGLE NODE_KEY FROM SNWD_EMPLOYEES WHERE LOGIN_NAME = @SY-UNAME INTO @LV_employee. "#EC CI_NOFIELD
IF SY-SUBRC <> 0.
TRY.
DATA(LO_DG_CHANNEL) = CL_EXM_DG_FACTORY=>GET_CHANNEL( 'CL_EPM_DGC_STANDARD' ).
LO_DG_CHANNEL->ADD_SYSTEM_USERS( VALUE #( ( CONV #( SY-UNAME ) ) ) ).
CATCH CX_EPM_API_EXCEPTION CX_EXM_API_EXCEPTION INTO DATA(LX_EXCEPTION).
MESSAGE 'Failed to register current user' TYPE 'x'. ##NO_TEXT
ENDTRY.
ENDIF.
ENDMETHOD.
The try block retrieves three central instances from the EPM facade. In case of an exception, we trigger a dump (message type X) because there is no way to recover this situation.
Next, we’ll test whether the current user is already registered as EPM user. If this is not the case, we need to add the user using a central factory method. Again, in case of an exception, we’ll trigger a dump because there is no way to recover the situation.
6. Activate your class.
Check the service implementation
You are now prepared to test your service. As a first check, you can use the Gateway client to test the service.
1. In transaction SEGW, expand the Service Maintenance node.
2. Select a system, and select SAP Gateway Client from the toolbar.
3. In the SAP Gateway client, click Execute. You should get a response as seen below. Note that the HTTP status code indicates that the call is successful.
4. Refresh the project in Eclipse in order to see Source Code Library --> Classes
5. You can also get a list of all purchase orders from your OData service. Select EntitySets from the toolbar and select the Purchase Order Entity Set. Execute the query to get a response as seen below:
I hope the twelfth part of the tutorial has sparked your interest in the chapters to come. Next time, we’ll implement the missing approve / reject functions as part of our OData service.
The purpose of this tutorial is to show you step-by-step how to build your own SAP Fiori Approve Purchase Orders app and provides additional insights into why certain aspects have been developed as they are.
Please see the introductory post (Tutorial: Build Your Own SAP Fiori Approve Purchase Order App) for background information regarding this tutorial.
Previously posted chapters can be find here:
In this chapter, we set up the app using the SAP Web IDE and ran the app using mock data.
In this chapter, we adapted the list screen of the app.
In this chapter, we adapted the detail screen of the app.
In this chapter, we enabled approve and reject buttons.
In this sixth chapter, we set up a new model that stores the global app state.
In this seventh chapter, we encapsulated approve / reject service calls.
In this eighth chapter, we mimicked the backend logic.
In this ninth chapter, we refreshed the master and detail screen.
In this tenth chapter, we implemented code to block the screen for further input, for example, to prevent a user from approving the same purchase order twice, and we also created an extension point.
In this eleventh chapter, we implemented the OData service used for the purchase approval app and created CDS views.
In this twelfth chapter, we’re going to register the current user as Enterprise Procurement Model (EPM) user.
Register current user as EPM user
As mentioned in the previous chapter, our CDS views assume that the current user is registered as an EPM employee. We cannot implement a self-registration mechanism on CDS level so we need to do this on OData level. The SAP Gateway Service Builder has already created a data provider extension class (DPC). We’ll place the registration logic in the constructor of this class. Additionally, we’ll use the constructor to get three handles of central EPM classes. These will be used once we implement the approve / reject functionality.
1. Expand Source Code Library --> Classes node of your project.
2. Double click <Your OData Service>_DPC_EXT class of your OData service.
3. In the private section, add three references:
PRIVATE SECTION.DATA:
MO_EPM_PO TYPE REF TO IF_EPM_PO,
MO_EPM_TXT TYPE REF TO IF_EPM_TEXT,
MO_EPM_MSG_BUFFER TYPE REF TO IF_EPM_MESSAGE_BUFFER.
4. In the public section, define a constructor for this class:
CLASS ZCL_Z_PO_TUTORIAL_DPC_EXT DEFINITION
PUBLIC
INHERITING FROM ZCL_Z_PO_TUTORIAL_DPC
CREATE PUBLIC .
PUBLIC SECTION.
METHODS CONSTRUCTOR.
5. Scroll down to the implementation section of this class and insert the coding for the constructor:
CLASS ZCL_Z_PO_TUTORIAL_DPC_EXT IMPLEMENTATION.
METHOD CONSTRUCTOR.
data: lv_employee type snwd_employees-node_key.
SUPER->CONSTRUCTOR( ).
" Get handle of central EPM classes
TRY.
MO_EPM_PO ?= CL_EPM_SERVICE_FACADE=>GET_BO( IF_EPM_PO=>GC_BO_NAME ).
MO_EPM_TXT ?= CL_EPM_SERVICE_FACADE=>GET_BO( IF_EPM_TEXT=>GC_BO_NAME ).
MO_EPM_MSG_BUFFER ?= CL_EPM_SERVICE_FACADE=>GET_MESSAGE_BUFFER( ).
CATCH CX_EPM_API_EXCEPTION.
" It is impossible to recover from this error at runtime
MESSAGE 'Failed to initialize EPM API' TYPE 'X' ##NO_TEXT.
ENDTRY.
" EPM uses business partner, check if current user is already registered.
SELECT SINGLE NODE_KEY FROM SNWD_EMPLOYEES WHERE LOGIN_NAME = @SY-UNAME INTO @LV_employee. "#EC CI_NOFIELD
IF SY-SUBRC <> 0.
TRY.
DATA(LO_DG_CHANNEL) = CL_EXM_DG_FACTORY=>GET_CHANNEL( 'CL_EPM_DGC_STANDARD' ).
LO_DG_CHANNEL->ADD_SYSTEM_USERS( VALUE #( ( CONV #( SY-UNAME ) ) ) ).
CATCH CX_EPM_API_EXCEPTION CX_EXM_API_EXCEPTION INTO DATA(LX_EXCEPTION).
MESSAGE 'Failed to register current user' TYPE 'x'. ##NO_TEXT
ENDTRY.
ENDIF.
ENDMETHOD.
The try block retrieves three central instances from the EPM facade. In case of an exception, we trigger a dump (message type X) because there is no way to recover this situation.
Next, we’ll test whether the current user is already registered as EPM user. If this is not the case, we need to add the user using a central factory method. Again, in case of an exception, we’ll trigger a dump because there is no way to recover the situation.
6. Activate your class.
Check the service implementation
You are now prepared to test your service. As a first check, you can use the Gateway client to test the service.
1. In transaction SEGW, expand the Service Maintenance node.
2. Select a system, and select SAP Gateway Client from the toolbar.
3. In the SAP Gateway client, click Execute. You should get a response as seen below. Note that the HTTP status code indicates that the call is successful.
4. Refresh the project in Eclipse in order to see Source Code Library --> Classes
5. You can also get a list of all purchase orders from your OData service. Select EntitySets from the toolbar and select the Purchase Order Entity Set. Execute the query to get a response as seen below:
I hope the twelfth part of the tutorial has sparked your interest in the chapters to come. Next time, we’ll implement the missing approve / reject functions as part of our OData service.
- SAP Managed Tags:
