SAP Community - OData

SAML+OAuth2 (PowerApps --> SAP)

2025-10-17T12:14:09.642000+02:00

Overview

This setup describes SAP data consumption (S/4HANA) in Microsoft PowerApps with user authentication using Microsoft EntraID. So you could login to Microsoft PowerApps with your EntraID account and use there data from S/4HANA.

If you're interested in the theory and architecture behind this setup, please read this excellent article written by Martin Pankraz.

Steps described here are compatible with S/4HANA On-premise, S/4HANA Private Cloud and ECC 6 EHP8, but some screens may look different as screenshots were captured in S/4HANA Private Cloud 2023.

Basic setup

Start by checking that all required services are enabled in T-Code SICF.

/sap/bc/webdynpro/sap/saml2
/sap/public/bc/sec/saml2
/sap/public/bc/sec/cdc_ext_service
/sap/public/myssocntl
/sap/bc/sec/oauth2/token

Open T-Code SAML2 and enable SAML support. Provider name could be any string, but must be URL compliant! It's best practice to use http://<SID><client>. Switch selection mode to automatic if you intent to use only one IDP.

Local provider is created. Download metadata needed for next steps.

Now go to EntraID and create Enterprise App of type "SAP NetWeaver".

On "Single sign-on" tab click "SAML". New blank configuration will be created. Use "Upload metadata file" button and select metadata file downloaded from SAP. This loads SAP's metadata into EntraID.

Edit "Reply URL" to point to Token service of OAuth2 and don't forget to set correct client in parameter "sap-client". "Sign on URL" could be any URL compliant string (ex. https://dummy.com).

Edit "Attributes & Claims". Click on "Unique User Identifier (Name ID)".

You have two options here, based on attribute that you like to use as user identifier.

If you don't have any email address assigned to more than one user in SAP and you use email as UPN in EntraID, you could match EntraID and SAP user based on email. In this case select "Name identifier format" = "Email address" and "Source attribute" = "user.userprincipalname".
Otherwise find source attribute that contains SAP username. Ex. sAMAccountName. For this scenario choose "Name identifier format" = "Unspecified".

Save and return to "Single sign-on" tab of your Enterprise App configuration. In "SAML Certificates" section download the certificate and federation metadata.

Go back to SAP backend and open T-Code SAML2. Switch to "Trusted Providers" tab and select "OAuth 2.0 Identity providers" under the "List of Trusted providers". Add a new provider using the metadata you just downloaded from EntraID.

In the next step, upload the certificate downloaded from EntraID. In the "Provider" and "Signature and Encryption" steps, click "Next" and then "Finish".

Edit the new trusted IDP and select the name format "Unspecified" or "E-mail", depending on the user mapping scenario. Scenario 1 is "E-mail", scenario 2 is "Unspecified".

Set the "User ID Mapping Mode" according to the scenario. For scenario 1 "email" or "Logon ID" for scenario 2.

Save and enable the configuration.

Open EntraID again and create new App registration (not Enterprise app) that will be used as client.

On "Authentication" tab, section "Platform configurations" click "Add a platform" and select "Web". Set "Redirect URIs" = "https://localhost:44326/signin-oidc" and select both tokens to be issued.

On "Certificates & secrets" tab generate new client secrete. Save the content of "Value" field as you can't access it later!

Next, on "API permissions" tab add a permission "Microsoft Graph" as delegated. Select "openid" (Sign users in).

On "Expose and API" tab add a scope. URI should be predefined. After clicking "Save" new configuration panel will be shown. Fill there "Scope name" = "user_impersonation" and switch consent to "Admins and users". Set some display name and description. Finally click "Add scope".

On the same tab add a client application. Set "Client ID" = "6bee4d13-fd19-43de-b82c-4b6401d174c3" and set our scope in "Authorized scopes". This fixed client ID is identifier of SAP OData connector in PowerApps platform.

Copy "Application (client) ID" from "Overview" tab.

Now switch to App registration (not Enterprise app) that corresponds to the server part (same name as our Enterprise app defined in the beginning). Go to "Expose and API" tab and add a client application. Add there copied client ID and set scope.

One again switch to SAP system. Create technical user for impersonation. This user must be type B (System) and has correct permission role assigned. You need these permissions:

S_RFC: RFC_TYPE=Function group, RFC_NAME=SYST, ACTVT=Execute
S_SCOPE: OA2_CLIENT=SOAUTH2 (set same as ID of technical user), OA2_SCOPE=<required_scopes> (start with "*" for testing and restrict later)

Call T-Code SOAUTH2. On the screen click "Create". Set ID of technical user as "OAuth 2.0 Client ID" and write some description.

In "Grant Type Setting" step select our trusted IDP from the list and set "Refresh Allowed".

In "Scope Assignment" step set some service that you'd like to expose.

Postman test

It's time for first test. You could use attached Postman collection. Edit variables of the collection.

Variable	Content	Example
SAP GW IP Address	Address of SAP AS	vhigyi4aci.*************
SAP GW Port	Https port of SAP AS	44300
AAD tenant ID	Entra tenant ID (visible on app registration overview)	d3f10f6d-****************
AAD Application ID for SAP GW	SAP AS SAML local provider name	http://I4A400
Frontend App Client Id	Client ID of client app registration	b20e44f0-d88a-4558-8a53-b34484425e3f
Frontend App Client Secret	Generated client secret of client app registration	HZ48Q~NDBD38a4XW~************
Frontend App custom scope	Exposed API scope of client app registration	api://b20e44f0-d88a-4558-8a53-b34484425e3f/user_impersonation
SAP OAuth Client ID	SAP AS technical user ID	SOAUTH2
SAP OAuth Client Pwd	SAP AS technical user password	krnsW)************
SAP OAuth Scope	Scope (service) defined in OAuth config on SAP AS	ZAPI_BUSINESS_PARTNER_0001
SAPBearerToken	Leave blank, generated in process
bearerToken	Leave blank, generated in process

Please also change service name and parameters in request number 4 based on your use case (if not calling BP OData service as in example).

Now open first call of the collection and send request. Ignore output and open console (bottom left corner). Copy whole link (without GET keyword) and paste it in the web browser. After successful EntraID login blank error page will be shown. Go to the address bar and copy content of parameter "access_token". Open request number 2 and paste token to the "assertion" parameter.

After sending request number 2 you should see "access_token" in the output. Open request number 3 and send it. If successfull you would get new (short) "access_token" and also "refresh_token" and correct "scope".

Finally open and send request number 4. You should see data from your service.

SAP Integration Suite setup

In order to use this setup from internet / public cloud you have to expose SAP AS over SAP Cloud Connector.

In case that you don't have SAP Integration Suite BTP subaccount already added in SAP Cloud Connector, please use official guide to add it: SAP Help Portal | SAP Online Help

Now go to the Cloud Connector subaccount and select "Cloud to On-Premises" in the left menu. On "Access Control" tab add new system (Mapping Virtual to Internal System). Backend type is "ABAP System", protocol "HTTPS". Fill in hostname and port of SAP AS.

Use same values for virtual host and port. Disable Principal Propagation and Certificate Logon as you don't need these in this scenario. Host in request header should be Virtual Host. Set SID (ex. I4A) as System ID.

Expose services (your OData) in "Resources" section. On this example I'm exposing whole system (don't do this with productive SAP AS!).

Open SAP Integration Suite and begin with setup there. In left menu select Configure -> APIs and select "API Providers" tab.

Create new provider. Fill some meaningful name on "Overview" tab. Switch to "Connection" tab and set "Type" = "On Premise", "Host" = <AS_ABAP_HOST>, "Port" = <AS_ABAP_PORT>, leave "Authentication" = "None". Set "sap-client" = <AS_ABAP_CLIENT> in Additional Properties.

Save provider and test connection. It should return "System is up and reachable. However, the ping check responded with code : 404; Message : Not found". That's correct state because we're calling base URL and not any reachable service.

Go to "Policy Templates" tab and import definition that's available in SAP Business Accelerator Hub. This policy needs some mapping. So switch to "Key Value Maps" tab and create new mapping (ex. name "I4ACLNT400_EntraID"). Use table bellow as an example.

Key	Content	Example value
issuer	Standard Microsoft issuer value (constant)	https://sts.windows.net/d3f10f6d-4a4d-4cde-acb6-284a54d78b3a/
AADSAPResource	SAP AS SAML local provider name	http://I4A400
entra-id-audience	Exposed API scope of client app registration (without scope name)	api://b20e44f0-d88a-4558-8a53-b34484425e3f
AADRegisteredAppClientSecret	Generated client secret of client app registration	HZ48Q~NDBD38a4XW~************
sap-oauth-client-password	SAP AS technical user password	krnsW)************
AADRegisteredAppClientId	Client ID of client app registration	b20e44f0-d88a-4558-8a53-b34484425e3f
SAPOAuthServerAdressForTokenEndpoint	SAP AS host + port	vhigyi4aci.**********:44300
sap-oauth-client-username	SAP AS technical user ID	SOAUTH2
sap-oauth-scope	Scope (service) defined in OAuth config on SAP AS	ZAPI_BUSINESS_PARTNER_0001
entra-id-tenant-id	Entra tenant ID (visible on app registration overview)	d3f10f6d-*****************

Finally switch to "API Proxies" tab and create new proxy. Select your API Provider, set URL to OData service that you have in the scope. Define some name and title of proxy. API Base Path could be anything you like - it's simply prefix for OData calls to this service (ex. /sap/utility/odata).

Ignore error "Unable to fetch metadata" - it's normal as we didn't applied policy yet.

In the new API provider click "..." in top right corner and select "Policies". Again in top right corner click "Policy Template" -> "Apply". Select policy that you downloaded earlier and apply it. You should now see it under target endpoint's post flow.

Now go step by step through the policy. In second step (MapVariables) replace value of "mapIdentifier" with the name of your value map (ex. I4ACLNT400_EntraID). In steps "RefreshSAPToken", "fetchSAPOAuthToken" and "GetCSRFToken" change value of tag "APIProvider" from "PM1-via-SCC" to your provider name (ex. I4ACLNT400_NOAUTH).

Click "Update", "Save" and "Deploy".

Microsoft PowerPlatform test

Login to Microsoft PowerApps at Power Apps and switch to correct environment (if using more). In the left menu click "Flows" and create new cloud flow "Instant cloud flow". Fill some name and choose "Manually trigger a flow".

Add new step with connector "SAP OData", action "Read OData entity".

Set authentication type "Microsoft Entra ID Integrated (with APIM)". OData base URI is URL of you API Proxy service (ex. https://******.test.apimanagement.******.hana.ondemand.com/sap/utility/odata/BusinessPartner), Entra ID resource URI is API scope of client app (ex. api://b20e44f0-d88a-4558-8a53-b34484425e3f/user_impersonation). Set "API Key Name" = "APIKey (constant), "API Key Value" = <Client_secret> (ex. HZ48Q~NDBD38a4XW~************) and SAP's client name / password.

You should see Entra ID popup for login. After that service should be authenticated and entities readable.

Troubleshooting

In case you're struggling with the basic setup (Postman testing), start T-Code SEC_DIAG_TOOL_VIEWER and capture the login traffic. You can find errors there and search SAP for Me. Always double check that user calling API (your business user, not SOAUTH2) is valid and has correct permission assigned (check SU53 for errors).

If calling OData API from PowerApps fails immediately with authentication error, check EntraID tenant log for errors associated with your registered client app.

Sometimes it fails later in login process and this could be debuged on Integration Suite. Open definition of your API Proxy, click "Debug" (top right corner) and "Start Debug" (bottom right corner). Now call API from PowerApps, refresh debugged window and check for errors.

Explore the potential of SAP Fiori development portal using complex building blocks (3 of 6)

2025-10-31T07:43:01.269000+01:00

In our previous posts, we introduced the SAP Fiori development portal and explored its structure. Now it's time to see the real power in action. Complex building blocks like the table don't just display data - they bring intelligent behavior, enterprise-grade features, and multiple visualization options that adapt to your business needs. Let's dive into how the portal helps you explore and understand these sophisticated capabilities.

Beyond Visual Display: Intelligent Behavior

The table building block exemplifies how SAP Fiori elements transforms simple annotations into comprehensive business functionality. When you annotate your UI.LineItems, you're not just defining columns - you're enabling a complete data management experience.

The table automatically adapts its behavior based on your entity's capabilities which are defined in the service metadata and annotations, for example:

Insertable entities enable users to create new records directly in the table
Deletable entities provide deletion capabilities with proper confirmation dialogs
Updatable entities allow inline editing, with optional mass edit features for bulk changes
Annotated actions become available as table actions, properly integrated with selection states

Built-in Delete Feature

This intelligence means your users get the functionality they need without additional development effort on your part.

Multiple Visualizations at Your Fingertips

The portal showcases how a single building block can transform into different visualizations based on your requirements:

Responsive Table - Optimized for mobile and varying screen sizes
Grid Table - High-performance display for large datasets
Analytical Table - Built-in aggregation and grouping capabilities
Tree Table - Hierarchical data representation

But the capabilities don't stop there. The table building block comes packed with enterprise-grade features that users expect from modern business applications:

File Operations - Upload and download functionality for seamless document management
Data Export - Export to Excel and PDF for offline analysis
Clipboard Integration - Copy and paste operations for efficient data entry
Personalization - Column reordering, resizing, and hiding based on user preferences
Variant Management - Save and share different table configurations across users
Filtering & Sorting - Built-in capabilities for data exploration and organization
Mass Operations - Bulk actions and mass editing for productivity

And this is just the beginning - the portal showcases dozens of additional features that activate automatically based on your metadata annotations, entity capabilities and configuration. Each feature is documented with examples showing exactly how to enable it in your application.

Extensibility When Standard Features Aren't Enough

The portal demonstrates how building blocks balance out-of-the-box functionality with extensibility. When standard features don't meet your specific needs for, you can:

Add custom controls to display calculated or derived data
Integrate custom actions for business-specific operations
Use the building block API in your controller code for advanced scenarios

Custom Column in Table

This extensibility ensures you're never locked into standard behavior while still benefiting from enterprise-grade foundation features.

Multi-Format Code Examples: A New Level of Support

One of the portal's newest and most valuable features is showing the same annotations in multiple formats. When you explore a building block like the table, you'll see the implementation in:

CAP CDS - For SAP Cloud Application Programming Model development
RAP CDS - For ABAP RESTful Application Programming (since 1.142)
XML annotations - For local annotations when service changes aren't possible

Line Item Implementation

The portal's multi-format code examples ensure every developer can find the implementation pattern that fits their development context. CAP CDS examples offer full interactivity - modify annotations and see immediate results in the preview. RAP CDS examples provide static but comprehensive guidance for ABAP developers working in modern SAP environments, showing exactly how to implement the same functionality using ABAP RESTful Application Programming patterns. It also helps you find a running sample in the RAP Feature Showcase. XML annotations serve as your fallback option when service-level changes aren't feasible. This comprehensive approach means whether you're building with CAP, RAP, or working with existing services, you have the code examples you need to implement any building block feature.

See It in Action: Table Building Block Example

Let's explore the table's responsive behavior. When you open the Table Overview on a desktop, you'll see columns for ID, begin date, end date, agency, and status. But here's where the intelligence kicks in:

Click "Show Code" next to the UI.LineItems annotation.
The code editor opens, the preview adjusts to a smaller viewport, and you'll notice fewer columns are displayed.
Note that the status column remains visible even though it's the 5th column in the annotation. This happens because of its @ui.Importance: #High setting.
Now try changing @ui.Importance from #High to #Low and watch the status column disappear from the table in real-time.

Changing UI.Importance

This demonstrates how building blocks intelligently prioritize content based on your annotations and available screen space.

Interactive Learning Through Live Code

The portal's live code editing capability transforms learning from passive reading to active experimentation. You can:

Modify annotations and see immediate visual results
Test different configuration combinations
Understand the relationship between metadata and UI behavior
Experiment safely without affecting your actual development environment

This hands-on approach helps you understand not just what's possible, but how different annotation patterns affect the user experience and can serve as input for your app development.

What's Next

In our next post, "Use SAP Fiori development portal to understand extension options for standard floorplans (4 of 6)," we'll shift focus from individual building blocks to complete pages. We'll explore how the portal guides you through extending standard floorplans like List Report and Object Page, showing you exactly where and how to add custom functionality while maintaining the enterprise-grade foundation these pages provide.

To get the full overview about the SAP Fiori development portal, check out the following blog posts of the mini-series:

Introducing the SAP Fiori Development Portal: Your Gateway to Rapid SAP Fiori App Creation (1 of 6)
Get familiar with SAP Fiori development portal and the power of the building blocks (2 of 6)
Explore the potential of SAP Fiori development portal using complex building blocks (3 of 6)
Use SAP Fiori development portal to understand extension options for standard floorplans (4 of 6)
Prepare building custom pages by using SAP Fiori development portal (5 of 6)
Bringing the SAP Fiori development portal and its use to the next level (6 of 6)

SAP Datasphere : Export Data of AnalyticalModel via Odata URL & Oauth Client of type Technical User

2025-11-05T07:58:30.289000+01:00

In this blog, I have explained how to export data from an analytical model into CSV file securely using an OData URL and a technical user OAuth client.

Step - 1) Create an Oauth Client with Purpose as Technical User and select required roles. get client ID and secret and save it. How to Guide

Step - 2) Create Odata_Tech_User_OauthClient.py file with below code

# --- IMPORTS ---
import requests              # For making HTTP requests to token and OData endpoints
import pandas as pd          # For handling tabular data from the OData response
import os                    # For file path resolution and environment variable access
from dotenv import load_dotenv  # For loading credentials from a .env file

# --- LOAD ENV VARIABLES ---
load_dotenv()                # Load environment variables from .env file into the runtime

# --- CONFIG: Read credentials and endpoints from environment ---
odata_url = os.getenv("ODATA_URL")             # OData service endpoint
token_url = os.getenv("TOKEN_URL")             # OAuth token endpoint
client_id = os.getenv("CLIENT_ID")             # OAuth client ID
client_secret = os.getenv("CLIENT_SECRET")     # OAuth client secret

# --- GET TOKEN: Request access token using client credentials ---
token_payload = {
    "grant_type": "client_credentials",        # OAuth flow type
    "client_id": client_id,                    # Injected from .env
    "client_secret": client_secret             # Injected from .env
}
token_resp = requests.post(token_url, data=token_payload)  # POST request to token endpoint
token_resp.raise_for_status()                 # Raise error if token request fails
access_token = token_resp.json()["access_token"]  # Extract access token from response

# --- CALL ODATA SERVICE: Fetch data using bearer token ---
headers = {"Authorization": f"Bearer {access_token}"}  # Auth header with token
response = requests.get(odata_url, headers=headers)    # GET request to OData endpoint
response.raise_for_status()                            # Raise error if data fetch fails

# --- PARSE RESULTS: Convert JSON payload to DataFrame ---
data = response.json()["value"]         # Extract 'value' list from OData response
df = pd.DataFrame(data)                 # Convert list of records to pandas DataFrame

# --- DISPLAY OR EXPORT: Show preview and optionally save to CSV ---
print()
print("🔍 Displaying top rows for quick inspection:")
print()
print(df.head())                        # Display top rows for quick inspection
print()

# --- Extract view name from OData URL ---
view_name = odata_url.rstrip("/").split("/")[-1]  # Gets 'AM_EXPORT' from the URL

# --- Construct filename ---
filename = f"{view_name}.csv"

# --- Display and save ---
df.to_csv(filename, index=False)
print(f"📁 Exported data Saved to: {os.path.abspath(filename)}")

Step - 3) Create .env file with all values of variables.

ODATA_URL : Copy the Odata link from analytical model

TOKEN_URL : get it from Datasphere -> System -> App Integration page

CLIENT ID & Secret : Get it from Step-1

Step- 4) Create .bat file with blow code

 off

chcp 65001 >nul

REM ───────────────────────────────────────────────
REM 🚀 ODATA TECH USER OAUTH CLIENT EXECUTION SCRIPT
REM ───────────────────────────────────────────────


echo.
echo ==============================================
echo 🔄 Starting OData export process...
echo ==============================================

REM --- Navigate to script directory ---
cd /d "%~dp0"

REM --- Run the Python script ---
echo 🐍 Running Python script: Odata_Tech_User_OauthClient.py
python Odata_Tech_User_OauthClient.py

REM --- Completion message ---
echo.
echo ✅ Script execution completed.
echo ==============================================

REM --- Keep window open ---
pause

Keep all files in same directory

Once everything is set up, just double-click the .bat file to run the process. It will execute the Python script and, once finished, generate a .csv file name exactly same name as the analytical model name. As part of the execution, the first five rows of data will also be displayed on screen for quick preview

Thanks

Vikas Parmar

Solution Order Simulation APIs - OData V4

2025-11-10T11:10:34.647000+01:00

Introduction

Solution Order is a business transaction in SAP Cloud ERP, used to sell solutions which can be a combination of either physical goods, one time services, recurring services, subscriptions, or projects bundled as one integrated customer offering. With the 2508 release of SAP Cloud ERP, the OData V4 APIs for simulation of solution order is available. Simulation APIs can be used to simulate various entities of solution order without creating a solution order. Various determination logic like partner determination, price determination, billing plan etc can be simulated without creating a solution order. This can be used to provide a quote using a quoting engine outside of SAP Cloud ERP. Such external quoting solutions can benefit from the possibility of quoting a real time price calculated in SAP Cloud ERP using the Solution Order simulation APIs. In this blog, you will find more information about the API, the entities available for consumption and the operations on these entities.

Authentication and Access

The communication arrangement with the Business Solution Order Integration scenario(SAP_COM_0706) needs
to be in place to access the API. You will need to create a communication arrangement for the communication scenario
SAP_COM_0706, A communication system with an inbound user. You can as well configure OAUTH 2.0 if
needed.

The API supports Basic Authentication(username/password), OAUTH2.0, and X.509 Certificate Authentication

Metadata

Metadata provides a description of the service, detailing the structure of the data, available entities, their
properties, relationships, and supported operations. It acts as a blueprint that allows both developers and tools
to understand how to interact with the service without needing prior knowledge of its design.
It can be accessed using the below URL
https://<<SERVER>>/sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/api_bussolnordsimulation/0001/$metadata
Below is a screenshot, with a part of the metadata of the Business Solution Order API.

In the above partial view of the metadata, you can see the Entity BusinessSolutionOrderItem, it has 2 key fields - BusinessSolutionOrder and BusinessSolutionOrderItem, a set of properties like Product, Quantity, BusSolnOrdItmCategory, etc. it also specifies the type, max length, precision etc of the properties. There are a set of navigational properties(or associations) for the entity. Associations are other entities related to the current entity.

API Capabilities and Entities

Entity	Supported Operations	Description	Associations
BusinessSolutionOrder	CREATE (Simulate)	Solution Order Header	_Item _Partner
BusinessSolutionOrderItem	CREATE (Simulate) only using deep insert on BusinessSolutionOrder	Solution Order Item	_BusinessSolutionOrder _Partner _PriceElement _BillingRequestItem
BusSolnOrdPartner	CREATE (Simulate) only using deep insert on BusinessSolutionOrder	Header Partner	_BusinessSolutionOrder
BusSolnOrdItmPartner	CREATE (Simulate) only using deep insert on BusinessSolutionOrder	Item Partner	_BusinessSolutionOrder _Item
BusSolnOrdItmPriceElement	CREATE (Simulate) only using deep insert on BusinessSolutionOrder	Item Price Element	_BusinessSolutionOrder _Item
BusSolnOrdItmBillgReqItem	CREATE (Simulate) only using deep insert on BusinessSolutionOrder	Billing Request Line of a Contract Item	_BusinessSolutionOrder _Item

BusinessSolutionOrder – Solution Order Header

Simulate solution order with one item to get header and item entities with simulated net value

You can add any number of items to simulate.

POST <host> /sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/bussolnordersimulation/0001
/BusinessSolutionOrder

X-CSRF-Token: abc
{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Simulation Demo",
  "SoldToParty": "17100001",
  "PayerParty": "17100001",
  "PaymentTerms": "0001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "_Item": [
    {
      "Product": "TG11",
      "Quantity": 1,
      "BusSolnOrdItmQtyUnitISOCode": "PCE"
    }
  ]
}

BusSolnOrdPartner – Solution Order Header Partner

You can pass an empty _Partner:[] entity in the payload to read the header partners that are determined based on the partner determination procedure assigned to the solution order transaction.

POST <host> /sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/bussolnordersimulation/0001
/BusinessSolutionOrder

X-CSRF-Token: abc

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Simulation Demo",
  "SoldToParty": "17100001",
  "PayerParty": "17100001",
  "PaymentTerms": "0001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
 
  //Empty Partner association in payload to return the simulated entity in response
  "_Partner":[],
  
  "_Item": [
    {
      "Product": "TG11",
      "Quantity": 1,
      "BusSolnOrdItmQtyUnitISOCode": "PCE"
    }
  ]
}

BusSolnOrdItmPartner – Solution Order Item Partner

Similar to header partner, You can pass an empty _Partner:[] entity in the payload to read the item partners that are determined based on the partner determination procedure assigned to the item category.

POST <host> /sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/bussolnordersimulation/0001
/BusinessSolutionOrder

X-CSRF-Token: abc

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Simulation Demo",
  "SoldToParty": "17100001",
  "PayerParty": "17100001",
  "PaymentTerms": "0001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "_Item": [
    {
      "Product": "TG11",
      "Quantity": 1,
      "BusSolnOrdItmQtyUnitISOCode": "PCE",
      
      //Empty Partner association in payload to return the simulated entity in response
      "_Partner": []
    }
  ]
}

You can also override a partner determined in simulation by passing the updated partner in the payload. This can be useful to for example simulate changes in shipping cost based on the address of a new partner that is passed which is different from the determined partner.

POST <host> /sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/bussolnordersimulation/0001
/BusinessSolutionOrder

X-CSRF-Token: abc

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Simulation Demo",
  "SoldToParty": "17100001",
  "PayerParty": "17100001",
  "PaymentTerms": "0001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "_Item": [
    {
      "Product": "TG11",
      "Quantity": 1,
      "ShipToParty": "17100002",
      "BusSolnOrdItmQtyUnitISOCode": "PCE",
      
      "_Partner": [
        {
          "CustMgmtPartnerFunction": "00000055",
          "CustMgmtBusinessPartner": "17100002"
        }
      ]
    }
  ]
}

BusSolnOrdItmPriceElement – Item Price Element

Similar to partners, You can pass an empty _PriceElement[] entity in the payload to read the item price elements that are calculated based on the pricing procedure assigned.

How ever you can also pass a new price element in simulation request like a discount to simulate the solution order with the discount condition

POST <host> /sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/bussolnordersimulation/0001
/BusinessSolutionOrder

X-CSRF-Token: abc
{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Simulation Demo",
  "Language": "EN",
  "SoldToParty": "17100001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "_Item": [
    {
      "Product": "TG12",
      "Quantity": 1,
      "BusSolnOrdItmQtyUnitISOCode": "EA",
      
      //Adding a fixed discount
      "_PriceElement": [
        {
          "ConditionType": "DRV1",
          "ConditionRateValue": -10,
          "ConditionCurrency": "USD"
        }
      ]
    }
  ]
}

BusSolnOrdItmBillgReqItem – Item Billing Request Item(Contract Item)

Billing Request Line item is relevant for a service contract item of type SOSC(Service Contract Item) and SOPA(Service Contract Item with Price Adaptation). You can simulate the billing plan by providing the billing date and settlement period in the payload and you will see the Billing Request Items accordingly. For example if you provide a settlement period as monthly for a contract running for 1 year, you will see 12 Billing Request Items in the simulation response.

POST <host> /sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/bussolnordersimulation/0001
/BusinessSolutionOrder

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Simulation of BRLs",
  "SoldToParty": "17100001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "_Item": [
    {
      "BusinessSolutionOrderItem": "10",
      "Product": "SRV_CONTRACT",
      "BusSolnOrdItmCategory": "SOSC",
      "Quantity": 1,
      "QuantityUnit": "AU",
      "BusSolnOrdItmQtyUnitISOCode": "C62",

      // Billing date first of the month
      "SrvcMgmtBillgPlanBillgDateRule": "BILL0002",
      // Settlement period - monthly billing
      "SettlementPeriodRule": "BILL0001",

      "ServiceContrItemStartDateTime": "2025-08-13T00:00:00Z",
      "ServiceContrItemEndDateTime": "2026-08-13T00:00:00Z",
      "_BillingRequestItem": [],
      "_PriceElement": []
    }
  ]
}

Solution Order APIs - OData V4

2025-11-11T15:16:58.766000+01:00

Introduction

Authentication and Access

The communication arrangement with the Business Solution Order Integration scenario(SAP_COM_0706) needs to be in place to access the APIs. You will need to create a communication arrangement for the communication scenario SAP_COM_0706, A Communication System with an inbound user. You can as well configure OAUTH 2.0 if needed.

The API allows Basic Authentication(Username/password), OAUTH2.0, and X.509 Certificate Authentication

Metadata

It can be accessed using the below URL

https://<<SERVER>>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001/$metadata

Below is a screenshot, with a part of the metadata of the Business Solution Order API.

In the above partial view of the metadata, you can see the Entity BusinessSolutionOrder, it has key- BusinessSolutionOrder, and a set of properties like BusinesssSolutionOrder, BusSolnOrdType, BusSolnOrdDescription, etc. it also specifies the type, max length, precision etc of the property. There are a set of navigational properties(or associations) for the entity. Associations are other entities related to the current entity.

API Capabilities and Entities

Entity	Supported Operations	Comments	Associations
BusinessSolutionOrder	CREATE / READ / UPDATE	Solution Order Header	_Items _Partner _Text _UserStatus _ItemRelationship _FUPSalesOrder _FUPServiceOrder _FUPServiceContr _FUPEntProject _FUPSubscrpn _Appointment
BusinessSolutionOrderItem	CREATE / READ / UPDATE / DELETE	Solution Order Item For Create operation, you can only use this entity in association with BusinessSolutionOrder	_Partner _PriceElement _Text _ScheduleLine _UserStatus _Product _ReferenceObject _BillingRequestItem _RateElement _SubscriptionParameter _SubscriptionPriceAgreement _FUPSalesOrderItem _FUPServiceOrderItem _FUPServiceContrItem _FUPEntProjectItem _FUPSubscrpnItem _Appointment _Duration _BusinessSolutionOrder
BusSolnOrdPartner	CREATE / READ / UPDATE / DELETE	Header Partner For Create operation, you can only use this entity in association with BusinessSolutionOrder	_PartnerAddress _BusinessSolutionOrder
BusSolnOrdItmPartner	CREATE / READ / UPDATE / DELETE	Item Partner For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_PartnerAddress _Item _BusinessSolutionOrder
BusSolnOrdPartnerAddress	READ / UPDATE	Header Partner Address	_Partner _BusinessSolutionOrder
BusSolnOrdItmPartnerAddr	READ / UPDATE	Item Partner Address	_Partner _BusinessSolutionOrder
BusSolnOrdItmPriceElement	CREATE / READ / UPDATE / DELETE	Item Price Element For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_Item _BusinessSolutionOrder
BusSolnOrdItmScheduleLine	READ	Schedule Line of Sales Item	_Item _BusinessSolutionOrder
BSOrdItmRateElement	READ	Rate Element of a Subscription Item	_Item _BusinessSolutionOrder
BSOrdItmSubscrpnParameter	CREATE / READ / UPDATE / DELETE	Subscription Parameter of a Subscription Item	_Item _BusinessSolutionOrder
BSOrdItmSubscrpnPriceAgrmt	CREATE / READ / UPDATE / DELETE	Price Agreement of Subscription Item	_Item _BusinessSolutionOrder
BusSolnOrdItmProduct	CREATE / READ / UPDATE / DELETE	Item Product For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_Item _BusinessSolutionOrder
BusSolnOrdItmRefObject	CREATE / READ / UPDATE / DELETE	Item Reference Object For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_Item _BusinessSolutionOrder
BusSolnOrdItemRelationship	CREATE / READ / DELETE	Item Relationship For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_BusinessSolutionOrder
BusSolnOrdUserStatus	CREATE / READ	Header User Status For Create operation, you can only use this entity in association with BusinessSolutionOrder	_BusinessSolutionOrder
BusSolnOrdItmUserStatus	CREATE / READ	Item User Status For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_Item _BusinessSolutionOrder
BusinessSolutionOrderLongText	CREATE / READ / UPDATE / DELETE	Header Text	_BusinessSolutionOrder
BusSolnOrdItmLongTxt	CREATE / READ / UPDATE / DELETE	Item Text For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_Item _BusinessSolutionOrder
BusSolnOrdItmBillgReqItem	READ	Billing Request Item of a Contract Item	_PriceElement _Item _BusinessSolutionOrder
BSOrdItmBillgReqItmPrcElm	CREATE/READ / UPDATE/DELETE	Price Element of Billing Request Line For Create operation, you can only use this entity in association with BusSolnOrdItmBillgReqItem	_BillingRequestItem _Item _BusinessSolutionOrder
BusSolnOrdAppointment	CREATE / READ / UPDATE	Header Appointments	_BusinessSolutionOrderTP
BusSolnOrdItmAppointment	CREATE / READ / UPDATE	Item Appointments	_Item _BusinessSolutionOrder
BusSolnOrdItmDuration	CREATE / READ / UPDATE	Item Duration	_Item _BusinessSolutionOrderTP
BusSolnOrdFUPSalesOrder	READ	Follow Up Sales Orders	_BusinessSolutionOrder
BusSolnOrdFUPSrvcOrd	READ	Follow Up Service Orders	_BusinessSolutionOrder
BusSolnOrdFUPSrvcContr	READ	Follow Up Service Contracts	_BusinessSolutionOrder
BusSolnOrdFUPSubscrpn	READ	Follow Up Subscriptions	_BusinessSolutionOrder
BusSolnOrdFUPEntProject	READ	Follow Up Projects	_BusinessSolutionOrder
BusSolnOrdItmFUPSalesOrder	READ	Follow Up Sales Order Items	_Item _BusinessSolutionOrder
BusSolnOrdItmFUPSrvcOrd	READ	Follow Up Service Order Items	_Item _BusinessSolutionOrder
BusSolnOrdItmFUPSrvcContr	READ	Follow Up Service Contract Items	_Item _BusinessSolutionOrder
BusSolnOrdItmFUPSubscrpn	READ	Follow Up Subscription Items	_Item _BusinessSolutionOrder
BusSolnOrdItmFUPEntProject	READ	Follow Up Project Items	_Item _BusinessSolutionOrder

BusinessSolutionOrder – Solution Order Header

With the Solution Order Header entity and its associations, you can create a solution order with the header and one or more of its associated entity(and its associated entities).

For Example: You can create a solution order by using the BusinessSolutionOrder along with Items, Partner, Item Partner, PriceElement, ItemRelationship, Text, UserStatus etc.

In the below example you will see creation of a solution order, adding items to the solution orders, creating a header text, and creating an item relationship between two items, all in separate OData calls and also to see how this can be achieved in one deep insert ODATA calls

Create a solution order with just header

POST <host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder

X-CSRF-Token: abc

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Solution Order",
  "Language": "EN",
  "SoldToParty": "17100001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "PurchaseOrderByCustomer": "External Reference"
}

Create an Item for an existing solution order

POST <host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100004251/_Item

X-CSRF-Token: abc

{
  "Product": "TG11",
  "BusinessSolutionOrderItem": "10",
  "Quantity": 1,
  "QuantityUnit": "PC",
  "BusSolnOrdItmQtyUnitISOCode": "PCE"
}

Create another Item for an existing solution order

POST <host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100004251/_Item

X-CSRF-Token: abc

{
  "Product": "SRV_01",
  "BusinessSolutionOrderItem": "20",
  "Quantity": 1,
  "SrvcContrDetnIsSpprsd": true,
  "QuantityUnit": "HR",
  "BusSolnOrdItmQtyUnitISOCode": "HUR"
}

Create a Header Text for an existing solution order

POST <host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100004251/_Text

X-CSRF-Token: abc

{
  "TextObjectType": "0001",
  "Language": "EN",
  "BusinessSolutionOrderLongText": "This is a Header Note"
}

Create an item relationship between item 10 and item 20 of an existing solution order

POST <host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100004251/_ItemRelationship

X-CSRF-Token: abc

{
  "BusinessSolutionOrder":"<<SOLUTION_ORDER_ID>>",
  "SrvcItemRelshpFromItemNumber": "10",
  "SrvcItemRelshpType": "001",
  "SrvcItemRelshpToItemNumber": "20"
}

You can also perform all the above in one deep insert OData request by specifying all the related entities in a single request

Create a solution order with deep insert: 2 items, override header partner, override item partner, add a header note and create an item relationship between item 10 and 20

POST <host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder

X-CSRF-Token: abc

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Solution Order",
  "Language": "EN",
  "SoldToParty": "17100001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "PurchaseOrderByCustomer": "External Reference",

  //Solution Order Item
  "_Item": [
    {
      "Product": "TG11",
      "BusinessSolutionOrderItem": "10",
      "Quantity": 1,
      "QuantityUnit": "PC",
      "BusSolnOrdItmQtyUnitISOCode": "PCE",
      "_Partner": [
        {
          "CustMgmtPartnerFunction": "00000055",
          "CustMgmtBusinessPartner": "17100003"
        }
      ]
    },
    {
      "Product": "SRV_01",
      "BusinessSolutionOrderItem": "20",
      "SrvcContrDetnIsSpprsd": true,
      "Quantity": 1,
      "QuantityUnit": "HR",
      "BusSolnOrdItmQtyUnitISOCode": "HUR"
    }
  ],

  //Partner at Header
  "_Partner": [
    {
      "CustMgmtPartnerFunction": "00000055",
      "CustMgmtBusinessPartner": "17100002"
    }
  ],

  //Notes at Header
  "_Text": [
    {
      "TextObjectType": "0001",
      "Language": "EN",
      "BusinessSolutionOrderLongText": "This is a Header Note"
    }
  ],

  //Relationship between Items
  "_ItemRelationship": [
    {
      "SrvcItemRelshpFromItemNumber": "10",
      "SrvcItemRelshpType": "001",
      "SrvcItemRelshpToItemNumber": "20"
    }
  ]
}

Read all the entities of a solution order

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003509?$expand=*

Read one or more associated entities of a solution order header

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003509?$expand=_Partner,_ItemRelationship

BusinessSolutionOrderItem – Solution Order Item

With the Solution Order Item entity, you can create one ore more of its associated entity. However, to create a solution order item, you will have to use the BusinessSolutionOrder along with _Item association.

For Example: You can create an Item Partner, PriceElement, Text, UserStatus etc for an item using the BusinessSolutionOrderItem along with the respective associations.

In the below examples you will see creation of a discount price condition, Item Text, Item Product, Reference Object, Item Appointment, Item Duration, Price Agreement for an existing solution order item,

Create a discount price element for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/20/_PriceElement

X-CSRF-Token: abc

{
  "ConditionType": "DRV1",
  "ConditionRateValue": -10
}

Create an item text for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/10/_Text

X-CSRF-Token: abc

{
  "TextObjectType": "0001",
  "Language": "EN",
  "BusSolnOrdItmLongText": "This is an Item Note"
}

Create an item product for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/30/_Product

X-CSRF-Token: abc

{
  "ServiceProductListItem": "1",
  "SrvcProductListProduct": "SRV_01"
}

Create item reference object for an existing solution order Service item

For a service item, you can create a reference object by passing either the functional location id or the equipment id.

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/20/_ReferenceObject

X-CSRF-Token: abc

{
  "ServiceReferenceEquipment":"10001405"
}

Create item reference object for an existing solution order Service item

For a contract item, you can create a reference object by passing either the functional location id or the equipment id or the Reference Product.

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/20/_ReferenceObject

X-CSRF-Token: abc

{
  "ServiceReferenceProduct":"10001405"
}

Create an item appointment for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/50/_Appointment

X-CSRF-Token: abc

{
  "SrvcDocAppointmentType":"SUBS_PRIC_DT",
  "SrvcDocApptStartDateTime":"2025-09-28T10:00:00Z",
  "SrvcDocApptEndDateTime":"2025-09-28T10:00:00Z"
}

Appointment entities are used to persist various date fields in solution order.

You define the Appointment type using the configuration activity Define Date Types, Duration Types and Date Rules for Service Transactions in your configuration environment. The system uses the duration, dates types, and date rules that are combined in a specific date profile to display dates in a transaction and to automatically determine them. Make sure to assign the date profile to transaction types.

Create an item duration for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/30/_Duration

X-CSRF-Token: abc

{
  "SrvcDocDurationType": "CONTDURA",
  "SrvcDocDurationValue": 18,
  "SrvcDocDurationUnit": "MONTH"
}

Fields on the UI like Fixed Term, Minimum Term, Minimum Term End, Renewal Term, Withdrawal Period, Withdrawal Period End, Term of Notice, Expected Term, Expected Term End, Expected Term Extension (visible under the Subscription Terms section in the UI), and Contact Validity Period (visible in the Dates Section of a contract item)are available in the Item Duration entity. These are persisted against the duration types below. The subscription terms can be updated in the UI as well as API only if the field “Override Default Terms” is selected (field in API - SubscrpnContrTrmsAreSpecified)

You define the Duration type using the configuration activity Define Date Types, Duration Types and Date Rules for Service Transactions in your configuration environment. The system uses the duration, dates types, and date rules that are combined in a specific date profile to display dates in a transaction and to automatically determine them. Make sure to assign the date profile to transaction types.

Create an item price agreement for an existing solution order subscription item

Price agreements are originally persisted in the subscription system, however this can be customised in the S/4HANA system. In such cases, the customised values are additionally persisted in S/4HANA systems.

Under the Price Calculation section you will see the prices that can be customisable. You can customize the price using the POST operation on the BusinessSolutionOrderItem entity using the _SubscriptionPriceAgreement association.

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001 /BusinessSolutionOrderItem/100003519/50/_SubscriptionPriceAgreement

X-CSRF-Token: abc

{
  "SubscriptionRateElement": "ONETIME",
  "SubscrpnBillgPrcElmntSpec": "OneTimePrice",
  "SubscrpnBillgPricingField": "price",
  "SubscrpnBillgPricingScaleType": "A",
  "SubscrpnBillgCndnCalcType": "B",
  "ConditionCurrency": "USD",
  "ConditionRateValue": 190,
  "SbscrBilgCndnScaleLineIsUnlmtd": false
}

Once the price is updated in S/4HANA it is persisted and you will notice under the customization status as Is Customized.

Since there is no persistency in the S/4HANA system until it is customised, the first time the customising of the price can be done using a POST operation of the API, and to update the prices again a PATCH operation can be used.

Multiple Price calculation is not supported. However if you still use the POST again after the initial customising, there will be 2 entries of the price which will be persisted in the table.

In such case the entire Price calculation section will become empty and the solution order item will unusable in the UI along with a simulation error. This cannot be corrected from the UI. To correct this, you will have to delete the record using the DELETE operation on the Item Price Agreement entity (BSOrdItmSubscrpnPriceAgrmt).

BusSolnOrdPartner – Solution Order Header Partner

Solution Order determines header partners based on the partner determination procedure assigned to the transaction type.

To override the determined partners, you can pass the partner information either using the partner functions available as properties in the BusinessSolutionOrder entity like ShipToParty, BillToParty, PayerParty, RespEmployeeBusinessPartnerId and ContactPersonBusinessPartnerId or by passing the respective partners in the _Partner association while creating a solution order using deep insert.

The header partner entity can also be created using the association _Partner of the BusinessSolutionOrder entity but this may result in a too many partner error on the document. So If you use the _Partner association to create a partner at header make sure the entry you are trying to create doesn’t create an additional partner of an existing type.

Create a header partner for an existing solution order

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003561/_Partner

X-CSRF-Token: abc
IF-Match: *

{
  "BusinessSolutionOrder":"100003561",
  "CustMgmtPartnerFunction":"00000003",
  "CustMgmtBusinessPartner":"17100002"
}

If you observe the metadata of the header partner entity, You will notice that both the properties CustMgmtPartnerFunction and CustMgmtBusinessPartner are key properties and hence they cannot be updated via a PATCH call. So to update a header partner, you can use the properties ShipToParty, BillToParty, PayerParty, RespEmployeeBusinessPartnerId and ContactPersonBusinessPartnerId in the BusinessSolutionOrder entity.

You should not try to update the SoldToPrarty property either at the header or the item.

Delete a header partner of an existing solution order

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdPartner/100003561/00000003/17100001

X-CSRF-Token: abc
IF-Match: *

Deleting a header partner might result in an error if the partner function is mandatory.

BusSolnOrdItmPartner – Solution Order Item Partner

Solution Order determines item partners based on the partner determination procedure assigned to the transaction type and the header partner.

To override the determined partners, you can pass the partner information either using the partner functions available as properties in the BusinessSolutionOrderItem entity like ShipToParty, BillToParty, PayerParty, RespEmployeeBusinessPartnerId and ContactPersonBusinessPartnerId or by passing the respective partners in the _Partner association while creating a solution order using deep insert.

The item partner entity can also be created using the association _Partner of the BusinessSolutionOrderItem entity but this may result in a too many partner error on the document. So If you use the _Partner association to create a partner at the item make sure the entry you are trying to create doesn’t create an additional partner of an existing type.

Create an item partner for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003561/10/_Partner

X-CSRF-Token: abc

{
  "BusinessSolutionOrder":"100003561",
  "BusinessSolutionOrderItem":"10",
  "CustMgmtPartnerFunction":"00000003",
  "CustMgmtBusinessPartner":"17100002"
}

If you observe the metadata of the item partner entity, You will notice that both the properties CustMgmtPartnerFunction and CustMgmtBusinessPartner are key properties and hence they cannot be updated via a PATCH call. So to update an item partner, you can use the properties ShipToParty, BillToParty, PayerParty, RespEmployeeBusinessPartnerId and ContactPersonBusinessPartnerId in the BusinessSolutionOrderItem entity. You should not try to update the SoldToPrarty property either at the header or the item.

Delete an item partner of an existing solution order item

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdPartnerItem/100003561/10/00000003/17100001

X-CSRF-Token: abc
IF-Match: *

Deleting an item partner might result in an error if the partner function is mandatory.

BusSolnOrdPartnerAddress – Address of Header Partner

Address of header partner can be read and updated

Update address of header partner of an existing solution order

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdPartnerAddress/100004251/00000003/17100001

X-CSRF-Token: abc
IF-Match: *

{
  "HouseNumber": "138",
  "StreetName": "ITPL Main Road",
  "CityName": "Banglaore",
  "Country": "IN",
  "Region": "KA",
  "PostalCode": "560066",
  "MobilePhoneCountry": "IN",
  "MobileNumber": "9988776655",
  "PhoneNumberCountry": "US",
  "PhoneNumber": "20204040",
  "PhoneExtensionNumber": "1234",
  "FaxNumberCountry": "IN",
  "FaxAreaCodeSubscriberNumber": "1234567890",
  "FaxExtensionNumber": "5678",
  "EmailAddress": "newmailaddr@mailbox.com"
}

BusSolnOrdItmPartnerAddr - Address of Item Partner

Address of item partner can be read and updated

Update address of item partner of an existing solution order item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmPartnerAddr/100004251/10/00000003/17100001

X-CSRF-Token: abc
IF-Match: *

{
  "HouseNumber": "138",
  "StreetName": "ITPL Main Road",
  "CityName": "Banglaore",
  "Country": "IN",
  "Region": "KA",
  "PostalCode": "560066",
  "MobilePhoneCountry": "IN",
  "MobileNumber": "9988776655",
  "PhoneNumberCountry": "US",
  "PhoneNumber": "20204040",
  "PhoneExtensionNumber": "1234",
  "FaxNumberCountry": "IN",
  "FaxAreaCodeSubscriberNumber": "1234567890",
  "FaxExtensionNumber": "5678",
  "EmailAddress": "newmailaddr@mailbox.com"
}

