cancel
Showing results for 
Search instead for 
Did you mean: 

How to consume S/4HANA Cloud API using ABAP program from the same S/4HANA Cloud system

yongkc
Explorer
1,072

Hi,

We're building a Fiori app prototype in S/4HANA Cloud on stack ABAP environment which can be used to post supplier invoice via API below:

Overview | Supplier Invoice | SAP Business Accelerator Hub

The prototype is to demonstrate Fiori app capability to consume API services from the same S/4HANA Cloud system.

In our program we are using class cl_web_http_client_manager to instantiate the HTTP client in ABAP environment as shown below:

The problem with this code is that we need to put in the username and password in the program as shown in the code from line 107 - 108. Without this the program will not be able to call the API from the same system.

Is there better alternative which we can opt for to consume the API without having the need of putting in the logon credential in the program? Otherwise, is it possible to obtain the user id and password by reading the communication user data in S/4HANA Cloud via CDS view or other class/method approach?

We've configured the corresponding communication arrangement in the system as shown below:

We've also tried using Business Object Interface but it does not work either.

In the behaviour definition, we implemented an action as shown below:

Code below is the implementation:

The app fails right away when it executes the MODIFY ENTITIES statement. Below is the error message we captured from S/4HANA Cloud:

Is there any prerequisite that we need to be aware of for using Business Object Interface in S/4HANA Cloud?

Thanks.

TamasFodor
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi,

We helped you to accept the answer, since there were no updates after a few days. You can unaccept it anytime if you have further questions.

Kind regards,

Tamas

SAP Community Topic Expert

View Entire Topic
kaidehmann
Product and Topic Expert
Product and Topic Expert

Hi @yongkc,

you should use the business object interface in this use case.

From the error message I derive that the call violates the RAP BO implementation contract, that is, you call the save action during the interaction phase. See https://help.sap.com/docs/abap-cloud/abap-rap/action-definition#action-types: „Save actions are actions that can only be triggered during the RAP save sequence specifically during the FINALIZE or ADJUST_NUMBERS. Calling a save action defined as save(finalize) during the interaction phase like for example from a determination on modify results in a short dump.”

To solve this problem, you can buffer the "to be performed action" during the interaction phase and then perform the actual action (from the buffer) during the save sequence, for instance. 

For more information regarding RAP BO implementation contract, also have a look at 

Best regards
Kai

Gheorghe-Valer
Explorer
0 Kudos

Hi Kaidehmann,

Let me see if I understand correctly:

1. We have a standard RAP Managed Business Object. 

2. Customer wants to make use of this RAP BO from the same ABAP instance calling on the Modify or Create operations. 

3. If the standard RAP BO has an interface implemented, that interface can be used to invoque EML operations? Is this correct?

4. What if there is no interface behavior implementation on the standard RAP object? How can we use it? We should implement a Service Consumer using the HTTP approach? 

Thank you.

 

kaidehmann
Product and Topic Expert
Product and Topic Expert
0 Kudos

Hi @Gheorghe-Valer 

yes, for local write access, please consume released BO interfaces as described in Business Object Consumption. If a released BO interfaces is not available (yet), but a corresponding API service is available, then you might consider implementing a remote write access using the API service as temporary mitigation. However, please keep in mind that this comes with several drawbacks compared to the usage of a BO interfaces that you need to consider. For example, a remote call issues an implicit database commit (see Database Commit), has its own LUW (transactional consistency), and causes additional overhead (performance). Thus, this approach is generally not recommended and should be used as mitigation only.

Best regards
Kai