SAP Community - SAP HANA

How I Used Microsoft Copilot and Azure Services to Improve SAP S/4HANA Project Tracking

2026-06-19T20:59:14.188000+02:00

How I Used Microsoft Copilot and Azure Services to Improve SAP S/4HANA Project Tracking and Governance

Introduction

One of the biggest challenges in large SAP S/4HANA transformation programs is not the implementation itself—it is maintaining visibility across hundreds of project activities, risks, defects, decisions, and action items spread across multiple teams and systems.

During global SAP transformation programs, project information is often distributed across several platforms:

Azure DevOps for defects and sprint activities
Microsoft Project for schedules
ServiceNow for incidents and change requests
Microsoft Teams for collaboration
SharePoint for project documentation
SAP Solution Manager or Cloud ALM for project execution activities

As project managers, we spend significant time consolidating information from these sources before we can make informed decisions.

Recently, I explored how Microsoft Copilot combined with Azure services can help project managers improve governance, risk management, reporting, and executive visibility throughout an SAP transformation lifecycle.

The Traditional Project Tracking Challenge

In a typical SAP S/4HANA transformation, a weekly status review often requires collecting information from multiple workstreams:

Program Management Office
Data Migration Team
Integration Team
Testing Team
Security Team
Change Management Team
Business Process Owners

The challenge is that critical project information exists in multiple repositories.

Typical Information Landscape

Azure DevOps
   │
   ├── Defects
   ├── User Stories
   └── Sprint Progress

Microsoft Project
   │
   ├── Project Schedule
   ├── Milestones
   └── Dependencies

ServiceNow
   │
   ├── Incidents
   ├── Changes
   └── Service Requests

Microsoft Teams
   │
   ├── Meetings
   ├── Discussions
   └── Action Items

SharePoint
   │
   ├── Documents
   ├── RAID Logs
   └── Status Reports

As a result, project managers spend considerable effort gathering information instead of analyzing risks and making decisions.

Introducing Microsoft Copilot into SAP Project Governance

Microsoft Copilot provides an opportunity to transform project management activities from manual reporting to intelligent project governance.

Rather than searching through multiple systems, project leaders can ask questions in natural language such as:

Which workstreams are currently behind schedule?
What are the highest-priority risks this week?
Which defects remain open beyond SLA?
What actions were assigned during steering committee meetings?
Which milestones are at risk for the upcoming release?

Instead of manually preparing reports, Copilot can help summarize information from connected project repositories.

Architecture Overview

The following conceptual architecture demonstrates how Azure services and Copilot can support SAP project tracking.

Architecture Diagram

+---------------------------------------------------+
|              SAP Transformation Program           |
+---------------------------------------------------+

          Data Sources
-----------------------------------------------------

 Azure DevOps      Microsoft Project
      |                    |
      |                    |
      +----------+---------+
                 |
                 |
 ServiceNow   SharePoint   Teams
      |           |          |
      +-----------+----------+
                  |
                  v

+--------------------------------------+
|      Microsoft Azure Services        |
+--------------------------------------+
| Azure Data Factory                   |
| Azure Logic Apps                     |
| Azure AI Services                    |
| Azure Storage                        |
| Azure Data Lake                      |
+--------------------------------------+
                  |
                  v

+--------------------------------------+
|         Microsoft Copilot            |
+--------------------------------------+
| Risk Summarization                   |
| Defect Trend Analysis                |
| Executive Status Reporting           |
| Action Item Tracking                 |
| Meeting Summaries                    |
+--------------------------------------+
                  |
                  v

+--------------------------------------+
| SAP Program Leadership Dashboard     |
+--------------------------------------+
| PMO                                  |
| Steering Committee                   |
| Business Stakeholders                |
| Program Leadership                   |
+--------------------------------------+

Use Case 1: Automated Executive Status Reporting

One of the most time-consuming activities for project managers is preparing executive status reports.

Traditionally, project managers gather information from multiple teams and manually create PowerPoint presentations.

With Copilot, project leaders can generate summaries based on:

Open risks
Defect trends
Milestone completion
Change requests
Resource constraints

Example prompt:

"Summarize all high-priority risks, critical defects, and delayed milestones for the SAP S/4HANA transformation program during the past seven days."

This significantly reduces manual reporting effort and allows project managers to focus on decision-making rather than document preparation.

Use Case 2: Risk Monitoring and Early Warning Indicators

Risk management is critical during SAP transformation programs.

In one project, recurring defects appeared during integration testing across multiple regions. Individually, each defect seemed manageable, but collectively they indicated a broader data quality issue.

Using AI-assisted analysis, project teams can identify:

Recurring defect patterns
Escalating risks
Delayed action items
Resource bottlenecks
Testing readiness concerns

Example Risk Analysis Flow

Defect Data
      +
Meeting Notes
      +
Action Items
      +
Schedule Updates
      |
      v

Azure AI Analysis

      |
      v

Risk Pattern Detection

      |
      v

Copilot Summary

      |
      v

Project Leadership Alert

This approach helps identify potential problems before they impact major milestones.

Use Case 3: Meeting Action Tracking

A common challenge in SAP programs is following up on action items generated during workshops and governance meetings.

Copilot can help by:

Summarizing meeting discussions
Extracting action items
Identifying owners
Tracking due dates
Highlighting overdue actions

Instead of manually reviewing meeting notes, project managers receive a consolidated action dashboard.

Use Case 4: Defect Trend Analysis

During testing cycles, hundreds or even thousands of defects may be logged.

Copilot can assist by identifying:

Defect hotspots
Repeated root causes
Process areas generating the highest defect volume
Regional implementation concerns

This helps testing managers prioritize corrective actions more effectively.

Lessons Learned

Through my experience managing enterprise transformation programs, I have learned that AI does not replace project managers.

Instead, it enhances their ability to:

Process information faster
Identify risks earlier
Improve governance visibility
Reduce manual reporting effort
Focus on strategic decision-making

The most successful approach combines:

Human expertise
Business process knowledge
Governance discipline
AI-assisted insights

Conclusion

The future of SAP project management is not about replacing project managers with AI. It is about empowering project leaders with better visibility and faster access to information.

By combining Microsoft Copilot with Azure services, organizations can transform project tracking from a manual reporting exercise into a proactive governance capability.

For SAP S/4HANA transformation programs, this means improved transparency, faster decision-making, better risk management, and ultimately a higher probability of successful program delivery.

As SAP transformations continue to grow in complexity, AI-powered project governance will become an increasingly important capability for program leaders seeking to deliver successful business outcomes.

Going Beyond the Tip of the Iceberg with SAP HANA Cloud SQL on Files

2026-06-24T04:34:53.984000+02:00

Related Blogs:

As I mentioned in my previous blogs, SQL on Files, a capability of SAP HANA database in SAP HANA Cloud, has been continuously expanding since SAP HANA Cloud QRC 3/2024. We started with native read-only access to CSV, Parquet, and Delta tables in SAP HANA Cloud, data lake Files. We then extended this access to external object storages (Amazon S3, Azure Blob/ADLS Gen2, Google Cloud Storage) and external Delta Sharing in QRC 4/2024. Most recently, we introduced Delta table-to-HANA replication in QRC 4/2025.

With SAP HANA Cloud QRC 2/2026, I'm pleased to announce that the journey continues, and this time the spotlight is on Apache Iceberg, the industry-standard open table format that has rapidly become a cornerstone of modern data lakehouse architectures. While Iceberg support has been quietly maturing in SAP HANA Cloud over the last few quarters, this is the first blog dedicated to telling the full story end-to-end.

In a nutshell, here is what SAP HANA Cloud now offers for Apache Iceberg, cumulatively from QRC 3/2025 through QRC 2/2026:

Direct read-only access to Apache Iceberg tables in object storage via the file adapter, including time-travel queries (QRC 3/2025).
Snapshot replica toggling support for Apache Iceberg virtual tables (QRC 1/2026).
Data Page V2 (DATA_PAGE_V2) support in the Parquet reader, aligning SAP HANA Cloud with the latest Parquet ecosystem (QRC 1/2026).
Direct read-only access to Apache Iceberg REST Catalogs via the new icebergcatalog adapter. QRC 1/2026 introduced the adapter with Cloudera and Databricks running on AWS as the initially certified providers, and QRC 2/2026 extends the multi-cloud coverage to Azure and GCP for Databricks while additionally certifying Snowflake across AWS, Azure, and GCP. Cloudera certification on Azure and GCP is planned for a future release.
AliCloud Object Storage Service (OSS) added to the list of supported external object storages (QRC 2/2026).

Alright, with these points in mind, let's dive deeper into the details with some examples.

Apache Iceberg via the file Adapter

Starting with SAP HANA Cloud QRC 3/2025, SQL on Files began supporting Apache Iceberg as an additional file format on top of the existing CSV, Parquet, and Delta table support. As highlighted in my first SQL on Files blog and follow-up blog, the file adapter provides direct read-only access to files in SAP HANA Cloud, data lake Files or in supported external object storages. With Iceberg now in the mix, customers can query Iceberg tables sitting on object storage without any data movement or ingestion.

Since Apache Iceberg is an open table format, the way of creating a virtual table is similar to Delta tables, where you only need to point the virtual table to the root of the Iceberg table:

-- create a virtual table by pointing to an apache iceberg table
CREATE VIRTUAL TABLE DEMO.ICEBERG_ORDERS AT "demo-hdlf_rs"."/iceberg/orders/" AS ICEBERG;

A few things worth knowing about this support:

Both Iceberg v1 (Copy-on-Write) and v2 (Merge-on-Read) are supported for read-only access.
Time-travel queries are supported, similar to Delta tables, via either snapshot ID or timestamp:

-- time travel by snapshot id
SELECT * FROM DEMO.ICEBERG_ORDERS FOR VERSION AS OF '2953155114686890267';

-- time travel by timestamp
SELECT * FROM DEMO.ICEBERG_ORDERS FOR SYSTEM_TIME AS OF '2025-04-08 07:43:31.793000000';

Two new built-in functions help you explore Iceberg metadata directly from SAP HANA Cloud:

Function	Returns
GET_ICEBERG_TABLE_SNAPSHOTS	Snapshot IDs, create time, sequence number, record count, file count, total file size
GET_VIRTUAL_TABLE_FILE_PARTITIONS	Partition values, file count, total file size per partition

The existing GET_REMOTE_SOURCE_FILE_COLUMNS built-in procedure has been extended to retrieve column information from Iceberg tables as well.

Important: Apache Iceberg metadata stores absolute table paths. Simply copying Iceberg files from one location to another will cause inconsistencies, and creating virtual tables on the copied files will not work. Always create or migrate Iceberg tables using a proper Iceberg-compatible engine.

Please refer to the links below for further details.

SAP HANA Cloud, SAP HANA Database SQL on Files Guide: Create a Virtual Table
SAP HANA Cloud, SAP HANA Database SQL on Files Guide: GET_ICEBERG_TABLE_SNAPSHOTS Function
SAP HANA Cloud, SAP HANA Database SQL on Files Guide: GET_VIRTUAL_TABLE_FILE_PARTITIONS Function
SAP HANA Cloud, SAP HANA Database SQL on Files Guide: GET_REMOTE_SOURCE_FILE_COLUMNS

Apache Iceberg REST Catalog via the icebergcatalog Adapter

Reading Iceberg tables directly from object storage with the file adapter is great for self-managed scenarios. However, in real-world enterprise lakehouses, Iceberg tables are usually managed by an Iceberg REST Catalog server, for example, Databricks Unity Catalog, Cloudera Data Platform, or Snowflake. Customers told us that, for production-grade integration, the catalog-based approach is what they consider enterprise-ready: it centralizes table management, access control, and metadata governance.

That's where the new icebergcatalog adapter comes in. Starting with SAP HANA Cloud QRC 1/2026, SQL on Files supports direct read-only access to external Apache Iceberg REST Catalogs, with Cloudera and Databricks running on AWS as the initially certified providers. With QRC 2/2026, the multi-cloud coverage is extended to Azure (ADLS Gen2) and GCP (GCS) for Databricks, and Snowflake is added as an additionally certified provider across AWS, Azure, and GCP. Cloudera certification on Azure and GCP is planned for a future release.

The way to create a remote source to an Iceberg REST Catalog follows the official Apache Iceberg REST Catalog specification with bearer-token (OAuth) authentication:

-- create a remote source to an iceberg rest catalog
CREATE REMOTE SOURCE <remote_source_name> ADAPTER "icebergcatalog" CONFIGURATION '
provider=databricks;
endpoint=<rest_endpoint>;'
WITH CREDENTIAL TYPE 'OAUTH' USING 'access_token=<bearer_token>';

Once the remote source is created, virtual tables are created in the same way as with other SAP HANA smart data access (a.k.a., SDA) adapters by pointing to the catalog → namespace → table:

-- create a virtual table on a table exposed via the iceberg rest catalog
CREATE VIRTUAL TABLE DEMO.VT_ORDERS
  AT "<remote_source_name>"."<NULL>"."<namespace>"."<table>";

A few important notes on the certification scope and authentication:

The icebergcatalog adapter is designed to work with any spec-compliant Apache Iceberg REST Catalog. In theory, any REST catalog that follows the official spec and bearer-token authentication should work.
However, because small differences in authentication flows or vendor-specific extensions can cause unexpected issues, SAP officially certifies only a defined set of Iceberg REST Catalog providers per QRC, as summarized below. Other REST catalogs may work but are not officially certified.

Provider	AWS	Azure (ADLS Gen2)	GCP (GCS)
Cloudera	Certified (QRC 1/2026)	Planned	Planned
Databricks	Certified (QRC 1/2026)	Certified (QRC 2/2026)	Certified (QRC 2/2026)
Snowflake	Certified (QRC 2/2026)	Certified (QRC 2/2026)	Certified (QRC 2/2026)

Authentication is currently limited to bearer-token (OAuth). Full credential flows (e.g., automatic token acquisition and refresh by negotiating directly with the identity provider) are not implemented inside SAP HANA Cloud. Instead, the credential flow is expected to live in the application layer, while the database layer simply consumes the access token.

For renewing access tokens, the SET SESSION CREDENTIAL statement can be used to inject a freshly obtained access token from the application layer:

-- renew the access token from the application layer
SET SESSION CREDENTIAL FOR REMOTE SOURCE <remote_source_name>
  TYPE 'OAUTH' USING 'access_token=<access_token_string>';

In other words, our expectation is that the credential flows are implemented in the application layer, while the database layer supports the way of renewing access tokens.

Please refer to the links below for further details.

SAP HANA Cloud, SAP HANA Database SQL on Files Guide: Create an Apache Iceberg Catalog Remote Source

More Improvements Worth Highlighting

Beyond the two main pillars above, several smaller but meaningful improvements landed alongside this Iceberg journey. They are bundled here for completeness.

Snapshot replica toggling for Apache Iceberg (QRC 1/2026)

For customers who want better query performance on Iceberg tables, snapshot replica toggling is now supported when the source is an Apache Iceberg table. As with other SDA-based virtual tables, you can toggle a virtual table to a snapshot replica by adding a snapshot replica with the ALTER VIRTUAL TABLE statement, then refresh or drop it as needed:

-- toggle to a snapshot replica
ALTER VIRTUAL TABLE DEMO.VT_ORDERS ADD SHARED SNAPSHOT REPLICA;

-- refresh the snapshot replica with the latest data from the source
ALTER VIRTUAL TABLE DEMO.VT_ORDERS REFRESH SNAPSHOT REPLICA;

-- delete the replica
ALTER VIRTUAL TABLE DEMO.VT_ORDERS DROP REPLICA;

A couple of important constraints to keep in mind:

Snapshot replica toggling always creates a full snapshot of the data the virtual table is pointing to. This means it does not help if the target Iceberg table holds a vast volume of data that cannot be replicated in full into SAP HANA Cloud. In such cases, the recommended approach is to keep federation only, or wait for the upcoming chunk-based replication discussed in Looking Ahead.
Unlike Delta tables, real-time replication via toggling is not yet supported for Iceberg. Real-time replication on Iceberg will become available together with the upcoming interval-based CDC support (see Looking Ahead).

Data Page V2 support in the Parquet reader (QRC 1/2026)

The Parquet ecosystem has been moving toward Data Page V2 (page_type=DATA_PAGE_V2), and several modern engines, now produce Parquet files using this newer page format. Starting with QRC 1/2026, the SAP HANA Cloud Parquet reader supports DATA_PAGE_V2, ensuring smooth interoperability with these engines. This is a quiet but important enabler for the full Iceberg story, especially for the Apache Iceberg REST Catalog scenario with Snowflake-managed Iceberg.

AliCloud Object Storage Service (OSS) support (QRC 2/2026)

The list of supported external object storages keeps growing. With QRC 2/2026, AliCloud Object Storage Service (OSS) joins Amazon S3, Azure Blob/ADLS Gen2, and Google Cloud Storage as a first-class storage option for SQL on Files.

However, please note one limitation specific to AliCloud deployments:

SQL on Files queries accessing Google Cloud Storage on AliCloud Cloud deployments are not supported.

Please refer to the links below for further details.

SAP HANA Cloud, SAP HANA Database SQL on Files Guide: Toggle Between Virtual Tables and Replica Tables

FAQs