BusSolnOrdItmPriceElement – Item Price Element

Item price element of a solution order item can be created by passing the price element in the _PriceElement association at the item while creating a solution order using deep insert.

The item price element entity can also be created using the association _ PriceElement of the BusinessSolutionOrderItem entity.

Create an item price element for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/10/_PriceElement

X-CSRF-Token: abc

{
  "ConditionType": "DRV1",
  "ConditionRateValue": -10
}

If you create a price element with the same condition type as existing, it will override the existing price element and will mark it inactive and make the new one active.

Update item price element of an existing solution order item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmPriceElement/100004251/10/240/1

X-CSRF-Token: abc
IF-Match: *

{
  "BusinessSolutionOrder": "100004251",
  "BusinessSolutionOrderItem": "10",
  "PricingProcedureStep": "240",
  "PricingProcedureCounter": "1",
  "ConditionType": "DRV1",
  "ConditionRateValue": -5
}

The PricingProcedureStep and PricingProcedureCounter needs to be passed in the parameter

Delete an item price element of an existing solution order item

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmPriceElement/100004251/10/240/1

X-CSRF-Token: abc
IF-Match: *

To Deleting an item price element, PricingProcedureStep and PricingProcedureCounter needs to be passed in the parameter.

BusSolnOrdItmScheduleLine – Item Schedule Line(Sales Item)

You can only read a schedule line entity and no other operations are supported on this entity, and this is only relevant for a sales item

Read a schedule line of a sales item of an existing solution order

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmScheduleLine/100004251/10/1

You can also use the $filter parameter to filter by the solution order you will get all the schedule line entities for the solution order

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmScheduleLine?$filter=BusinessSolutionOrder eq '100004251'

BSOrdItmRateElement – Item Rate Element (Subscription Item)

You cannot update a rate element but can read an existing rate element for a solution order subscription item using BSOrdItmRateElement

By passing the solution order number, item and rate element number. You can also read the rate element when you read a solution order item with an expand=_RateElement

BSOrdItmSubscrpnParameter – Item Subscription Parameter(Subscription Item)

You can read a subscription parameter using a GET operation on the BSOrdItmSubscrpnParameter entity by passing the solution order number, item and the subscription parameter sequence number or by reading the solution order item with a $expand = _SubscriptionParameter

Update subscription parameter of an existing solution order item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BSOrdItmSubscrpnParameter/100004251/70/1

X-CSRF-Token: abc

IF-Match: *

{
  "SubscriptionParameter": "ONETIME_CREDIT",
  "SubscrpnParameterIntegerValue": 2
}

You can update a subscription parameter of a subscription item only if the item is not released or completed already

Delete subscription parameter of an existing solution order item

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BSOrdItmSubscrpnParameter/100004251/70/1

X-CSRF-Token: abc
IF-Match: *

You can delete a subscription parameter of a subscription item only if the item is not released or completed already

Create subscription parameter of an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/70/_SubscriptionParameter

X-CSRF-Token: abc
IF-Match: *

{
  "SubscriptionParameter": "ONETIME_CREDIT",
  "SubscrpnParameterIntegerValue": 1
}

You can create a subscription parameter of a subscription item using the POST operation on BusinessSolutionOrderItem using the association _SubscriptionParameter

BSOrdItmSubscrpnPriceAgrmt Item Price Agreement(Subscription Item)

Update subscription price agreement of an existing solution order item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BSOrdItmSubscrpnPriceAgrmt(BusinessSolutionOrder='100004251',BusinessSolutionOrderItem='000070',SubscriptionRateElement='ONETIME_CRDT',SubscriptionRateSubElement='',SubscrpnBillgPrcElmntSpec='OneTimePrice',SubscrpnBillgPricingField='price',SubscrpnBillgPrcAgreementLine='900001')

X-CSRF-Token: abc
IF-Match: *

{
  "SubscrpnBillgPricingScaleType": "A",
  "SubscrpnBillgCndnCalcType": "B",
  "ConditionRateValue": 1001,
  "ConditionCurrency": "USD"
}

Delete subscription price agreement of an existing solution order item

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BSOrdItmSubscrpnPriceAgrmt(BusinessSolutionOrder='100004251',BusinessSolutionOrderItem='000070',SubscriptionRateElement='ONETIME_CRDT',SubscriptionRateSubElement='',SubscrpnBillgPrcElmntSpec='OneTimePrice',SubscrpnBillgPricingField='price',SubscrpnBillgPrcAgreementLine='900001')

X-CSRF-Token: abc
IF-Match: *

You can update or delete a subscription price agreement of a subscription item only if the item is not released or completed already. To be sure you pass the mandatory information correctly, you can do a GET operation on the BSOrdItmSubscrpnPriceAgrmt entity for the subscription item you want to update the price Agreement. It is required to pass the scale type and calculation type in the payload even though you do not intend to modify them

BusSolnOrdItmProduct – Item Product(Contract Item)

Update item product list of an existing solution order contract item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmProduct/100004251/100/1

X-CSRF-Token: abc
IF-Match: *

{
  "SrvcProductListProduct":"SRV_05"
}

Delete subscription price agreement of an existing solution order item

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmProduct/100004251/100/1

X-CSRF-Token: abc
IF-Match: *

You can update or delete an Item Product List of contract item only if the item is not released or completed already.

BusSolnOrdItmRefObject – Item Reference Object(Service or Contract Item)

Update item reference object list of an existing solution order contract item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmProduct/100004251/100/1

X-CSRF-Token: abc
IF-Match: *

{
  "SrvcProductListProduct":"SRV_05"
}

Delete item reference object list of an existing solution order contract item

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmRefObject/100004251/100/1

X-CSRF-Token: abc
IF-Match: *

You can update an Item Reference object of a service item by passing the equipment id or the functional location id in the payload or that of a contract item by passing the reference product id or the equipment id or the functional location id in the payload.

BusSolnOrdItemRelationship – Solution Order Item Relationship

Get all item relationships in a solution order

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItemRelationship?$filter=BusinessSolutionOrder eq '100004251'

Delete an item relationship of type 001 (Depends on) between item 10 and 20

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItemRelationship/100004251/10/001/20

X-CSRF-Token: abc
IF-Match: *

BusSolnOrdUserStatus – Header User Status

Create user status at header for an existing solution order

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/<<SOLO_ID>>/_UserStatus

X-CSRF-Token: abc

{
  "BusinessSolutionOrder": "100004251",
  "UserStatus": "E0002"
}

Create user status at header using deep insert while creating a solution order

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder

X-CSRF-Token: abc

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Solution Order with User Status",
  "Language": "EN",
  "SoldToParty": "17100001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "PurchaseOrderByCustomer": "External Reference",
  "_UserStatus": [
    {
      "UserStatus": "E0002"
    }
  ]
}

BusSolnOrdItmUserStatus – Item User Status

Prerequisites: Make sure to assign the status profile to which the user status belongs to the respective item category of the solution order item. To do this, using SSCUI, define status profile for User Status and assign the status profile to item categories

Create item user status at item for an existing solution order

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100004251/10/_UserStatus

X-CSRF-Token: abc

{
  "UserStatus": "E0002"
}

Create item user status using deep insert while creating a solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100004251/_Item

X-CSRF-Token: abc

{
  "Product": "TG11",
  "Quantity": 1,
  "BusSolnOrdItmQtyUnitISOCode": "EA",
  "_UserStatus": [
    {
      "UserStatus": "E0002"
    }
  ]
}

BusinessSolutionOrderLongText – Header Long Text

Get all header text of a solution order

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderLongText?$filter=BusinessSolutionOrder eq '100004251'

Get a specific header text of a solution order

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderLongText/100004251/0001/EN

Update a header text of a solution order

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderLongText/100004251/0001/EN

X-CSRF-Token: abc
IF-Match: *

{
  "BusinessSolutionOrderLongText":"Updated Header Text"
}

Delete a header text of a solution order

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderLongText/100004251/0001/EN

X-CSRF-Token: abc
IF-Match: *

BusSolnOrdItmLongTxt – Item Long Text

Get item text of a solution order item 10

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmLongTxt?$filter=BusinessSolutionOrder eq '100004251'and BusinessSolutionOrderItem eq '10'

Update item text of a solution order item 10

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmLongTxt/100004251/10/001/EN

X-CSRF-Token: abc
IF-Match: *

{
  "BusSolnOrdItmLongText": "Updated Item Text"
}

Delete item text of a solution order item 10

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmLongTxt/100004251/10/001/EN

X-CSRF-Token: abc
IF-Match: *

BusSolnOrdItmBillgReqItem – Billing Request Item(of a Contract Item)

Only READ operation is supported on the BusSolnOrdItmBillgReqItem entity. This will be available only for service contract item with item category SOSC (Service Contract Item) and SOPA (Service Contract Price Adaptation)

Get all Billing Request Items of a solution order contract item

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmBillgReqItem?$filter=BusinessSolutionOrder eq '100004251'

Get a specific billing request item of a solution order contract item by id

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmBillgReqItem/100004251/100/800001

BSOrdItmBillgReqItmPrcElm – Price element of Billing Request Item (Contract Item)

You can create a Price Element for a Billing request Item of a Contract item of a solution order using the _PriceElement association of the BusSolnOrdItmBillgReqItem entity.

Create a discount price element for a specific billing item a solution order service contract item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmBillgReqItem/100004251/100/800001/_PriceElement

X-CSRF-Token: abc

{
  "ConditionType": "DRV1",
  "ConditionRateValue": -10,
  "ConditionCurrency": "USD"
}

Above payload will create a price element (Fixed Discount DRV1) for billing item 800001 of the service contract item

Read all the price element for a billing request item of a solution order contract item

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmBillgReqItem/100004251/100/800001/_PriceElement

Update a price element for a billing request item of a solution order contract item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BSOrdItmBillgReqItmPrcElm/100004251/100/800001/90/1

X-CSRF-Token: abc
IF-Match: *

{
   "ConditionType": "PSI1",
   "ConditionRateValue": 120
}

BusSolnOrdAppointment – Header Appointment

Appointment entities are used to persist various date fields in solution order.

Update BILL_DATE at solution order header using the Appointment Entity

Billing Date is a single date field and does not have a start and end date, in such case in the payload, the SrvcDocApptStartDateTime needs to be passed.

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdAppointment/100004251/BILL_DATE

X-CSRF-Token: abc
IF-Match: *

{
  "SrvcDocAppointmentType": "BILL_DATE",
  "SrvcDocApptStartDateTime": "2025-10-23T00:00:00Z",
}

Read BILL_DATE at solution order header using the Appointment Entity

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdAppointment/100004251/BILL_DATE

BusSolnOrdItmAppointment – Item Appointment

To update subscription end date of a subscription item, use the ServiceContrItemEndDateTime field at the BusinessSolutionOrderItem entity instead of the CONTEND Appointment type.

Update Requested delivery date of a sales item of a solution order using the Appointment Entity

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmAppointment/100004251/10/REQ_DLV_DATE

X-CSRF-Token: abc
IF-Match: *

{
  "SrvcDocAppointmentType": "REQ_DLV_DATE",
  "SrvcDocApptStartDateTime": "2025-10-28T00:00:00Z"
}

BusSolnOrdItmDuration – Item Duration

Various durations like subscription terms, contract duration, renewal terms, etc are stored as durations in the BusSolnOrdItmDuration entity which has an association with the BusinessSolutionOrderItem entity. The different duration types in solution order are persisted across the duration types specified in the below table.

Update Contract Duration of a contract item of a solution order using the Duration Entity

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmDuration/100004251/100/CONTDURA

X-CSRF-Token: abc
IF-Match: *

{
  "SrvcDocDurationType": "CONTDURA",
  "SrvcDocDurationValue": 48,
  "SrvcDocDurationUnit": "Month"
}

BusSolnOrdFUPSalesOrder – Follow-up Sales Order

You can only read the follow up sales order and no other operations are supported on this entity. This will list all the follow-up sales order document for the solution order. Once a sales item is released, the follow up document gets created. This corresponds to the “Transaction History” section on the UI

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003541/_FUPSalesOrder

BusSolnOrdFUPSrvcOrd – Follow-up Service Order

You can only read the follow up service order and no other operations are supported on this entity. This will list all the follow-up service order document for the solution order. Once a service item is released, the follow up document gets created. This corresponds to the “Transaction History” section on the UI

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003541/_FUPServiceOrder

BusSolnOrdFUPSrvcContr – Follow-up Service Contract

You can only read the follow up service contract and no other operations are supported on this entity. This will list all the follow-up service contract document for the solution order. Once a service contract item is released, the follow up document gets created. This corresponds to the “Transaction History” section on the UI

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003541/_FUPServiceContr

BusSolnOrdFUPSubscrpn – Follow-up Subscription

You can only read the follow up subscription and no other operations are supported on this entity. This will list all the follow-up subscription document for the solution order. Once a subscription item is released, the follow up document gets created. This corresponds to the “Transaction History” section on the UI

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003541/_FUPSubscrpn

BusSolnOrdFUPEntProject – Follow-up Enterprise Project

Only read operation is supported on this entity. This will list all the follow-up project document for the solution order. Once a project item is released, the follow up document gets created. This corresponds to the “Transaction History” section on the UI

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003541/_FUPEntProject

BusSolnOrdItmFUPSalesOrder - Follow-up Sales Order Item

Only read operation is supported on this entity. This will list all the follow-up sales order along with its corresponding item numbers. Once a sales item is released, the follow up document gets created.

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/10/_FUPSalesOrderItem

BusSolnOrdItmFUPSrvcOrd – Follow-up Service Order Item

Only read operation is supported on this entity. This will list all the follow-up service order along with its corresponding item numbers. Once a sales item is released, the follow up document gets created.

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/20/_FUPServiceOrderItem

BusSolnOrdItmFUPSrvcContr – Follow-up Service Contract Item

Only read operation is supported on this entity. This will list all the follow-up service contract along with its corresponding item numbers. Once a service contract item is released, the follow up document gets created.

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/30/_FUPServiceContrItem

BusSolnOrdItmFUPSubscrpn – Follow-up Subscription Item

Only read operation is supported on this entity. This will list all the follow-up subscription. Once a subscription item is released, the follow up document gets created.

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/40/_FUPSubscrpnItem

BusSolnOrdItmFUPEntProject - Follow-up Enterprise Project Item

Only read operation is supported on this entity. This will list all the follow-up project document for the solution order. Once a service contract item is released, the follow up document gets created.

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/50/_FUPEntProjectItem

How to connect with SAP S/4HANA OData Services from SAP APIM?

2025-11-13T17:45:49.137000+01:00

Assuming that you have enabled the API Management capability in Integration Suite, I will start with API Provider creation.

1. Create API Provider

Connection

Type	On Premise
Host	Virtual Host, as mentioned in Cloud Connector
Port	Virtual Port, as mentioned in Cloud Connector
Location ID	As mentioned in Cloud Connector
Authentication	NONE
Additional Properties:	sap-client: XXX

Catalog Service Settings

Path Prefix	/sap/opu/odata
Service Collection URL	/IWFND/CATALOGSERVICE;v=2/ServiceCollection
Authentication type	BASIC
Username	SAP's User Name for communication
Password	***

Test connection:

2. Create API Proxy

Select the API Provider, click on Discover to select the API which you wanted to use

Select the API & then click on Create.

3. Create Key Value Map to store the credentials to S/4HANA

4. Add Policies

Verify API Key - To verify the key which you are going to pass while calling the API.
Where do you get the API? - When you create the Product, and a Subscription, after creating a Subscription in the Developer Hub you will get a Key. That key is to be provided to the Consumer, and this Policy will verify the key sent by the consumer.

 <!--Specify in the APIKey element where to look for the variable containing the api key--> 
<VerifyAPIKey async='true' continueOnError='false' enabled='true' 
xmlns='http://www.sap.com/apimgmt'>
	<APIKey ref='request.header.apikey '/>
</VerifyAPIKey>

Key Value Map Operations - To fetch the credentials saved in the Key Value Mapping

<KeyValueMapOperations mapIdentifier="SAP_S4HANA_Credentials" async="true" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
    <Get assignTo="private.usernameFromKVM" index="1">
        <Key>
            <Parameter>Username</Parameter>
        </Key>
    </Get>
    <Get assignTo="private.passwordFromKVM" index="1">
        <Key>
            <Parameter>Password</Parameter>
        </Key>
    </Get>
    <Scope>environment</Scope>
</KeyValueMapOperations>

Basic Authentication - To pass the credentials fetched in the previous step.

<BasicAuthentication async='true' continueOnError='false' enabled='true' xmlns='http://www.sap.com/apimgmt'>
	<Operation>Encode</Operation>
	<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
	<User ref='private.usernameFromKVM'></User>
	<Password ref='private.passwordFromKVM'></Password>
 	<AssignTo>request.header.Authorization</AssignTo>
</BasicAuthentication>

Assign Message - So you get an error as, "{"fault":{"faultstring":"Unsupported Encoding \"br\"","detail":{"errorcode":"protocol.http.UnsupportedEncoding"}}}".
BR is a data format Brotli which is often defined by backend for webpage loading and not accepted by default. And this Assign Message will help your message reach the target.

<!-- This policy can be used to create or modify the standard HTTP request and response messages -->
<AssignMessage async="false" continueOnError="false" enabled="true" xmlns='http://www.sap.com/apimgmt'>
 
	<!-- Sets a new value to the existing parameter -->
	<Set>
		<Headers>
		     <Header name="Accept-Encoding">gzip,deflate</Header>
	     </Headers> 
	</Set>
	<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
	<AssignTo createNew="false" type="request"></AssignTo>
</AssignMessage>

5. Create Product & Add the API

6. Create a Subscription for the Product created

7. It's time to test!

Use SAP Fiori Development Portal to Understand Extension Options for Standard Floorplans (4 of 6)

2025-11-17T12:15:41.843000+01:00

In our previous posts, we explored individual building blocks and their sophisticated capabilities. Now it's time to see how these building blocks come together in predefined layouts called standard floorplans delivered by SAP Fiori elements for OData V4. The SAP Fiori development portal not only showcases these proven layouts but also reveals the rich set of extension options available to customize them for your specific business needs. Let's explore how you can leverage standard floorplans while maintaining the flexibility to extend when necessary.

Understanding Standard Floorplans

Standard floorplans are predefined layouts of building blocks provided to enable efficient SAP Fiori elements application development. These floorplans inherit all the qualities of their building blocks while adding optimizations for component interaction at the floorplan level. Think of them as proven blueprints that combine the building blocks we explored in previous posts into coherent, user-friendly experiences.

In the portal's section for Standard Floorplans we demonstrate why this is the most efficient approach for building your SAP Fiori elements application. These layouts represent years of UX research, customer feedback, and real-world usage patterns. When your requirements align closely with a standard floorplan, you get enterprise ready functionality with minimal development effort.

The list report – object page layouts are the most common floorplans in SAP Fiori elements

Exploring Floorplans in the Portal

The portal showcases different types of standard floorplans, each optimized for specific use cases:

List Report Page - The classic combination of filter bar and table for comprehensive data exploration and management
- Worklist - A streamlined version focusing purely on the table when filtering isn't the primary concern
- Analytical List Page – An enhanced version with visual filters and charts for data analysis and insights
Overview Page - Visual card-based interface for quick access to vital business information and immediate action
Object Page - Comprehensive detail views with headers, forms, tables, charts, and draft-enabled editing capabilities for seamless document management

What's important to understand is that all these floorplans make use of the same building blocks we explored in our previous posts – like the table, chart, field, and filter bar components. The difference lies in how these building blocks are orchestrated and optimized to work together at the page level.

Extensions: When Standard Isn't Enough

Every standard floorplan provides extension points, and the portal's Extensions chapter is where you discover how to customize these proven layouts for your unique requirements. Let's look at a practical example that demonstrates both the power and philosophy of the extensibility that SAP Fiori elements for OData V4 offers.

In the Custom Section example, you'll see how to add a custom FlightMap section to an Object Page. This FlightMap control from SAPUI5 isn't natively supported by SAP Fiori elements, yet it integrates seamlessly into the standard floorplan structure.

Custom Section in Object Page

This example beautifully illustrates a key principle: your SAP Fiori elements application is never locked in. When you need functionality that goes beyond standard building blocks, you can extend the framework while retaining all the enterprise-grade features of the underlying floorplan.

However - and this is crucial - whenever functionality can be implemented using native SAP Fiori elements support (like adding a table or chart through annotations), it should be implemented that way. The closer your application stays to standard SAP Fiori elements patterns, the better your UI consistency, and the less development and maintenance effort you'll require over time.

Global Patterns: The Invisible Foundation

Don't overlook the Global Patterns chapter in the portal. These non-visual building blocks provide the enterprise-grade foundation that makes SAP Fiori applications truly business-ready, like:

Draft Handling - Seamless save and restore functionality
Routing and Navigation - Consistent navigation patterns across your application
Side Effects - Automatic field updates triggered by user interactions, maintaining data consistency across the UI

These global patterns are automatically used by standard floorplans, providing the robust foundation that users expect from SAP applications. Like their visual counterparts, they support extensions when your business logic requires custom behavior.

TypeScript Support: Modern Development Made Easy

The portal provides the code examples in TypeScript, reflecting the modern development practices we recommend for SAP Fiori elements applications. Take the Draft Handling page as an example. When you click "Show Code" next to "Implementing a Hook," you'll see TypeScript implementations that leverage our new BaseControllerExtension types.

Type Script Example in Fiori Development Portal

These new types make it significantly easier to implement hooks in TypeScript, providing better IntelliSense, type safety, and development experience. The portal even includes live transpiling in the browser, so you can see the immediate effects of your code changes. Try this yourself by changing the line:

return this.openDialog("Do you want to edit this travel request?", true);

to:

return this.openDialog("Do you really want to edit this travel request?", true);

Click the Edit button in the sample preview, and you'll see your modified dialog text appear immediately.

Updated Sample

This interactive learning approach helps you understand not just what's possible, but how your changes affect the user experience in real-time.

Conclusion

The SAP Fiori development portal proves to be an invaluable resource for exploring standard floorplans and understanding their extension capabilities. Whether you're building a straightforward List Report or a complex Object Page with custom sections, the portal guides you through the possibilities while helping you make informed decisions about when to use standard functionality versus custom extensions. The beauty of SAP Fiori elements lies in this balance: start with proven, enterprise-ready standard floorplans, then extend precisely where your business requirements demand it. The portal ensures you understand both the power of the standards and the flexibility of the extensions, enabling you to build applications that are both efficient to develop and maintain.

What's Next

In our next post, "Prepare building custom pages by using SAP Fiori development portal (5 of 6)," we'll explore how to move beyond standard floorplans entirely. We'll show you how the portal guides you through creating completely custom page layouts using the same building blocks, giving you maximum creative freedom while retaining all the enterprise-grade features that make SAP Fiori elements applications so powerful.

To get the full overview about the SAP Fiori development portal, check out the following blog posts of the mini-series:

Introducing the SAP Fiori Development Portal: Your Gateway to Rapid SAP Fiori App Creation (1 of 6)
Get familiar with SAP Fiori development portal and the power of the building blocks (2 of 6)
Explore the potential of SAP Fiori development portal using complex building blocks (3 of 6)
Use SAP Fiori development portal to understand extension options for standard floorplans (4 of 6)
Prepare building custom pages by using SAP Fiori development portal (5 of 6)
Bringing the SAP Fiori development portal and its use to the next level (6 of 6)

Handling $filter,$search and $orderby in SAP CAP when consuming External REST APIs

2025-11-25T05:57:09.692000+01:00

Introduction

When building applications with the SAP Cloud Application Programming Model (CAP), a very common real-world scenario is:

Your CAP service acts as a proxy
Data is fetched from an external REST API
The external API does not support OData

But your Fiori/UI5 frontend still sends OData queries like:

$filter=country eq 'IN'&$search=Bangalore&$orderby=name desc

This blog explains how to handle OData query options like $filter, $search, and $orderby in SAP CAP Node.js when your service consumes a non-OData external REST API.

Here is a lightweight JavaScript utility (handleOData.js) that:

Interprets CAP’s query structure (req.query.SELECT)
Applies filtering logic directly on API responses
Adds full-text search capability
Supports dynamic sorting based on $orderby

With this approach, your Fiori/UI applications can continue using rich OData queries without any dependency on the external API.

This solution is ideal for building CAP-based proxy services on SAP BTP that integrate with legacy or third-party REST systems.

Problem Statement :

Consider this scenario: Your frontend sends

GET /odata/v4/srv/DemandAreas?$filter=country eq 'IN'&$orderby=name asc

But your backend actually calls ,

GET https://external.api/demandAreas

The external API:

Does not support $filter
Does not support $search
Does not support $orderby

Yet you still want your frontend to fully leverage OData features.

So how do we bridge this gap?

Architecture Overview:

Solution Overview:

Utility file , handleOData.js exposes three main functions:

module.exports = { handleFilter, handleSearch, handleSort }

Each function handles a specific OData concept.

1. Handling $filter

CAP provides filters in a structured format (req.query.SELECT.where).

This utility interprets this structure and evaluates it against each result record.

Core logic idea:

function handleFilter(filters, item) {
  const stack = [];

  const applyComparison = (field, op, value) => {
    const fieldValue = item[field];

    switch (op) {
      case '=': return fieldValue == value;
      case '!=': return fieldValue != value;
      case '>': return fieldValue > value;
      case '>=': return fieldValue >= value;
      case '<': return fieldValue < value;
      case '<=': return fieldValue <= value;
      default: return false;
    }
  };

  // Logic continues to resolve AND / OR conditions}

This supports:

eq, ne, gt, ge, lt, le
Logical operations: AND, OR
Nested conditions

2. Handling $search

CAP exposes the search phrase via req.query.SELECT.search. The utility applies search across properties of each record.

Simplified logic:

function handleSearch(searchTerm, data) {
  return data.filter(item =>
    Object.values(item).some(val =>
      String(val).toLowerCase().includes(searchTerm.toLowerCase())
    )
  );
}

This allows our Fiori/UI app to use for example , $search=Bangalore

Even if the external API has no search support at all.

3. Handling $orderby

Ordering is handled using CAP’s orderBy structure.

Logic overview:

function handleSort(req, result) {
  const [orderClause] = req.query.SELECT.orderBy;
  const field = orderClause.ref[0];
  const dir = orderClause.sort === 'desc' ? -1 : 1;

  return [...result].sort((a, b) =>
    a[field] > b[field] ? 1 * dir : -1 * dir
  );
}

Supported:

$orderby=name asc
$orderby=createdAt desc

CAP Service Integration Example

Below is how you can plug this into your service implementation file:

const { handleFilter, handleSearch, handleSort } = require('./code/handleOData');
module.exports = (srv) => {

  srv.on('READ', 'DemandAreas', async (req) => {

    // 1. Call external REST APIlet data = await fetchExternalData();

    // 2. Apply $filterif (req.query.SELECT.where) {
      data = data.filter(item => handleFilter(req.query.SELECT.where, item));
    }

    // 3. Apply $searchif (req.query.SELECT.search) {
      data = handleSearch(req.query.SELECT.search, data);
    }

    // 4. Apply $orderbyif (req.query.SELECT.orderBy) {
      data = handleSort(req, data);
    }

    return data;
  });
};

Benefits of this Approach

Clean separation between CAP and external REST API
Full OData filtering support for Fiori/UI apps
No dependency on the external service supporting OData
Plug-and-play in any Node.js CAP project
Easy to extend with more operators

Conclusion:

This utility helps bridge the gap between OData-driven applications and non-OData REST services, while keeping our CAP service clean and the UI fully functional. If you’re building similar integrations, I hope this helps accelerate your work.

Prepare building custom pages by using SAP Fiori development portal (5 of 6)

2025-11-26T10:03:47.891000+01:00

In our previous posts, we explored individual building blocks, their sophisticated capabilities, and how they come together in standard floorplans. We also learned how to extend these standard floorplans when needed. But what happens when your business requirements demand a layout that doesn't match any standard floorplan? The SAP Fiori development portal has you covered. In this post, we'll show you how to build a completely custom page layout while leveraging SAP Fiori elements building blocks to maintain enterprise-grade functionality.

When to Choose Custom Pages

Before we dive into creating custom pages, let's be clear about the decision path. If your UI requirements fit one of the existing standard floorplans (List Report, Object Page, Analytical List Page, Overview Page, or Worklist), you should absolutely use them. Standard floorplans offer:

Reduced development and maintenance costs
Automatic UI consistency across your application landscape
Built-in enterprise features that would take months to develop from scratch
Future-proof compatibility with SAP Fiori elements updates

However, when you need a special layout - like a wizard, shopping cart, or any non-standard UI pattern - you're not blocked. You can implement your custom layout while using as many SAP Fiori elements building blocks as possible to retain the benefits of the framework.

Exploring Custom Pages in the Portal

The SAP Fiori development portal's Custom Page chapter provides comprehensive guidance for building custom layouts. Let's explore its key sections:

Overview - Shows a simple custom page demonstrating how building blocks integrate into custom layouts
Building Blocks Usage - Explains how to use SAP Fiori elements building blocks in existing UI5 freestyle applications, bridging the gap between traditional UI5 development and the SAP Fiori elements approach
Custom Root View - Demonstrates how to create and register custom root views when the standard options (FullScreen and Flexible Column Layout) don't meet your needs
Draft Handling - Shows how to leverage the Draft controller extension in your custom pages for seamless draft management

Fiori Development Portal: Custom page sample

These sections provide the foundation for understanding custom page development. Now let's put this knowledge into practice with a real-world example.

Building a Wizard: A Step-by-Step Journey

Let's create a wizard for travel request creation - a floorplan currently not available as a standard in SAP Fiori elements. We'll build this step by step, just as you would when developing your own custom page. The beauty of the portal is that you can experiment with code changes - auto-run is enabled by default, automatically refreshing the preview when you make simple changes. For more complex modifications, you can disable auto-run and manually click the "Run" button to update the sample when you're ready.

Step 1: Setting Up the Wizard Structure

Navigate to the Custom Pages Overview section in the portal. Click "Show Code" to open the code editor. We'll transform this simple page into a wizard.

First, let's add the wizard structure without any content in the steps. Replace the content of the CustomPageSample view with:

<mvc:View
	id="application-product"
	height="100%"
	controllerName="sap.fe.core.fpmExplorer.customPage.CustomPageSample"
	xmlns="sap.m"
	xmlns:mvc="sap.ui.core.mvc"
	xmlns:macros="sap.fe.macros"
>
	<macros:Page title="Create New Travel Request" class="sapUiContentPadding">
		<Wizard
			id="travelWizard"
			enableBranching="false"
			class="sapUiResponsivePadding--header sapUiResponsivePadding--content"
		>
			<WizardStep
				id="travelDataStep"
				title="Travel Information"
				validated="true"
			>
				<!-- We'll add content here -->
			</WizardStep>

			<WizardStep
				id="approvalDataStep"
				title="Budget and Approval"
				validated="true"
			>
				<!-- We'll add content here -->
			</WizardStep>

			<WizardStep
				id="bookingsStep"
				title="Bookings"
				validated="true"
			>
				<!-- We'll add content here -->
			</WizardStep>

			<WizardStep
				id="reviewStep"
				title="Submit Travel Request"
				validated="true"
			>
				<!-- We'll add content here -->
			</WizardStep>
		</Wizard>
	</macros:Page>
</mvc:View>

Now update the controller to support the wizard functionality. In the controller code editor, replace the CustomPageSample controller with:

import PageController from "sap/fe/core/PageController";
import MessageBox from "sap/m/MessageBox";
import type Context from "sap/ui/model/odata/v4/Context";

/**
 * Controller for the custom travel request wizard page.
 */
export default class CustomPageSampleController extends PageController {
	/**
	 * Creates a new travel request draft context and binds it to the view before rendering.
	 */
	public onBeforeRendering(): void {
		const view = this.getView();

		try {
			const model = view.getModel();

			// Create list binding and create a draft context
			const listBinding = model.bindList("/Travel");
			const wizardContext = listBinding.create({
				CurrencyCode_code: "EUR",
				BookingFee: 0,
				TotalPrice: 0,
				TravelStatus_code: "O"
			});

			// Bind the view to the created context
			view.setBindingContext(wizardContext);
			// Set the UI model property to make the forms and table editable
			view.getModel("ui").setProperty("/isEditable", true);
		} catch (error) {
			MessageBox.error("Failed to create travel request: " + (error as Error).message);
		}
	}

	/**
	 * Handler called when the submit button is pressed.
	 */
	public async onSubmitTravelRequest(): Promise<void> {
		// Navigate to the Object Page
		const routing = this.getExtensionAPI().getRouting();
		routing.navigate(this.getView().getBindingContext() as Context);
	}
}

You now have a working wizard structure with four steps! Before rendering the view, the controller's onBeforeRendering() method creates a new draft travel request and binds it to the view, so all our building blocks automatically work with this draft data. The onSubmitTravelRequest() method will be used later to finalize the wizard. For now, notice how the wizard steps are empty but navigable.

Preview wizard without step content

Step 2: Adding the First Form

Now let's add content to our first wizard step. This is where the portal becomes invaluable. You can either navigate to the Form Building Block in the same tab (the portal keeps your changes in memory as long as you don't refresh the browser), or better yet, open the portal in a second browser tab so you can reference the Form documentation while working on your wizard.

Open the Form page in the portal. You'll see it demonstrates the UI.FieldGroup#ApprovalData annotation. But we want to use a different field group for our first step. To see what's available, click "Show Code" next to the annotations example and look at the annotations.cds file in the code editor. You'll find several field groups, including TravelData, which is perfect for our first step.

Back in your wizard code, update the first WizardStep to include the form:

<WizardStep
	id="travelDataStep"
	title="Travel Information"
	validated="true"
>
	<MessageStrip
		text="Please provide the basic information about your travel request."
		type="Information"
		class="sapUiSmallMarginBottom"
	/>
	<macros:Form
		id="travelDataForm"
		metaPath="@UI.FieldGroup#TravelData"
	/>
</WizardStep>

Run the sample and navigate to the first step. You'll see the form with the travel data fields.

Preview of first wizard step

Notice that the TravelID field appears as the first field. However, since travel IDs are calculated in the backend, it doesn't make sense to show this field here.

Let's remove it from the field group. Go back to the annotations.cds code editor and locate the TravelData field group. Remove the TravelID field:

FieldGroup #TravelData : {
	{ Value : BeginDate },
	{ Value : EndDate },
	{ Value : AgencyID },
	{ Value : CustomerID }
}

Click the "Run" button to refresh the preview with your changes - the TravelID field disappears! This demonstrates the power of annotation-driven UIs: simple metadata changes directly affect the user interface without touching the view code.

Preview without travel ID

Step 3: Adding the Budget & Approval Form

Now let's add the second form. Update the second WizardStep:

<WizardStep
	id="approvalDataStep"
	title="Budget and Approval"
	validated="true"
>
	<MessageStrip
		text="Provide budget information for approval."
		type="Information"
		class="sapUiSmallMarginBottom"
	/>
	<macros:Form
		id="approvalDataForm"
		metaPath="@UI.FieldGroup#ApprovalData"
	/>
</WizardStep>

This step uses the ApprovalData field group, which contains financial information like booking fee and total price. The same building block, configured differently through the metaPath property, delivers completely different content.

Preview second wizard step

Step 4: Adding the Bookings Table

The third step needs a table for managing flight bookings. Navigate to the Table Building Blocks in the portal. Study how the table building block works, paying special attention to the metaPath property.

For our wizard, we want to display bookings that are associated with the travel request. Since our view is bound to a Travel context, we need to set the metaPath to the bookings navigation. Update the third WizardStep:

<WizardStep
	id="bookingsStep"
	title="Bookings"
	validated="true"
>
	<VBox>
		<MessageStrip
			text="Add flight bookings for your travel. You can add multiple bookings."
			type="Information"
			class="sapUiSmallMarginBottom"
		/>

		<macros:Table
			id="bookingsTable"
			metaPath="/Travel/to_Booking/@UI.LineItem"
			personalization="Sort,Column"
			header="Flight Bookings"
			creationMode="NewPage"
		/>
	</VBox>
</WizardStep>

Run the sample and navigate to the Bookings step. Click the "Create" button in the table toolbar. You can now create bookings! The table building block automatically provides creation, editing, and deletion capabilities based on the entity's capabilities defined in the service metadata. This is enterprise-grade functionality delivered through a single building block with minimal configuration.

Preview third wizard step

Step 5: Submitting the Travel Request

The final step allows users to review and submit their travel request. Update the fourth WizardStep:

<WizardStep
	id="reviewStep"
	title="Submit Travel Request"
	validated="true"
>
	<VBox class="sapUiContentPadding">
		<Text
			text="You have successfully completed all steps. Your travel request is ready to be submitted."
			class="sapUiMediumMarginBottom"
		/>

		<HBox justifyContent="End" class="sapUiMediumMarginTop">
			<Button
				text="Submit"
				type="Emphasized"
				press="onSubmitTravelRequest"
				icon="sap-icon://paper-plane"
			/>
		</HBox>
	</VBox>
</WizardStep>

Notice that we're not saving the draft directly using the EditFlow controller extension. Instead, when users click "Submit", the onSubmitTravelRequest method in our controller uses the routing API to navigate to the travel request's Object Page:

public async onSubmitTravelRequest(): Promise<void> {
	// Navigate to the Object Page
	const routing = this.getExtensionAPI().getRouting();
	routing.navigate(this.getView().getBindingContext() as Context);
}

With this approach, users can review their complete travel request in the standard Object Page layout, make any final changes, and then save it using the familiar Object Page header actions. This demonstrates an important principle: you can mix custom pages with standard floorplans in the same application, using each where it fits best.

The Power of Building Blocks in Custom Pages

What we've built demonstrates the core value proposition of SAP Fiori elements building blocks in custom pages:

Rapid Development - We created a sophisticated multi-step wizard with forms, tables, and draft handling in minutes, not days
Enterprise Features - Each building block brings personalization, validation, error handling, and accessibility automatically
Annotation-Driven - Business logic changes (like removing the TravelID field) require only metadata updates, not code changes
Consistency - The forms and table in our wizard look and behave exactly like those in standard floorplans, ensuring UI consistency
Flexibility - We combined building blocks with standard UI5 controls (Wizard, MessageStrip, Button) to create a layout not available in standard floorplans

Key Takeaways

When building custom pages with SAP Fiori elements:

Choose Wisely - Use standard floorplans whenever possible. Resort to custom pages only when your layout requirements genuinely don't fit standard patterns
Maximize Building Block Usage - The more you use SAP Fiori elements building blocks in your custom pages, the more enterprise features you get for free
Leverage the Portal - Use the SAP Fiori development portal to understand building block capabilities, experiment with configurations, and see immediate results
Mix and Match - Combine custom pages with standard floorplans in the same application, using each where appropriate
Stay Annotation-Driven - Even in custom pages, let annotations drive as much behavior as possible to minimize code and maximize maintainability

What's Next

In our final post, "Bringing the SAP Fiori development portal and its use to the next level (6 of 6)," we'll explore options to advance portal features and how to best include all project team members for maximizing productivity.

To get the full overview about the SAP Fiori development portal, check out the following blog posts of the mini-series:

Bringing the SAP Fiori Development Portal and Its Use to the Next Level (6 of 6)

2025-12-05T21:46:54.974000+01:00

As we conclude our mini-series on the SAP Fiori development portal, where we provided you with everything needed to make the best possible choices for your project, it is now up to you to pick your set of building blocks and decide where to use what for your targeted SAP Fiori app. Let's consolidate key learnings that will help you maximize the portal's potential in your development workflow and look at the way forward.

Transform how you approach SAP Fiori app development

The SAP Fiori development portal represents more than just documentation - it's a comprehensive platform that transforms how you approach SAP Fiori app development. Whether you're a seasoned developer, a business analyst defining requirements, or a designer crafting user experiences, the portal provides real-time exploration options for building apps based on SAP Fiori elements for OData V4 to make informed decisions and build enterprise-grade applications efficiently.

Now it's time to consolidate what we've learned into actionable guidance that will help you maximize the portal's potential in your development workflow.

Tips and Tricks for Maximum Productivity

It is all about balancing standardization with customization. The portal structure and feature help you navigate the SAP Fiori elements for OData V4 options to maximize your success.

Portal Structure

The portal structure supports you in balancing standardization with customization.

Map business requirements to building blocks first - use the portal to identify which components can address your function needs out-of-the-box
Leverage Global Patterns early in your project planning - these non-visual building blocks like draft handling and navigation patterns are often overlooked but critical for enterprise applications
Evaluate standard floorplans against your use cases before building custom solutions - List Report and Object Page patterns handle the majority of business scenarios. Together with the extension points provided by SAP Fiori elements, they can often meet your requirements with minimal effort
Use Custom Pages for more creative app layouts - if the target picture of your application is too far from the standard floorplans, opt for custom page creation using building blocks and global patterns to get the benefits of the metadata-driven UIs, or leverage freestyle SAPUI5 to achieve your goal.

Portal Features

Use "Show Code" consistently - every page offers this feature to reveal the underlying annotations and implementation details
Experiment with live code editing - modify annotations in real-time to understand how changes affect the UI behavior. Switch off live mode for more complex code changes
Explore both display and edit modes - many building blocks behave differently in these modes, and the portal shows both scenarios
Follow "Documentation" links for detailed product documentation - the portal provides focused overviews while official docs offer comprehensive details

The Portal as Your Companion

The SAP Fiori development portal isn't just a reference - it's an active participant in your development process, already starting when designing the target picture. When mapping the business user needs to how this translates into application UI, you want to review the options in the SAP Fiori development portal since following standard patterns or use standard building blocks will reduce implementation and maintenance efforts drastically. By including the portal in your everyday development process, you'll find that it becomes an indispensable tool for delivering high-quality SAP Fiori applications efficiently.

As the portal continues to evolve, these fundamental approaches will serve you well. The combination of hands-on experimentation, systematic evaluation, and informed decision-making creates a development workflow that scales with your team's growth and adapts to changing business requirements.

While using it in your day-to-day work, help us understand what helps you the most, where things go in the right direction but lack the last mile, and inspire us for things we haven't even thought about yet.

Looking Forward – SAP Fiori elements is compatible with AI tooling

The SAP Fiori development portal represents our commitment to making SAP Fiori elements development more accessible, efficient, and collaborative. That also includes using its content and the learning when providing AI-based development support by SAP Fiori tools. As we continue to enhance the portal, remember that it's designed to grow with your expertise.

We can think in the following directions right now:

Enhance the level of detail for developers, e.g. . This also make makes the portal useful as a grounding document for AI tools and LLMs that assist developers with creating SAP Fiori elements apps
Include the designer persona much more - bridging to the SAP Design System for the basics and providing guidance for the use of available features of SAP Fiori elements based on the context
Connect the explorer world of the portal with the implementation world of SAP Fiori tools

Whether you're building your first SAP Fiori application or extending an existing enterprise solution, the portal provides the foundation for making informed decisions that balance rapid development with enterprise-grade quality. The building blocks, patterns, and guidance we've explored throughout this series are your tools for creating applications that users love and businesses depend on.

Thank you for joining us on this journey through the SAP Fiori development portal. We're excited to see the innovative applications you'll build using these tools and techniques. And maybe you are already one of the next customers presenting how the portal helped you in crafting your SAP Fiori app in the SAP Fiori development roundtable. Your feedback and experiences will continue to shape the portal's evolution, making it an even more powerful resource for the entire SAP Fiori development community.

Complete Blog Series Overview

To get the full overview of the SAP Fiori development portal, check out the following blog posts of the mini-series:

Introducing the SAP Fiori Development Portal: Your Gateway to Rapid SAP Fiori App Creation (1 of 6)
Get familiar with SAP Fiori development portal and the power of the building blocks (2 of 6)
Explore the potential of SAP Fiori development portal using complex building blocks (3 of 6)
Use SAP Fiori development portal to understand extension options for standard floorplans (4 of 6)
Prepare building custom pages by using SAP Fiori development portal (5 of 6)
Bringing the SAP Fiori development portal and its use to the next level (6 of 6)

Building a Real RAP Application Step by Step — Vlog Series Introduction

2025-12-15T21:13:47.721000+01:00

Introduction

This vlog series aims to demonstrate how to build a real-life ABAP RAP application, following a practical, incremental, and production-oriented approach.

Disclaimer:
This series focuses on showcasing how a RAP application can be built incrementally from real functional requirements. The app is intentionally kept practical and educational, rather than exhaustive or fully hardened for production. Some edge cases or potential enhancements are intentionally not covered.
The purpose of the vlog is to share knowledge, demonstrate real development workflows, and contribute to the SAP community, not to deliver a fully polished commercial-grade application.
To allow anyone to follow the vlog series, I will be using an SAP BTP Pay-As-You-Go platform with ABAP free-tier. This environment carries several limitations compared to a customer system (i.e. I do not have I_Product available), but it is perfectly sufficient for demonstrating the concepts and end-to-end implementation.

Instead of showing a pre-built demo or isolated RAP examples, the series walks through the development process from scratch, implementing the application one requirement at a time, exactly as it would be done in an actual ABAP Cloud project.

Each episode focuses on a small, well-defined set of user stories, keeping the learning process smooth and allowing you to see how the application grows after every step. The structure ensures the app is testable from the very beginning, and every enhancement is immediately visible in the UI preview.

If you want to understand RAP not just in theory but in practice, including determinations, validations, feature control, actions, side effects, completeness checks, semantic keys, and UI configuration, this series is for you.

What are we going to build?

We’ll be developing an internal equipment request application for a consulting firm.

Employees can request items kept in internal stock (laptops, monitors, headsets, etc.).

Each request follows a simple lifecycle:

Not Prepared / In Preparation / Delivered / (later also Cancelled)

Each request includes header data (requester, deadline, priority, status) and one or more items referencing products from a customizing table of available materials.

The scenario is intentionally simple but rich enough to cover the most important RAP concepts: CDS data modeling, RAP behavior definitions in managed scenarios, Semantic keys, Determinations & validations, UI annotations, Feature control, Prechecks, Popup actions, Value helps, Inline editing, Integration with customizing tables, ABAP Cloud–compliant development practices.

How the Vlog is structured

The application is built based on a list of functional requirements expressed as user stories. These stories are implemented in the same order they would typically be addressed in a real project. The format of each episode is:

Short and focused (usually covering 1-3 user stories)
Incremental (the app evolves visibly every episode)
Practical (every change is immediately testable)
Aligned with ABAP Cloud guidelines
Designed for long-term learning and reference

Whether you're starting with RAP or expanding your expertise, this series aims to provide a clear, realistic, and reusable learning path.

Episode Roadmap

Each episode implements a specific subset of user stories. Episodes are planned to be released on a weekly basis (approx.). Episode 1 will be released shortly, before end of year!

01	Project introduction + Data model basics (Video \| Repo)	US-01
02	Service exposure + First UI (read-only) preview (Video \| Repo)	US-01
03	Basic behavior + Search fields (Part 1): Free text + Requester (Video \| Repo)	US-02 (part 1)
04	Search fields (Part 2): Status & Priority (Video \| Repo)	US-02 (part 2)
05	Semantic key & Sequential numbering (Video \| Repo)	US-03
06	Mandatory fields + Deadline validation (Video \| Repo)	US-04 + US-05
07	Automatic Priority determination + Status icons & visual enhancements (Video \| Repo)	US-06 + US-07
08	Status behavior rules (Video \| Repo)	US-08 + US-09 + US-10
09	Cancel feature (Part 1) (Video \| Repo)	US-11 + US-12
10	Cancel feature (Part 2)	US-13 + US-13b + US-14
11	Item popup creation & inline editing	US-18 + US-19
12	Product customizing + availability	US-15 + US-16
13	Item consistency: prevent duplicates	US-17 + US-20
14	Additional rules	US-21 + US-22

If this introduction was helpful, a like or follow would be appreciated as it helps others in the community find the series.

Full requirement backlog (User Stories)

Below is the collection of user stories implemented throughout the series, listed in almost the exact order used for development:

US-01: Basic request object: As an employee, I want to create internal equipment requests so that I can receive the products I need.

US-02: Search and Filter capabilities: As a user, I want to search requests using structured filters so that I can quickly locate relevant orders. I need to be able to search through the following criteria:

free search field,
by Requester (with search help),
by Priority (drop-down )
by Status (drop-down with multiple selections).

US-03: Sequential External ID and semantic key: As the system, I want to assign each request a sequential external number so that users can reference meaningful IDs.

US-04: Mandatory fields: As a user, I want the system to require Requester Name and Deadline Date so that requests are always complete.

US-05: Deadline validation: As the system, I want to validate that the deadline date is at least one day in the future so that operations can prepare on time.

US-06: Automatic priority determination: As the system, I want priority to be set based on deadline so that urgent requests receive proper attention (High: < 3 days, Medium: <7 days, otherwise, Low).

US-07: Status icons: As a user, I want statuses displayed with colored icons so that I can understand them at a glance.

US-08: Cancel status restrictions: As a user, I want to search for cancelled requests but not manually set status as “Cancelled” so that lifecycle rules are respected.

US-09: Default status: As the system, I want new requests to default to “Not Prepared” so that the lifecycle begins correctly.

US-10: Status editability rules: As a user, I want status to be editable only after creation so that inconsistencies are avoided.

US-11: Cancel action: As a user, I want to cancel one or more requests from the list so that I can invalidate unnecessary requests.

US-12: Cancellation popup: As a user, I want to cancel and justify cancellations through a popup so that the system enforces to have reasons registered.

US-13: Cancel reason rules: As a user, I want “Cancellation Reason” to be editable only when status is “Cancelled” so that it appears available only when relevant.

US-13b: changing dynamic field hiding approach from CDS into virtual element.

US-14: No editing after cancellation: As the system, I want cancelled requests to become read-only so that historical data is kept intact.

US-15: Product catalog restriction: As a user, I want to select products only from internal stock so that I request only available items. Internal stock is customized through a customizing table.

US-16: Product value help: As a user, I want a value help showing only available products so that selection is efficient.

US-17: Unique product per request: As a system, I want to prevent duplicate products within a request so that items remain consistent.

US-18: Item creation via popup: As a user, I want to create items in a popup and edit them inline so that maintenance is fast and intuitive.

US-19: Make popup fields mandatory: As a system, I want to ensure that the data entered through the Product popup is complete.

US-20: Make item fields mandatory: As a system, I want to ensure that the data entered through the Product object page is complete.

US-21: Show product description at item level: As a system, I want to show the item description instead of the Product ID at item level.

US-22: No editing after completion: As the system, I want completed requests to become read-only so that historical data is kept intact.

Hands-On Guide: SAP Build + Joule Skill for Purchase Order Listing, Approval, or Modification

2025-12-22T08:09:03.721000+01:00

Introduction

In this tutorial, we will build an AI powered Purchase Order listing, modification or approval app using SAP Build and Joule. This step by step guide covers everything from OData integration to creating a working Joule Skill.

Table of Contents

In today’s SAP ecosystem, intelligent automation is an expectation, not a future goal. SAP Build allows developers to quickly create business applications without extensive coding and SAP Joule brings AI-driven intelligence to these experiences.

In this hands-on guide, I’ll walk you through the process of building a Joule skill that connects to an OData service, allowing users to list, approve, and update purchase orders directly through SAP Build. ( This guide uses ZTABLE to store purchase order data because the standard SAP tables in the test system I work on don't have enough or the right kind of data. However, you can use the standard tables instead of ZTABLE. )

This project shows how AI capabilities can seamlessly integrate into SAP’s low-code environment, enabling automation and human decision-making in one interface. Whether you want to enhance your workflow with intelligent actions or explore real-world Joule integration scenarios, this guide will provide a practical starting point.

1. Create an Environment

We need to create an environment for testing joule skill.

Open the SAP Build Lobby, choose Control Tower->Environments and press the Create button.

Name your environment and add Description.

2. Exposing the Destination

Url of the destination on BTP is the url of our SAP system and the destination must have these properties:

sap.applicationdevelopment.actions.enabled -> true

sap.processautomation.enabled -> true

sap.build.usage -> odata_gen

Also the destination’s user will be used for set an external break-point for debugging the ABAP code.

Open the SAP Build Lobby, choose Control Tower->Destinations and press the Add button.

Select the Destination and choose next.

Choose the environment in which you want to use the target. For this tutorial you can choose the Test Environment that you create.

3. Create a database table to store purchase orders

@EndUserText.label : 'Purchase Order Change With Sap Build'
@AbapCatalog.enhancementCategory : #NOT_CLASSIFIED
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #ALLOWED
define table zbg_build_test {
  key mandt                      : mandt not null;
  key purchaseorder              : ebeln not null;
  key purchaseorderitem          : ebelp not null;
  key reservationitem            : ebelp not null;
  material                       : matnr;
  materialcompisvariablesized    : boolean;
  materialcomponentisphantomitem : boolean;
  reservation                    : char10;
  @Semantics.quantity.unitOfMeasure : 'zbg_build_test.entryunit'
  requiredquantity               : menge_d;
  requirementdate                : dats;
  reservationisfinallyissued     : boolean;
  baseunit                       : meins;
  @Semantics.quantity.unitOfMeasure : 'zbg_build_test.entryunit'
  quantityinentryunit            : menge_d;
  entryunit                      : meins;
  plant                          : werks_d;
  latestrequirementdate          : dats;
  billofmaterialitemnumber       : ebelp;
  bomitemcategory                : char1;
  isbulkmaterialcomponent        : boolean;
  debitcreditcode                : shkzg;
  @Semantics.quantity.unitOfMeasure : 'zbg_build_test.entryunit'
  withdrawnquantity              : menge_d;
  approver                       : uname;
  appoved                        : flag;

}

Fill the table:

4. Create a CDS from the ZTABLE for Odata

@AbapCatalog.sqlViewName: 'ZSLV_BUILD_TST_V'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Purchasing Document Informations CDS'
@Metadata.ignorePropagatedAnnotations: true
@ObjectModel.deleteEnabled: true
@ObjectModel.createEnabled: true
@ObjectModel.updateEnabled: true
define view ZSLV_V_BUILD_TEST as select from zbg_build_test as z 
    
{   @EndUserText.label: 'Purchase Order'
    key purchaseorder,
    @EndUserText.label: 'Purchase Order Item'
    key purchaseorderitem,
    @EndUserText.label: 'Reservation Item'
    key reservationitem,
    @EndUserText.label: 'Material'
    material,
    @EndUserText.label: 'Material Size'
    materialcompisvariablesized,
    @EndUserText.label: 'Material Item'
    materialcomponentisphantomitem,
    @EndUserText.label: 'Reservation'
    reservation,
    @EndUserText.label: 'Quantity'
    requiredquantity,
    @EndUserText.label: 'Date'
    requirementdate,
    @EndUserText.label: 'Reservation Issue'
    reservationisfinallyissued,
    @EndUserText.label: 'Unit'
    baseunit,
    @EndUserText.label: 'Entry Unit'
    entryunit,
    @EndUserText.label: 'Quantity In Entry Unit'
    quantityinentryunit,
    @EndUserText.label: 'Plant'
    plant,
    @EndUserText.label: 'Latest Requirement Date'
    latestrequirementdate,
    @EndUserText.label: 'Bill Of Material Number'
    billofmaterialitemnumber,
    @EndUserText.label: 'BOM Item Category'
    bomitemcategory,
    @EndUserText.label: 'Is Bulk Material'
    isbulkmaterialcomponent,
    @EndUserText.label: 'Debit Credit Code'
    debitcreditcode,
    @EndUserText.label: 'With Drawn Quantity'
    withdrawnquantity,
    @EndUserText.label: 'Approver'
    approver,
    @EndUserText.label: 'Approved'
    appoved 
    
}

5. Create OData service with T-code SEGW

(Because of the version of the system I work on, this guide uses SEGW instead of RAP to create an OData service. However, you can easily create your own OData service with RAP.)

Press ‘Create Project’ button, fill the fields and assign the package, request (For this tutorial it will be local object).

Complete the creation.

Extend the project, right click to ‘Data Model’, select the Reference->Source

Fill the CDS name that you created. Choose ‘Next’.

Choose ‘Finish’.

Activate and generate the Service:

Go to the class ZCL_ZSLV_BUILD_DPC_EXT. At the bottom of the method list redefine the update method ZSLV_V_BUILD_TES_UPDATE_ENTITY.

In the method, update the approved field with the below code and activate it.

METHOD zslv_v_build_tes_update_entity.
 
  DATA: lv_ebeln TYPE ebeln,
        lv_ebelp TYPE ebelp,
        lv_item  TYPE ebelp,
        ls_entity TYPE zcl_zslv_build_mpc=>ts_zslv_v_build_testtype,
        lr_entity TYPE REF TO data,
        ls_table TYPE zbg_build_test.
 
  LOOP AT it_key_tab INTO DATA(ls_key).
    CASE ls_key-name.
      WHEN 'purchaseorder'.
        lv_ebeln = ls_key-value.
      WHEN 'purchaseorderitem'.
        lv_ebelp = ls_key-value.
      WHEN 'reservationitem'.
        lv_item = ls_key-value.
    ENDCASE.
  ENDLOOP.
 
  io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
  MOVE-CORRESPONDING ls_entity TO ls_table.
  er_entity = ls_entity.
  UPDATE zbg_build_test FROM ls_table.
  COMMIT WORK.
 
ENDMETHOD.

6. Activate the Odata service via /iwfnd/maint_service T-code

Choose ‘Add Service’

Select the ‘System Alias’, fill the ‘Technical Service Name’ and press ‘Get Services’. Select the service that you create and press ‘Add Selected Services’.

Assign the package and continue.

We have added the service, which should appear as follows. In the ICF Nodes section, there is a button labeled "SAP Gateway Client" that provides a testing environment for the service. Press that button.

Select the HTTP method as ‘GET’. Press ‘EntitySets’ to choose entity set. Choose the one that you created.

Press ‘Execute’ button for testing and response should appear as follows.

7. Crete an Action in SAP Build

Open the SAP Build Lobby, choose Connectors->Actions and press the ‘Create’ button. Choose ‘OData Destinations’ and select the Destination that we created.

Fill the Resource Path as follows and click ‘Next’.

The available methods are listed in this window. Select ‘Next’.

Fill the name and description for your action and create.

The action Purchase_Order_Action is created. Click the action and open it.

Select the methods in the OData Service.

The GET method's input has no required fields, only optional GET parameters.

Output parameters are the fields in the CDS that we created.

Methods can be tested in the action interface. For the GET method we don’t need to fill any input parameters. Click ‘Test’ button.

The data appears on the ‘Test Preview’ section.

The PATCH method requires purchaseorder, purchaseorderitem and reservationitem, all of which are key fields in our ZTABLE and CDS.

There are no standard output in PATCH method.

In the Test section, all required fields and fields that need to be changed must be filled out. In this scenario these fields are purchaseorder, purchaseorderitem, reservationitem and approved fields.

Also the link on the Test section can be used in the SAP Gateway Client to test the PATCH method.

PATCH method return “204: NO CONTENT” and empty Response. This means the update is successful and we will use this emptiness in our joule skill.

After checking and testing, save the methods using the ‘Save’ button and select ‘Release’. After the release process, the action should appear as shown below. Then, press 'Publish'.

You can debug when testing methods via the SAP Gateway Client or the SAP Build Action. Set an external breakpoint for the user in your destination that we created at the beginning.

For the PATCH method, our key fields in the internal table IT_KEY_TAB.

8. Create A Joule Skill to Get Purchase Order

Open the SAP Build Lobby, choose Create->Joule Skill and fill the name and description. Open the created skill.

Select the ’Trigger’ step. On the ‘General’ tab fill the name and description. Allow Joule to generate a response and skill to be started directly by user.

We don't need input, but outputs can vary according to our needs. In this tutorial, the parameters shown below have been added as outputs.

Choose ‘Configure’ and add parameters you want to show to the user. For this example, all parameters are string except the ‘approved’ which is boolean.

Press ‘+’ and choose ‘Call Action’, ‘Browse All Actions’.

Search for ‘ZSLV_V_BUILD_TEST’ or your Service Name. Add the ‘Get entities from ZSLV_V_BUILD_TEST’.

Select the ‘Destination Variable’ as Destination we created.

We can skip the input tab because there are no input for GET method.

We can see the output parameters in this tab.

On the "End" step, we need to assign the input and output parameters for the skills. Since we don't have any inputs, let's assign the outputs added in the "Trigger" step as our action's outputs.

Save the Joule Skill.

And Release.

Now Deploy.

Choose the Environment we created and click ‘Upgrade’.

Match the destinations, and the skill will be ready to use by Joule after deployment.

9. Create A Joule Skill to Approve Purchase Order

On the ‘Trigger’ step, fill the name and description. Deactivate the ‘Allow Joule to generate a response’ feature because in this skill we will create our own messages. The other feature should be active.

Configure the input parameters. Add purchaseorder, purchaseorderitem and reservationitem key fields as string. For approve skill we don’t need any output field.

Choose ‘+’ and ‘Call Action’.

Browse All Actions.

Search update or the service name. Add the Update entity in ZSLV_V_BUILD_TEST.

On the ‘General’ tab, assign the Destination.

On the ‘Inputs’ tab, assign the purchaseorder, purchaseorderitem and reservationitem to the parameters created on the "Trigger" step.

We only need to fill the fields ‘approved’ from the fields to be updated. We need to configure the ‘approved’ field because action inputs can only be string.

Choose ‘approved’ field and ‘Apply a formula’.

Type ‘true’ and click ‘Apply’.

Choose ‘+’ and ‘Check Condition’.

Choose the ‘Condition Editor’.

Add the following conditions and Click ‘Apply’. If PATCH method is executed successfully, the result will be empty.

If the condition is met, the left branch of the condition executes. In the opposite case, the ‘Default’ branch of the condition executes.

Choose the ‘+’ on the left branch and ‘Send Response’.

Open Message Editor.

Fill the parameters as shown below and save.

You can add parameters to the title and message with the ‘<>’ button.

Do the same steps for the right branch of the condition. ‘+’ -> ’Send Response’ -> ‘Open Message Editor’

Fill the parameters as shown below and save.

Save, Release and Deploy just like the previous GET_PURCHASE_ORDER skill.

10. Launch The Joule and Test The Skills

Open the SAP Build Lobby, choose Control Tower->Environments->Joule

Launch the joule, ask for Purchase Orders and get the details.

Ask joule to approve the purchase orders and get the illustrated success message card we create.

How To Consume External APIs in S/4HANA Private Cloud Edition (PCE) 2023 via RAP Framework

2026-01-08T14:08:04.222000+01:00

Scenario:
Suppose we need to expose images related to a "PickTicket" from an external system, making them available in SAP via a custom OData service.

Steps Overview

1. Create a Custom Entity CDS View
2. Create Service Definition
3. Create Service Binding
4. Implement ABAP Class to Consume the External API
5. Test the OData Service

1. Create a Custom Entity (CDS View)

Start by defining a **custom entity** to represent the data structure for the API response:

@EndUserText.label: 'Custom Entity for Image Data'
@ObjectModel: {
query: {
implementedBy: 'ABAP:ZCL_IMAGESET'
}
}
define root custom entity ZCE_IMAGESET
{
key pickticketid : abap.char(20);
key urlshortlivedthumbnail : abap.char(255);
trigger_ : abap.char(20);
source : abap.char(40);
imageid : abap.char(20);
urlthumbnail : abap.char(255);
urlshortlived : abap.char(255);
}

This entity acts as a **virtual view**—data retrieval is handled by an ABAP class (see `implementedBy` above).

2. Create a Service Definition

Expose the custom entity in your service definition:

@EndUserText.label: 'zsd_imageset'
define service Zsd_imageset {
expose ZCE_IMAGESET;
}

3. Create a Service Binding

Next, create a **service binding**—for example, `ZSB_IMAGESET` for OData V4—which generates the OData endpoint for your application. *Use the standard RAP tools in Eclipse or ADT to create this binding from the CDS service definition.*

4. Implement the ABAP Class to Handle API Call

Define the ABAP class (`zcl_imageset`) to fetch and provide data from the external API.
Use the **RAP Query Provider Interface** (`if_rap_query_provider`) for custom data provisioning:

Class Definition

CLASS zcl_imageset DEFINITION
PUBLIC
FINAL
CREATE PUBLIC .

PUBLIC SECTION.

TYPES: BEGIN OF ty_imageset,
trigger TYPE char20,
pickticketid TYPE char20,
source TYPE char40,
imageid TYPE char20,
urlthumbnail TYPE char255,
urlshortlived TYPE char255,
urlshortlivedthumbnail TYPE char255,
END OF ty_imageset.

TYPES: tt_imageset TYPE STANDARD TABLE OF ty_imageset WITH EMPTY KEY.

INTERFACES if_rap_query_provider.
PROTECTED SECTION.
PRIVATE SECTION.
ENDCLASS.

Class Implementation

CLASS ZCL_IMAGESET IMPLEMENTATION.

METHOD if_rap_query_provider~select.

DATA lt_images TYPE tt_imageset.
DATA lv_pickticketid TYPE string.

" Get filter (PickTicketId)

DATA(lo_filter) = io_request->get_filter( )->get_as_sql_string( ).
DATA(lv_offset) = io_request->get_paging( )->get_offset( ).
DATA(lv_page_size) = io_request->get_paging( )->get_page_size( ).
DATA(lv_max_rows) = COND #( WHEN lv_page_size = if_rap_query_paging=>page_size_unlimited THEN 0
ELSE lv_page_size ).
DATA(lt_sort_table) = VALUE string_table( FOR ls_sort_element IN io_request->get_sort_elements( )
( ls_sort_element-element_name && COND #( WHEN ls_sort_element-descending = abap_true THEN ` descending` ELSE ` ascending` ) ) ).
CONCATENATE 'PICKTICKETID ' 'SOURCE'
INTO DATA(lv_default_sort) SEPARATED BY ',' .
DATA(lv_sort_string) = COND #( WHEN lt_sort_table IS INITIAL THEN lv_default_sort
ELSE concat_lines_of( table = lt_sort_table sep = ',' ) ).


IF io_request IS BOUND.
DATA(lt_expressions) = io_request->get_filter( )->get_as_ranges( ).


LOOP AT lt_expressions INTO DATA(ls_expr).
IF ls_expr-name = 'PICKTICKETID'.
LOOP AT ls_expr-range INTO DATA(ls_range).
IF ls_range-option = 'EQ'.
lv_pickticketid = ls_range-low.
EXIT.
ENDIF.
ENDLOOP.
EXIT.
ENDIF.
ENDLOOP.

ENDIF.

" Build target URL for the external request
DATA(lv_url) = |https://<external domain url>/pickTickets/{ lv_pickticketid }/images|.

" Create HTTP client and set headers
DATA lo_http_client TYPE REF TO if_http_client.
cl_http_client=>create_by_url(
EXPORTING url = lv_url
IMPORTING client = lo_http_client
).
lo_http_client->request->set_header_field( name = 'client_id' value = '<your_client_id>' ).
lo_http_client->request->set_header_field( name = 'client_secret' value = '<your_client_secret>' ).
lo_http_client->send( ).
lo_http_client->receive( ).
DATA(lv_response) = lo_http_client->response->get_cdata( ).
lo_http_client->close( ).

" Parse JSON response to ABAP table
DATA(lo_json) = NEW /ui2/cl_json( ).
lo_json->deserialize(
EXPORTING json = lv_response
CHANGING data = lt_images
).

" Return the data
io_response->set_total_number_of_records( lines( lt_images ) ).
io_response->set_data( lt_images ).

ENDMETHOD.

ENDCLASS.

*Replace* `<external domain url>`, `<your_client_id>`, and `<your_client_secret>` *with real values.*

5. Publish and Test Your OData Service

Use `/IWFND/MAINT_SERVICE` or the service binding UI in Eclipse/ADT to publish your OData service.
Test the endpoint with a filter on `PickTicketId`:
Example: /sap/opu/odata/sap/ZSB_IMAGESET/ZCE_IMAGESET?$filter= pickticketid eq '123456'

Key Takeaways

Custom Entities in RAP allow you to virtualize data from external sources as standard OData.
You can leverage the **HTTP client functionalities** in ABAP to fetch data from any REST API.
RAP and ABAP Cloud stack are open for API-driven architectures.
Make sure to treat secrets and API credentials securely—avoid hardcoding in productive code.

Conclusion

You now have a **custom OData service** in SAP S/4HANA PCE, powered by the RAP framework, which brings in dynamic data from an **external API**. You can enhance, secure, and extend this pattern for many integration use cases—be it analytics dashboards, mobile apps, or UI5/Fiori apps!

Let me know your feedback, or reach out for specific questions.

SAP ECC vs S/4HANA Integration Capabilities: A Practical Guide for Integration Architects

2026-01-16T17:05:43.629000+01:00

SAP System Exposure: The Complete Integration Capability Guide for ECC & S/4HANA

IMPORTANT NOTE:

This guide is based on practical hands-on experience across SAP ECC and S/4HANA landscapes. While we've referenced official SAP documentation and community resources throughout, capabilities may vary based on:

NetWeaver version and support package levels
Installed add-ons and components
System configuration and authorizations
SAP release versions.

For architecture decisions and production implementations, always consult:

Official SAP Help documentation (https://help.sap.com)
SAP Notes for specific component details
SAP Business Accelerator Hub (https://api.sap.com) for released APIs
Your SAP Basis team for system-specific configurations

This document focuses on what SAP systems CAN expose and consume. Integration middleware patterns (SAP Integration Suite, PI/PO) are mentioned for context but are not the primary focus.

1. INTRODUCTION

When I'm asked to integrate an external system with SAP, the first question isn't "which tool should I use?" It's "what can SAP actually expose?"

After few years working across SAP ECC and S/4HANA landscapes with Integration Suite, I've learned that understanding what's available in your SAP system is just as critical as knowing how to integrate it. Yet most integration guides skip this foundation and jump straight to implementation.

This is the reference guide, it maps every integration capability available in SAP ECC and S/4HANA On-Premises systems, explains when to use each protocol, and provides the checklists you need to prepare your systems for Integration Suite connectivity.

What You'll Learn:

Complete inventory of integration capabilities in ECC & S/4HANA
RFC/BAPI, IDoc, OData, SOAP, and file interface fundamentals
Protocol comparison matrix with use case recommendations.
System preparation checklists for production readiness
Integration architecture patterns
Decision framework for choosing the right protocol.

Who This Is For:

Integration consultants working with SAP landscapes.
Solution architects designing SAP integrations.
Developers building connections to SAP systems.
Functional consultants exploring integration possibilities.
Anyone planning Integration Suite implementations.

Let's start with what SAP can actually give us.

2. SAP ECC INTEGRATION CAPABILITIES

SAP ECC has been the backbone of enterprise operations for decades., it provides robust, battle-tested integration interfaces that still power thousands of integrations today.

2.1 RFC (Remote Function Call) & BAPIs

RFC is SAP's proprietary protocol for synchronous communication between systems. BAPIs (Business Application Programming Interfaces) are standardized RFCs that provide access to SAP business objects and processes.

Key Characteristics:

Synchronous: Call and wait for response
Transactional: Can commit or rollback
Type-safe: Strongly typed parameters.
Widely available: Broad range of reusable standard BAPIs in ECC

Common BAPIs You'll Use:

BAPI Name	Purpose	Use Case
BAPI_PO_CREATE1	Create Purchase Order	External procurement systems posting POs
BAPI_GOODSMVT_CREATE	Post Goods Movement	Warehouse systems updating inventory
BAPI_MATERIAL_GETDETAIL	Get Material Master	E-commerce platforms fetching product data
BAPI_ACC_DOCUMENT_POST	Post Financial Document	External systems creating FI documents
BAPI_SALESORDER_CREATEFROMDAT2	Create Sales Order	CRM systems posting orders to SAP
BAPI_CUSTOMER_GETDETAIL	Get Customer Master	External apps accessing customer data

NOTE:

BAPIs do NOT auto-commit. The calling program must explicitly control transaction boundaries:

To Save Changes: Call BAPI_TRANSACTION_COMMIT

To Discard Changes: Call BAPI_TRANSACTION_ROLLBACK

This allows multiple BAPIs to be grouped in a single Logical Unit of Work (LUW).

Reference: SAP Note 0131838

Technical Details:

Access: Transaction SE37 (Function Builder)
Discovery: Search pattern "BAPI_*"
Testing: SE37 → Test/Execute
Authentication: RFC destination in SM59

When to Use RFCs/BAPIs:

Use When:

You need real-time, synchronous responses
Transaction integrity is critical (commit/rollback)
Complex business logic required
Creating or updating SAP documents
Reading data with complex selection criteria

Integration Pattern:

EXAMPLE SCENARIO:

Purchase Order Creation from Web Portal

Business Context:
Manufacturing company has external procurement portal where buyers create purchase requests. Once approved, these need to become POs in SAP ECC instantly.

Technical Setup:

Source: Custom web portal (Node.js/React)
Target: SAP ECC 6.0
BAPI: BAPI_PO_CREATE1
Frequency: Real-time (on PR approval)
Volume: 50-100 POs per day

Process Flow:

2.2 IDoc (Intermediate Document)

IDoc (Intermediate Document) is SAP’s standard asynchronous integration mechanism.
It is designed for high-volume, reliable, loosely coupled data exchange between SAP and external systems.

An IDoc is:

Self-contained
Status-driven
Processed independently of user interaction

This makes IDocs ideal for batch integrations, master data replication, and guaranteed delivery scenarios.

Key Characteristics:

Asynchronous: Fire-and-forget or guaranteed delivery
Bulk-friendly: Efficient for large volumes
Loosely coupled: Systems don't need to be online simultaneously
Status-tracked: Built-in monitoring (WE02, WE05)

IDoc Structure:

Common IDoc Types:

IDoc Type	Message Type	Purpose	Direction
ORDERS05	ORDERS	Purchase Orders	Outbound/Inbound
INVOIC02	INVOIC	Invoices	Outbound
MATMAS05	MATMAS	Material Master	Outbound
DESADV01	DESADV	Delivery Notes	Outbound
WMMBXY03	WMMBXY	Goods Movements	Outbound
DEBMAS06	DEBMAS	Customer Master	Outbound
CREMAS03	CREMAS	Vendor Master	Outbound

Technical Details:

Access: Transaction WE30 (IDoc Type Development)
Partner Setup: WE20 (Partner Profiles)
Port Config: WE21 (Port Definition)
Testing: WE19 (Test Tool)
Monitoring: WE02 (IDoc Display), WE05 (IDoc List)
Triggering: Message Control, Change Pointers, IDOC_OUTPUT_* FMs

When to Use IDocs:

Use When:

High-volume data transfer (thousands of records)
Asynchronous processing acceptable
Standard SAP business documents (PO, Invoice, etc.)
Batch processing requirements.
Need for guaranteed delivery with retry.
Master data replication

Integration Patterns:

Outbound (ECC → External):

Inbound (External → ECC):

EXAMPLE SCENARIO:

Nightly Material Master Sync to Data Warehouse

Company needs to send all material master changes from ECC to external data warehouse every night for reporting and analytics.

Technical Setup:

Source: SAP ECC 6.0
Target: External Data Warehouse (Snowflake)
IDoc Type: MATMAS05
Frequency: Nightly batch (2 AM)
Volume: 5,000-10,000 materials per night

End-to-End IDoc Asynchronous Integration Flow

Material master records are created or updated in SAP ECC throughout the day (MM01/MM02).
Change pointers capture only relevant delta changes for the MATMAS message type.
At 2:00 AM, the BD21 batch job executes during off-peak hours.
The system reads accumulated change pointers.
A MATMAS05 IDoc is generated for each changed material.
IDocs are sent via partner profile WAREHOUSE using an HTTP port.
SAP CPI receives the IDoc XML through the IDoc adapter.
CPI parses the hierarchical IDoc structure.
Business data is transformed into a target JSON format.
Records are grouped into batches of 1,000 for optimized processing.
CPI posts each batch to the Snowflake bulk API.
On success, IDocs are updated to status 53 (Posted).
On failure, IDocs move to 51 (Error) and are retried in the next batch cycle.
A consolidated processing report is emailed to the data team at 3:00 AM.

2.3 SOAP Web Services

SAP ECC exposes business functionality as SOAP-based web services.
These services are WSDL-driven, XML-based, and follow a strict request–response contract over HTTP/HTTPS.

SOAP services are widely used in legacy enterprise landscapes, especially where Java or .NET middleware already exists.

Key Characteristics:

Standards-based: WSDL, SOAP 1.1/1.2, WS-* standards
Synchronous: Request-response pattern
Platform-agnostic: Any SOAP client can consume
Structured: XSD-defined schemas

Technical Details:

Access: Transaction SOAMANAGER (Service Administration)
Development: SPROXY (Proxy Development)
Types:
- Provider Services (ECC exposes to external)
- Consumer Services (ECC consumes from external)

When to Use SOAP:

Use When:

External system requires SOAP/WSDL
Enterprise service repository already defined.
Need WS-Security features.
Cross-platform integration with Java/.NET systems

Integration Pattern:

EXAMPLE SCENARIO:

Legacy Java Middleware Posting Financial Documents

Existing Java-based middleware system (10 years old) collects invoice data from multiple subsidiaries and needs to post consolidated financial documents to ECC.

Technical Setup:

Source: Java middleware (Spring Boot)
Target: SAP ECC 6.0
Service: FinancialDocumentCreate (Enterprise Service)
Frequency: Real-time as invoices arrive
Volume: 200-300 documents per day

Process Flow:

Java app collects invoice from subsidiaries.
Validates and enriches data.
Builds SOAP XML per WSDL specification.
Sends SOAP request to CPI endpoint.
CPI routes to ECC SOAMANAGER
Enterprise service validates structure.
Calls backend BAPI for FI posting.
Document posted, accounting entries created.
Returns FI document number in SOAP response.
Java app stores document number for reference.

2.4 File Interfaces

File interfaces are one of the oldest and most reliable integration mechanisms in SAP ECC, designed for scheduled, high-volume, non-real-time data exchange.
Data is exchanged using physical files that are picked up, processed, and archived in batch cycles.

This pattern is still widely used for:

Vendor uploads
Price lists
Mass master data changes
One-time or recurring migrations

File Formats:

Flat files (fixed width, delimited)
CSV/Excel
XML
Custom formats

Technical Approaches:

Output: Report programs, BDC, LSMW
Input: Batch Input (BDC), Direct Input, BAPI calls

When to Use Files:

Use When:

Batch processing windows.
Large data migrations
Legacy system integration
Offline scenarios

Example Scenario: Nightly Vendor Price Upload (CSV)

The procurement team receives daily price updates from multiple vendors.
Each vendor uploads a CSV file containing updated material prices, which must be reflected in SAP ECC before business hours.

Technical Setup

Source: Vendor SFTP servers
Integration Layer: SAP CPI
Target: SAP ECC 6.0
File Type: CSV
Schedule: Nightly (4:00 AM)
Volume: ~50 files, 10,000–15,000 records

Process Flow (Clear & Sequential)

Vendors upload CSV price files to the SFTP server between 1:00–3:00 AM
At 4:00 AM, SAP CPI scheduler triggers the batch job
CPI connects to SFTP and downloads all available files
For each file, CPI:

Identifies the vendor from the file name
Parses the CSV line by line
Validates mandatory fields and price values

For each valid record:

CPI calls BAPI_MATERIAL_SAVEDATA
Updates the vendor price / info record

Processing continues even if individual records fail
CPI writes:

Success entries to the success log
Failed records to the error log with reason

Processed files are archived to /archive
A summary report is generated
Email notification is sent to the procurement team

2.5 OData Services via SAP NetWeaver Gateway

SAP NetWeaver Gateway is a fully supported SAP component that enables ECC to expose RESTful OData services with JSON and XML support.

Key Characteristics

Protocol: HTTP/HTTPS (RESTful)
Data Format: JSON or XML (via $format=json or Accept header)
Query Capabilities: $filter, $select, $expand, $orderby, $top, $skip
CRUD Operations: GET, POST, PUT, PATCH, DELETE Self-Describing: $metadata endpoint

Technical Access

Service Builder: Transaction SEGW (Service Artifact Generation Wizard)
Service Registration: Transaction /IWFND/MAINT_SERVICE
Service Testing: Transaction /IWFND/GW_CLIENT
Error Monitoring: Transaction /IWFND/ERROR_LOG
ICF Nodes: Transaction SICF (activate HTTP services)

OData Query Examples

Basic Read: GET /sap/opu/odata/sap/Z_PRODUCT_SRV/Products

Filtering: GET /sap/opu/odata/sap/Z_PRODUCT_SRV/Products?$filter=Price gt 100

JSON Format: GET /sap/opu/odata/sap/Z_PRODUCT_SRV/Products?$format=json

Metadata Discovery: GET /sap/opu/odata/sap/Z_PRODUCT_SRV/$metadata

When to Use Gateway OData

Use When:

Building Fiori applications on ECC
Modern web/mobile applications need REST APIs
External developers need API access
JSON format preferred over XML

2.6 Event Mechanisms in ECC

SAP ECC provides several mechanisms to trigger integrations based on business events. While not as standardized as S/4HANA's Event Enablement Framework, these are widely used in production environments.

Available Event Mechanisms:

Change Pointers

Track changes to master data and trigger IDoc generation.

Technical Details:

Purpose: Master data change detection (Material, Customer, Vendor)
Transaction BD50: Activate change pointers
Transaction BD51: Activate for message types
Transaction BD52: Assign fields to monitor
Transaction BD21: Create IDocs from change pointers
Processing: Batch-driven (scheduled job RBDMIDOC)

Workflow Events

Trigger when specific business transactions occur.

Technical Details:

Purpose: React to business document lifecycle events
Transaction SWE2: Event Type Linkages
Transaction SWEL: Event Trace
Event Pattern: BusinessObject.EventName Example: BUS2032.CREATED (Sales Order Created)
Subscribers: Workflows, function modules

Output Determination (Message Control)

Application-specific (MM, SD, FI)
Condition-based triggering
Can generate IDocs, emails, print outputs
Transaction: NACE (Output Control)

BAdIs (Business Add-Ins)

Enhancement points in standard SAP code
Can call external systems via RFC
Transaction: SE18 (BAdI Definition), SE19 (BAdI Implementation)

User Exits / Enhancement Points

Custom code injection points
Can trigger HTTP calls, RFCs to external systems
Transaction: CMOD (Enhancements)

3. SAP S/4HANA ON-PREMISE INTEGRATION CAPABILITIES

S/4HANA builds on everything ECC provides and adds modern integration capabilities that change the game.

3.1 EVERYTHING ECC HAS, ENHANCED

RFCs/BAPIs:

All ECC BAPIs available
New S/4HANA-specific BAPIs
Better performance (HANA database)
CDS view consumption via RFCs

IDocs:

All ECC IDoc types
Improved processing speed
Better error handling
Enhanced monitoring

SOAP Services:

All enterprise services
Service adaptation framework
Better performance

3.2 ODATA SERVICES (Enhanced in S/4HANA)

OData is the REST-based protocol that makes SAP data accessible like modern APIs. OData introduces true RESTful APIs, designed for:

Web applications
Mobile apps
External developer consumption
Real-time queries

S/4HANA enhances OData capabilities with native support, pre-built APIs, and the RAP framework for OData V4.

What's Enhanced from ECC:

OData V2 embedded by default
OData V4 support via RAP framework (new capability)
Pre-built released APIs in SAP Business Accelerator Hub
HANA-optimized query performance

Why OData Matters

REST over HTTP
JSON-first
Queryable data access
Self-describing APIs

Key Characteristics:

RESTful: Standard HTTP methods (GET, POST, PUT, DELETE)
JSON/XML: Modern data formats
Query-capable: $filter, $select, $expand, $orderby, $top, $skip
Self-documenting: $metadata endpoint
Stateless: No session management needed

SAP Gateway Architecture:

Standard S/4HANA APIs (Examples):

API Service	Business Purpose	Key Entity Sets
API_PURCHASEORDER_PROCESS_SRV	Purchase Order lifecycle management	A_PurchaseOrder, A_PurchaseOrderItem
API_PRODUCT_SRV	Material / Product master data	A_Product, A_ProductDescription
API_SALES_ORDER_SRV	Sales order processing	A_SalesOrder, A_SalesOrderItem
API_BUSINESS_PARTNER	Unified business partner model	A_BusinessPartner, A_BPContactAddress
API_MATERIAL_STOCK_SRV	Inventory and stock levels	A_MaterialStock

Technical Details:

Service Registration: /IWFND/MAINT_SERVICE
Testing: /IWFND/GW_CLIENT
Development: SEGW (Gateway Service Builder)
Monitoring: /IWFND/ERROR_LOG

OData Query Capabilities

Basic Read

GET /sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV/A_PurchaseOrder

Filtering

GET .../A_PurchaseOrder

?$filter=DocumentDate ge datetime'2025-01-01'

and PurchaseOrderType eq 'NB'

Selecting Specific Fields

GET .../A_PurchaseOrder

?$select=PurchaseOrder,Supplier,DocumentDate,TotalAmount

Expanding Navigation Properties

GET .../A_PurchaseOrder('4500000001')

?$expand=to_PurchaseOrderItem

Pagination

GET .../A_PurchaseOrder?$top=100&$skip=0

Response:

"__next": "...&$skiptoken=100"

Metadata Discovery

GET /sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV/$metadata

Returns:

Entity sets
Properties
Associations

When to Use OData

Use When

Modern web or mobile applications
Real-time queries required
REST/JSON integration
Flexible query support needed

EXAMPLE SCENARIO: Mobile Sales App Querying Products

Business Context:

Sales representatives use mobile app to check product availability, pricing, and specifications while visiting customers. Need instant access to product catalog with real-time stock levels.

Technical Setup:

Source: React Native mobile app
Target: S/4HANA On-Premise
API: API_PRODUCT_SRV, API_MATERIAL_STOCK_SRV
Frequency: Real-time as sales rep searches
Volume: 500-1,000 queries per day

Process Flow:

Sales rep searches "Bearing" in mobile app
App sends HTTP GET to CPI endpoint
CPI forwards to S/4HANA Gateway
Gateway routes to Data Provider Class
DPC queries HANA database (ultra-fast)
Returns matching products as JSON
For each product, fetch stock level
Combine product + stock data
Response returns to mobile app
Rep sees list: 15 products with prices and stock

3.3 CDS Views as Integration Endpoints

Core Data Services (CDS) views are HANA-optimized semantic data models defined in S/4HANA. They represent business entities and logic at the database level and can be exposed directly for integration.

CDS views can be:

Exposed as OData services via SAP Gateway
Consumed internally or externally via RFC-enabled function modules

Key Benefits

High performance: Logic is pushed down to the HANA database
Pre-aggregated data: Reduces processing in the application layer
Embedded business logic: Calculations, annotations, and semantics included
Rich relationships: Associations allow navigation across related entities

Process Flow

CDS View → Gateway Service → OData → Integration Suite

3.4 SAP Business Events & Real-Time Integration

S/4HANA introduces native event-driven integration capabilities, allowing systems to react immediately to business changes instead of relying on batch jobs or polling.

Key enhancements include:

Standardized business event triggers
Improved change detection
Workflow-driven event publishing
Native integration with SAP Event Mesh

Note: Event Mesh provides additional capabilities like publish/subscribe, guaranteed delivery queues, and multiple independent subscribers.

Event-Driven Integration Pattern

S/4HANA Business Event → Event Mesh Topic → Multiple Subscribers (CPI iFlows) → External Systems

Typical Use Cases

Purchase order approved → Notify procurement portal
Stock level falls below threshold → Trigger replenishment
Sales order created → Update CRM system
Invoice posted → Notify payment or reporting systems

EXAMPLE SCENARIO:

Real-Time Stock Alerts to E-Commerce

E-commerce website needs instant notifications when product stock falls below threshold to display "Low Stock" warnings and trigger replenishment.

Technical Setup:

Source: S/4HANA On-Premises
Targets: E-commerce website, Replenishment system, Analytics dashboard
Event: Material.StockChanged
Frequency: Real-time (as goods movements occur)
Volume: 2,000-3,000 events per day

Step-by-Step Flow

Goods Issue Posted
- A goods issue is posted in S/4HANA using transaction MIGO.
Stock Update in HANA
- The stock quantity is immediately updated in the HANA database.
Business Event Triggered
- The system triggers the business event Material.StockChanged.
Event Published
- The event is published to SAP Event Mesh.
- Topic: inventory/changes
Parallel Event Consumption
- Multiple systems subscribe to the same event and process it independently.

Subscriber A – E-Commerce System

Receives the event through a CPI iFlow
Updates the product page inventory
Displays a “Low Stock” indicator (e.g., “Only 75 left”)

Subscriber B – Replenishment System

Evaluates stock against reorder threshold (100 units)
If below threshold:
- Creates a Purchase Requisition
- Notifies the purchasing team

Subscriber C – Analytics Dashboard

Updates real-time inventory charts
Stores event data in the data warehouse for reporting

Independent Processing
- Each subscriber processes the event independently and in parallel.
Acknowledgement
- Each system sends an acknowledgement back to Event Mesh.

Events are published once and delivered to multiple consumers in parallel, without tight coupling.

4. INTEGRATION SCENARIOS & COMPARISON

Now that we understand what each system offers, let's look at how to choose the right protocol and see complete integration scenarios.

4.2 Decision Tree

4.3 Cross-Protocol Integration Scenarios

Scenario 1: Manufacturing Company - Complete Landscape

Integration Breakdown

Web Portal → SAP ECC (Purchase Orders)

Protocol: REST → RFC/BAPI
Purpose: Real-time purchase order creation
Volume: ~100 purchase orders per day

SAP ECC → Data Warehouse (Material Master)

Protocol: IDoc → JSON
Purpose: Nightly master data synchronization
Volume: ~10,000 materials per night

Mobile App → SAP S/4HANA (Product Catalog)

Protocol: REST → OData
Purpose: Real-time product search and availability
Volume: ~1,000 queries per day

SAP S/4HANA → E-Commerce Platform (Stock Alerts)

Protocol: Business Events via Event Mesh
Purpose: Real-time inventory notifications
Volume: ~3,000 events per day

5. System Preparation Checklists

Before starting integration development, systems must be technically and operationally ready. The following checklists reflect production-grade prerequisites.

5.1 SAP ECC Preparation

Technical Configuration

RFC Destinations (SM59)
☐   HTTP/RFC destination created for Integration Suite
☐ Connection test successful
☐   Timeout parameters adjusted
☐   Trusted RFC configured (if applicable)

IDoc Configuration (If IDocs Are Used)
☐   Partner profiles maintained (WE20)
☐ Inbound parameters
☐   Outbound parameters
☐   Message types assigned
☐   Ports configured (WE21)
☐   HTTP port to Integration Suite
☐ Port connectivity tested
☐   Message control configured (for outbound IDocs)
☐ Application (ME, VL, VF, etc.)
☐   Output type
☐   Medium = 6 (IDoc)
☐   Test IDocs generated successfully (WE19)

Web Services (SOAMANAGER)
☐ Service definitions created
☐ Endpoints configured and reachable
☐ WSDL accessible externally
☐ Authentication configured

User & Authorization
☐   Technical user created (SU01)
☐   Required authorizations assigned:
☐   S_RFC
☐   S_IDOCDEFT
☐   Relevant business authorizations
☐   Password policy compliant
☐   Dialog access restricted for security

Network & Security

Firewall Rules
☐ Outbound: ECC → Integration Suite (HTTPS 443)
☐ Inbound: Integration Suite → ECC (HTTP/HTTPS)
☐ IP whitelisting completed

SSL / TLS Configuration
  ☐   Certificates imported (STRUST)
  ☐   Certificate chain verified
  ☐   Expiry monitoring in place

Cloud Connector (If On-Premise Connectivity Is Required)
  ☐   Installed and connected to BTP subaccount
  ☐   Access control rules defined
  ☐   Resource mapping configured
  ☐   Audit logging enabled

5.2 SAP S/4HANA Preparation

All ECC prerequisites apply, plus the following.

OData / Gateway Configuration

  ☐   Services activated (/IWFND/MAINT_SERVICE)
☐   System alias assigned
☐ Service registration complete
☐   ICF nodes active (SICF)
☐   Service testing completed (/IWFND/GW_CLIENT)
☐   $metadata accessible
☐   Entity sets queryable
☐   CRUD operations verified
☐   Authorization configured (S_SERVICE, PFCG roles)

Custom OData Services (If Applicable)
☐   Data model designed (SEGW)
☐   DPC_EXT implemented
☐ Runtime objects generated
☐   Service registered and tested

Event Configuration (If Event-Driven Integration Is Used)
☐   Business events identified
☐ Event Mesh connectivity established
☐   Topic and queue structure defined
☐   Payload format designed
☐   End-to-end testing completed.

CDS View Exposure
☐   CDS views created and optimized
☐   Exposed via OData
☐   Authorization validated
☐   Performance tested.

5.3 SAP BTP Integration Suite Preparation

Platform Enablement

☐   Integration Suite provisioned
☐   Cloud Integration enabled
☐   API Management enabled (if required)
☐   Event Mesh enabled (if required)
☐   Integration Advisor enabled (if B2B scenarios)

Connectivity

☐   Destinations configured
☐ HTTP destinations to ECC/S/4HANA
☐   Authentication defined
☐ Proxy type set (Internet / On-Premise)
☐   Cloud Connector configured
☐   Location ID assigned
☐ Virtual host mapping
☐   Access control lists maintained

Security

☐   Credentials stored securely
☐   OAuth tokens configured (if applicable)
☐   Certificates uploaded and validated
☐   Secure parameters used for sensitive values
☐   Known hosts configured for SFTP

Design & Operations

☐   Integration packages created
☐   Naming conventions defined
☐   Versioning and transport strategy agreed
☐   Message monitoring enabled
☐   Alerts configured
☐   Log retention policy set
☐   Operational dashboards created

6. INTEGRATION ARCHITECTURE OVERVIEW

Understanding how all pieces fit together:

Component Explanations

Cloud Connector

Provides a secure tunnel between SAP BTP and on-premise SAP systems
Eliminates the need for VPN connectivity
Enables resource-level access control
Supports audit logging for compliance and security monitoring

CPI Adapters

Enable protocol translation (RFC ↔ REST, IDoc ↔ JSON, SOAP ↔ HTTP)
Handle authentication and credential management
Support connection pooling for performance optimization
Provide built-in retry mechanisms for transient failures

API Management

Enforces rate limiting and quotas
Supports API key and OAuth-based validation
Offers analytics and usage monitoring
Includes a developer portal for API discovery and onboarding

Event Mesh

Supports publish / subscribe messaging
Provides queue-based guaranteed delivery
Enables topic-based routing
Allows multiple subscribers to process events independently

7. Key Takeaways

Understanding System Capabilities

SAP ECC Strengths

Mature and stable RFC/BAPI framework
Robust IDoc infrastructure for asynchronous processing
Battle-tested reliability in enterprise landscapes
Rich Enterprise Services Repository

SAP S/4HANA Advantages

Native OData / REST APIs
Built-in event-driven integration
High performance powered by SAP HANA
CDS views for optimized data access
Includes everything ECC offers — enhanced and modernized

SAP BTP Integration Suite as the Bridge

Centralized protocol translation
Secure cloud connectivity
End-to-end orchestration layer
Enterprise-grade monitoring and governance

Protocol Selection Guidance

RFC / BAPI: Synchronous transactions with immediate validation
IDoc: Bulk data processing with guaranteed delivery
OData: REST APIs for modern applications
SOAP: Legacy enterprise web services
File Interfaces: Batch processing and data migrations
Events: Real-time, decoupled integration (S/4HANA)

Preparation Is Critical

System configuration must be completed before development
Security and authorizations must be production-ready
Network connectivity should be fully tested
Monitoring and alerting should be established early

8. What’s Next

This blog explained what is possible.
The next blogs series will be focused on how to implement.

Acknowledgments & Corrections

This document was refined based on valuable feedback from the SAP Community, particularly regarding:

NetWeaver Gateway as a standard, supported component in ECC
JSON support in OData V2 for both ECC and S/4HANA
BAPI transaction control requirements
Event architecture distinctions

I welcome continued feedback to ensure this remains an accurate, community-validated resource.

Step-By-Step Guide: Creating Your First RAP Application using OData V4 and Transporting to Quality

2026-01-20T07:14:41.239000+01:00

Introduction

In this blog, we will walk through the detailed steps to create your first RAP (RESTful ABAP Programming Model) application and correctly move it to the Quality system. This blog also highlights mandatory steps before transport and common mistakes that beginners usually make, based on real project experience.

Target Audience & Prerequisites

ABAP developers who are new to RAP
Basic knowledge of CDS Views and ABAP Development Tools (ADT)
System used: SAP S/4HANA (On-Premise / Private Cloud)
Exposure type: OData V4
Scenario covered: Basic Read-only RAP application
Mandatory Objects in a RAP Application:
- Package
- Interface CDS View
- Projection CDS View (Optional we can directly create service definition on Interface view also)
- Service Definition
- Service Binding

Create Package:
Create a package in ADT:
- Right-click on project → New → ABAP Package
- Enter package name and description
- Do not create it as a local package ($TMP)
- Capture it in a transport request
- Only transportable packages can be moved to Quality and Production systems.
Interface CDS View: A CDS View is a virtual data model in ABAP that defines how data from database tables is accessed and represented. In RAP, it often serves as the “Interface View.”
1. Why It Matters:
  - Reusable logic: Centralizes data access for transactional and analytical purposes.
  - Foundation: Serves as the starting point for business object modeling in RAP.
2. Steps:
  - Right-click your database table (e.g., ZTRAVEL_RAJ_M), select New Data Definition.
  - Provide a name, description, and use the Define View Entity template.
  - Assign to transport, activate, and check for errors.
Service Definition: The Service Definition specifies which data elements (entities) of a RAP business object are exposed as OData services.
1. Why It Matters:
  - Exposure Layer: Decides what consumers (e.g., Fiori apps, external APIs) can interact with.
  - It’s the contract between your backend logic and external consumers.
2. Steps:
  - Right-click on the projection view, select New Service Definition.
  - Name, description, assign transport, and activate.
  - This exposes your RAP objects as a service.
Service Binding: Service Binding links a service definition to an actual communication protocol (such as OData V4) and activation state.
1. Why It Matters:
  - Enables Consumption: Without binding, your service cannot be called or used.
  - Protocol Choice: Determines how front ends communicate with your service (e.g., OData V4 for Fiori/UI5 apps).
2. Steps:
  - Right-click on the service definition, select New Service Binding.
  - Choose OData V4 protocol (for most Fiori/RAP apps).
  - Assign transport, describe, finish, and activate.
Why You Should NOT Publish from ADT: Publishing directly from ADT is meant only for local testing.
1. Issues with ADT Publishing
  - Service is registered as a local ($TMP) object
  - Cannot be transported to Quality or Production
  - Not supported for productive landscapes
2. Correct Way: Publish via /IWFND/V4_ADMIN
  - Transaction /IWFND/V4_ADMIN is the recommended way to publish RAP services.
3. Steps:
  - Open /IWFND/V4_ADMIN and click Publish Service Groups
  - Enter System Alias = LOCAL, Service Binding name click on get service groups
  - Select service and Publish
  - From the service group list, right click on your service group and click on transport publishing. It will prompt for customizing TR enter the transport and save. After that Click on transport routing assignment and capture in the customizing TR.
  - Service is now published
Preview: Finally, let’s preview the application to verify that the service is working as expected.

Conclusion:

In this blog, we learned how to create a basic RAP application and the correct approach to publish and transport OData V4 services to the Quality system.
Using /IWFND/V4_ADMIN ensures transport safety and helps avoid common deployment issues that beginners often face.

Note:

To customize the user interface of your RAP application, add appropriate UI annotations in the CDS view (interface or projection, depending on your design). Common annotations include @ui.headerInfo, @ui.lineItem, and @ui.selectionField.

After publishing the service, share the service URL (available in the Service Binding) with the Fiori development team so they can create the required Fiori tile.
After transporting to the Quality system, SICF activation is a manual step. Without activating the relevant SICF nodes, the service will not be accessible. Coordinate with your Basis team to complete this step.

Connecting SAP Sales Cloud V2 to a Standalone SAP Analytics Cloud - A Practical Alternative

2026-01-21T05:54:01.435000+01:00

The Customer Challenge

A customer approached me with what seemed like a straightforward request: "We want to analyze our SAP Sales Cloud Version 2 data in SAP Analytics Cloud."

Their situation was common for mid-sized companies adopting SAP's CX portfolio:

SAP Sales Cloud Version 2 was live and running well
SAP Analytics Cloud was licensed separately (not the embedded version)
No SAP BTP subscription yet, it wasn't part of the initial scope
No SAP Integration Suite same reason
No SAP Datasphere, they wanted to avoid another data platform

The goal was simple: import Accounts, Contacts, and Opportunities into SAC for custom dashboards that combined CX data with data from other sources

What SAP Officially Recommends

Before building anything custom, I researched SAP's official guidance. The recommended architecture for Sales Cloud V2 analytics integration involves:

SAP Datasphere as a central data layer
SAP Integration Suite for event-driven data replication
SAP Advanced Event Mesh (optional but recommended) for resilience

SAP published a detailed two-part blog series on this: Event-Driven Data Integration from SAP Sales and Service Cloud V2 to SAP Datasphere

This architecture is elegant and production-grade. It's also significant additional investment for a customer who just wants to run a few reports.

Cost Implications

The official path requires more than you might expect:

Component	Status for this Customer
SAP Datasphere	Not licensed (€€€/month)
SAP Integration Suite	Not licensed (€€/month)
SAP BTP subscription	Not available
Implementation effort	Significant (weeks)

For a customer with ~24,000 accounts who wants three dashboards, this felt like using a sledgehammer to crack a nut.

The Obvious First Attempt: SAC's Built-in Connectors

SAC has connectors for various SAP sources. Surely there's something for Sales Cloud?

Attempt 1: The "SAP Cloud for Customer" Connector

SAC includes a dedicated connector called "SAP Cloud for Customer" that works beautifully with the older C4C (Cloud for Customer) system. It connects to OData services like:

https://<tenant>/sap/c4c/odata/v1/c4codataapi/AccountCollection

The problem: Sales Cloud V2 is not C4C. So the OData connector won’t work:

Attempt 2: The Generic OData Connector

SAC also has a generic "OData Services" connector. Maybe that works?

The problem: Sales Cloud V2 doesn't expose OData endpoints. The APIs on the SAP Business Accelerator Hub are REST, not OData.

GET /sap/c4c/api/v1/account-service/accounts ← REST, not OData
GET /sap/c4c/api/v1/contact-service/contacts ← REST, not OData

Attempt 3: Live Connection

Sales Cloud V2 has embedded SAC capabilities. Could we establish a live connection?

The problem: The embedded analytics are designed for "embedded" use cases. Connecting a standalone SAC tenant to Sales Cloud V2 for custom reporting seems to be... let's say "not a focus area" right now.

I opened a support ticket to clarify the expected behavior and it was put in development after a little back and forth.

The Hidden Challenge: Real-Time vs. Import

At this point, I had to step back and discuss architecture with the customer.

Even if a direct connector existed, there are implications to consider:

Approach	Pros	Cons
Live Connection	Always current data	Query performance depends on source; cannot combine with other data sources easily
Import Connection	Fast queries; can blend with other sources	Data has latency; storage costs

The customer wanted to combine Sales Cloud V2 data with SAP S/4HANA data in the same dashboard. This essentially requires import connections for both sources, plus a data model in SAC that joins them.

Real-time was never really an option as they needed data at rest in SAP Analytics Cloud

The Solution: A Lightweight REST-to-OData Proxy

Since the customer had:

No appetite for SAP Datasphere
No CPI license
A clear, limited scope (three entity types)
Tolerance for daily data refresh (not real-time)

I proposed building a thin proxy server that:

Authenticates with Sales Cloud V2
Fetches data via REST APIs
Transforms responses to OData format
Exposes endpoints that SAC can consume natively

Architecture

This sounds straightforward... until you start building it...

Challenge 1: The 999 vs. 1000 Mismatch

This one deserves its own section because it’s so unexpected.

SAP Sales Cloud V2 REST APIs have a maximum page size of 999 records. You can request $top=999, but not more.

SAP Analytics Cloud OData import has a minimum batch size of 1000 records.

Yes, you read that correctly. The source maxes out at 999. The target starts at 1000. I'll admit I stared at the logs for longer than I'd like to admit before I realized what was happening. The first 999 records imported perfectly. Then nothing. It took me a while to connect that SAC was waiting for a 1000-record batch that would never arrive.

The Solution

The proxy implements on-demand parallel fetching:

async function fetchAllRecords(entityType: string): Promise<any[]> {
  // Get first page to determine total count
  const firstPage = await fetchFromSalesCloud(entityType, {
    $top: 999,
    $skip: 0
  });
  
  if (firstPage.value.length < 999) {
    // All records fit in first page
    return firstPage.value;
  }
  
  // Calculate remaining pages and fetch in parallel
  const totalEstimate = firstPage.totalCount || 10000;
  const remainingPages = Math.ceil((totalEstimate - 999) / 999);
  
  const pagePromises = Array.from({ length: remainingPages }, (_, i) => 
    fetchFromSalesCloud(entityType, {
      $top: 999,
      $skip: 999 * (i + 1)
    })
  );
  
  const results = await Promise.all(pagePromises);
  return [firstPage.value, ...results.map(r => r.value)].flat();
}

The proxy fetches pages in parallel (not sequentially), caches the combined result, and serves it to SAC in appropriately sized batches. The cache has a configurable TTL (e.g., 1 hour) and automatically refreshes on the next request after expiry.

Challenge 2: Nested Objects and Flattening

Sales Cloud V2 returns nicely structured JSON with nested objects:

{
  "value": [{
    "accountId": "A001",
    "accountName": "ACME Corp",
    "primaryContact": {
      "contactId": "C001",
      "firstName": "John",
      "lastName": "Doe"
    },
    "addresses": [
      { "type": "BILL_TO", "city": "Berlin" },
      { "type": "SHIP_TO", "city": "Munich" }
    ]
  }]
}

SAC’s OData importer cannot handle this. The SAP Help documentation states clearly: Embedded Complex types are not supported.

The Solution

The proxy must flatten nested structures into separate entity sets:

/odata/Accounts         → Flat account records
/odata/Contacts         → Flat contact records  
/odata/AccountAddresses → One row per address, linked by accountId

Challenge 3: REST APIs Behave Differently Than OData

Coming from the OData world, I expected certain conventions:

$filter for filtering
$select for field selection
$expand for related entities
Standardized metadata endpoint

Sales Cloud V2 REST APIs have their own conventions:

Different query parameter syntax
No $metadata endpoint
Pagination via custom headers or response properties

The proxy needs to translate between these worlds, implementing just enough OData semantics to satisfy SAC’s importer.

Challenge 4: The $skip 10,000 Limit

Just when you think you’ve handled pagination, there’s another surprise waiting for datasets with more than 10,000 records.

Sales Cloud V2 returns an error if $skip is 10,000 or greater.

// This works
GET /accounts?$top=999&$skip=9000  ✅

// This fails
GET /accounts?$top=999&$skip=10000  ❌ Error!

So even if you’ve cleverly worked around the 999 page size limit, you hit a wall at record 10,001. Simple offset-based pagination ($skip) just stops working.

The Solution

Instead of offset-based pagination, the proxy uses keyset pagination with $skiptoken:

// src/constants.ts
export const SC_MAX_SKIP = 10000;

// When approaching the skip limit, switch to skiptoken
async function fetchWithKeysetPagination(entityType: string): Promise<any[]> {
  const allRecords: any[] = [];
  let nextLink: string | null = buildInitialUrl(entityType);
  
  while (nextLink) {
    const response = await fetch(nextLink);
    const data = await response.json();
    
    allRecords.push(...data.value);
    
    // Use the skiptoken from the response for next page
    nextLink = data['@odata.nextLink'] || null;
  }
  
  return allRecords;
}

Keyset pagination uses a token (typically based on the last record’s ID or timestamp) rather than a numeric offset. This approach:

Has no upper limit on the number of records
Is actually more performant than large offsets
Is the pattern SAP recommends for large datasets

If you have more than 10,000 records in any entity, you must use $skiptoken-based pagination. Simple $skip won’t cut it.

Implementation Notes

Technology Choice

I built the proxy with:

Node.js + Fastify: Lightweight, fast, excellent TypeScript support
On-demand caching: No scheduled jobs; cache fills dynamically on first request
Docker deployment: Runs on any container platform (I use Coolify on a VPS)

This is a production-ready setup. The proxy has been running reliably for the customer with no issues.

Smart Caching: On-Demand Parallel Fetching

Rather than running scheduled batch jobs, the proxy uses an on-demand approach:

First page served instantly: When SAC requests data, the proxy immediately returns the first page (up to 999 records) from Sales Cloud V2
Parallel fetching in background: While SAC processes the first page, the proxy fetches remaining pages in parallel
Cache populated for subsequent requests: By the time SAC requests page 2, the data is already cached

async function handleODataRequest(req: Request): Promise<Response> {
  // Check cache first
  if (cache.has(entityType) && !cache.isExpired(entityType)) {
    return serveFromCache(entityType, req.query);
  }
  
  // Fetch first page immediately
  const firstPage = await fetchPage(entityType, 0, 999);
  
  // Start parallel fetching of remaining pages (non-blocking)
  fetchRemainingPagesInBackground(entityType, firstPage.totalCount);
  
  // Return first page immediately
  return formatAsOData(firstPage);
}

This approach has several advantages:

No unnecessary background jobs: Data is only fetched when actually needed
Fast initial response: User doesn’t wait for full dataset
Self-healing cache: Expired cache automatically refreshes on next request

Optional: Deploying to SAP BTP Cloud Foundry

If you already have a BTP subscription with available credits, deploying there can make sense. You’re using infrastructure you’re already paying for. The migration is straightforward:

Standalone Setup Cloud Foundry Setup

Environment variables for credentials	Destination Service binding
In-memory cache	PostgreSQL Hyperscaler Option (free tier available)
Direct HTTP endpoint	XSUAA + AppRouter

Why PostgreSQL if you move to BTP?

On a single-container deployment (VPS e.g. with Coolify), in-memory caching works perfectly. But Cloud Foundry typically runs multiple app instances for high availability. If you need persistence across instances, PostgreSQL Hyperscaler Option is the lightweight choice. It has a free tier (since November 2025) and requires no additional management.

The additional effort for Cloud Foundry deployment is roughly:

Add mta.yaml with service bindings (~1 hour)
Configure Destination Service for Sales Cloud V2 credentials (~30 min)
Add XSUAA for authentication (~1 hour)
Test and deploy (~2 hours)

Total: Less than one additional day if you decide BTP is the right fit.

Don’t just default to BTP just because it’s SAP. Evaluate what you already have and what makes sense for your situation. A €5/month VPS running Docker might be exactly right for your use case.

OData Response Format

SAC expects OData V2or V4 responses. The minimum viable format:

{
  "d": {
    "results": [
      { "AccountID": "A001", "AccountName": "ACME Corp", ... },
      { "AccountID": "A002", "AccountName": "Globex", ... }
    ]
  }
}

Plus a $metadata endpoint returning EDMX that describes your entity types.

Authentication

Sales Cloud V2 supports:

Basic Authentication (simplest for server-to-server)
OAuth 2.0 (more secure, recommended for production)

The proxy stores credentials securely and handles token refresh for OAuth.

Results

After implementing the proxy:

SAC successfully imports Accounts, Contacts, and Opportunities
Data refreshes nightly via scheduled import
Customer can blend CX data with S/4HANA data in unified dashboards
No additional SAP platform licenses required
Total implementation time: ~2 days

When This Approach Makes Sense

The right solution depends on what you have and what you need. Here’s how I think about it:

A lightweight proxy makes sense when:

Limited scope (specific entities, not the entire data model)
Import/batch refresh is acceptable (not real-time requirements)
You don’t have Datasphere or CPI licensed and don’t need them for other use cases
You want to validate the integration quickly before investing in bigger infrastructure

Datasphere + CPI makes sense when:

You need event-driven, near real-time data replication
You’re integrating many entity types with complex relationships
You already have Datasphere or CPI licensed then use what you’re paying for
You have a broader data strategy where Datasphere is the central hub anyway

The key question: What do you already have, and does this use case justify adding more?

SAP’s platforms are excellent, no question! But sometimes a focused solution that solves exactly your problem is better than pulling in the big guns for a straightforward requirement.

Lessons Learned

1. Don’t Assume SAP Products Integrate Seamlessly

Sales Cloud V2 and SAC are both modern SAP cloud products. The integration gap exists because V2’s move away from OData wasn’t accompanied by a new native SAC connector (yet).

2. Check API Patterns Before Committing to Architecture

The shift from OData to REST in Sales Cloud V2 is documented, but easy to miss if you’re coming from C4C experience. Always verify on api.sap.com.

3. Test with Realistic Data Volumes

The 999/1000 mismatch only surfaces with more than 999 records. Demo systems with 50 accounts work fine. Production breaks.

4. Use What You Have, Validate What You Need

The official architecture is powerful. But if you don’t already have Datasphere and CPI licensed, ask yourself: does this specific use case justify adding them? Sometimes a focused solution that solves exactly your problem is the right call. You can always scale up later if requirements grow.

What’s Next?

I’ve published a reference implementation on GitHub that demonstrates the core patterns:

REST-to-OData transformation
Parallel fetching with caching
The 999→1000 batch bridging logic
Keyset pagination with $skiptoken for large datasets (>10k records)

👉 GitHub: SAP Sales Cloud V2 OData Proxy

A note on scope: The repository shows how the solution works, but doesn’t include everything from my production implementation. Some aspects are tied to specific client configurations that I can’t share. If you’re facing a similar challenge and want help getting to production faster, feel free to reach out.

If you’ve built something similar or found a better approach I’d love to hear about it in the comments.

Building an Email-Based SAP Sales Order Automation with n8n & AI Function Calling

2026-01-27T08:02:05.123000+01:00

Building an Email-Based SAP Sales Order Assistant with AI Function Calling

The Problem That Started This

A few weeks ago, I was watching a colleague struggle with a simple request: "Can you check if order 10850 shipped?" They had to VPN in, open SAP GUI, navigate to VA03, enter the order number, and finally get the answer. For one question. That took 3 minutes.

I thought - what if they could just send an email and get an answer back?

Why Not Just Use Rules or Keywords?

My first instinct was simple pattern matching. Look for "create order" then run the create flow. Look for "check status" then run the query flow. Easy, right?

Then I looked at actual emails people send:

"Hey, can you set up an order for 17100003? They need 5 of TG11 and 10 of TG12"
"pls make SO for cust 17100003 - TG11 x5, TG12 x10"
"Customer 17100003 wants to place an order. Materials: TG11 (5 units), TG12 (10 units)"

Same request, completely different wording. Building regex patterns for every variation? That's a maintenance nightmare waiting to happen. And what about typos, abbreviations, or when someone writes in a mix of languages?

This is exactly where AI shines - understanding intent regardless of how it's expressed.

Why Function Calling Instead of Free-Form AI?

I didn't want the AI making up SAP field names or guessing at API structures. That's a recipe for errors. Function calling gives you the best of both worlds:

The AI handles the messy, unpredictable part (understanding what the user wants)
The code handles the precise, structured part (calling SAP correctly)

You define exactly what functions exist and what parameters they accept. The AI picks the right function and extracts the right values. No hallucinated field names, no invented API calls.

The Architecture

Four components working together:

Microsoft Outlook - Triggers when an email arrives
LLM with Function Calling - Interprets the email, picks the operation
n8n - Orchestrates everything, handles data transformation
SAP S/4HANA OData APIs - Does the actual work

Setting Up n8n with Docker (The Network Gotchas)

I run n8n locally in Docker, and connecting it to an on-premise SAP system over VPN was... an adventure. Here's what I learned.

The Basic Setup

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  --add-host=host.docker.internal:host-gateway \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

That --add-host=host.docker.internal:host-gateway flag is crucial. It lets containers reference your host machine's network. Without it, your container is isolated and can't see anything your host can see - including VPN connections.

The VPN Problem

Here's the thing: when you connect to a VPN on your Mac, the VPN routes are available to your host machine, but Docker containers live in their own network namespace. They can't directly reach 172.16.0.11:44300 even though your browser can.

You might think "just use --network host" - but on macOS, that doesn't work the way you'd expect. Docker Desktop on Mac runs containers in a Linux VM, so --network host gives you the VM's network, not your Mac's network.

The socat Bridge Solution

The workaround is to run a TCP forwarder on your host that bridges the connection:

socat TCP-LISTEN:15001,fork,reuseaddr TCP:172.16.0.11:44300

This listens on port 15001 on your Mac and forwards traffic to the SAP server at 172.16.0.11:44300. Now from inside Docker, you can reach SAP at:

https://host.docker.internal:15001/sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder

The flow is: Docker container → host.docker.internal:15001 → socat on your Mac → VPN → SAP server

Keep the socat command running in a terminal while you're working. Kill it when you're done.

Quick Tip: If you're getting "connection refused" errors, check that:

Your VPN is connected
socat is running
You're using host.docker.internal, not localhost or the direct IP

The Functions I Defined

Three operations cover most daily requests:

get_sales_orders

"Show me recent orders," "What's the status of order X?"

Parameters: $top, $filter, $orderby

create_sales_order

"Create an order for customer X with these items"

Parameters: SoldToParty, items[] (Material, RequestedQuantity), plus optional fields

update_sales_order

"Change the PO reference on order 10904"

Parameters: SalesOrder (required), plus any fields to update

When an email comes in, the AI returns structured JSON:

{
  "function": "create_sales_order",
  "arguments": {
    "SoldToParty": "17100003",
    "items": [
      {"Material": "TG11", "RequestedQuantity": "5"},
      {"Material": "TG12", "RequestedQuantity": "10"}
    ]
  }
}

Clean, predictable, easy to work with.

The CSRF Token Headache

I have to mention this because it cost me hours. SAP OData APIs require CSRF tokens for write operations. Sounds simple - fetch a token, send it with your POST. But here's what the documentation doesn't make obvious:

The token is tied to your session cookies. You need to:

GET request with x-csrf-token: fetch header
Capture the token AND the SAP_SESSIONID cookie from the response
Send BOTH with your write request

I kept getting "CSRF token validation failed" with a perfectly valid token. Turns out I was missing the session cookie. The token alone is useless without it.

Another gotcha in n8n

The cookie header comes back with extra metadata like path=/; secure; HttpOnly. If you pass that whole string in your Cookie header, you'll get "Invalid character in header content." You need to extract just the cookie value:

// In an Edit Fields node, clean the cookie
$json.headers['set-cookie'][0].split(';')[0] + '; ' + 
$json.headers['set-cookie'][1].split(';')[0]

This gives you a clean sap-usercontext=sap-client=100; SAP_SESSIONID_S4H_100=abc123... that SAP will accept.

Data Transformation for Deep Insert

One more SAP quirk: when creating an order with line items, you can't just send an items array. SAP expects a nested structure called to_Item.results. In n8n's Code node:

const args = JSON.parse(
  $input.first().json.choices[0].message.tool_calls[0].function.arguments
);
const body = { ...args };

if (body.items) {
  body.to_Item = { results: body.items };
  delete body.items;
}

return [{ json: { sapBody: body } }];

This transforms the AI's clean output into SAP's expected format.

A Real Example

Input Email

Hello, please create a sales order with the following details:
Customer: 17100003
Sales Org: 1710
Items: TG11 (qty 5), TG12 (qty 10)
Currency: USD

What Happens

AI identifies this as create_sales_order
Extracts: customer, items array, currency
Workflow fetches CSRF token + session cookie
Transforms items array to SAP's to_Item.results format
POSTs to /sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder
SAP creates order, returns details

Response Email

The user never touched SAP. They just sent an email.

What's Next

The same pattern works for anything with an OData API:

Invoice queries
Delivery status checks
Material lookups
Customer master updates

Define the function, connect the endpoint, done.

The Takeaway

AI isn't replacing SAP knowledge here - it's translating between human language and system requirements. The business logic, the validations, the actual processing - that's all still SAP. The AI just makes it accessible to people who don't speak SAP.

And honestly? That's the kind of AI use case I find most valuable. Not replacing expertise, but removing friction.

How to call AS ABAP from SAP Datasphere

2026-01-27T08:11:27.946000+01:00

Introduction

For communication between SAP systems based on AS ABAP, RFC connections are the standard method. For example, when extracting from SAP ERP, the SAP BW system first launches the extractor in the source system via a BW->ERP RFC connection. The source system then returns the data collected by the extractor via an ERP->BW RFC connection.

For SAP Datasphere (hereinafter referred to as DSP), the natural successor to this approach is the BW Bridge use. However, not all projects justify using BW Bridge in terms of system landscape, architecture, project scope, and implementation costs.

This blog proposes an approach that allows DSP to execute code in a system running AS ABAP (without using BW Bridge). We will call this code as target code. The idea is to leverage CDS functionality known such as Virtual Elements. A Virtual Element is a field in a CDS View Entity, specifically defined using annotations. This field is not retrieved from the database table level and is not calculated by formulas within the CDS View itself. Instead, accessing the CDS View triggers execution of specialized ABAP code that implements the calculation logic for this field. For BW specialists this may remember well-known virtual characteristics and key figures. On the other hand, the CDS View is an object accessible to DSPs, for example, as a Source for Data Flow. Thus, by running Data Flow Run on the DSP side, we automatically initiate execution of the code that calculates the Virtual Element values in AS ABAP. We can, in turn, include calls of any desired programs, functional modules, or class methods to this code—that is, achieve the execution of the target code.

Unfortunately, this approach has one significant drawback that complicates its implementation: Virtual elements are only function within OData services generated from CDS views. This means that we cannot use connections of type SAP S/4HANA On-Premise, SAP ABAP, or SAP BW on the DSP side. You will need to create a Generic OData connection.

Implementation plan is following:

Create a CDS View Entity in S/4HANA using a Virtual Element.
Create an ABAP class that implements the calculation of this Virtual Element. The class code will include the target code call.
Register and test the OData Service.
Review the permissions required for the technical user on whose behalf the connection will be made. These permissions should be broader than the standard permissions for connections of type SAP S/4HANA On-Premise or SAP ABAP.
Notes regarding creating a Generic OData connection in DSP.
Create a simple Data Flow in DSP using the OData connection to the created CDS View. Running this Data Flow (manually, scheduled, or as part of a Task Chain) will trigger our target code in S/4HANA.

CDS View Entity with Virtual Element

We will create a dummy CDS View. It doesn't need to provide any meaningful data. We only need the ability to add a Virtual Element field to it. Therefore, as an example, we'll use a selection from the TKA01 (Controlling Areas) table. Typically, a single Controlling Area with a value of 1000 is used. Based on this assumption, we'll create the CDS View. Of course, you can use other selections that are guaranteed to return a single record in your system. The following code is proposed:

@EndUserText.label: 'CDS Virtual Element Test'
@analytics.dataCategory: #DIMENSION
@AccessControl.authorizationCheck: #NOT_REQUIRED
@vdm.viewType: #BASIC
@Metadata.ignorePropagatedAnnotations:true
@ObjectModel.usageType.serviceQuality: #A
@ObjectModel.usageType.sizeCategory: #S
@ObjectModel.usageType.dataClass: #MASTER
@analytics.dataExtraction.enabled: true
@analytics.dataExtraction.delta.changeDataCapture.automatic: true
@ObjectModel.supportedCapabilities:[#EXTRACTION_DATA_SOURCE]
@AbapCatalog.viewEnhancementCategory: [#NONE]
@odata.publish: true

define view entity Z_CDS_VIRT_ELEM as select from tka01
{
key kokrs,
substring( cast( tstmp_current_utctimestamp() as abap.char(17) ), 1, 8 ) as dat,
@ObjectModel.readOnly: true
@ObjectModel.virtualElement: true
@ObjectModel.virtualElementCalculatedBy: 'ABAP:ZCL_CDS_VIRT_ELEM_CALC'
cast('' as abap.sstring( 1 )) as flag
}
where kokrs = '1000'

The annotation at line 13 enables access to the CDS View via the OData Service.
The ‘dat’ field is added as a simple log: to see the date of the last calculation run.
The ‘flag’ field of the Virtual Element type is defined at line 22. It has the simplest form of a flag field. By default, as can be seen from the code, this field is empty. However, upon completion of calculations on the AS ABAP side, it will be filled with the value 'X'. This flag confirms at DSP side the successful completion of ABAP calculations.
The annotations at lines 19-21 define the "flag" field as a Virtual Element. In particular, the @ObjectModel.virtualElementCalculatedBy annotation specifies the name of the ABAP class that should calculate the ‘flag’ field.

When you initially activate this code, you'll receive, in particular, two warnings. For line 13 the system reports that the corresponding OData service is not active. For line 21 the system reports that the corresponding class doesn't exist. In the next steps, we'll resolve these issues.

If we use the context menu command 'Open With -> Data Preview' on our CDS View at this point, the result will be as follows:Here the 'kokrs' and 'dat' fields are populated using standard CDS syntax. The virtual 'flag' field is left blank.

Creation of ABAP Class implementing our calculations

A Virtual Element calculation implementing class must use two standard interfaces: IF_SADL_EXIT и IF_SADL_EXIT_CALC_ELEMENT_READ:

class ZCL_CDS_VIRT_ELEM_CALC definition
public
final
create public .

public section.

interfaces IF_SADL_EXIT .
interfaces IF_SADL_EXIT_CALC_ELEMENT_READ .
protected section.
private section.
ENDCLASS.

Second of these interfaces has two standard methods. A detailed description of these methods and their parameters can be found in the official documentation: https://help.sap.com/docs/ABAP_PLATFORM_BW4HANA/cc0c305d2fab47bd808adcad3ca7ee9d/4b5e56ec6f28453f81a...

In our example, the following code is proposed for the GET_CALCULATION_INFO method:

METHOD if_sadl_exit_calc_element_read~get_calculation_info.
IF iv_entity = 'Z_CDS_VIRT_ELEM'.
"Here we'll list which fields of CDS View will be used in virtual element calculation
IF line_exists( it_requested_calc_elements[ table_line = 'FLAG' ] ).
APPEND 'KOKRS' TO et_requested_orig_elements.
ENDIF.
ELSE.
" Potential errors should be processed by public constants,
" described in exceptional class, inherited from CX_SADL_EXIT.
" For example, if CDS View is unknown:

RAISE EXCEPTION TYPE zcx_ds_virt_elem_exceptions EXPORTING textid = zcx_ds_virt_elem_exceptions=>c_entity_not_known.
ENDIF.
ENDMETHOD.

Errors occurring during execution of the class described above must be handled using system messages. For this purpose, public constants will be created in a separate exception class. The class must be a child of the standard CX_SADL_EXIT class. An example of such an exception class is provided in the official documentation: https://help.sap.com/docs/SAP_NETWEAVER_AS_ABAP_751_IP/cc0c305d2fab47bd808adcad3ca7ee9d/8cf451799476...

As we can see, after specifying the parent class, a small constructor override is required. Each error is then declared as a public constant attribute. Naturally, such attribute contains a system message, previously defined in the Message Class relevant to the task.

Since our CDS View is designed to be as simple as possible, the IT_REQUESTED_CALC_ELEMENTS table will contain a single row with the ‘FLAG’ field. The ET_REQUESTED_ORIG_ELEMENTS table of regular source fields also contains only one record with the ‘KOKRS’ field.

Let's move on to the CALCULATE method:

METHOD if_sadl_exit_calc_element_read~calculate.
CHECK NOT it_original_data IS INITIAL.
DATA lit_calculated_data TYPE STANDARD TABLE OF z_cds_virt_elem WITH DEFAULT KEY.
MOVE-CORRESPONDING it_original_data TO lit_calculated_data.

LOOP AT lit_calculated_data ASSIGNING FIELD-SYMBOL(<lfs_calculated_data>).
"Here we need to add a call to the code that we wanted to initiate from the DSP side.
"For example, we can submit some program:
" SUBMIT z_some_program AND RETURN.
<lfs_calculated_data>-flag = 'X'. "Formal flag of the calculation readiness
EXIT. "Additional guarantee that calculation will be performed only once
ENDLOOP.
MOVE-CORRESPONDING lit_calculated_data TO ct_calculated_data.
ENDMETHOD.

Our CDS View is intentionally designed to return exactly one record. This means that in the CALCULATE method, the IT_ORIGINAL_DATA table also contains exactly one record. Consequently, the LOOP/ENDLOOP loop will only be executed once, and the target code will also be called only once.

After the ZCL_CDS_VIRT_ELEM_CALC class is activated, the warning on line 21 of our CDS View code will disappear.

OData Service activation

Our CDS View annotation specifies that it can be accessed via an OData Service. When we activate the CDS code, the corresponding OData Service will be created but not activated. Activation must be performed manually in the /IWFND/MAINT_SERVICE transaction. The OData Service name consists of the name of our CDS View followed by the _CDS suffix. In our example, the resulting name is Z_CDS_VIRT_ELEM_CDS.

Click the 'Add Service' button:

An ‘Add Selected Services’ window will appear. Enter Z_CDS_VIRT_ELEM_CDS as the technical name, and select LOCAL from the list in the 'System Alias' field. Then click 'Get Services'. A line with our service should appear:

Select the row with service description and press the ‘Add Selected Services’ button:In the 'Package Assignment' field, specify the appropriate package for subsequent import of developed objects to the production system. In the 'ICF Node' section, select the 'SAP Gateway OData V2' setting. An important setting is the 'Enable OAuth for Service' checkbox. Check with your BASIS Team to determine whether OAuth will be used when connecting the DSP to the ABAP system. If so, enable this checkbox. After confirming the settings, service activation will begin. Upon completion, the following message will appear:

Now you need to return to the main transaction window and filter the newly activated service in the list:

Check the traffic light in the 'Status' field (the leftmost field in the ICF Nodes section). If it's yellow, select the drop-down list from the 'ICF Node' button directly above it and execute the 'Activate' command:

The window for selecting a package for importing activated objects into production will appear again:

After this, the traffic light will change to green. You can now test the service by clicking the 'SAP Gateway Client' button:

By default, the test transaction specifies a URI that reads the service description:

But we're interested in what entities this service can provide. This can be found by clicking the 'Entity Set' button:

Here we see that the service can read data for CDS View Z_CDS_VIRT_ELEM. By double-clicking this name, we can change the URI:

If you now click the 'Execute' button, data will be read from the CDS View Z_CDS_VIRT_ELEM via the OData Service. This is precisely the operation that should trigger the calculation of the 'flag' field via the ABAP class described above. If you need to study or debug this class, you can set breakpoints there before clicking 'Execute'. The calculation results will be presented here in XML format:Here you can see that the 'flag' field is filled with the value 'X'. This means that the CALCULATE method was executed along with the target code call.

System user authorizations

When creating a DSP connection to an ABAP system, a special user of the System type is used. Typically, the BASIS Team assigns this user a standard set of permissions sufficient for connections of SAP S/4HANA On-Premise, SAP ABAP, or SAP BW types. Experience has shown that a Generic OData connection requires a number of additional permissions.

First, you need to add authorizations to launch the created OData Service. This is the S_SERVICE authorization object. Editing it differs from most standard authorization objects. After adding the object to the role profile, click the edit button for the SRV_NAME field. In the window that appears, select 'TADIR Service' from the Type drop-down list, which will display a list of services allowed to launch:

We need to add two types of objects for our service: IWSG and IWSV. First, select the appropriate type from the list in the 'Object Type' column. Then, use the search (for example, by pressing F4) in the 'Object Name' column. In both cases, you can use the name of our service (i.e. - Z_CDS_VIRT_ELEM_CDS) to search for the desired value:The name of the object being searched consists of the service name and the ordinal number of the active version of this service (four digits). For the first version of service in our example, the IWSG type value is 'Z_CDS_VIRT_ELEM_CDS_0001', and the IWSV type value is 'Z_CDS_VIRT_ELEM_CDS 0001'.

After saving the selected values, you will see that the value 'HT' is automatically added to the SRV_TYPE field. Thus, the S_SERVICE authorizations have been added and the values specified.

It is also important to note that specific authorizations may be required, which depend on the specific target code you want to run in the CALCULATE method described above. For example, if you plan to use a command like 'SUBMIT z_some_program AND RETURN' to launch a program, you will need the corresponding authorizations in the S_PROGRAM object. If the target code performs, for example, calculations related to the FI module, the system user may require authorizations specific to that module. If the target code accesses the contents of database tables, authorizations in the S_TABU_DIS and S_TABU_NAM objects may be required. And so on. Most likely, during the OData service testing phase (as described in the previous section), you will need to collaborate with the BASIS Team to monitor missing authorizations and add them to the system user's roles. The simplest solution is to temporarily (and only in the development system!) change the user type from system to dialog. In this case, you can log in to the SAP GUI with this user's login and manually run OData service testing while simultaneously monitoring the authorizations being checked.

The security issue of assigning such non-typical authorizations to a system user is mitigated by the fact that this user is created only to connect DSP to the ABAP system and cannot be used for manual data access, like a dialog user.

DSP OData Connection

Creating a Generic OData connection should be performed by BASIS Team specialists, as the required settings depend on the system landscape used in your specific project, as well as the security settings applied (for example, whether OAuth is enabled). Here's an example of the settings used in our project:The address entered in the ‘URL’ field ends with the technical name of our OData service. Therefore, a separate connection will need to be created for each OData service.

In the ‘Version’ field, V2 is selected. This is because we specified OData V2 when activating the service above and didn't have the option to select V4:

The example also shows that OAuth is used. That's why the corresponding checkbox was enabled earlier when activating the service:

At the bottom of the connection settings window, click the ‘Show Advanced Properties’ button:

Here you need to specify for the OData service the client number of the ABAP system we are connecting to:

DSP Data Flow to use OData connection and trigger the target code

We need to create a Data Flow with our OData service as a source. To do this, open Data Builder (in the same Space where you created OData service connection). In the left pane, select the 'Sources' tab and open the 'Connections' folder:

If all connection settings and system user authorizations were configured correctly, you will see the connection, and when you expand it, you will see the name of our CDS View:

The icon next to the CDS View is the same as for a regular table. You can drag and drop this View into the Data Flow being created. It will be automatically recognized as a Source. At this step, you can select the 'Preview Data' command for this table:

The result should look like this:

The presence of an 'X' in the 'flag' field means that the target code has been executed on the ABAP system side. If the target code execution takes a long time, you will also notice the delay when viewing it in the DSP.

As a final step, you need to complete the Data Flow by adding the target table to it, which in this case only serves as a dummy. Save the Data Flow and deploy it.

Result

Now you can initiate execution of the target code in the ABAP system in any way convenient for you: by manually starting the Data Flow, scheduling it, or including the Data Flow in a Task Chain.

Note: Data Preview is not working for Virtual Element

As a result of our implementation, OData Service is activated and implementing ABAP class exist for our Virtual Element. And we can repeat attempt of CDS data preview in ABAP Development Tools (CDS editor context menu command 'Open With -> Data Preview'). Unfortunately, result will be the same: field ‘flag’ is empty:

This is explained by the fact that the Virtual Element calculation is performed only when accessing the CDS through OData Service.

When Synchronous OData Failed for bulk data processing: How I Solved Problem Using OData V4 Async :

2026-02-09T07:33:18.454000+01:00

The Business Context:

BlueYonder sends planning and operational data
The data volume is large
Data needs to be posted into SAP S/4HANA Public Cloud
SAP exposes this functionality via OData V2 and V4 APIs

The expectation was simple: “Send data from BlueYonder and create/update records in S/4HANA.” But in reality, it was not that easy.

Introduction:

In real projects, integrations look simple on paper but behave very differently in production.

This blog is about a real-time problem I faced while integrating BlueYonder planning data into SAP S/4HANA Public Cloud using OData V2 Inbound.

The solution was understanding how OData V4 async processing works and using one small but powerful HTTP header.

In this blog, I will explain:

What problem I faced
Why synchronous processing failed
How I implemented async OData V4 processing with API proxy(through URL).
What changed after enabling async

The Actual Problem

Initially, I implemented the integration in a synchronous way.

What Happened

CPI sent data to S/4HANA public cloud using standard OData V2 synchronous Api
The backend took time to process the payload
CPI waited for the response
Requests started failing due to:

Timeouts
Long-running backend processing
Unstable behaviour during peak loads

The Key Issue

OData V2 APIs are synchronous by default. This means:

CPI waits until S/4HANA public cloud finishes posting
Large payloads increase risk
One slow request can block the entire flow This was not acceptable for a production-grade integration.
Chunking the payload using General splitter and streaming could increase the number of API Calls and may increase the load on Public cloud.

Design:

While analysing SAP documentation, I came across the asynchronous processing capability of OData V4. SAP provides a standard way to tell the backend: “Accept the request, process it in the background, and do not keep the connection open.”
This is done using the HTTP header: Prefer = respond-async

Step-by-Step Implementation :

Step 1: Receiving HighRadiusData in CPI

BlueYonder sends data in Flatten File.
CPI receives the data and prepares it for S/4HANA public cloud.

Data structure is aligned to OData V4 expectations At this point, the flow is still normal.

*Here I had implemented the Retry mechanism using JMS Queues which is the best practice for the SAP integrations ,If you like you implement it do check out my previous Blog that I had posted in the SAP Community.
Blog URL – {https://community.sap.com/t5/technology-blog-posts-by-members/handling-connectivity-and-recoverable-errors-in-sap-cpi-with-jms-queues/ba-p/14137974}

Step 2: Setting the Async Header (Most Important Step)

In CPI, I used a Content Modifier to add HTTP headers.

Header : Prefer Header Prefer = respond-async This header completely changes how the request is handled.

What Happens After Adding respond-async

Once this header is added:

CPI sends the request
S/4HANA immediately responds with HTTP 202 – Accepted
Backend processing continues asynchronously
CPI does not wait for the final processing result This single header removed timeout risks completely.

Step 3: Posting Data via API Proxy

* Here, I had used OAuth 2.0 Authentication between Integration suite to API Proxy and between API Proxy and S/4 Hana public cloud I had used Certificate Based Authentication.

CPI sends the request to an API Proxy
The proxy forwards the call to the OData V4 API from SAP Business Accelerator Hub
The proxy is created using the URL-based option

Note : OData V4 services do not appear in the API Provider’s service catalog in SAP API Management, so discovery isn’t possible — and that’s why I go with the URL method, so if you want to create proxy for OData V4 public cloud the correct approach is just go with the URL Option don’t fall for this pitfall.

If you want to leverage more on how to create API Proxy with URL option follow SAP Official Documentation.
Official documentation: {https://help.sap.com/docs/sap-api-management/sap-api-management/create-api-proxy-by-providing-direct-target-endpoint-url}

From CPI’s perspective:

The request is completed successfully

No long-running connection is maintained

What Changed After This Implementation
Before Async
- Timeouts during high data volume
- Unstable integration behaviour
- Risk of message failures
After Async
- Immediate response to CPI
- Backend processing happens safely
- No timeout issues
- Integration became stable and predictable
This was a real production-grade improvement, not just a theoretical change, I hope this helps you folks that don’t fall for this pitfall in your production.

Using Adapter HTTP - Response 403 for OData API Post Method- How to solve the big challenge

2026-02-21T11:06:08.764000+01:00

Connecting SAP S/4 HANA or ERP systems with external applications using OData services is becoming the backbone of modern enterprise integrations. Tools such as SAP Cloud Integration (CPI) or Integration Suite’s using HTTP Adapter make it easy to consume or expose APIs—until you hit a frustrating roadblock:

“HTTP 403 – Forbidden” when calling an OData API POST method.

This error is notoriously deceptive. Your GET requests work fine. Your endpoint is correct. Your payload is correct. Yet POST still fails.
Why?

In this blog, we’ll break down why HTTP 403 happens, what makes POST requests special, and—most importantly—how to solve this challenge with proven, real-world fixes.

1. Understanding the 403 Forbidden Error

A 403 Forbidden response means:

The server understood your request but refuses to authorize it.

In the context of OData POST calls via the HTTP adapter, this almost always indicates an authorization, CSRF, or policy-related issue.

2. Why GET Works but POST Fails

Many developers test an OData service with a GET call, find that it works, and assume the setup is correct. But POST behaves differently because it:

Modifies data, triggering stricter authorization checks
Requires CSRF token handling (depending on the endpoint)
May require additional headers

This is why GET succeeding does not prove the integration is fully configured.

3. The Top Causes of HTTP 403 for OData POST (and How to Fix Them)

Cause 1 — Missing or Incorrect CSRF Token

Many SAP OData services require a valid X-CSRF-Token for POST/PUT/PATCH/DELETE.

✔ Solution:
Perform a GET request with header:

X-CSRF-Token: Fetch

and capture:

Returned CSRF token
Returned cookies

Then send them along in your POST call:

X-CSRF-Token: <token>
Cookie: <cookies>

Cause 2 — Incorrect or Missing Headers

Some OData services enforce additional constraints.

Mandatory headers may include:

Content-Type: application/json
Accept: application/json

4. How to Troubleshoot 403 Efficiently

Step 1 — Test POST via Postman

Fetch CSRF token first
Send cookies + token in POST
Add all required headers

Step 2 — Check SAP Gateway Error Logs

Use transaction /IWFND/ERROR_LOG or /IWBEP/ERROR_LOG.

You may see:

"No CREATE authorization"
"CSRF Token validation failed"
"Request method not allowed"

These messages are extremely helpful.

5. Example Adapter HTTP Configuration for POST (CPI)

Headers

Method: POST
Content-Type: application/json
Accept: application/json
X-CSRF-Token: <fetched token>
Cookie: <SAP cookies>

Body (Example)

{
  "Name": "Sample Item",
  "Quantity": 10
}

Set Header for Cookie + CSRF token

Groovy Script 1(Shown from above Iflow image)

import com.sap.gateway.ip.core.customdev.util.Message;


def Message processData(Message message) {
    def headers = message.getHeaders();
    def cookie = headers.get("Set-Cookie");
    def csrf = headers.get("x-csrf-token");
    StringBuffer bufferedCookie = new StringBuffer();
    for (Object item : cookie)
    {
        bufferedCookie.append(item + "; ");
    }
    message.setHeader("Cookie", bufferedCookie.toString());
    message.setHeader("x-csrf-token", csrf)

    return message
}

POST Method

6. Conclusion – Turning a Frustrating 403 into a Successful POST

The HTTP 403 Forbidden error for OData POST calls is one of the most common yet misunderstood issues when integrating SAP systems. But once you understand:

CSRF handling
Role/authorization requirements
Header and policy rules
Gateway restrictions

…the problem becomes easy to solve.

Following the troubleshooting guidelines above will help you quickly identify the root cause and ensure your POST requests work reliably—whether you're integrating via CPI, API Management, BTP, or direct HTTP calls.