OData Adapter | Sender and Receiver

What is OData Adapter? 

An OData Adapter is an integration component that lets cloud platforms or enterprise systems connect to and communicate with OData APIs using the standardized Open Data Protocol.

Key Capabilities

CRUD Operations: Supports standard actions like Create, Read, Update, and Delete on exposed data entities.

Built-in Query Options: Simplifies data filtering, sorting, pagination, and selection using native parameters (like $filter, $select, $top, and $skip) without manual query writing.

Automatic Metadata Handling: Reads service metadata (EDMX files) to automatically discover entity sets, map structures, and convert payloads between formats like JSON, ATOM, and XML.

Authentication: Supports secure connections via Basic Authentication and OAuth 2.0.

Common Use Cases

Enterprise Integration: Widely used in platforms like SAP Cloud Integration (CPI) and Oracle Integration to link cloud apps with systems like SAP S/4HANA, SuccessFactors, or Ariba.Data Migration: Used to securely extract, transform, and load (ETL) structured entity data between disparate business systems.

Sender Adapter:

The OData Sender Adapter in SAP CPI (Cloud Platform Integration) allows you to expose your integration flows as OData services. This means external clients can call your CPI iFlow using OData protocol (REST + metadata), which is common in SAP UI5, Fiori, and other SAP apps.

Receiver Adapter:

In SAP Cloud Integration, receiver adapters are crucial for enabling communication with external systems. When integrating with an OData API, developers can choose to use either an OData (V2/V4) receiver adapter or an HTTP receiver adapter. While the OData adapter offers convenience by automating some tasks, it also comes with limitations that may necessitate the use of an HTTP adapter. In this blog, I will share my experiences regarding the advantages and limitations of the OData adapter in comparison to the HTTP adapter.

Advantages of the OData Receiver Adapter::

Automated X-CSRF-Token & Cookie Handling

One of the key advantages of the OData adapter is its automatic handling of the X-CSRF-Token and cookies, which is essential for making POST, PUT, and DELETE requests. When making a POST, PUT, or DELETE request using the HTTP receiver adapter without providing a valid token and cookie, you will likely encounter the error...: “HTTP operation failed invoking … with statusCode: 403” with the response body “CSRF token validation failed”. (Important to note is that - although this error seems to indicate a missing or invalid X-CSRF-Token - it may also be caused by missing or invalid cookies).

Configuration Details:

Sample URL:

https://services.odata.org/V2/(S(xjqjf2rkzrvecxualorv4hp))/OData/OData.svc

Here, specify Operation details like Query (GET), POST, Update ..etc based on your requirement.

And then select Resource Path and Query Details..as shown in above screenshot.

Page Size:

Maximum number of records that must be fetched in one page of results.

The value is set to Empty by default.

If no value is set, then Server-side pagination(__next link) is considered.

If a value is entered, Client-side pagination is considered with the value provided.

It’s recommended to leave the value Empty.

Process in Page:

By selecting Process in Pages, you enable the adapter to process messages in batches. The size of a message is defined by the value that you specify for the Page Size.

To use Process in Pages, you must use the adapter in a Local Integration Process that is invoked by a Looping Process Call step. In the Looping Process Call, provide the loop condition details that follow:

Select Expression Type as Non-XML

For Condition Expression, provide ${property.<receiver.name>.<channel.name>.hasMoreRecords} contains 'true'

For Maximum Number of Iterations, provide 999

This option isn’t enabled for Content Enricher.

Retry:

Select the check boxes based on your business case..

OData V4: (latest)

 

Allow Chunking - select it if required.

Now, test the iflow from Postman as shown below..

Status code is 200 OK, it means - Successfully you have received the response from SAP CPI.

Note:

The considerations for choosing between the HTTP and OData receiver adapters in SAP Cloud Integration depend on your integration scenario's specific requirements. The OData adapter simplifies integration with automated token handling and entity management, making it ideal for standard SAP services with XML payloads. However, for specific scenarios that require non-XML payloads or navigation paths, the HTTP adapter provides the necessary flexibility.

I hope this blog provides some insights into when and how to use the HTTP and OData adapters effectively. Please feel free to share any additional experiences or tips in the comments.

Thanks for reading. :-)

SAP Cloud Connector - Setup

What is SAP Cloud Connector.?

SAP Cloud Connector (SCC) is a lightweight software component that securely connects your on-premises systems to SAP BTP (Business Technology Platform) without exposing your internal systems directly to the internet.

Think of it as a secure tunnel between your company's internal network and SAP BTP.

For example, if SAP Integration Suite (Cloud Integration / CPI) needs to communicate with an on-premises SAP ECC system, the Cloud Connector enables that communication securely.

Key benefits:

• Secure connectivity: Establishes an encrypted connection to SAP BTP.

• No inbound firewall opening required: It establishes the connection from your internal network to SAP BTP.

• Access control: Exposes only the internal systems and resources explicitly configured.

• On-premises integration: Enables cloud applications to access permitted internal resources.

How the communication work..?

1. The Cloud Connector is installed on a server inside the corporate network.

2. The administrator connects it to the relevant SAP BTP subaccount.

3. The administrator configures the backend system, virtual host, port and permitted resources.

4. The CPI iFlow sends a request to the configured virtual address using the appropriate connectivity setup.

5. The Cloud Connector forwards the request to the actual internal backend system.

6. The response travels back through the secure connection.

Important: Cloud Connector does not automatically make every internal system accessible. The administrator must explicitly configure the allowed systems and resources.

How to download and install it?

Download the installer from tools.hana.ondemand.com. https://tools.hana.ondemand.com/#cloud 

Choose the OS-specific version (Windows MSI or Linux RPM).

Follow the basic installation steps, Cloud Connector runs as a local service.

After installation, access the UI using:

https://localhost:8443

UserName: Administrator

Pwd: manage

You can change the pwd after first login

How to configure it?

• Connect SCC to SAP BTP Subaccount
• Login to the UI.
• Go to Cloud To On-Premises => Subaccount.
• Enter your SAP BTP SubAccount ID, Region, and Authentication details.
• Save and establish the connection.

If successful, the Subaccount will show the status as "Connected"

Add On-Premise Backend Systems

Now expose on-prem services to BTP:

• Navigate to Cloud To On-Premise → Add System.
• Choose the system type (ABAP, HTTP, RFC, etc.).
• Provide host, port, and protocol details of the backend system.
• Map virtual host/port to internal host/port.
• Select resources (paths, RFC functions, services) you want to expose.

Assign Access Control

For each system:

• Enable Access Control.
• Specify the resources BTP apps are allowed to consume.
• Set principal type (none, principal propagation, or basic auth).

Verify the Connection from SAP BTP

• Go to your SAP BTP Cockpit → Connectivity → Cloud Connectors.
• Verify status, system availability, and reachable endpoints.

Supported Protocols

To allow your cloud applications to access a certain on-premise system on the intranet, you must specify this system in the Cloud Connector. The procedure is specific to the protocol that you're using for communication. The following protocols are supported:

HTTP

RFC

LDAP

TCP

Now, provide the CPI - sub-account details and check the status..

Common Issues in Cloud Connector?

Sources: help.sap.com

Thanks for reading :-)

Event Mesh & Solace - Administration

Solace - Administration

Solace Administration, which includes configuring, operating, monitoring, and securing the Solace PubSub+ event broker platform.

Solace PubSub+ is an event broker used to distribute messages and events between applications, microservices, enterprise systems, and cloud platforms.

Typical administration responsibilities include:

• Creating and configuring message VPNs (isolated messaging environments).
• Managing queues, topics, and topic subscriptions.
• Creating client usernames, profiles, and ACL (Access Control List) permissions.
• Configuring message delivery, persistence, and replay-related capabilities.
• Monitoring queue depth, message rates, connections, and broker health.
• Troubleshooting authentication, authorization, connectivity, and message-delivery issues.
• Managing high availability, disaster recovery, and broker upgrades.

Please refer below link for how to create Queue/Topic in Solace admin page and following CPI iflows:

Solace - Queue/Topic Setup

What is SAP Event Mesh?

SAP Event Mesh is a messaging service on SAP Business Technology Platform (BTP) that allows applications to exchange messages asynchronously using queues and topics.

It is useful when integrating SAP and non-SAP applications, for example:

• SAP S/4HANA publishes a business event.
• SAP Event Mesh receives and routes the event.
• SAP CPI (Cloud Integration) consumes the event.
• CPI transforms the payload and calls a third-party API or another enterprise application.

Depending on the SAP service and event source, events can originate from S/4HANA, SAP applications, or custom applications.

Solace Administration vs. SAP Event Mesh

SAP Event Mesh with SAP CPI

SAP Integration Suite, Advanced Event Mesh

Choose standard Event Mesh when:

• You primarily integrate S/4HANA with CPI and a few target systems.
• Event volume and payload sizes fit the service limits.
• You want to control infrastructure and licensing costs.
• You don't need a distributed network of brokers.

Choose Advanced Event Mesh when:

• Your organization needs a global event-driven architecture.
• Applications span on-premises, multiple clouds and geographic regions.
• You need advanced event discovery, governance, filtering, tracing or replay.
• Your throughput, payload or retention needs exceed standard service limits.

Common production incidents you should be able to troubleshoot..

Daily, Weekly and Monthly duties::

Daily

Review critical alerts and failed integrations.

Check queue backlogs and message-processing delays.

Investigate access and connectivity incidents.

Weekly

Review queue and message-volume trends.

Check recurring failures and consumer performance.

Review upcoming certificate and credential expirations.

Monthly

Review service consumption, quotas and capacity forecasts.

Audit permissions and inactive credentials.

Review changes, DR readiness and operational documentation.

Note: I have added most of the day to day and monthly roles and responsibilities from BTP Admin perspective. 

Sources: help.sap.com

Thanks for reading :-)