Q: Can I write to an Apache Iceberg table from SQL on Files?
A: No. SQL on Files is read-only by design, both via the file adapter and the icebergcatalog adapter. INSERT, UPDATE, and DELETE on virtual tables pointing to Iceberg are not supported. Write operations should be performed by Iceberg-native engines (e.g., Spark, the catalog provider's compute) on the source side.

Q: Which Iceberg REST Catalog providers are officially certified?
A: Cloudera and Databricks running on AWS were initially certified with QRC 1/2026. With QRC 2/2026, Databricks is additionally certified on Azure and GCP, and Snowflake is newly certified across AWS, Azure, and GCP. Cloudera certification on Azure and GCP is planned for a future release. See the certification table in the icebergcatalog adapter section above for the full per-QRC, per-hyperscaler matrix. Other spec-compliant REST catalogs may work but are not officially certified.

Q: What kind of authentication is supported for the icebergcatalog adapter?
A: Bearer-token (OAuth) only. Full credential flows are expected to be handled in the application layer, with the access token being injected into SAP HANA Cloud either at remote source creation time or via SET SESSION CREDENTIAL for refresh.

Q: Can I replicate an Apache Iceberg table into a SAP HANA table?
A: Today, only snapshot replica toggling is supported for Iceberg. Full remote subscription-based replication (initial load + interval-based CDC), equivalent to the Delta table replication introduced in QRC 4/2025, is on the roadmap (see Looking Ahead).

Q: I'm running Google Cloud Storage on AliCloud. Can I use SQL on Files to read data from there?
A: No. SQL on Files queries accessing Google Cloud Storage are not supported on AliCloud deployments. Other supported object storages remain accessible.

Q: Is there any plan to support Apache Iceberg format V3?
A: The Iceberg ecosystem is evolving toward V3, and we are actively defining our adoption strategy. See Looking Ahead for the high-level direction.

Q: I'm already accessing Apache Iceberg tables via the file adapter. Do I need to change anything with the introduction of the icebergcatalog adapter?
A: No. The two adapters cover different scenarios and coexist. If you have been using the file adapter to access Iceberg tables directly on object storage, your existing setup keeps working as-is. The icebergcatalog adapter is an additional option for customers who manage their Iceberg tables through an Iceberg REST Catalog (Cloudera, Databricks, or Snowflake).

Looking Ahead

While this blog focuses on what is generally available with QRC 2/2026, there are a couple of directions we are actively exploring for the longer term:

Apache Iceberg table-to-HANA replication: Today, Delta table replication (QRC 4/2025) gives customers chunk-based or one-step initial load combined with user-driven or scheduled CDC. We see strong demand for the equivalent capability on Apache Iceberg via both the file adapter and the icebergcatalog adapter, including Data Replication UI integration. Release timing has not yet been finalized.
Apache Iceberg format V3: V3 introduces extended types (e.g., variant, geometry, geography, nanosecond timestamps), default values, row lineage, and binary deletion vectors. We plan to selectively enable V3 capabilities as the broader ecosystem matures, so customers get predictable behavior with V3 tables. Release timing has not yet been finalized.

These items reflect long-term direction rather than committed deliveries, so please treat them as forward-looking signals rather than firm release plans.

Conclusion

With SAP HANA Cloud QRC 2/2026, the Apache Iceberg story in SQL on Files is now complete in its first chapter: direct read-only access to Iceberg tables via the file adapter, enterprise-grade integration with Iceberg REST Catalogs via the new icebergcatalog adapter across AWS, Azure, and GCP, plus a set of supporting improvements like snapshot replica toggling, Data Page V2, and AliCloud OSS coverage.

This continues SAP HANA Cloud's commitment to open table formats, meeting customers where their data already lives, whether that's a Delta Lake, an Iceberg lakehouse, or a mixture of both. As we remain committed to innovation, stay tuned for upcoming updates that will continue to expand and enrich your SAP HANA Cloud experience, including richer Iceberg replication and evolving Iceberg V3 support.

Security Administrator Exam

2026-06-29T10:26:29.731000+02:00

Planning on taking the SAP C_SEC certification? Here are a few tips that may help with your preparation:

Pay close attention to SAP naming conventions. Many exam questions rely on the exact terminology used by SAP, so understanding names, roles, objects, and concepts is essential.
Read each question carefully—more than once if needed. A single word can change the meaning of the question and lead to a different answer.
Think outside the box. Some questions are scenario-based and require you to apply your knowledge rather than simply recall facts.
Review the Live Sessions, Learning Journeys, and training materials thoroughly. They cover the key topics and concepts you'll need for the exam, so don't skip them.

Good luck with your preparation and the exam!

#saphana#fiori

Beyond Single-Company: Configuring Multi-Company PM Order Replication to SAP FSM

2026-07-01T11:01:10.081000+02:00

Note: This feature will be available for 2025 release from October 2026.

Contents

Introduction & Business Context
Why Multi-Company?
How It Works — The Big Picture
Step-by-Step Configuration Guide
Controlling the FSM Planning Board
Extensibility
Monitoring & Error Recovery
Summary

1. Introduction & Business Context

SAP S/4HANA Plant Maintenance (PM) and SAP Field Service Management (FSM) are designed to work together as one end-to-end maintenance execution platform. When a planner raises a PM order in S/4HANA — for a breakdown repair, a preventive inspection, or a scheduled overhaul — that order is automatically pushed to FSM, where a dispatcher assigns it to the right field technician. The technician receives the work on their mobile device, executes it on-site, and the completion confirmation flows back to S/4HANA — closing the loop without manual re-entry.

A companion blog post covers this integration for organisations with a single FSM company. This blog addresses a more common enterprise scenario: a single SAP system serving multiple business units, regions, or subsidiaries, each managed by a separate FSM company.

2. Why Multi-Company?

    SAP FSM supports a single-company model where all field service data lives in one place.
    While authorizations can be used to restrict what each country or business unit user sees,
    this still means all their data — customers, orders, technicians, activities — is loaded
    into and managed within that single company. For many enterprises this is not desirable:
    different subsidiaries may have different contracts, different service processes, different
    FSM configurations, or strict data segregation requirements. Multi-company support
    allows organisations to segregate their business and data into separate FSM companies,
    each operating independently with its own configuration, workforce, and dispatching logic —
    while still being driven from a single S/4HANA system.

Beyond data segregation, multi-company support also enables:

Capability	What it means in practice
Automatic routing	PM orders are routed to the correct FSM company based on the planning plant and order type — no manual steps, no middleware transformation needed.
Independent filter rules	One subsidiary may push orders to FSM as soon as they are Released; another may prefer to wait until Ready for Scheduling. Each company configures this independently.
Independent code-list mappings	Status codes, service call types, problem types, priorities, and regions can all differ between FSM companies to match local FSM configurations.
Custom routing for complex scenarios	For organisations where plant and order type alone are not enough to determine the target FSM company, a custom BAdI provides full programmatic control.

3. How It Works — The Big Picture

Every time a PM order is released and saved in S/4HANA — on creation or any subsequent
update — the system evaluates whether and where to replicate it to FSM. The steps are:

Step	What happens
1 Trigger	PM order save detected. Replication check begins in the background.
2 Company routing	The order's planning plant and order type are matched against configuration to identify the responsible FSM company.
3 Relevance check	The order's current system status is compared against the configured filter rules. Only orders in a qualifying status proceed.
4 Field mapping	PM order data is translated into an FSM Service Call payload — subject, status, type, priority, region, activities, components, partners, and more.
5 Replication	The payload is sent asynchronously to FSM. FSM creates or updates the Service Call and its Activities accordingly.
6 Response & logging	The FSM response is evaluated and logged in SAP's Application Interface Framework (AIF), giving operations teams full visibility and restart capability.

Note: Why asynchronous? Replication happens in the background via a queue —
it does not hold up the PM order save transaction. Planners experience no delay;
the FSM API call is processed independently after the order is committed in S/4HANA.

4. Step-by-Step Configuration Guide

Configuration lives in two places in SPRO (transaction SPRO)

Multi-company routing (Steps 1–5) is maintained via a single SPRO node that
      opens a view cluster. All sub-views are navigated through the
      Dialog Structure panel on the left-hand side of the screen.

SPRO Node: Service → Integration with Other SAP Solutions → SAP Field Service Management →
Configure Multiple Company Replication
Code-list mappings & region (Steps 6–7) are direct child nodes under
a separate path with no additional grouping:

SPRO Node: Plant Maintenance and Customer Service → Integration with SAP Field Service Management

4.1. Define S/4 FSM Companies

      Create a logical identifier for each FSM company you want to replicate to. This short key
      — for example COMP_NORTH or COMP_SOUTH — becomes the
      master reference that all subsequent configuration links back to:
      FSM account details, plant assignments, filter rules, and code-list mappings all
      reference this identifier.

SPRO: Configure Multiple Company Replication → Dialog Structure:Define S/4HANA FSM Company

4.2. Assign FSM Account & Company Details

      For each S/4 FSM Company ID, enter the technical identifiers from your FSM tenant.
      These are found in the FSM Admin portal under
      Account → Account Information and Account → Companies.

Field	Description	Where to find in FSM Admin
FSM Account ID	Numeric identifier for the FSM tenant account	FSM Admin → Account Information
FSM Company ID	Numeric identifier for the specific FSM company	FSM Admin → Companies → select company → ID field

SPRO: Configure Multiple Company Replication → Dialog Structure: Define S/4HANA FSM Company →Assign FSM Company Details

Note:  RFC destination is shared across all companies: The FSM Account ID
      and Company ID configured here are sent as HTTP request headers and can differ per S/4 FSM
      Company. However, the underlying RFC destination — which defines the FSM
      endpoint URL and OAuth profile — is always read from the global configuration
      ( CRMC_FSM_CONFIG ) and cannot be varied per company, either through the
      multi-company table or through the BAdI. This means all S/4 FSM companies must
      reside within the same FSM tenant — they are separate companies within one
      account, not companies on different FSM endpoints.

4.3. Assign Rule Type to the PM Replication Object

      Specify how the system determines which FSM company a PM order is routed to.
      The rule type is a configuration value that tells the system which routing strategy to
      apply. Two rule types are supported for PM orders:

Code	Name	When to choose it
01	Plant	The target FSM company is determined by the order's planning plant and order type. This is the standard approach and covers the vast majority of customer scenarios.
07	Custom Logic	A custom BAdI implementation determines the FSM company programmatically. Use this only when plant and order type alone are not sufficient — for example, when routing depends on a functional location attribute or a custom partner function. See Section 6 for details.

Set the Replication Object = PM and select the appropriate rule type.

SPRO: Configure Multiple Company Replication → Dialog Structure:Assign Rule Type to Replication Object

4.4. Enable PM Replication per Company

      For each S/4 FSM Company ID, activate PM order replication by adding the
      replication object PM. This acts as a
      per-company master switch — if a company does not have PM enabled here,
      no PM orders will ever be routed to it, regardless of the plant configuration in Step 4.

SPRO: Configure Multiple Company Replication → Dialog Structure:Assign Replication Object Details

4.5. Assign Relevant Plants — Rule Type 01 Only

      For plant-based routing, define which combination of S/4 FSM Company +
      Planning Plant + Order Type should route PM orders to which FSM company.
      This is the core routing table.

Important: This routing configuration is maintained here under the multi-company replication IMG node. It is a separate entry point from the single-company plant filter and must not be confused with it.

S/4 FSM Company	Planning Plant	Order Type	Routes to
COMP_NORTH	1000	PM01	Northern Operations FSM
COMP_SOUTH	2000	PM01	Southern Operations FSM
COMP_SOUTH	3000	PM02	Southern Operations FSM

SPRO: Configure Multiple Company Replication → Dialog Structure: Assign Replication Object Details →Assign Relevant Plants

4.6. Configure Code-List Mappings & Filters

      SAP PM and FSM use different codes for the same business concepts. All configuration
      in this step uses SPRO node:

SPRO: Plant Maintenance and Customer Service →Integration with SAP Field Service Management

Each item below corresponds to a separate child node in this path.

4.6.1. Define System Status to filter Maintenance Order replication

      Configure which S/4 system statuses should trigger or
      block replication for each company and order type. Each subsidiary
      independently decides at which point in the PM lifecycle orders flow to FSM.

Setting	Meaning
Order Status	The S/4 system status that activates this rule — e.g. Released, Ready for Scheduling, Technically Complete
Replication Type 1	Replicate when this status is active → order lands on the Dispatching Board in FSM
Replication Type 2	Block replication when this status is active
Replication Type 3	Replicate when this status is active → order lands on the Capacity Planning Board in FSM

SPRO: Integration with SAP Field Service Management →Define System Status to filter Maintenance Order replication

4.6.2 Configure Mapping for Status Codelist

      Translates S/4 system statuses to FSM Service Call status codes. When multiple
      active statuses match simultaneously, the entry with the
      lowest configured priority number is applied.
      Example: S/4 Released → FSM status –2 (Ready to Plan).

SPRO: Integration with SAP Field Service Management →Configure Mapping for Status Codelist

4.6.3. Configure Mapping for Service Call Type Codelist

      Maps the S/4 order type (e.g. PM01, PM02) to the FSM
      Service Call Type (e.g. Maintenance, Repair, Inspection).
      This determines how work is categorised in FSM and affects which service call
      templates and follow-up workflows are triggered.

SPRO: Integration with SAP Field Service Management →Configure Mapping for Service Call Type Codelist

4.6.4. Configure Mapping for Problem Type Codelist

      Maps the S/4 maintenance activity type (e.g. Electrical, Mechanical,
      Preventive) to the FSM Problem Type. This helps dispatchers instantly
      understand the nature of the job and assign a technician with the right skill set.

SPRO: Integration with SAP Field Service Management →Configure Mapping for Problem Type Codelist

4.6.5. Configure Mapping for Priority Codelist

      Maps S/4 PM priority codes to FSM priority values (HIGH, MEDIUM, LOW). A separate
      Emergency Priority field is also available — when an emergency order
      is processed (identified by its processing context), this value overrides the standard
      priority mapping, ensuring urgent work is immediately visible to the FSM dispatcher.

SPRO: Integration with SAP Field Service Management →Configure Mapping for Priority Codelist

4.6.6. Set Default Business Partner (Customer)

      Defines a fallback customer (Business Partner) per FSM company, used when the PM order
      does not carry a Ship-To party. FSM requires a business partner on every Service Call,
      so this default prevents replication failures for orders that have no customer reference.

SPRO: Integration with SAP Field Service Management →Set Default Business Partner (Customer)

4.6.7. Configure Region

      In FSM, a Region links each Activity to a geographical or organisational
      area, which drives scheduling availability, resource pooling, and address resolution.
      For PM integration, the region code is derived from S/4HANA data and included in
      every Activity sent to FSM. The source of that region code is configurable
      per FSM company, giving each subsidiary the flexibility to align
      the region model to how they have structured FSM.

SPRO: Integration with SAP Field Service Management →Configure Region

5. Controlling the FSM Planning Board

    When a PM order arrives in FSM it lands on one of two planning boards, depending on how
    the filter rule was configured in Step 6. This determines how the dispatcher interacts
    with the work before a technician is assigned.

FSM Board	When it is used	What the dispatcher sees
Dispatching Board	Replication triggered from Released status (Replication Type 1). The order is ready for immediate technician assignment.	Service Call appears directly on the Dispatching Board — the dispatcher can drag and drop it onto a technician's schedule straight away.
Capacity Planning Board	Replication triggered from Ready for Scheduling status (Replication Type 3). The order needs resource-level planning first.	Service Call appears on the Capacity Planning Board for workload balancing and resource allocation before moving to Dispatching.

6. Extensibility

    When rule type 07 (Custom Logic) is configured for the PM replication
    object, the system invokes BAdI CRMS4_FSM_RELV_COMP_DETERM to determine
    which FSM company and account a PM order should be routed to. This gives full programmatic
    control over company routing for scenarios that cannot be handled by plant and order type
    alone.

BAdI: CRMS4_FSM_RELV_COMP_DETERM

Method: DETERMINE_RELVNT_COMP

When to implement

Use this BAdI when the target FSM company cannot be resolved from planning plant and order
type alone. Common examples:

Routing based on a functional location hierarchy — e.g. all orders
under a specific FL node go to a specific FSM company regardless of plant
Routing based on a custom partner function or responsible person on
the PM order
Routing determined by an external system lookup or custom Z-field
Complex multi-level routing logic that changes dynamically at runtime

How it works

    The BAdI is called inside the replication class.
    Before the BAdI is called, any company and account values already resolved by the standard
    plant-based lookup are cleared. This means the BAdI has full responsibility
    for the result — it completely overrides the standard determination.

    The BAdI is retrieved with a filter on replication object PM,
    so a single enhancement spot can hold separate implementations for PM orders, Service Orders,
    Equipment, and other replication objects — each triggered independently without interference.

Interface

Parameter	Direction	Description
IT_RELEVANT_OBJ_ID	Importing (table)	One row per order: • SRVCMGMTFSMREPLICATIONOBJECT = PM • SRVCMGMTFSMRPLCTNOBJID = maintenance order number
CT_RELEVANT_COMP	Changing (table)	Your implementation must populate at minimum: • FSMCOMPANY — target FSM Company ID • FSMACCOUNT — target FSM Account ID

Important: Important: If CT_RELEVANT_COMP is left empty or an exception
    is raised, replication is silently skipped for that order — no error is
    written to AIF. Always ensure your implementation populates at least one row with a valid
    FSM Company ID and Account ID.

7. Monitoring & Error Recovery

    Every replication attempt — successful or failed — is recorded in SAP's
    Application Interface Framework (AIF). This gives operations
    teams complete visibility into what was sent to FSM, what FSM responded,
    and the ability to restart any failed message after the root cause is resolved —
    all without developer involvement.

From the AIF monitor, teams can:

See exactly which PM orders were replicated and when
Inspect the full message payload sent to FSM and the FSM response received
Restart failed messages with a single action — for example after a
missing region in FSM has been created, or a connectivity issue has been resolved
Receive automatic alerts when errors occur, via configurable
recipient groups — ensuring nothing fails silently

AIF Key	Value
Namespace	/FSMPM
ORDER_OUT	bgRFC Interface for PM Order replication to FSM
ORD_CRT_IN	Maintenance Order Inbound on create
ORDER_IN	Maintenance Order Inbound
ORDEROP_IN	Maintenance Order Operation Inbound
CONFIRM_IN	Maintenance Order Confirmation Inbound
Transaction	/AIF/ERR

8. Summary

    Multi-company PM FSM integration enables enterprises to run a unified SAP system while
    keeping each business unit's field service operations fully independent. Here is
    what it delivers at a glance:

Capability	Benefit
Automatic plant-based routing	Each plant's PM orders flow to the correct FSM company without manual steps or middleware logic.
Per-company status filters	Each subsidiary independently decides at which PM lifecycle stage orders are pushed to FSM.
Per-company code-list mappings	Status, priority, service call type, and problem type mappings are fully independent per FSM company.
Flexible region derivation	Region codes can be sourced from the order work center, operation work center, or planner group — independently per FSM company.
FSM planning board control	Orders land on the Dispatching Board or Capacity Planning Board based on the PM process used, with full Phase Model and emergency order support.
Custom company routing (Rule Type 07)	A BAdI provides full programmatic control for complex routing scenarios that go beyond plant and order type.
Full backward compatibility	If no multi-company configuration is present, the system falls back automatically to single-company mode — no migration required.

References

Integrating SAP S/4HANA Plant Maintenance Orders with SAP FSM

What’s New in SAP HANA Cloud – July 2026

2026-07-03T11:29:14.472000+02:00

The Q2 2026 release of SAP HANA Cloud continues to advance our vision of delivering an intelligent, AI-native, and enterprise-scale data platform. This quarter introduces innovations that make it easier to build AI-powered applications, manage large-scale enterprise workloads, simplify database administration, and strengthen security across your data landscape.

From deeper integration with SAP AI Core and new machine learning capabilities, to larger database instance sizes, enhanced data integration, and intelligent administration tools, this release allows you to unlock greater value from your data while reducing operational complexity.

Whether you're building next-generation AI applications, modernizing your enterprise data landscape, or optimizing business-critical workloads, SAP HANA Cloud continues to provide the foundation for secure, scalable, and intelligent data management.

Let's take a look at some of the key innovations introduced with the Q2 2026 release.

Agentic Data Access in SAP HANA Cloud

We're taking another major step toward an AI-native data platform with new capabilities that enable agentic data access in SAP HANA Cloud.

At the core of this innovation is the ability to automatically generate a custom database objects knowledge graph. SAP HANA Cloud scans your database metadata including: tables, views, columns, and their relationships, and automatically builds a semantic representation of your data landscape.

By eliminating the need for manual semantic modeling, this knowledge graph provides a rich foundation for data discovery, reasoning, and AI-driven interactions. It enables both users and AI agents to better understand how enterprise data is organized and connected.

Building on this semantic foundation, we are introducing the Database Object Discovery Tool and the Data Retrieval Tool, available beginning in early July.

Today, working with enterprise data often requires you to understand complex database schemas, identify the right database objects, and manually write SQL queries to retrieve information. With these new capabilities, you can simply describe what they are looking for using natural language.

The Database Object Discovery Tool identifies the relevant database objects and relationships by leveraging the database objects knowledge graph. The Data Retrieval Tool then translates your request into an executable SQL statement and runs it directly within SAP HANA Cloud.

Together, these capabilities dramatically simplify the way we can discover, understand, and query enterprise data, without requiring deep SQL expertise or detailed knowledge of the underlying database schema.

Built on the multi-model foundation and Knowledge Graph Engine of SAP HANA Cloud, these innovations lay the groundwork for a new generation of conversational, agent-driven, and AI-powered data experiences, making it easier than ever to build intelligent applications on enterprise data.

To learn more about the agentic database tools, take a look at Shabana's blog post.

You can also learn how to set them up through this tutorial by @Dan_vL

Natural Language Processing (NLP), Machine Learning and AI Core integration

With the Q2 2026 release of SAP HANA Cloud, we continue to strengthen embedded NLP and Machine Learning capabilities with broader SAP AI Core integration, unlocking access to SAP RPT-1 and LLMs and thus completely new type of AI-driven database applications.

Key highlights as part of the Predictive Analysis Library (PAL) include:

A new function for synthetic data generation using diffusion models, e.g for securing data privacy when training custom AI models
Time Series Forecasting function enhancements like support for lagged regressors with Additive Model Time Series Analysis (aka prophet) and easier time series cross validation using the Unified Time Series procedures for better forecast predictions
Further enhancements include columnar analysis of large data sets using Online Univariate Analysis

The full list of PAL enhancements for SAP HANA Cloud 2026 Q2 is documented here. Additionally, the python Machine Learning client for SAP HANA 2.29 is supporting several new functions (see here) like PCA-based vector dimension reduction or the text tf-idf operator in AutoML.

Key highlights for SAP AI Core integration include:

Remote sources to SAP AI Core now supporting use of LLMs and SAP RPT-1 as standardized and secure gateway for 3rd party LLMs access
Benefit from on-the-fly predictions, without the need to create, train and manage use-case specific ML models by simply utilizing the new AI_TABULAR_PREDICTION SQL procedure to access tabular AI models like SAP RPT-1
Ability to leverage LLM capabilities, directly from the database SQL processing engine, by simply utilizing the new AI_TEXT_COMPLETION SQL function to execute one-shot-tasks like text generation or text summarization based on your text data managed in SAP HANA Cloud, unlocking for completely new type of LLM-driven application scenarios.

These enhancements focus on making tabular AI predictions using custom AI models or semantic data retrieval scenario easier to use and applied to real business application data.

Right-sizing your instance with Performance Class Advisor

Knowing whether your SAP HANA Cloud instance is the right size shouldn't require manual analysis or reactive firefighting. The Performance Class Advisor changes that by continuously monitoring your instance's compute and memory usage and automatically generating right-sizing recommendations every Sunday, without any manual trigger.

You choose a lookback window of 2, 4, or 6 weeks to match your workload patterns, and the advisor checks whether CPU or memory usage has exceeded 80% during that period, if either threshold is breached, a recommendation is triggered. The advisor then calculates the optimal upsized spec, targeting approximately 20% additional capacity and snapping to the nearest valid instance configuration.

In this initial release, recommendations are limited to upsizing only, as downsizing carries higher risk given that short lookback windows may not capture infrequent but critical workload spikes, and that is in our backlog to investigate further. The benefits are threefold: right-sizing guidance based on actual historical workload patterns rather than guesswork; proactive resource management that surfaces capacity pressure before it impacts business continuity, giving you time to act rather than react; and automated weekly insights with zero manual effort — switch it on once, and stay informed from there.

Learn more on SAP HANA Cloud's Intelligent Advisors in this blogpost by @jinheejeong

Automated SQL Plan Management with SQL Plan Advisor

SQL execution performance can fluctuate for various reasons. A common culprit is a change in the execution plan within the SQL Plan Cache, either because a cached plan becomes suboptimal over time, or because an inefficient plan was cached based on the initial parameter sets used during compilation.

To better manage these regressions, SQL Plan Advisor was introduced in QRC 2/2024. It automatically detects degraded query executions by analyzing historical performance statistics stored via SQL Plan Stability. To resolve a performance dip, older, historical plans had to be verified to ensure they performed faster than the currently cached plan. However, this verification and testing process could only be triggered manually.

With QRC 2/2026, this testing process is now fully automated. The system autonomously executes faster historical plans to verify their effectiveness, swapping out the degraded cached plan to seamlessly restore optimal database performance.

Please check out the details in the blog by @Taesuk found here.

Database Administration & Developer Productivity

Import & Export

SAP HANA Cloud Central will soon be adding a new top-level application named Import and Export designed to enable users to quickly complete import and export operations within SAP HANA Cloud. This application provides guided wizards for importing data into a table, exporting data from a table or view, and importing and exporting both catalog objects and SAP HANA deployment infrastructure containers. Supported storage providers include SAP HANA Cloud data lake, Amazon S3, Microsoft Azure storage, and Google Cloud storage. Users can also view the generated SQL for any import or export task directly within the wizard.

Additionally, the export wizard will support the ability to provide a query to further filter the data being exported.

SQL Console

Improved Tab Management
Previously if a SQL console tab was closed accidently, its contents were gone. Users can now restore closed tabs using the Restore Last Closed Tab option in the toolbar. Additionally, tabs can be renamed and reordered, making it easier to stay organized when working across multiple queries at once.

A new search capability is also available from the actions menu, that lets users search across the content of all open tabs enabling a specific query to be quickly located.

Enhanced Syntax Help Panel
The syntax help panel has also received a refresh. Object details are now collapsible, reducing visual clutter when users only need a quick reference. Columns and parameters are also searchable, which allows users to find what they need without scrolling through extensive lists. These columns are now clickable as well – selecting one directly inserts it into the editor.

SQL Results
Users now also have more control within SQL results, which has been enhanced with options to handle how data is displayed and refreshed. Users can customize which columns they want to be shown or hidden and also reorder them in whichever way that suits their workflow. Results can also be re-executed on demand without requiring parameters to be re-entered.

Data Integration (Federation & Replication)

SQL on Files: Apache Iceberg REST Catalog support in SAP HANA Cloud

Direct read-only access to Apache Iceberg tables in object storage, which has been introduced since QRC 3/2025, has offered real-time analytics on Iceberg lakehouses without moving data into SAP HANA Cloud. With QRC 2/2026, it evolves further by supporting Apache Iceberg REST Catalogs, which is how the modern enterprise lakehouses centralize table management, access control, and metadata governance.

Through the new icebergcatalog adapter, SAP HANA Cloud now connects directly to spec-compliant Iceberg REST Catalogs across AWS, Azure, and GCP, bringing enterprise-grade integration to your Iceberg lakehouse with minimal effort. Note that while the adapter is designed to work with any spec-compliant Iceberg REST Catalog, only a defined set of providers is officially certified by SAP per QRC.

To learn more about SAP HANA Cloud's new Apache Iceberg REST Catalog support, take a look at @SeungjoonLee's blog post here.

S/4HANA CDS View Entity replication to SAP HANA Cloud

S/4HANA Federated access was introduced in QRC 1/2024, as detailed in the blog Taking Data Federation to the Next Level: Accessing Remote ABAP CDS View Entities in SAP HANA Cloud. Building on this, QRC 2/2026 introduces support for replicating data directly to SAP HANA Cloud.

CDS view replication allows you to copy data from SAP S/4HANA CDS view entities into local tables within SAP HANA Cloud, enabling fast local analytics without the need for remote federated queries.

Key benefits include:

Lower Latency: Data resides locally, and efficiency is maximized by replicating only changed rows.
Reduced Source Overhead: Impact on the source system is minimized because replication can be scheduled at custom intervals or run entirely on demand.
Flexible Filtering: Data can be filtered by specific rows, selected columns, or both.

You can configure replication via SQL or by using the Data Replication tool in SAP HANA Cloud Central.

To learn more about SAP HANA Cloud’s new S/4HANA CDS View replication, check out @Taesuk ’s blog post here.

Security, Data Protection & Privacy

Post-quantum cryptography (PQC) for Transport Layer Security (TLS) connections

With the Q2 2026 release, SAP HANA Cloud database introduces post-quantum cryptography (PQC) for TLS connections, providing quantum-resistant protection for all data in transit between clients and SAP HANA Cloud databases.

Post-quantum cryptography addresses the "harvest now, decrypt later" threat — where adversaries capture encrypted traffic today with the intent of decrypting it once quantum computers become capable. By enabling PQC now, SAP HANA Cloud ensures that data encrypted today remains protected against future quantum attacks.

Key capabilities include:

Hybrid Post-Quantum Key Exchange

A transparent ML-KEM key establishment negotiated during TLS 1.3 handshakes, combining classical and quantum-resistant algorithms. Enabled by default for all SAP HANA Cloud databases with no customer configuration required.

Full Backward Compatibility

Clients with PQC support (SAP Client using OpenSSL 3.5+, SAP HANA client 2.29+) automatically negotiate the quantum-resistant hybrid exchange. Clients without PQC support safely fall back to classical key exchange with zero disruption to existing applications.

Built-in Observability

New SSL_KEY_EXCHANGE and SSL_SIGNATURE columns in M_CONNECTIONS and M_OUTBOUND_NETWORK_IO system views, enabling administrators to verify PQC adoption per connection and identify clients that need upgrading.

The feature is aligned with NIST post-quantum standards (ML-KEM / FIPS 203) ahead of anticipated regulatory mandates and requires no customer action to activate.

Typical use cases include verifying quantum-safe connection status across the landscape and meeting compliance requirements for post-quantum readiness.

Access Logging & Column-Level Security for SQL Views

SAP HANA Cloud introduces two complementary capabilities for protecting sensitive data: access logging for columns containing sensitive data and column-level security for SQL views. Together, these address two sides of the compliance equation - preventing unauthorized access and detecting all access for audit purposes - enabling compliant direct SQL access to data containing sensitive columns.

The Context

Regulations like GDPR require both prevention of unauthorized access to personal data AND demonstrable accountability for all access. Direct SQL access to HANA databases containing sensitive data requires enforcement and audit trails to meet these compliance requirements.

These two capabilities address this:

Prevent:	Column-Level Security for SQL Views	Ensures unauthorized users cannot see sensitive columns (returned as NULL)
Detect:	Access Logging for Sensitive Columns	Logs who accessed which sensitive columns, when, and on which table (values never logged)

Access Logging

Access logging is activated directly in the table definition using the AUDIT (READ | NONE) syntax. Once columns are marked, read access is automatically reported via the predefined "SAP - column access" audit policy, as no custom policy creation is needed. Both direct and indirect access is reported, including access via views or during procedure execution. The audit log entry includes the schema name, table name, and the list of accessed columns (quoted and comma-separated), while the actual data values and SQL statements are never logged - ensuring the audit trail provides accountability without creating a secondary repository of sensitive data.

Column-Level Security

Column-level security for SQL views provides a dynamic access control mechanism. Columns on SQL views are tagged with DPP classification identifying Sensitive Personal Data, and the authorization model determines which tagged columns are permitted for access. At query execution time, the engine evaluates authorization dynamically – this evaluation is not tied to the current database user but can rely on any information in the session context or other tables. Authorized columns return actual values, while unauthorized columns return NULL. The key design decision is that columns are masked, not omitted - query structure remains stable for all consumers, meaning downstream dashboards, pipelines, and applications continue to function without modification.

Combined Value

Together, these capabilities enable compliant direct SQL access to sensitive data in SAP HANA Cloud. Column-level security ensures users see only data they are authorized to access, while access logging provides auditable evidence of all access events, satisfying both the prevention and accountability requirements of GDPR and similar regulations.
The operational overhead is minimal: DDL-based activation for access logging, a system-managed audit policy, and dynamic authorization evaluation for column-level security - with no duplicate views, no application-layer workarounds, and no custom configuration frameworks required.

Increase in-memory capacity with up to 16 TB and 24 TB Instances on AWS

As enterprise workloads continue to grow in size and complexity, organizations increasingly require larger in-memory database configurations to support mission-critical transactional and analytical applications.
With the Q2 2026 release, SAP HANA Cloud expands its scalability by introducing support for 16 TB and 24 TB database instances on AWS.

These new instance sizes are designed for customers running some of the most demanding enterprise workloads, providing the processing power and memory capacity required for large-scale SAP and custom applications while maintaining the simplicity of a fully managed cloud service.

To ensure predictable performance and guaranteed resource availability, these instances are deployed on dedicated, pre-reserved physical infrastructure that is allocated exclusively to a customer's subaccount within a selected AWS availability zone. The reserved capacity remains available throughout the three-year reservation period, regardless of whether the database instance is running, stopped, paused, or temporarily deprovisioned.

Customers can request these instance sizes directly through SAP HANA Cloud Central by opening an SAP support ticket. Once the requested capacity has been approved and the dedicated infrastructure has been provisioned, the new database instance can be deployed against the reserved resources.

Support for 16 TB and 24 TB instances is currently available in selected AWS regions. For the latest information on supported regions and availability zones, please refer to the SAP HANA Cloud documentation.

Data Lake Innovations

Thin Clone Decoupling for Data Lake Relational Engine

Building on the thin clone capability in SAP HANA Cloud, data lake relational engine, which is designed for creation and deployment of clones of petabyte-scale databases in development and testing environments in just a few minutes, we are introducing thin clone decoupling. Thin clone decoupling promotes a thin clone to a fully standalone SAP HANA Cloud, data lake relational engine instance. Once the decoupling process completes, the instance operates independently, completely detached from the parent instance.

Upon decoupling, backups are enabled on the decoupled instance, making it eligible for disaster recovery scenarios. The decoupled instance can itself serve as a source for creating new thin clones.

 Thin clone decoupling opens a clear path for promoting development or test databases to production-grade instances improving data reliability and integrity.

Innovations on Calculation View features

The calculation view features blog for 2026 QRC2 by @jan_zwickel covers several new calculation view capabilities. Two complementary deployment options help to reduce deployment time and protect privileges: optimized redeployment skips unchanged dependent views instead of dropping and recreating them all, and the new replace option performs in-place replacement so that cross-container privileges are not lost.

On the scalability front, Active/Active read-enabled hints can be set at the individual calculation view level for fine-grained query routing to read replicas. A Join-to-Non-Equi-Join conversion in the context menu eliminates the need to rebuild join logic from scratch when switching from equi joins to non-equi joins. The support of calculated measures executed at query runtime allow defining runtime calculations for MDS Cubes in calculation views. Finally, a new status dialog surfaces the view's connection state, read-only reasons, data classification inconsistencies, and BDC integration status when a calculation view is opened.

Thanks for taking the time to explore the What’s New in SAP HANA Cloud on Q2 2026 innovations!

If you’d like to go deeper into the technical details of the Q2 2026 release, we recommend visiting the What’s New Viewer in the technical documentation. It provides a comprehensive overview of the full release scope. To stay informed about upcoming innovations, announcements, and best practices, follow the SAP HANA Cloud tag.

You can also find our latest blog posts by searching for the #whatsnewinsaphanacloud hashtag.

If you missed earlier What’s New webinars, you’ll find recordings of past sessions and upcoming events in our YouTube playlist. Our What’s New webinar covering the Q2 2026 innovations will be posted on this playlist very soon. You can also download the slides from the webinar here.

Do you have questions about SAP HANA Cloud or want to share your thoughts on the new features?
Join the conversation in the SAP HANA Cloud Community Q&A or leave a comment below. We’d love to hear from you!

Code Connect 2026: Final Info Before We Kick Off!

2026-07-06T11:02:20.615000+02:00

Code Connect 2026 is just around the corner! From July 13–16, 2026, the SAP developer community will gather in St. Leon-Rot, Germany – onsite and online.

Here’s everything you need to know before we get started.

We Are Fully Booked!

All onsite tickets are fully booked - thank you for the amazing interest!

If you couldn’t secure a ticket:

Join the waiting lists on Code Connect 2026 in case seats become available.
Follow selected sessions via live stream or Microsoft Teams link.

Even if you're not onsite, you can still be part of Code Connect. Selected sessions will be streamed live, and recordings of some sessions will be available afterwards. Check back soon for details.

UI5con (July 14)

Main stage sessions will be live streamed on YouTube.
Check the agenda to see which sessions are streamed.

re>≡CAP (July 15)

Main stage sessions will be broadcasted.
Some sidetracks (W1/W2) can be attended via Microsoft Teams link.
Check the agenda to see which sessions are broadcasted or available via Microsoft Teams link.

HANA Tech Con (July 16)

The links will be announced on the event day.

The Agendas Are Live

The full program is already available - time to plan your schedule!

Check-In opens at 8.00 AM every day. Please bring the QR code with you that you can find in your ticket.

July 13 – Code Jams & Community Meetup

Hands-on Code Jams:

OpenUI5
CAP
AI Agents

Informal pre-event meetup (no registration needed):
Ihle Besen, Höfe am Sträßel 3, 69231 Rauenberg
5:00 PM CEST

July 14–16 – Main Conference Days

Explore all agendas:

July 14: UI5con
July 15: re>≡CAP
July 16: HANA Tech Con

On July 14 also the HANA AI CodeJam takes place.

Location

Code Connect takes place at:

SAP-Allee 27
68789 St. Leon-Rot, Germany

Find detailed information on directions, parking, and public transport here.

Final Tips

Bookmark your favorite sessions in advance
Arrive early for popular sessions (rooms fill quickly!)
Bring your laptop for Code Jams and hands-on sessions/ workshops
Don’t miss the networking moments - some of the best conversations happen in between sessions
Follow the agendas closely for last-minute updates

See You Soon!

We’re looking forward to an inspiring week of learning, sharing, and connecting.

See you at Code Connect 2026!

Why Stock Fields Return Zero in Custom CDS Views on MARC - and How to Resolve It

2026-07-08T11:22:05.761000+02:00

Why Stock Fields Return Zero in Custom CDS Views on MARC - and How to Resolve It

I was building a custom CDS view on the MARC table (Plant Data for Material) to extract data into SAP Datasphere using Change Data Capture (CDC) for delta loads.

After activating the view, I checked the data and found something odd. The field TRAME (Stock in Transit) had a proper value in the MARC table, but in my CDS view the same field was completely empty.

To give a concrete example, for one material and plant the MARC table showed TRAME = 50.000, but my CDS view showed TRAME = 0.000 for the same key. All the master data fields were perfectly fine. Only the stock field was wrong.

That single clue — master data correct, stock field zero — is what pointed me to the real cause.

Where the data actually lives in S/4HANA

In the older SAP ECC system, stock quantities were physically saved in many tables, and the same figure was often repeated in several places. This created redundancy and slowed things down.

In S/4HANA, SAP redesigned this part of the system with the New Simplified Data Model (NSDM). The idea is straightforward: all stock movements are written into a single table called MATDOC, and the stock figures are calculated when you ask for them instead of being stored everywhere.

Because of this change, MARC became a so-called hybrid table. It still physically stores the material master and planning data, but the stock quantity fields are no longer filled in the table itself. Fields like TRAME, UMLMC, GLGMG and BWESB are now worked out on the fly from MATDOC whenever they are read.

So in S/4HANA, the TRAME column inside the physical MARC table is basically empty. The real stock-in-transit figure is calculated from MATDOC only at the moment it is needed.

Why SE16 showed the value but my CDS did not

This is the most important point of the whole story. SE16 and my CDS view were reading the same table through two completely different paths.

When you open MARC in SE16, the read goes through the normal application layer. SAP automatically redirects that read to a proxy object behind MARC, which performs the MATDOC calculation and returns the correct TRAME value. That is why SE16 happily showed 50.000.

My CDS view, on the other hand, was written as select from marc. A CDS view runs straight on the database and reads the physical MARC table directly. It never passes through the redirect, so it picked up the empty physical column and returned 0.000.

In one sentence:

SE16 reads MARC through the proxy and gets the calculated value. A CDS that selects directly from MARC reads the raw table and gets nothing. That difference in the read path was the entire reason the data "did not come."

My first fix — and why it failed

My first idea was simple. If the proxy returns the correct value, why not read from the proxy instead of the table? So I changed the source of my view to the proxy object:

Before (TRAME comes as zero):

@AbapCatalog.sqlViewName: 'ZCDS_MARC_DEX'

@AbapCatalog.compiler.compareFilter: true

@AbapCatalog.preserveKey: true

@AccessControl.authorizationCheck: #NOT_REQUIRED

@EndUserText.label: 'Plant Data for Material'

@Metadata.ignorePropagatedAnnotations: true

@analytics.dataExtraction:{enabled: true,

delta.changeDataCapture:{mapping:[

{table:'marc',role:#MAIN,

viewElement:['Matnr','Werks'],

tableElement:['matnr','werks']}]}}

define view ZCDS_MARC_DEX_CDC as select from marc

{

key matnr as Matnr,

key werks as Werks,

pstat as Pstat,

lvorm as Lvorm,

bwtty as Bwtty,

xchar as Xchar,

trame as Trame,

... remaining MARC fields ...

After (TRAME correct and CDC activates):

@AbapCatalog.sqlViewName: 'ZCDS_MARC_DEX'

@AbapCatalog.compiler.compareFilter: true

@AbapCatalog.preserveKey: true

@AccessControl.authorizationCheck: #NOT_REQUIRED

@EndUserText.label: 'Plant Data for Material'

@Metadata.ignorePropagatedAnnotations: true

@analytics:{

dataExtraction.enabled: true,

dataExtraction.delta.changeDataCapture:{

mapping:[

{

table:'marc',

role:#MAIN,

viewElement:['Matnr','Werks'],

tableElement:['matnr','werks']

}]

}

define view ZCDS_MARC_DEX_CDC as select from nsdm_e_marc

{

key matnr as Matnr,

key werks as Werks,

pstat as Pstat,

lvorm as Lvorm,

bwtty as Bwtty,

xchar as Xchar,

trame as Trame,

... remaining MARC fields ...

The only real change is the data source: from marc to nsdm_e_marc. The CDC mapping still refers to the physical table marc

This is not only a MARC problem

The same behaviour happens with all NSDM stock tables in S/4HANA. If your CDS reads stock fields straight from any of these, you can get zeros:

MARC – plant stock fields (TRAME, UMLMC, GLGMG, BWESB)
MARD – storage location stock
MCHB – batch stock
MKOL – special / consignment stock
MSKA – sales order stock
MSKU – customer special stock
MSLB – stock with vendor (subcontracting)
MSPR, MSSA, MSSQ – project and sales order stock totals
MSTB, MSTE, MSTQ – stock in transit tables

A simple rule of thumb: if a table held stock quantities in ECC, in S/4HANA those quantities are now calculated, and a direct CDS read will return zero. Use the table's proxy instead.

How to find the correct proxy in your own system

You do not have to guess the name. For any table (example: MARC):

Open the table in SE11.
Choose menu Extras → Replacement Object to see the assigned proxy (for MARC it is NSDM_E_MARC).

Example – "MARC" Replacement Object

Conclusion

What first looked like a bug in my CDS view turned out to be normal S/4HANA behaviour. Under the New Simplified Data Model, stock quantity fields are no longer stored in tables like MARC — they are calculated from MATDOC only when they are read. SE16 shows the correct value because it goes through the replacement object, while a CDS view that reads the table directly picks up the empty physical column and returns zero.

The fix itself is small but important: source the CDS view from the replacement object (for MARC, NSDM_E_MARC) instead of the base table. After that one change, TRAME returned the correct value. And because this is standard NSDM behaviour, the same approach works for every stock table in the family — whenever a stock field comes back as zero, the first thing to check is whether you are reading the base table directly instead of its replacement object.

The bigger lesson I took away is to always confirm where a field's data actually lives before building a CDS view on top of a table. A quick look at SE11 → Extras → Replacement Object tells you whether a table is a hybrid table and which object you should really be reading from. That single check can save a lot of confusing "the value is there in SE16 but missing in my view" situations.

Calculation View Features of 2026 QRC2

2026-07-08T14:50:53.797000+02:00

Within the time frame of 2026 Q2, several new calculation view features have been released in SAP Business Application Studio when connected to SAP HANA Cloud database QRC2. Some of these features are highlighted below. You can find examples that illustrate the individual features here. An overview of features of other releases can be found here.

Optimized Redeployment

When a calculation view is redeployed in a stacked scenario, all dependent objects in the same HDI container are normally dropped and sequentially recreated. This default behavior avoids cascading revalidations but comes with a cost: privileges on dependent objects are temporarily, or in cross-container scenarios potentially permanently, revoked, and the full recreate cycle adds significant deployment time.

Optimized redeployment addresses this. Instead of dropping all dependents upfront, a consistency check determines which dependent views are still valid after the change. Views unaffected by the redeployed calculation view are kept as-is and skipped entirely. This reduces both the time spent recreating unaffected views and the privilege reassignment overhead.

To enable optimized redeployment for calculation views, add the following parameter to the hdi-deploy invocation in package.json:

"start": "node node_modules/@sap/hdi-deploy/deploy.js --parameter com.sap.hana.di.calculationview/optimized_redeploy=true"

A global parameter (optimized_redeploy=true) is also available and activates the behavior for all HDI object types that support it.

Replace Instead of Drop and Recreate During Redeployment

By default, calculation views are dropped and recreated during redeployment. Dropping a view revokes all privileges associated with it. Privileges defined in HDI roles of the same container are automatically regranted at the end of deployment, but direct privileges held by roles outside the current HDI container are permanently lost.

The new replace option substitutes the drop-and-recreate cycle with an in-place replacement. Because the object is never dropped, existing privileges are preserved throughout deployment. The benefit is most significant when combined with optimized redeployment: without it, dependent views are dropped before the root view is replaced, so they never benefit from the replace logic. With both options active, the replace strategy also applies to dependent views.

To enable the replace behavior, pass the following parameter:

"start": "node node_modules/@sap/hdi-deploy/deploy.js --parameter optimized_replace=true"

Combining optimized_replace=true with optimized_redeploy=true gives the strongest deployment time and privilege preservation benefit.

Active/Active Read-Enabled Hints

In an Active/Active (Read-Enabled) setup, query routing hints can now be configured at the individual calculation view level. This gives fine-grained control over whether a query is directed to the primary system or the read replica, allowing workload to be distributed and overall throughput to be increased.

Hints are evaluated only on calculation views that are directly referenced in the query.

Switching from a Join Node to a Non-Equi Join Node

A Join node can now be converted directly to a Non-Equi Join node via the node's context menu, without needing to manually rebuild the join logic.

During conversion you can choose how the resulting join condition is expressed: either graphically, based on the column display,

or as an explicit join expression.

This simplifies the refactoring of join logic and reduces manual rework. Note that features not supported by Non-Equi Join nodes, such as dynamic joins, text joins, and filter expressions, are removed automatically during the conversion.

Calculation View Status Dialog

When opening a calculation view with certain properties, a status dialog now appears and reports details about the current view state. Where applicable, the dialog also offers direct actions to resolve issues, for example, prompting you to log in to Cloud Foundry when no active database connection is found.

The dialog covers four categories:

Read-only mode: reasons why the calculation view was opened in read-only mode
Database connection: current connection status to the database
Data classification inconsistencies: detected mismatches in the data classification setting
BDC integration: whether the calculation view is used with BDC integration mode

Calculated Measures in MDS Cubes

Calculated measures can now be added to MDS Cubes and are evaluated at query runtime. This makes it possible to execute calculations at query runtime.

If a calculated measure cannot be translated into a valid MDS formula, deployment fails with a corresponding error message.

Connecting Two SAP CAP Projects Without Duplicating Your Data

2026-07-08T22:32:55.964000+02:00

There's a problem that comes up on almost every multi-project SAP BTP engagement, and I've seen teams solve it in some really messy ways.

You have two CAP projects. One of them — let's call it Project A — owns a set of shared constants, configuration parameters, maybe a job run log. Project B needs to read that data. So what do people do? They copy the table. Or they create an API. Or they hardcode values that really shouldn't be hardcoded.

All of these work. None of them are clean.

The proper solution is HDI cross-container synonyms. Once it's set up, Project B can query Project A's HANA tables directly — same SQL, same CAP service code, no replication, no drift between environments. It looks and feels like a local table. It just happens to live in someone else's HDI container.

I put together a Tech Bite on this recently and figured it's worth writing up properly, because the documentation is scattered and the first time you set it up you will almost certainly hit at least one of the three errors I mention at the end.

The thing nobody explains first: why it's complicated at all

HDI containers are isolated. That's the point of them — each CAP project gets its own schema, its own deploy lifecycle, its own access controls. But that isolation also means Container B can't just say "I want to read from Container A's schema" — because the schema name is dynamically assigned at deployment time. You can't hardcode it.

So SAP's solution is a User-Provided Service, or UPS. It's a simple Cloud Foundry construct — basically a key-value store with no runtime component — that carries the schema name of Project A. You register it with the -t hana tag, declare it in Project B's mta.yaml, and the HDI deployer picks it up during deployment and injects the correct schema wherever you've referenced it.

That's it. That's the whole trick. Everything else — the synonym files, the config files, the grants — is just plumbing on top of that core idea.

What you're actually building in Project B

Once you understand what the UPS is doing, the rest makes sense. You need four types of files:

.hdiconfig tells the deployer which plugins to use. You need two of these — one in db/src/ and one in db/cfg/. It's a small JSON file, easy to get wrong by forgetting one of the two locations.

.hdbsynonym is where you define the local alias. So instead of referencing PROJECT_A_SCHEMA.CONSTANTS_TABLE (which you can't hardcode anyway), you just write CONSTANTS_TABLE and map it to the actual technical object name in Project A. This lives in db/src/.

.hdbsynonymconfig is the file that connects the synonym to the UPS. This is what makes the schema resolution dynamic. It lives in db/cfg/ — deliberately separate from db/src/ to avoid deployment conflicts. The key thing here is that the value you put in schema.configure must start with exactly the same string you used as the key in mta.yaml. More on this when I get to the errors.

.hdbgrants is the access control piece. Project B's container needs to be explicitly granted a role from Project A. That role needs to already exist over in Project A — it's not something you create in Project B. Your Project A team needs to have a role set up that grants SELECT on the tables you need.

The setup, briefly

On the Cloud Foundry side, you create the UPS once:

cf create-user-provided-service ProjectA_UPS \
  -p '{"schema": "YOUR_PROJECT_A_SCHEMA"}' -t hana

Then in Project B's mta.yaml, you declare it as an existing service resource and bind it to the db-deployer module under SERVICE_REPLACEMENTS:

- name: ProjectA-UPS-resource
  group: SERVICE_REPLACEMENTS
  properties:
    key: ProjectA_UPS
    service: ~{service-name}

Your synonym config then references it like this:

"schema.configure": "ProjectA_UPS/schema"

And once everything deploys, your CAP service code doesn't need to know any of this happened. You just query it:

const db = await cds.connect.to("db");
const results = await db.run(
  `SELECT * FROM "CONSTANTS_TABLE" WHERE "PARAM" = ?`, [value]
);

Clean. No different from querying a local table.

The three errors you will probably hit

I'm not going to pretend this always works first time. Here's what goes wrong most often:

"synonym config refers to unknown service replacement" — This one is almost always a key mismatch. The string you put as key in mta.yaml and the prefix before /schema in your .hdbsynonymconfig need to be identical. Character for character. Check both files side by side.

"insufficient privilege" — The role you referenced in .hdbgrants doesn't exist in Project A, or it exists but doesn't include SELECT on the tables you're trying to reach. You'll need to go back to whoever owns Project A and check what roles are actually deployed there. HANA DB Explorer is your friend here.

"object not found" — The object name in your .hdbsynonym is wrong. The technical name of a table in HDI usually follows a namespace pattern with underscores replacing dots — something like HR_HTR_UTILITY_OBJECTS_CONSTANTS_TABLE. The only reliable way to find the exact name is to look it up directly in HANA DB Explorer under Project A's schema.

One thing worth knowing for local development

When you run cds watch locally, you're using SQLite — there's no HDI container, no synonym. So you need a workaround for local testing.

The simplest approach is to create a CDS entity with @CDS.persistence.exists that mirrors the external table's structure, and seed it with a CSV file. It won't be connected to Project A's live data, but it lets you develop and test the rest of your logic without needing a full BTP deployment every time.

Worth the setup

The first time you wire this up it feels like a lot of moving parts. And honestly, it is. But once it's done, it just works — and it works cleanly. No sync jobs, no API calls for what is essentially a config lookup, no risk of the two sides drifting apart over time.

If your project has shared reference data living in another team's HDI container, this is the right way to access it.

Happy to answer questions in the comments if you hit something I haven't covered here.

#SAP #SAPCAP #SAPHANA #BTP #SAPDevelopment #HDI #CloudFoundry #PwC

EXT4 File System Change to XFS File System in SAP HANA Database.

2026-07-13T06:46:28.542000+02:00

After reading this post, please check your HANA default File System type. If it is EXT4, please follow this post to change it to XFS.

because HANA does not supported EXT4 File System.

My Operating System is Linux Enterprise Server.

df -hT command to check File System Type in Linux.

Overview

XFS is designed to give fast performance and handle big data smoothly and It is a high-performance file system used mostly in Linux. XFS File System is easy to understand , High performance and Reads , writes data very fast.

in SAP/HANA environments, XFS is often used for

/hana/data
/hana/log
/hana/shared

Below supported filesystems.

GPFS
MPFS*
NFS
OCFS2*
XFS
ext3*
NFS4

Where XFS is used?

1 Linux servers
2 SAP systems (like HANA environments)
3 Databases
4 Cloud storage
5 Backup systems

EXT4 vs XFS Comparison

Feature	EXT4	XFS
Type	General-purpose file system	High-performance file system
Best For	Small to medium files	Large files and big data
Performance	Good for normal workloads	Excellent for heavy workloads
Scalability	Limited compared to XFS	Very high (handles TBs easily)
File Size	Supports large files	Supports very large files efficiently
Speed	Good	Faster for large data operations
Journaling	Yes	Yes
Recovery	Easier recovery tools available	Recovery is more complex
Usage	OS, apps, general storage	Databases, SAP, large storage systems
Default Use	Common default in Linux	Used in enterprise environments

Team Requirement.

1. SAP Basis Team
Main owner of the activity

Plan downtime and activity steps
Stop & start SAP Application and HANA system
Validate system after change
Coordinate with all teams

2. OS / Linux Team
Responsible for file system change

Create new filesystem (XFS)
Format disks using mkfs.xfs
Mount new file system
Update /etc/fstab
Set correct permissions

3. Backup Team
Ensures data safety

Take full HANA backup before change
Provide restore support if needed

Prerequisites.

1. Full System Backup (Mandatory)

Take complete HANA backup (data + log)
Also take OS-level backup if possible.

2. Downtime Planning

File system change requires system downtime
Inform business/users and schedule maintenance window.

3. Check Current File System Type.
df -hT

4. Stop SAP Application and HANA DB Server.
HDB stop
Ensure all HANA services are stopped.

Step 1

I am changing here 3 File System Type.

/hana/shared

/hana/data

/hana/log

We can see here ext4 file system showing.

Step 2

Run this command ------zypper install xfsprogs

What is xfsprogs?

xfsprogs to create, manage, check, and repair XFS file systems on Linux.

xfsprogs has been installed.

Step 3

Take the backup of that File System which is you want to change. So i have taken backup of Dir , Files , and all other things which is contain in below File Systems.

/hana/shared

/hana/log

/hana/backup

Step 4

Now Stop the ABAP Application.

Step 5

Now stop Tenant DB from Studio.

ALTER SYSTEM STOP DATABASE SID

Step 6

Now Stop HANA DB

Step 7

Check the Process after stop HANA DB

HDB info

HANA DB Stopped

Step 8

Run this command umount /dev/xvdd

Target is busy so run this command------à fuser -km /hana/shared

Again, run this command------à Unmount /dev/xvdd

Step 9

Now run lsbk command for checking the /hana/shared File System unmount or not.

lsbk

We can see in above screenshot xvdd /hana/shared its unmount here.

Step 10

Now run this command--- sudo mkfs.xfs -f /dev/xvdd

(for formatting existing partition having different filesystem) its completed.

Step 11

Now change the File System Type. Go to /etc/fstab

Cat /etc/fstab you can see here /hana/shared is ext4

Now open in vi /etc/fstab and change from ext4 to xfs and save :wq!

I red marked under line which is contain ext4 File system now as default.

Step 12

Now run this command-----à mount -av its done.

Step 13

Step 14

Step 15

Now change fstab file from ext4 to xfs

Vi /etc/fstab

Step 16

mount -av for checking the mount point

Step 17

Copy again all Data in original location and create symbol link.

Cd /usr/sap/HDP

ln -s /hana/shared/HDP/HDB03 /usr/sap/HDP

Step 18

After creation link Start the HANA DB.

HDB start

Step 19

Now start Tenant DB from Studio. Tenant DB automatically started when HANA DB started if not started we have to start to manually.

ALTER SYSTEM START DATABASE H4P

Step 20

Now start Application Server.

Run this command df -hT to see File system type.

We have xfs File System now.

Conclusion.

Changing from EXT4 to XFS in HANA is recommended to achieve better performance and handle large data efficiently.

Use XFS for HANA systems because it gives better speed and handles large data more efficiently than EXT4.

for Better understanding check this SAP Note 2972496 - SAP HANA Filesystem Types

Please keep this in mind when you are planning to install HANA DB. First check File system Type.

Thanks

SSL in HANA Cockpit

2026-07-13T09:04:02.734000+02:00

SSL Configuration in SAP HANA Cockpit.

SAP HANA Cockpit is a primary administration and recommended tool to manage SAP HANA databases. It provides some additional features and steps that are not available in HANA Studio.

Purpose.
This blog describes the steps to configure SSL for the SAP HANA Cockpit.

Overview: SSL Configuration for SAP HANA Cockpit.

Secure Sockets Layer (SSL) configuration for SAP HANA Cockpit is essential to ensure secure and encrypted communication between users (browsers) and the HANA Cockpit system.

Key Purpose.

Protect sensitive data from unauthorized access.
Ensure secure login and data transmission.

How It Works.

SSL uses digital certificates to encrypt communication.
The SAP HANA Cockpit is configured to use HTTPS instead of HTTP.
Certificates are issued by a trusted Certificate Authority (CA) or created internally if you have SSO Server in your environment.

High-Level Steps.

HANA Cockpit Should be installed in your environment.
Technical Communication User should be created.
SYSTEM and TENANT DB must be added in Cockpit.
Generate SSL certificate from OS level with sidadm user.
Sign certificate with your CA authority or you can sign self if SSO Server in your environment.
Import certificate into HANA XSA keystore.
Configure HTTPS settings in HANA Cockpit.
Restart Cockpit services to activate SSL.
Access Cockpit using https://:

Benefits.
Secure browser access.

Prerequisites.

HANA Cockpit Should be installed in your environment.
Sign certificate with your CA authority.
SSO Server installed (Optional)

Team Requirements.

Basis Consultant will install Cockpit and Configure SSL.

Certificate Authority will Sign Certificate.

Now We are going to Configure SSL in HANA Cockpit.

Step 1

Launch HANA Cockpit. We can see in Green Color Not secure coming in HANA Cockpit URL.

Step 2

Run env for checking the sec dir path

Go to this path ---> /usr/sap/D1C/HDB00/ and take backup of sec dir.

Step 3

Backup has been taken with sec_bkp_21_05_2021 name

Step 4

Now generate the pse and csr name. I am generating here with this name domain.pse and domain.csr

Now run below command.

sapgenpse gen_pse -p domain.pse -.r domain.csr -k "GN-dNSName:FQDN.com" -k "GN-dNSName:hostname" "CN=FQDN.com, OU=IT,

Step 5

Now check ls –ltr and see domanin.pse and domain.csr file generated. in /usr/sap/dic/HDB00/hostname/sec

Step 6

Now open domain.csr file for checking the certificate. Copy this Certificate and Sign it from your CA Authority or SSO Server.

We have our SSO Server for signing the certificate.

I am login in my SSO Server.

Now login in SSO Server.

Step 7

Go to Certificate Management--> Sign certificate requests and paste that certificate.

Click on Show Certificate Request.

Step 8

Click on Sign Certificate and after Sign copy the Certificate

Step 9

Step 10

Now create one file with domain.p7b and paste Signed certificate in this file.

/usr/sap/SID/HDB00/Hostname/sec

Step 11

I pasted Singed Certificated in domain.p7b file.

Step 12

Now import the certificate with below command.

sapgenpse import_own_cert -p domain.pse -c domain.p7b

Certificated imported Successfully.

Step 13

Now we need to set certificate with domain. What domain we have run xs domains command for checking the domain name. We have only one domain.

Before set the certificate run this command for checking the certificate status. xs domain-certificates

We have no certificate now.

Step 14

Now run this for set the certificate xs set-certificate host --pse domain.pse

Step 15

Certificate done now restart the XSA from XSA restart command.

Step 16

Now check again XSA Domain Certificate xs domain-certificates we can see certificate with signed.

Now check the https URL from xs version command.

You can see hana-cockpit URL showing https://hostname:51026

Step 17

Now run this command XSA diagnose for checking the issue in system.

Now issue coming all is ok.

Step 18

Now run this command for open the Cockpit with ----> https://hostname:51026

HANA Cockpit SSL has been completed.

Conclusion

SSL in SAP HANA Cockpit makes the system safe by protecting data between the user and the system.
It allows access using HTTPS, which improves security and reliability.

SAP HANA Cloud release June 2026 Round-up

2026-07-15T16:05:19.094000+02:00

Dear SAP HANA Cloud Enthusiasts,

We are excited to share a collection of the latest videos, blog posts, and resources highlighting the SAP HANA Cloud Q2 2026 release.

	What’s New Teaser Explore the latest innovations in SAP HANA Cloud with Lead Product Manager Thomas Hammer, as he shares his top highlights from the newest release in this engaging teaser. Watch it now on YouTube.
What’s New blogpost Intrigued by the teaser? Explore our "What’s New in SAP HANA Cloud in June 2026" blogpost for an in-depth look at the innovations and find valuable links to further demos and content. Read it here!
	What's New Webinar Prefer watching over reading? Our 'What’s New' webinar is just for you! Join our Product experts for an in-depth view of the latest features. Available to watch anytime here!

Don’t miss out on all the content and remember to follow us in the SAP HANA Community.

Remember to check our content following the # whatsnewinsaphanacloud tag: here

Don’t forget to subscribe and follow SAP HANA Cloud on YouTube to always stay up-to-date regarding the most recent innovations in SAP HANA Cloud.

All the best,

Andrea on behalf of the SAP HANA Cloud team

#SAP HANA Cloud, SAP HANA database #SAP HANA Cloud

#whatsnewinsaphanacloud

Building Custom AI Agents with SAP Joule Studio: A Practical Guide Part-1

2026-07-20T13:23:44.641000+02:00

Introduction

Joule is already available in SAP Launchpad for many users, and it is great for broad questions.
My challenge started when business users asked for operational actions, not guidance.

A user asked:
“Show all blocked sales orders for customer 17100001 and remove the delivery block for order 487.”

I am unable to directly retrieve or display information on open sales orders due to system limitations. However, I can guide you on how to use the 'Sales Order - Query' to access this information manually. Would you like me to provide instructions on how to do this?

Out of the box, Joule gave a helpful explanation, but it did not execute the business action.
So I built a custom agent in Joule Studio that could read and update sales orders in SAP S/4HANA through OData APIs.

The Two Building Blocks: Skills & Agents

Everything in Joule Studio revolves around two core concepts:

1. Skill — A Specific Task

A skill is a single, focused capability. Think of it as one action your agent can perform. It could be:

A CRUD operation (Create, Read, Update, Delete)
A process or automation
A condition check
Launching another Joule skill
Each skill does one thing well. For example:
- Read all sales orders
- Update delivery block on a sales order
- Create a new sales order
- Delete sales order.

2. Agent — The Orchestrator

An agent is the brain that holds multiple skills together. It decides when to use which skill based on what the user asks. An agent can even call other agents — making it possible to build complex, multi-step workflows.

Anatomy of an Agent
When you create an agent in Joule Studio, you'll work with several important configuration areas:

Expertise & Instructions

Expertise — Tell the agent what domain it specializes in. Is it for HR? Sales? Procurement? This helps the agent understand its boundaries.
Instructions — This is where the magic happens. You're essentially writing a playbook for the agent:
1. What to do and what not to do
2. How to format responses
3. When to trigger which skill
4. Rules and guardrail

Additional Context — Common abbreviations, company-specific terminology, or any contextual information the agent might need to understand your business language.

Model Settings
You get to choose your LLM provider:

Anthropic
OpenAI
Google
MistralAI

Enable Backup LLM Provider. This sets up automatic failover — if your primary provider is slow or unavailable, the backup kicks in automatically, keeping your agent running without interruption.

MCP Servers
Add MCP (Model Context Protocol) Servers to give your agent access to additional tools and external capabilities.

Tools
Add tools that provide the agent with additional context, system data access, or the ability to perform actions.

calculator
joule skill
joule agent
Documents(Document Grounding)

Agent Output

Define how the output should be formatted:

Markdown
Text
Data Type
JSON

What I Built (Actual Implementation)

I implemented a Sales Order Assistant agent for a finance and sales operations scenario.

Scope of the agent:

Read sales orders with filters (customer, status, billing date, block flags)
Update delivery block on a specific sales order
Return a table-style summary for business users
Refuse to answer if live data cannot be read

Technical stack:

Joule Studio agent
3 custom skills (GET, PATCH, POST)
SAP S/4HANA OData service: API_SALES_ORDER_SRV
Destination-based connectivity in test environment
Primary + backup LLM provider enabled

Step 1: Skills I Created

I separated skills by operation so tool selection remained predictable.

1. Read Sales Orders (GET)
Purpose: Retrieve sales orders and basic status fields.

2. Modify Sales Order (PATCH)
Purpose: Update delivery block and selected editable fields.

3. Create Sales Order (POST)
Purpose: Create a new order for approved scenarios.

Why this helped:
When I initially combined read and update into one “do everything” skill, the agent often chose the wrong operation. Splitting skills reduced tool-calling errors significantly.

Step 2: Agent Instructions I Actually Used

The single biggest improvement came from strict instructions.

Key rules I configured:

1. Always call Read Sales Orders before any status answer.
2. Call Modify Sales Order only when user intent is clearly an update.
3. Never generate order numbers, dates, or statuses without API output.
4. On 4XX/5XX, return a clear business-safe error message and next step.

Response format:

Always output a compact table for list queries.
Always include order ID, customer, billing date, and status.
Flag risky records: overdue billing, missing assignment, missing reference.

What changed after this:
Before strict rules, I saw occasional “plausible” but unverified responses. After adding mandatory tool-use rules, those stopped.

Step 3: Real Test Cases and Results

I tested using business-like prompts.

Test prompts:

“Show all blocked sales orders for customer 17100001.”
“Remove delivery block on order 500001234.”
“List overdue orders with missing assignment.”

Observed behavior:

Read queries: agent called GET skill, then summarized correctly.
Update queries: agent called PATCH skill with target order.
Failure case (invalid order): agent returned API error context and suggested verification steps.

One practical lesson:
If the API payload is too large, response quality drops. I reduced returned fields to only what users need and got more stable answers.

These were the most useful implementation learnings :

1. Keep skills narrow and explicit
Broad “multi-action” skills increase wrong tool selection.

2. Put tool-calling rules at the top of instructions
Priority placement improved consistency.

3. Add business-safe refusal behavior
If data retrieval fails, the agent must refuse to guess.

4. Minimize API response payload early
Too many fields create noisy reasoning and weaker summaries.

5. Add backup LLM provider, but validate output style
Failover worked, but I had to align formatting instructions across models.

6. Test with ambiguous prompts
Examples like “fix this order” forced me to add clarification logic before updates.

Execution Trace: What Happens Under the Hood (From My Test Runs)
For a prompt like “Show blocked orders for customer 17100001”:

1. Agent starts and loads instructions/context
2. Intent classified as data retrieval
3. GET skill called with filters
4. Raw response compressed
5. Agent applies formatting + risk flags
6. Final response returned as table

For an update prompt:

1. Agent detects action intent
2. Validates target order context via read
3. PATCH skill executes update
4. Agent confirms changed field and status

Real-World Example: Sales Order Assistant
Let me walk you through a practical example. My requirement was to build an agent that can:

Handle natural language queries like *"Show all open orders for customer X"* or *"Remove delivery block on order Y"*
Provide contextual insights (customer credit status, expected delivery dates)
Suggest corrective actions and guide users through SAP Fiori apps

Step 1: Pick Your API

I went to the SAP Business Accelerator Hub and chose the standard OData service: `API_SALES_ORDER_SRV/`

Step 2: Create Skills

I built three separate skills — one for each operation:

Skill	Operation	Purpose
Read Sales Orders	GET	Fetch all sales orders
Update Sales Order	PATCH	Modify fields like delivery block
Create Sales Order	POST	Create a new sales order

The GET skill is that it retrieves all sales orders, but the agent processes the response based on your question. Ask for a specific customer? It filters and gives you only that data — not the entire list.

Step 3: Configure the Agent

Here's an example of how I set up the expertise and instructions:

Expertise:

You are an SAP Sales Order Assistant. Your expertise includes:
- Retrieving sales order details from SAP S/4HANA using OData services
- Explaining order status, delivery dates, and pricing information
- Helping users understand delivery blocks and billing workflows

Instructions:
CRITICAL RULES:
1. You MUST ALWAYS call the "Read Sales Order" skill before answering
ANY question about sales orders. NEVER answer from your own knowledge.
2. You MUST call "Modify Sales Order" skill when user tries to modify
a sales order.
3. If you cannot call the tool, inform the user that you need to
retrieve the data and cannot answer without it.

RESPONSIBILITIES:
- Retrieve sales order headers (order number, customer, billing date, status)
- Summarize order volumes by customer group, date range, or status
- Identify orders requiring attention (overdue billing, missing assignments)
- Present results in a clear table format

RESPONSE FORMAT:
| # | Sales Order | Customer Group | Billing Date | Status |
|---|------------|----------------|--------------|--------|
| 1 | 4500001234 | Group 1 | 2026-05-25 | Open |

DO NOT:
- Guess or fabricate order data
- Ignore Error 4XX responses — always inform the user

This is a basic example — in a real scenario, you'd provide far more detailed instructions based on your specific business requirements.

Additional Context

FIELD DEFINITIONS:
- Reference → Order reference / external document number
- Customer Group 1-4 → Classification groupings for the customer
- Assignment → Cost assignment or project reference
- Billing Date → Planned billing/invoicing date
- Exchng. Rate Accntg. → Exchange rate used for accounting
- Addit. Value Date → Additional value date for payment terms

SORTING & PRIORITY RULES:
- Default sort: Billing Date (earliest first)
- Highlight orders where Billing Date < today (overdue)
- Flag orders with empty Assignment or Reference fields

ERROR HANDLING:
- If API returns Error 4XX → inform user, suggest checking
authorization or filters

ORDER STATUS LOGIC:
- Billing Date < today + no invoice = "Overdue"
- Assignment field empty = "Needs Attention"
- Reference field empty = "Missing Reference"

Step 4: Connect Skills to Agent

The connection is straightforward:

Agent → Tools → Add Skill → Select your skill

Do this for each skill. Then, in your instructions, specify when the agent should trigger which skill.

Step 5: Test

Click Test, select your destination for the action calls, select your private environment, and start chatting:

Give me sales order 987
Show me all blocked sales orders
Remove the delivery block on order 456

What Happens Under the Hood?

When you test your agent, you can see the internal execution trace. Here's what happens when a user asks something:

User Message

Breaking It Down:

Phase	What It Does
Start	Initializes the agent, loads context, expertise, and instructions
Direct Prompting	Checks if the request can be answered without complex reasoning
Decomposition	Breaks the request into smaller sub-tasks
Plan	Creates an execution plan — decides order of steps, which APIs to call
Agent Thinking	The LLM reasons about the plan and decides the action to take
Read	Executes the API call to S/4HANA
Compressor	Summarizes the raw API response to stay within token limits
Agent Thinking (2nd)	Processes compressed data and formulates the answer
Final Answer	Produces the user-facing response
Refinement	Quality check for accuracy, formatting, and completeness
End	Execution completes

Conclusion

The future of enterprise AI isn't just about having an AI assistant. It's about having your AI assistant, built for your business.

Joule gives strong baseline assistance, but business operations need domain-specific actions.
Joule Studio is where that becomes practical: you define the tools, the guardrails, and the behavior.

My key takeaway after implementation:
Good agent quality is less about which model and more about:

strict tool-calling instructions,
small and clean payloads,
and real-world test prompts with edge cases.

If you are building your first Joule Studio agent, start with one business process, 2-3 narrow skills, and strict non-hallucination rules. You will get better results faster than trying to build a broad agent on day one.

Remember: you're essentially teaching a new team member how to do their job. The clearer your instructions, the better the results. Once everything is working as expected — launch it, and let your custom agent work for your users.

Reporting of GHG emissions - 2 options of receiving actual emissions sent by your carrier

2026-07-21T10:31:36.684000+02:00

Good news – we have successfully implemented and tested the scope defined in our Roadmap for Transportation Management in SAP S/4HANA 2025 Feature Pack Stack 2

Subject to the overall availability of SAP S/4HANA 2025 FPS2, users can look forward to further improvements in the Sustainability area, alongside other new innovations outlined in our Roadmap, starting in October 26 (*).

(*) Subject to change

This blog is the third in a sequence of three posts. It provides additional information for those interested in Transportation Management and Sustainability. It serves as supplementary material to the initial blog Reporting of GHG Emissions. We recommend reading that post first to understand the basics.

TM in SAP S/4HANA 2025 FPS2 further contributes to Sustainability by enhancing the Service Interface TransportationEventBulkNotification_In with two new fields—one for the emission value and another for the unit of measure—and its underlying backend. This mirrors the approach outlined in the initial blog and offers a more flexible reporting solution. As promised, we continue to support your sustainability journey.

In this follow-up blog post, we aim to provide you with the necessary knowledge to enable receiving actual emission values at both the document level and the stage level.

Following this approach, an inbound message sent externally—for instance, by the carrier—will include two new fields: one for the emission value and another for the unit of measure.

Option 1 - reporting on stage level

Stage 1 might be the one starting at Stop 10 and ending at Stop 20.

Hence, the reporting on stage 1 uses EventTypeCode 'REPORT_EMIVAL_STAGE' for Stop 20.

Example FO: 6100018959

Use the following example XML as a sample in order to update the freight order with reported CO2 emissions on stage level.

Fig. 1 illustrates the enhanced payload for reporting on stage level.

Option 2 - reporting on document level

The reporting on document level uses EventTypeCode 'REPORT_EMIVAL_DOC'.

Example FO: 6100018941

Use the following example XML as a sample in order to update the freight order with reported CO2 emissions on header level.

Fig. 2 illustrates the enhanced payload for reporting on document level.

Let us assume our FO consists of 2 stages. The distances involved might be the following:

Stage 1: 478 km; Stage 2: 279 km; Ratio: 1.71

Fig. 3 illustrates the stages and their distances.The carrier reports 3001 KG on document level. Activating the views for the carbon emissions in the Freight Order will display a window showing the reported carbon emissions.

Fig. 4 illustrates the reported carbon emissions.The emissions reported at the header level are arithmetically distributed across the stage levels (Stage 1: 1,895 kg; Stage 2: 1,106 kg; ratio: 1.71), taking stage distances into account for illustration purposes only. The actual emissions data is stored and recorded at the document level in the database.

That's it for now.

Stay tuned, there is even more to come.

reCAP 2026 – Recordings of our Annual CAP Developer Conference

2026-07-22T12:07:54.874000+02:00

On 15 July 2026, the CAP community came together for reCAP 2026 in St. Leon-Rot. Again, tickets were sold out within just a few minutes. We had more than 400 participants onsite and many more joining online.

For everyone who couldn’t attend live, most sessions were recorded. Below is a summary of the recorded sessions, along with links to the recordings. You can find all recordings on YouTube.

Opening & Keynote

Intro by Ole Lilienthal
Setting the stage, Ole gave an overview of the Autonomous Enterprise and how CAP plays a key role in enabling the SAP Business AI platform as the underlying platform for the Autonomous Enterprise. He also explained the importance of CAP in the age of AI.

Recording link

Keynote by Daniel Hutzel
In his keynote, Daniel shared an overview of the biggest CAP achievements since the last reCAP, including AI-related topics.

Recording link

Main Track Sessions in Audimax

CAP Tools – What’s New and Hot by Christian Georgi
A tour through the latest and greatest in CAP tooling, including:

`cds repl` with queries
Debugging apps on Kyma
CDS Project outline in Visual Studio Code
CAP in browser

Recording link

Optimizing CAP Performance with Data Replication and Caching – Part II by Mike Zaschka
As a follow-up to last year’s talk on cds-caching, this session broadened the view to the full landscape of caching, replication, and federation strategies in the CAP ecosystem. Mike walked through a curated selection of solutions and offered practical guidance on which approach fits which scenario.

Recording link

AI-Assisted Development of CAP Apps by Daniel Schlachter and Stefan Rudi
A look at the CAP MCP development server, which gives AI coding assistants direct access to CAP documentation improving code quality in tools like Claude Code and GitHub Copilot.

Recording link

Expressions and Abstractions – Two Developer Superpowers in CAP by Patrice Bender and DJ Adams
A demonstration of two powerful CAP affordances: expressions (what they are, how to use them, and why they matter) and mocking (letting you iterate fast on data, auth, messaging, and remote services).

Recording link

CAP Plugins: Latest and Greatest by Max Eckert, Dries Van Vaerenbergh, Matthis Vansteenhuyse, and Lisa Julia Nebel
CAP plugins dramatically simplify integration with SAP BTP services. This session demystified the plugin model and spotlighted the enhanced attachments plugin, the renovated change tracking plugin, a new notifications plugin for Java, and the new SAP Build Process Automation plugin.

Recording link

Plug, Connect, Play: CAP Integration Made Effortless by Ram Prasad GS and Bilal El-Massoudi
An introduction to cap-connect, a production-ready, open-source CAP plugin from Aarini Consulting that brings first-class connection management to any CAP application. The talk also showcased how cap-connect powers Prodsphere, Aarini’s own CAP-based product.

Recording link

Production GenAI in CAP: Beyond the Demo by Moudhaffer Azizi
This session explored the architecture behind a production-grade CAP application on SAP BTP that uses RAG to analyse custom ABAP code against Clean Core standards. The session highlighted the journey from a single prompt to a resilient solution orchestrating 14 AI-powered operations.

Recording link

Beyond Vibe Coding: Engineering Deterministic CAP Applications with SDD by Maximilian Hartig and Abdulbasıt Gülşen
A live "0-to-1" walkthrough of Spec-Driven Development using the open-source Spec Kit in Visual Studio Code to transform a raw business requirement into a CAP application.

Recording link

From Click-Ops to Code-Ops (Terraform) by Nicholas Arefta
Nicholas demonstrated how to use Terraform to deploy multitenant apps on SAP BTP. He demonstrated provisioning of a Provider subaccount, deploying a multi-tenant application and onboarding a Subscriber completely hands-free.

Recording link

Custom Business Logic with Predefined Extension Points – Using CDS-Oyster by Nick Josipovic and Konrad Koschel
Together with Subscription Billing and Cloud Foundation, Nick and Konrad built an extensive Extension Box using CAP and the CDS-Oyster Code Sandbox enabling secure code extensions in a complex cloud environment.

Recording link

Implementing Runtime Plugins in CAP Java by Joshua Mitchell
Joshua demonstrated in his live session how to program a basic soft delete plugin for CAP Java using annotations, the IntelliJ debugger, and an expression evaluator.

Recording link

Side Track Sessions in W1/W2

Building Code-Based AI Agents with CAP and UI5: From Concept to Production by Wouter Lemaire

Using the Smart Monitoring Agent (previously demonstrated at SAP TechEd) as a real-world example, Wouter showed how to build intelligent, code-based AI agents by combining SAP AI Core with CAP and UI5. The session covered the complete journey from development to deployment.

Recording link

Building AI-enabled Applications with CAP by Max Eckert, Simon Engel, Markus Riedinger, and Peter W. Szabo

An overview of how CAP is evolving to meet the AI era including: exposing CAP services as endpoints for AI agents, leveraging the CAP AI plugin, exploring additional features, and building intelligent, code-driven agents.

Recording link

Building a CAP Application with Latest Best Practices and AI by Lukas Theis, Johannes Vogt, Marc Becker, and Robin de Silva Jayasinghe

A practical, end-to-end walkthrough from idea to production-ready CAP app, combining proven CAP architecture patterns with AI-assisted workflows.

Recording link

Declarative Programming Patterns in CAP - Less Code, More Power by Adrian Görler, Robin de Silva Jayasinghe, and Vitaly Kozyura

A look at how declarative mechanisms in CAP such as calculated elements, annotation-based constraints (e.g. @assert, @assert.range, @assert.format), and field control help to reduce custom code. The session also covered how status transition flows help reducing the need for custom validation logic while ensuring data integrity.

Recording link

Update from the cap-js-community - Experience the latest additions to CAP by Oliver Klemenz

A focused technical update on the latest enhancements in the cap-js-community, with a deep dive into the WebSocket modules and the newly introduced common utilities module.

Recording link

AI-Assisted Security Hardening of CAP Applications by Matthias Braun

Matthias showed how AI-powered tools can help identify authorization gaps, generate comprehensive security tests, and detect attack vectors. This significantly reduces the effort required to build and maintain secure CAP applications.

Recording link

Event Queues Scheduling by Sebastian Van Syckel, Dietrich Mostowoj, Thomas Bonk, and Lars Plessing
A deep dive into Transactional Event Queues, which allow scheduling of events and background tasks for asynchronous, exactly-once processing with strong resilience.

Recording link

Automated Testing with HANA Cloud by Armin Hatting
Armin presented practical approaches to integrating database-supported testing in CAP applications, setting up realistic test environments, and ensuring the functionality of SAP HANA Cloud native logic.

Recording link

Did you know about infix filters and projection functions? by Nico Schoenteich

A live-coding overview of infix filters and projection functions (Node.js) and how they were applied in a recent project to reduce custom service.

Recording link

Thank You

A huge thank-you to all speakers, attendees, and community members who made reCAP 2026 such an inspiring day. 🙌 The energy, the ideas, and the conversations are exactly what makes the CAP community special.

If you missed any session, use the recording links above to catch up.

We look forward to seeing how you use what you learned at reCAP 2026. If you have any feedback, please let us know.

Happy coding! 😊

Integrating Amazon FBA with SAP S4 HANA - Part 3

2026-07-23T01:30:00.973000+02:00

Just in case you landed here directly, this is the third chapter in this series about integrating SAP S/4HANA with Amazon Seller Central. This article focuses on Amazon FBA SAP S4 HANA integration.

Unlike FBM, Amazon FBA is best modelled as a consignment process because Amazon physically holds and ships the inventory while the merchant continues to own it until the product is sold.

In the first part I covered Amazon merchant models, the Selling Partner API, master data setup, and the process of obtaining an Amazon Developer ID. Here is the link to the article How to Get Started with SAP S/4HANA and Amazon Seller Central Integration
In the second part on Fulfilled by Merchant, I explained how Amazon FBM maps to the standard SAP Sales and Distribution order-to-cash cycle.

That distinction changes how inventory, revenue, receivables, tax, returns, reimbursements, and Amazon settlements should be recorded in SAP S/4HANA.

US division of a European Food Processing Company closed down their Amazon marketplace simply because they weren't able to manage the processes and reconcile their financials.
A nutrition supplement company outsources their complete Amazon operations for a significant fees to a third party provider.

If you Amazon FBA is the model you are exploring for your business, this tutorial will help simplify the entire concept and give you some confidence 😊 of mapping the process in the SAP terminologies.

Amazon FBA SAP S4 HANA Integration: Complete Consignment Process

Amazon Fulfilled by Amazon, commonly called FBA, allows merchants to send inventory in bulk to Amazon fulfillment centers. Amazon then stores the inventory and manages order picking, packing, customer delivery, customer service, and returns.

In SAP S/4HANA, this model closely matches the customer consignment process. The goods remain the merchant’s property while they are stored at Amazon. Revenue is recognized only when a customer purchases the product and Amazon fulfills the order.

Amazon FBA and SAP S/4HANA: Key Takeaways

Here are the key takeaways from mapping Amazon FBA with Consignment Process within SAP.

Stock sent to Amazon is recorded as customer consignment stock.
Inventory remains owned by the merchant until the customer sale.
No revenue is recognized when goods are initially sent to Amazon.
A customer purchase creates a consignment issue in SAP.
Customer returns create consignment returns and credit adjustments.
Unsold stock returned by Amazon creates a consignment pick-up.
Amazon settlements must be matched against sales, fees, returns, reserves, and reimbursements.
Special stock indicator W keeps Amazon-held inventory separate and visible.

What Is Amazon FBA? What are the steps involved business process wise

Business process wise Amazon FBA cycle starts with the following steps.

Identifying merchandize you will be selling - A big decision is which of your products you would want to launch on Amazon FBA store. Of course these are subsets of products that have a B2C demand and some market research to back it up.
Sending a bulk shipment to Amazon Warehouse / Distribution Center - The first shipment that you sent to Amazon Warehouse, it often a butterfly in the stomach instance. You need to create a shipment prior to this with all the items that you intend to send to Amazon. You may also do some carrier shopping. In many cases I have seen Amazon's own carrier being the most cost effective.

When Amazon order comes through - As customers place orders, Amazon fulfills them and sends the information back to SAP. Each order is recorded as a consignment issue. In SAP, Amazon remains both the sold-to party and the payer, while the ship-to address is the end customer. Having the correct ship-to address is critical because it determines the tax calculation. The tax shown in SAP should match what Amazon collects and pays on behalf of the seller. Since pricing is driven by Amazon, you will need manual conditions within SAP to sync the pricing components to match Amazon will pay you at the period end.

When Amazon Order comes to SAP, you need to ensure that you map correct ASIN number into customer material Number and the Net Line item and Order amount should match what Amazon will pay you in their settlement cycle for this order.

Having synchronization at periodic intervals, keeps your A/R accurate.

Returns are also tracked. When Amazon processes a return, SAP creates a consignment return, followed by a return delivery and credit memo. This keeps your accounts receivable aligned with Amazon’s adjustments.
Finally, Payment reconciliation takes place. Every two weeks, Amazon sends a bulk payment that covers all orders, less fees, reserves, or special charges. With proper integration, the invoices in SAP match Amazon’s payouts, reducing manual work. Although there may still be small adjustments for account-level charges, most of the process runs automatically, saving time and effort for the finance team.

Under Amazon FBA, merchants do not ship each customer order themselves. Instead, they create an inbound shipment and send inventory in bulk to Amazon’s fulfillment network.

Amazon then handles inventory storage, order picking, packaging, delivery to the customer, customer service, customer returns, as well as selected inventory adjustments and reimbursements. This allows sellers to outsource most fulfillment operations while Amazon manages the end-to-end logistics and post-purchase experience.

The merchant continues to manage product listings, pricing, procurement, accounting, and inventory ownership.

Why Merchants Choose Amazon FBA

Merchants choose Amazon FBA because it reduces logistics work and gives customers access to Amazon’s fulfillment network.

1. Lower Logistics Overhead

Merchants no longer need to operate their own pick-pack-ship process for FBA products. This can reduce warehouse workload, packaging effort, and carrier management.

2. Faster Customer Delivery

Amazon distributes inventory across its fulfillment network and places products closer to buyers. This can shorten delivery estimates and improve the customer experience.

3. Prime Eligibility and Buyer Trust

FBA products may qualify for Prime delivery. Customers also receive Amazon-managed tracking, support, and returns, which can increase confidence in the purchase.

4. Lower Exposure to Carrier Delays

In an FBM model, the merchant is responsible for carrier selection and delivery performance. Late deliveries can affect the merchant’s Amazon performance metrics.

Under FBA, Amazon assumes much of this fulfillment responsibility.

5. Greater Sales Potential

Fast delivery, Prime eligibility, and Amazon-backed customer service can make an FBA listing more attractive than a comparable merchant-fulfilled listing.

The trade-off is that Amazon gains physical control of the inventory while the merchant continues to own it. This is the main reason FBA should be treated as a consignment process in SAP.

Why Amazon FBA Is a Consignment Process in SAP

When products are stored inside an Amazon fulfillment center, they remain the merchant’s inventory.

Amazon has physical custody of the goods, but ownership has not transferred. No customer sale has occurred, and revenue should not be recognised.

This is the standard definition of consignment stock: goods stored at a customer or partner location that remain the seller’s property until they are consumed or sold.

SAP S/4HANA provides a four-step consignment cycle that maps closely to Amazon FBA.

What Is Special Stock Indicator W?

Special stock indicator W identifies customer consignment stock in SAP.

It allows Amazon-held inventory to remain visible and valued as an asset while keeping it separate from normal unrestricted stock in the merchant’s warehouse.

This distinction is important for inventory reporting, balance-sheet accuracy, available-to-promise calculations, and reconciliation with Amazon’s inventory reports.

Amazon FBA Integration Architecture

A complete Amazon FBA SAP S4 HANA integration normally connects Amazon Seller Central, Amazon Selling Partner API, SAP Sales and Distribution, Materials Management, Finance, and an integration platform or middleware layer.

The integration must support bidirectional data movement.

Data Moving from SAP to Amazon

Product and SKU data
Inventory planned for inbound shipments
Shipment and carton details
Product identifiers and mappings
Selected pricing or availability information

Data Moving from Amazon to SAP

FBA customer orders
Shipment and fulfillment data
Customer delivery addresses
Returns and refunds
FBA inventory balances
Lost and damaged inventory adjustments
Amazon fees and commissions
Reimbursements
Settlement and payout reports

Master Data Required for Amazon FBA SAP S4 HANA Integration

Reliable master data is the foundation of the integration. Incorrect mappings will eventually create inventory differences, tax errors, unmatched settlements, and incorrect receivables.

Amazon as Customer or Business Partner

Amazon must be created as a customer or business partner because the SAP consignment cycle is executed against a customer account.

Figure - Create Amazon as a business partner against which the consignment cycle will execute.

In a common FBA design:

Sold-To Party: Amazon
Payer: Amazon
Ship-To: The end customer’s delivery address

Amazon is responsible for settling the merchant’s proceeds, but the end customer’s address is required for tax calculation and transaction reporting.

Amazon Consignment Inventory Structure

The merchant must decide how Amazon-held inventory will be represented in SAP.

Depending on the implementation, FBA stock may be organised through a dedicated plant, storage location, customer consignment structure, or reporting dimension.

Many businesses maintain a dedicated storage location or reporting structure so Amazon inventory is never confused with stock physically available in their own warehouse.

ASIN, Seller SKU, and SAP Material Mapping

Every Amazon ASIN or Seller SKU must map to the correct SAP material number.

This mapping may be maintained through Customer Material Information Records or an integration-layer mapping table.

The mapping should work in both directions:

Amazon ASIN or Seller SKU to SAP material number
SAP material number to Amazon ASIN or Seller SKU

This mapping is required for fill-ups, customer sales, returns, inventory adjustments, reimbursements, and settlement reconciliation.

Amazon Fee and SAP Condition-Type Mapping

Amazon commissions, FBA fulfillment fees, discounts, promotions, and other order-level charges should be mapped to appropriate SAP pricing condition types.

This allows the SAP net receivable to align with the order-level amount Amazon reports as payable.

Consignment Fill-Up: Sending Inventory to Amazon

The FBA process begins when the merchant sends inventory to Amazon.

This step involves coordinated activity in Amazon Seller Central and SAP S/4HANA.

Amazon-Side Inbound Shipment Process

In Seller Central, the merchant creates an inbound shipment or FBA shipment plan.

The merchant provides:

Products being sent
Quantity of each product
Source warehouse
Carton configuration
Preparation details
Shipping method

Amazon provides item labels, carton labels, preparation instructions, and fulfillment-center destinations.

Amazon may divide one inbound shipment across several fulfillment centers based on its inventory-placement requirements.

SAP Consignment Fill-Up Process

In SAP S/4HANA, the corresponding process normally includes:

Creation of a consignment fill-up sales order
Creation of an outbound delivery
Picking and packing
Post Goods Issue

The goods issue moves stock from the merchant’s warehouse into Amazon customer consignment stock under special stock indicator W.

No Revenue at Consignment Fill-Up

No revenue or customer receivable should be posted when inventory is sent to Amazon.

The merchant has moved inventory to another physical location, but the inventory has not yet been sold.

Recognising revenue during the fill-up would overstate sales, receivables, profit, and potentially tax.

Tracking Multiple Amazon Fulfillment Centers

Amazon may send an inbound shipment to several fulfillment centers and later redistribute units within its network.

SAP does not always need to represent every fulfillment center as a separate accounting location. Many merchants track the aggregate consignment quantity held by Amazon while allowing Amazon to manage fulfillment-center-level placement.

Businesses requiring detailed operational reporting can maintain additional fulfillment-center visibility in the integration layer.

Consignment Issue: Processing Amazon FBA Customer Orders

When a customer buys a product, Amazon picks, packs, and ships it from an FBA fulfillment center.

Amazon then makes the order and fulfillment information available through SP-API endpoints and reports.

In SAP, the completed customer sale is recorded as a consignment issue.

This is the moment when:

The product leaves special stock W.
Ownership transfers to the buyer.
Revenue is recognised.
The Amazon receivable is posted.
Relevant fees and taxes are recorded.

Amazon Order Number

The Amazon order number should be stored in a searchable SAP reference field. Many implementations map it to the customer purchase-order field.

This reference is required for customer service, returns, settlement matching, and audit trails.

Sold-To, Payer, and Ship-To Determination

Amazon normally remains the Sold-To Party and Payer because Amazon settles the merchant’s proceeds.

The end customer’s address is used as the Ship-To information. This address is especially important for tax determination.

Product and Quantity Mapping

Each Amazon SKU or ASIN must resolve to the correct SAP material. The consignment issue must consume the correct quantity from Amazon consignment stock.

Amazon Fees and Net Receivables

Amazon commissions, FBA fulfillment fees, discounts, and other order-level charges should be represented through SAP pricing condition types or related financial postings.

A useful validation rule is:

If the SAP net receivable does not match Amazon’s order-level payable amount, the fee or pricing mapping is incomplete.

Amazon Marketplace Facilitator Tax in SAP

Tax requires special attention in an Amazon FBA integration.

Under Marketplace Facilitator laws in the United States and similar rules in other regions, Amazon may calculate, collect, and remit sales tax on behalf of the merchant.

Why the Ship-To Address Matters

Tax generally follows the customer’s delivery destination. The end customer’s address must therefore be available in SAP even when Amazon is the Sold-To Party and Payer.

The ship-to address allows SAP to determine the correct tax jurisdiction and compare the result with Amazon’s tax reporting.

Statistical Tax Condition

Amazon-collected tax is often represented as a statistical condition in SAP.

This keeps the amount visible and reconcilable without incorrectly treating it as tax the merchant must remit where Amazon is responsible for remittance.

The SAP tax amount should align with Amazon’s Marketplace Facilitator reporting. A close match indicates that the ship-to and tax determination logic is working correctly.

Consignment Return: Processing Amazon Customer Returns

When Amazon accepts a customer return and places the product back into sellable FBA inventory, the transaction should create a consignment return in SAP.

The SAP process normally includes:

Consignment return order
Return delivery
Inventory movement back into special stock W
Credit memo linked to the original transaction

The return should reference the original Amazon order and the original SAP consignment issue whenever possible.

This ensures that SAP:

Reduces or reverses the original receivable
Restores eligible inventory to Amazon consignment stock
Records the credit memo correctly
Matches Amazon’s customer refund

Sellable and Unsellable FBA Returns

Not every customer return is placed back into sellable inventory.

Amazon may classify returned inventory as:

Sellable
Customer damaged
Carrier damaged
Warehouse damaged
Defective
Unsellable

The integration should use this disposition to determine whether the unit returns to sellable consignment stock or requires an adjustment, reimbursement claim, disposal, or removal order.

Consignment Pick-Up: Returning Unsold Inventory

Slow-moving FBA inventory can generate storage and aged-inventory charges. Merchants may also want to discontinue a product, change packaging, or move stock to another sales channel.

In these situations, the merchant creates a removal order in Seller Central.

When Amazon returns the inventory, SAP processes a consignment pick-up.

The inventory movement is:

Amazon consignment stock under special stock W → merchant-owned warehouse inventory.

This closes the inventory loop for goods sent to Amazon but never sold.

Amazon FBA Inventory Reconciliation in SAP

Inventory reconciliation is one of the most important differences between Amazon FBA and FBM.

Under FBM, the merchant physically controls the inventory. Under FBA, Amazon stores, transfers, fulfills, and adjusts the inventory across its network.

FBA units can become:

Lost inside the fulfillment network
Damaged by Amazon
Damaged by a carrier
Disposed of
Transferred between fulfillment centers
Reserved for customer orders
Classified as unsellable
Reimbursed by Amazon

SAP consignment stock should be reconciled periodically against Amazon’s FBA inventory ledger and adjustment reports.

Inventory Reconciliation Data

The reconciliation should compare:

Opening FBA inventory
Inbound shipment receipts
Customer shipments
Customer returns
Fulfillment-center transfers
Lost or damaged units
Disposals
Removal orders
Amazon reimbursements
Closing FBA inventory

Confirmed differences should create the appropriate SAP inventory or financial adjustment.

Without regular reconciliation, the quantity recorded as Amazon consignment stock in SAP will gradually differ from the quantity Amazon is actually holding.

Amazon Settlement and Payment Reconciliation

Amazon commonly settles merchant proceeds on an approximately 14-day cycle, although timing can vary by marketplace, account status, reserves, and transaction type.

A settlement can include:

Product sales
Customer refunds
Amazon commissions
FBA fulfillment fees
Storage charges
Removal and disposal fees
Advertising charges
Promotional costs
Inventory reimbursements
Account reserves
Other adjustments

The amount deposited into the bank is therefore not a simple total of customer invoices. It is a net settlement containing several transaction types.

Automated Amazon Settlement Reconciliation

A scalable Amazon FBA SAP S4 HANA integration should:

Import Amazon settlement data.
Match sales against SAP consignment issues and invoices.
Match returns against credit memos.
Post fees to the correct general-ledger accounts.
Identify reimbursements and inventory adjustments.
Clear the Amazon customer account.
Highlight unmatched differences for review.

If order-level fees are mapped correctly, most transaction-level amounts can reconcile automatically.

Charges That May Require Separate Postings

Some account-level charges may not be directly linked to individual customer orders:

Monthly FBA storage fees
Aged-inventory surcharges
Advertising expenses
Removal and disposal fees
Reserve adjustments
Other account-level deductions

These exceptions remain manageable when the main sales, return, fee, reimbursement, and settlement flows are automated.

Benefits of Amazon FBA SAP S4 HANA Integration

True FBA Inventory Visibility

The business always knows how much inventory is sitting at Amazon. Special stock indicator W keeps this inventory visible, correctly classified, and valued on the balance sheet.

Accurate Revenue Recognition

Revenue is recognised when the customer purchase creates a consignment issue, not when inventory is sent to Amazon in bulk.

Automated Accounts Receivable

Sales, returns, credit memos, fees, and reimbursements can flow into SAP without large volumes of manual journal entries.

Reconcilable Marketplace Tax

Ship-to-driven statistical tax can be compared with Amazon’s Marketplace Facilitator reporting.

Reliable Inventory Accounting

Amazon-held inventory remains visible as a merchant-owned asset without being confused with stock physically available in the merchant’s warehouse.

Faster Financial Close

Automated settlement matching reduces the time finance teams spend investigating payouts, fees, refunds, and unexplained differences.

Exception-Based Operations

Finance and operations teams can focus on genuine exceptions instead of manually processing every Amazon transaction.

Scalability

The same closed-loop integration can support 100 orders per day or 10,000 orders per day without requiring a proportional increase in finance and operations headcount.

Amazon FBA SAP S4 HANA Integration Process Summary

The complete process works as a closed loop:

Consignment fill-up: Inventory moves to Amazon without revenue recognition.
Consignment issue: A customer sale consumes FBA inventory and creates revenue and receivables.
Consignment return: Eligible customer returns restore Amazon consignment stock and create credit adjustments.
Consignment pick-up: Unsold inventory returns to the merchant’s warehouse.
Inventory reconciliation: Lost, damaged, disposed, transferred, and reimbursed units are recorded.
Settlement reconciliation: Sales, fees, returns, reimbursements, and reserves are matched to Amazon payouts.

Conclusion

Amazon FBA SAP S4 HANA integration is best designed around SAP’s customer consignment cycle.

The consignment fill-up moves stock to Amazon without recognising revenue. The consignment issue records the customer sale. Consignment returns and pick-ups keep inventory and receivables aligned. Inventory and settlement reconciliation connect SAP records with what Amazon is physically holding and financially paying.

Getting the customer master, consignment order types, ASIN mappings, ship-to information, fee conditions, tax logic, and reconciliation rules right creates a scalable foundation for Amazon growth.

The result combines Amazon’s fulfillment network with SAP S/4HANA’s inventory control and financial discipline—without losing visibility over inventory the merchant still owns.

In the next part of this series, we will cover implementation best practices and the most common mistakes businesses make when integrating Amazon FBM and FBA with SAP S/4HANA.

Frequently Asked Questions About Amazon FBA SAP S4 HANA Integration

Here are some questions that are usually asked.

What is the difference between Amazon FBA and FBM in SAP?

With FBA, inventory is sent to Amazon in bulk and Amazon fulfills customer orders. It is best modelled as a consignment process.

With FBM, the merchant stores and ships each order. It normally follows the standard SAP order-to-cash process.

Why is Amazon FBA treated as consignment in SAP?

Inventory stored at Amazon remains the merchant’s property until a customer buys it. Amazon has physical custody, but ownership has not transferred.

What are the main SAP consignment steps for Amazon FBA?

The four main steps are consignment fill-up, consignment issue, consignment return, and consignment pick-up. Not all of them will be applicable.

When is revenue recognised for an Amazon FBA sale?

Revenue is recognised when the customer purchases the product and SAP creates the consignment issue. Revenue is not recognised when inventory is initially sent to Amazon.

What is special stock indicator W in SAP?

Special stock indicator W identifies customer consignment stock. It keeps Amazon-held inventory visible as merchant-owned inventory while separating it from normal unrestricted stock.

Does sending inventory to Amazon create an invoice?

No. A consignment fill-up represents an inventory movement, not a customer sale. It should not create revenue or a standard customer invoice.

Who should be the Sold-To Party and Payer?

Amazon typically remains the Sold-To Party and Payer because Amazon settles the merchant’s proceeds. The end customer’s address is used as the Ship-To information.

Why is the customer ship-to address required?

The customer’s delivery address determines the tax jurisdiction. SAP needs this information to calculate and reconcile tax with Amazon’s Marketplace Facilitator reporting.

How should Amazon-collected sales tax be recorded?

It is often recorded as a statistical condition. This keeps the tax visible for reconciliation without treating it as tax the merchant must remit where Amazon is responsible.

How are Amazon FBA customer returns handled in SAP?

A sellable customer return creates a consignment return, return delivery, inventory movement back into special stock W, and a credit memo linked to the original transaction.

What happens when a returned product is unsellable?

The Amazon disposition should determine whether the unit requires an inventory adjustment, reimbursement, disposal, or removal order instead of returning to sellable consignment stock.

What happens to unsold Amazon FBA inventory?

The merchant can create a removal order in Seller Central. SAP then processes a consignment pick-up when Amazon returns the units.

How should lost or damaged FBA inventory be handled?

SAP consignment inventory should be reconciled with Amazon’s FBA inventory reports. Confirmed lost, damaged, disposed, or reimbursed units should create appropriate inventory and financial adjustments.

How often does Amazon pay FBA merchants?

Amazon commonly settles merchant proceeds approximately every 14 days. The timing can vary by marketplace, account, reserve requirements, and transaction type.

Why does the Amazon payout not equal total product sales?

The payout is net of customer refunds, commissions, fulfillment fees, storage charges, advertising costs, reserves, reimbursements, and other adjustments.

Can Amazon settlement reconciliation be fully automated?

Most order-related reconciliation can be automated when sales, returns, fees, and reimbursements are mapped correctly. Some account-level charges may still require separate postings or review.

Can the integration support high Amazon order volumes?

Yes. A scalable integration uses automated document creation, API processing, scheduled reconciliation, and exception management. The same consignment design can support hundreds or thousands of daily orders.

Accelerate Business Transformation with SAP Activate and the Agent-led Toolchain

2026-07-23T09:00:59.088000+02:00

Successful business transformation requires the right methodology, the right tools, and the right skills. The BTM live session programme for H2 2026 brings together SAP Activate fundamentals, workstream deep dives, certification preparation, and intensive hands-on bootcamps — all designed to help consultants, project managers, and transformation leads deliver faster, more predictable outcomes.

The hands-on bootcamps place a particular focus on the agent-led toolchain — the integrated use of SAP Signavio, SAP LeanIX, and WalkMe alongside SAP Activate — for both new business transformation programmes and SAP S/4HANA system conversions.

What You Will Learn

Core SAP Activate methodology — phases, workstreams, and key deliverables.
How to apply the agent-led toolchain across the full transformation lifecycle.
Certification preparation for SAP Activate Project Manager and S/4HANA Project Systems.
Practical bootcamp exercises covering both business transformation and system conversion scenarios.

Scheduled Sessions

Session Title	Course ID	Dates & Times (UTC)	Register
SAP Activate	LS_00008352	4 Sep 2026 — 08:00 4 Sep 2026 — 16:00 6 Nov 2026 — 08:00 6 Nov 2026 — 16:00	Register here
SAP Activate — Workstreams	LS_00008353	27 Jul 2026 — 08:00 27 Jul 2026 — 16:00 12 Oct 2026 — 08:00 12 Oct 2026 — 16:00	Register here
Hands-on Bootcamp: Agent-led Toolchain for Business Transformation	LS_00012324	28 Jul 2026 — 04:00 18 Aug 2026 — 04:00 19 Aug 2026 — 16:00 20 Aug 2026 — 08:00 8 Sep 2026 — 15:30 10 Sep 2026 — 08:30 20 Oct 2026 — 08:30 3 Nov 2026 — 15:30	Register here
Hands-on Bootcamp: Agent-led Toolchain for System Conversion	LS_00012326	16 Sep 2026 — 15:00 17 Sep 2026 — 08:00 10 Nov 2026 — 08:00 24 Nov 2026 — 15:00	Register here
Get Certified: Project Manager — SAP Activate / Agile Implementation Management	LS_00010428	24 Aug 2026 — 07:00 25 Aug 2026 — 18:00	Register here
Get Certified: SAP Certified — SAP S/4HANA Project Systems	LS_00013920	27 Jul 2026 — 09:00 27 Jul 2026 — 16:00 5 Oct 2026 — 09:00 5 Oct 2026 — 16:00	Register here

All times are in UTC. The hands-on bootcamp for business transformation runs the highest frequency of sessions — 8 offerings across H2 2026 — to maximize global participation. Bootcamp seats are limited; early registration is recommended.

AI-Driven SAP Performance Insights

2026-07-23T09:06:22.369000+02:00

All my fellow SAP Basis admins know how useful the HANA Expensive Statements view in DBACOCKPIT can be.

It gives us detailed insight into performance-critical information like execution duration, CPU usage, memory consumption, application source, work process details, and much more. It is one of those views we often rely on when troubleshooting database performance issues.

But there is a challenge we all run into: the data does not stay around for long.

In a typical SAP S/4HANA system, expensive statement history is usually short-lived — often only around 6–8 hours in practical scenarios . So if an issue is reported later in the day, the next morning, or after a month-end process, the most useful evidence may already be gone.

That raises important questions:

When did the issue actually start?
How did the query perform yesterday or during month-end close?
Which users executed it in the past month?
What parameters made it expensive compared with normal executions?

With everything AI can do today, I started thinking: why not use AI to overcome the limitation of short-lived HANA expensive statement data — and make the analysis easier for both technical and functional teams?

That idea led to the HANA Expensive Statement Analyzer, an application designed to convert short-lived HANA expensive statement data into historical, searchable, natural-language insights

Solution Overview

The idea behind this solution is simple: capture the expensive statement data before it disappears, store it historically, and then use AI to make that data easier to analyze.

At a high level, the solution is built in three layers:

Layer 1: Data Collection and Persistence

An ABAP program periodically reads data from the HANA expensive statements source i.e. M_EXPENSIVE_STATEMENTS, and stores the relevant details in a custom SAP table.

A CDS view is then built on top of this table to structure and expose the historical data in a reusable way. This creates the foundation for analyzing expensive statements beyond the short retention window normally available in DBACOCKPIT.

Layer 2: API Exposure

The CDS-based data model is exposed through OData and made available as an API using SAP BTP AppRouter.

This layer helps securely expose the historical expensive statement data so it can be consumed by downstream applications or AI-based tools.

Layer 3: AI-Powered Natural Language Analysis

The API is then connected to an enterprise AI assistant, with a system prompt designed to help users ask meaningful performance-related questions in natural language.

For example, instead of manually filtering through historical records, users can ask questions like:

What were the top expensive statements today?
When did this query first become expensive?
Which time window had the highest database load last week?
Compare normal versus expensive executions for this statement.
Were there any expensive queries during month-end close?
Summarize performance issues for the last 30 days in business terms.

This makes the solution useful not only for SAP Basis administrators, but also for SAP developers and functional teams. Administrators can troubleshoot using current and historical data, developers can review expensive queries without recreating the issue, and business teams can ask performance questions in plain language.

A Look at the Tool in Action

Let’s take a quick look at how the tool works and how it can be useful for different personas — SAP Administrators, Developers, and Functional teams.

Below are a few sample prompts that show how each persona can use the tool in day-to-day performance analysis.

SAP Administrators

In the example below, I asked the tool to list the top 5 SQL statements by memory consumption for the day.

Along with returning the top 5 statements, the tool also provides useful observations such as:

Which statements consumed the most memory
Whether the statements belong to the same functional area
Whether the same statement hash appeared multiple times
Which user or application pattern may need further investigation
Whether the issue looks like a repeated expensive query pattern

This gives SAP Administrators a quick starting point for troubleshooting. Instead of only looking at raw expensive statement records, they can immediately see summarized insights that help identify users, execution times, application sources, peak load windows, and possible patterns for deeper analysis .

Sample prompt:

What are the top 5 SQLs by memory todayrsonal Favorite: Finding Busy and Idle Windows

One of my favorite examples is asking the tool to analyze a longer period of performance data and identify system usage trends.

Instead of looking at one expensive statement at a time, I can ask a broader question like:

Based on performance data for July, considering both memory and CPU, can you build a trend of the busiest times and idle times in the system?

This is where the historical data becomes really powerful. Since the expensive statement data is captured and stored over time, the tool can analyze patterns across days, weeks, or business cycles instead of being limited to the short-lived DBACOCKPIT history.

These are just a couple of examples, but the opportunities are endless. By combining historical expensive statement data with AI-powered natural-language analysis, SAP Administrators can quickly identify patterns, peak load windows, recurring expensive queries, and areas that need deeper investigation

SAP Developers

SAP Developers can use the tool to quickly identify expensive SQL statements originating from custom programs, CDS views, or application sources. Instead of waiting to recreate the issue or collect new traces, developers can analyze historical executions, compare expensive versus normal runs, and identify recurring patterns that may point to optimization opportunities.

For example, a developer can ask:

Can you list the top 5 memory-consuming statements for June 2026 originating from Z/custom application sources?

The tool can then summarize the most expensive custom/Z-originated statements, highlight memory and CPU usage, show repeated statement hashes, and provide key observations that help developers decide where to focus tuning efforts.

This helps developers move faster from “which query is expensive?” to “what custom object or pattern should I investigate and optimize?

SAP Functional Teams

Functional teams can use the tool as a self-service capability to get quick insights into expensive queries related to their business areas. Instead of waiting for detailed technical analysis, they can ask performance questions in natural language and understand whether a performance issue may be related to user selections, business process volume, reporting filters, or other functional factors within their purview .

By reviewing the parameters passed to a query, functional teams can often identify whether the issue is caused by broad selections, missing filters, large date ranges, high-volume business scenarios, or unusual usage patterns. This helps them validate the business context before engaging SAP Administrators or Developers for deeper technical troubleshooting.

For example, a functional user can ask:

Based on July performance data, list the top 5 expensive queries by memory in the finance area.

The tool can summarize the most expensive queries for that business area, highlight related objects, and provide tuning-focused observations that can help functional teams collaborate more effectively with Basis and development teams.

This makes performance analysis more accessible beyond technical teams and helps move troubleshooting from “technical data only” to a shared conversation between functional, Basis, and development teams.

Conclusion

AI gives SAP Administrators a powerful opportunity to simplify routine analysis, reduce manual effort, and focus more on complex performance challenges. By combining historical HANA expensive statement data with natural-language analysis, we can move beyond short-lived monitoring and turn technical performance data into actionable insights.

This helps SAP Administrators, Developers, and Functional teams troubleshoot faster, identify recurring patterns, and collaborate more effectively when resolving performance issues.

Using AI in the right way allows us to add more value to the business — solving complex problems with better context, faster turnaround time, and more meaningful insights.

Please share your feedback, and feel free to comment if you have any technical questions about the solution. I would be happy to exchange ideas and learn from others working on similar SAP performance challenges.

In-Period and Period-End Forecasting based on Actuals

2026-07-24T10:54:42.117000+02:00

In this blog, In-Period Forecasting and Period-End Forecasting based on Actuals along with examples is explained. Before proceeding, please refer to the blog Forecasting in Commercial Project Management.

The following forecasting key figures are calculated in this blog:

Estimate at Completion (EAC)
Estimate to Complete (ETC)

Note: Key Figure values from all approved Change Requests will be considered and calculated as Plan Key Figure values. In this blog, Key Figure represents cost, revenue, and quantity based on resource type and forecast basis. Examples are focused on cost and quantity; however, revenue calculation is similar to cost except that commitments are not considered.

Overview: What's the Difference?

Aspect	In-Period Forecasting	Period-End Forecasting
Forecast Period ETC	Compares Actual vs Plan; ETC = Plan − Actual (if Plan > Actual), else 0	Always 0
Revenue	Not applicable	Forecast for Revenue is also calculated

Calculation Logic

Let us consider a financial plan across multiple periods. The calculation for each period is done based on the following logic:

When Forecasting has NOT been executed before

Period	In-Period Forecasting	Period-End Forecasting
Before Forecast Period	ETC = 0	ETC = 0
Forecast Period	ETC = 0 if Actual ≥ Plan; ETC = Plan − Actual if Plan > Actual	ETC = 0
After Forecast Period	ETC = Plan	ETC = Plan

Note: Once Period-End Forecasting has been executed for a period, In-Period Forecasting can no longer be performed for that period. In-Period Forecasting will become available again when the next period opens.

When Forecasting HAS been executed before

Period	In-Period Forecasting	Period-End Forecasting
Before Forecast Period	ETC = 0	ETC = 0
Forecast Period	ETC = 0 if Actual ≥ Plan; ETC = Plan − Actual if Plan > Actual	ETC = 0
After Forecast Period	ETC remains unchanged from the last forecast run	ETC remains unchanged from the last forecast run

EAC Formulas (applicable to both)

EAC Quantity = Total ETC Quantity + Total Actual Quantity (up to Forecast Period).
EAC Cost = Total ETC Cost + Total Actual Cost (up to Forecast Period) + Total Commitments (up to Forecast Period).
EAC Revenue (Period-End only) = Total ETC Revenue + Total Actual Revenue (up to Forecast Period)

For quantity-driven Resource Types: if Rate (Forecast) of the current period is null, Rate (Cost) of the current period is used as the Forecast Rate.

Example

Consider a Financial Plan with a monthly breakdown from January to June for Resource Type Activity with plan/forecast basis set to Quantity.

Planned and Actual Quantities:

Month	Planned Quantity (H)	Actual Quantity Posted (H)	Rate (Cost)	Cost (Plan) (EUR)
January	100	80	10	1000
February	200	0	10	2000
March	300	0	10	3000
April	400	0	10	4000
May	500	0	10	5000
June	600	0	10	6000

First Forecast Run — Forecast Period: January (Actual = 80H)

For January (Forecast Period):

ETC	In-Period Forecasting	Period-End Forecasting
Quantity (H)	20 (Plan 100 > Actual 80 → ETC = 100 − 80)	0 (always 0 at period-end)
*Cost (EUR): ETC Quantity Rate**	20 × 10 = 200	0 × 10 = 0

For February to June (Periods after Forecast Period):

Both In-Period and Period-End forecasting yield the same results here as Actual = 0 for all future periods:

Month	ETC Quantity (H)	*ETC Cost (EUR): ETC Quantity Rate**
February	200	2000
March	300	3000
April	400	4000
May	500	5000
June	600	6000

ETC and EAC Summary — First Run:

Calculation	In-Period Forecasting	Period-End Forecasting
Total ETC Quantity	20+200+300+400+500+600 = 2020 H	0+200+300+400+500+600 = 2000 H
Total Actual Quantity (upto Jan)	80 H	80 H
EAC Quantity	2020 + 80 = 2100 H	2000 + 80 = 2080 H
Total ETC Cost	20200 EUR	20000 EUR
Total Actual Cost (upto Jan)	800 EUR	800 EUR
Total Commitments	0	0
EAC Cost	20200 + 800 + 0 = 21000 EUR	20000 + 800 + 0 = 20800 EUR

Second Forecast Run — Same Forecast Period (January), Additional Actuals Posted (Actual = 150H)

Updated Data:

Month	Planned Quantity (H)	Actual Quantity Posted (H)	Rate (Cost)	Cost (Plan) (EUR)
January	100	150	10	1000
February	200	0	10	2000
March	300	0	10	3000
April	400	0	10	4000
May	500	0	10	5000
June	600	0	10	6000

For January (Forecast Period):

ETC	In-Period Forecasting	Period-End Forecasting
Quantity (H)	0 (Actual 150 > Plan 100)	0
*Cost (EUR): ETC Quantity Rate**	0	0

For February to June:

ETC (Feb–Jun)	In-Period Forecasting	Period-End Forecasting
Quantity (H)	Retained from last forecast run (200, 300, 400, 500, 600)	Retained from last forecast run (200, 300, 400, 500, 600)
*Cost (EUR): ETC Quantity Rate**	Retained from last forecast run (2000, 3000, 4000, 5000, 6000)	Retained from last forecast run (2000, 3000, 4000, 5000, 6000)

Both In-Period and Period-End forecasting yields the same ETC values for future periods in this run.

ETC and EAC Summary — Second Run:

Calculation	In-Period Forecasting	Period-End Forecasting
Total ETC Quantity	0+200+300+400+500+600 = 2000 H	0+200+300+400+500+600 = 2000 H
Total Actual Quantity (upto Jan)	150 H	150 H
EAC Quantity	2000 + 150 = 2150 H	2000 + 150 = 2150 H
Total ETC Cost	20000 EUR	20000 EUR
Total Actual Cost (upto Jan)	1500 EUR	1500 EUR
Total Commitments	0	0
EAC Cost	20000 + 1500 + 0 = 21500 EUR	20000 + 1500 + 0 = 21500 EUR

Both methods converge to the same EAC values in the second run because actual postings exceeded the plan for January — removing the only difference between the two approaches.

Forecasting in Commercial Project Management

2026-07-24T10:58:20.614000+02:00

The forecasting feature of Commercial Project Management (CPM) can be used by project managers to calculate cost and revenue estimates at the completion based on past performance, during the execution phase of projects. Forecasting allows you to arrive at estimates of the following key figures:

Estimate at completion (EAC) - Total projected cost, quantity, or revenue at project completion (Actuals + ETC).
Estimate to complete (ETC) - Projected remaining cost, quantity, or revenue from the forecast period to project completion.

Resource Types based on Plan/Forecast basis

There are four categories in which resource types can be categorized based on Plan/Forecast basis:

Quantity - The Quantity, Rate, Cost (Rate) and Revenue (Rate) columns will be enabled for planning. Forecasted Cost and Forecasted Revenue are calculated based on Forecasted Quantity.
Cost and Revenue - The Cost and Revenue columns will be enabled for planning.
Revenue - Only the Revenue column will be enabled for planning.
Cost - Only the Cost column will be enabled for planning.

In CPM, the following forecasting methods are used:

Forecast based on Actuals: This method is suitable for those projects which are time bound and flexible with respect to cost. The Actuals and remaining Plan derive the EAC for the project. The EAC is calculated by summing up actuals from the past periods and remaining planning for future periods.
Forecast based on Constant EAC: This method is suitable for those projects which are cost bound but flexible with respect to time. When the forecast is executed for the first time, the EAC will be copied as total plan value. The EAC remains constant throughout the forecast process until it is manually adjusted by changing ETC. In case the Actuals are not same as corresponding Planned values up to forecast period, the balanced value is adjusted to the future period. This adjustment is the difference between planned value up to forecast period and Actual value up to forecast period. If the adjustment is negative, then the ETC for the next period(s) will be reduced by this adjustment. Therefore ETC is re-calculated based on Actuals incurred while keeping the EAC constant.
Forecast based on Configuration: It is the dynamic forecasting method and is the combination of both the above methods. It is suitable for those projects where certain resources are time bound and others are cost bound. Each Resource Type can be configured to follow one of the above forecasting method.

Period Options in Forecasting

The following period options are available for forecasting:

In-Period Forecasting: Forecasting is performed at any time during an open period using the actuals posted up to that point, along with the remaining forecast for the rest of the period. Project Manager is allowed to adjust the forecast for current forecast period.
Period-End Forecasting: Forecasting is performed while closing the period, that is, when all actuals for that period have been posted. This provides a forecast based on complete actual data for the period.

There are different Planning Functions associated based on forecast method and the period option selected. These Planning Functions contain multiple formulae. Based on the above Resource types, the corresponding formula of the Planning Function will be executed. These formulae are part of BW IP Planning Function which gets executed when user executes the forecast.

Each forecasting scenario is described in detail with examples in the following blogs: