cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Unified Destination Setup for Accessing Multiple OData Services in BAS

sawa-tomoki
Discoverer
0 Likes
267

Dear SAP Support,

I would like to ask a question regarding how to manage Destinations on SAP BTP.

So far, we have been using the SAP S/4HANA Cloud Extensibility service to create Destinations for each individual communication scenario (e.g., one for sales order integration, another for purchase order integration).
As a result, we are ending up with multiple Destinations—one per communication scenario—that correspond to each OData service we wish to use.

On the other hand, when connecting BTP with an SAP on-premise system, it has been possible to access various OData services through a single Destination.

Our current objective is to enable a development flow where we can build a Fiori application in BAS and, at the initial data source selection step, choose from various OData services (e.g., purchase, sales, or custom OData) via a single Destination.

However, as it stands, only the OData services associated with the specific communication scenario used when the Destination was created are selectable during BAS development. This limits flexibility in application development.

Is there any recommended configuration or best practice that would allow us to create a single Destination that can be used to access multiple communication scenarios or OData services?

I would greatly appreciate your guidance on this matter.

Thanks,

Accepted Solutions (0)

Answers (1)

Answers (1)

Chris1973
Active Contributor
0 Likes

Good day @sawa-tomoki 

Thank you for your question.

Have a look at the following references for further details.

Configure Communication Management, Configure Communication Arrangements, Extending Existing SAP Solutions Using SAP BTP    , Integration with SAP S/4HANA Cloud Public Edition.

To summarise, external access to OData APIs is managed in public cloud strictly through communication scenarios and communication arrangements. Each of which:

  • Represents a defined set of released APIs grouped by business area,
  • Is secured by its own technical communication user and OAuth token endpoint, and
  • Is governed by clean-core principle, which ensures APIs are only exposed in the scope defined by managed communication scenarios.

Each time you create a communication arrangement (e.g., SAP_COM_0109 for Sales Orders, SAP_COM_0008 for Purchase Orders, etc.), SAP Cloud Identity and the communication management layer generate:  a unique Service Key/URL endpoint and a dedicated OAuth client in your S4H tenant. Because of this architectural isolation, each destination in BTP maps to one communication arrangement and therefore one API set.

 

Best regards

Chris