SAP Community - SAP HANA Cloud

Beyond Vectors: The Next Evolution of RAG on SAP BTP using SAP HANA Cloud

2026-01-05T16:24:19.911000+01:00

Introduction

We are all familiar with Retrieval-Augmented Generation (RAG) by now. It has become the standard architecture for bringing enterprise data to Large Language Models (LLMs). The pattern is simple: chunk your documents, create vector embeddings, and perform a similarity search.

But as we move from "Proof of Concept" to production, we are hitting a ceiling.

Standard Vector RAG is excellent at finding things that "sound like" your query (semantic similarity), but it struggles with structure and reasoning. It can tell you that "Alice works at SAP," but it often fails at multi-hop questions like "Who works in the same department as the person who wrote the Q3 report?"

This is where GraphRAG enters the picture. And the best part? If you are on SAP BTP, you already have one of the most powerful engines for this architecture: SAP HANA Cloud.

The Limitations of "Flat" Data

In a standard Vector Store, your data is essentially a pile of isolated chunks. When you search, you grab the top 5 chunks from the pile. You lose the context of how those chunks relate to one another.

This becomes even more critical when dealing with Multimodal Data. Real-world enterprise documents aren't just text; they are PDFs containing diagrams, flowcharts, and architecture schematics. In a standard vector process, these images are often ignored or separated from the text that explains them.

The Solution: Hybrid GraphRAG

The next evolution of AI on SAP BTP isn't about choosing between Vector Search or Knowledge Graphs. It is about using both. I have been exploring a "Hybrid" approach where we use:

The Vector Engine (built into SAP HANA Cloud) for fuzzy, semantic search.
The Graph Engine (RDF/SPARQL in SAP HANA Cloud) for precise, structured relationships.

Imagine SAP HANA Cloud as a "Super Librarian." It has a messy pile of fuzzy ideas (Vectors) and a neat corkboard of connected facts (The Knowledge Graph). To answer a complex business question, the system checks the fuzzy pile to understand the intent, but validates the answer against the corkboard to ensure factual accuracy.

Multimodal RAG: Keeping Context Intact

One of the most exciting capabilities of this hybrid approach is handling mixed media.

When processing complex documentation (like technical manuals or financial reports), we can use the graph to create structural links. We can index a diagram or an image not just by what is inside it, but by where it sits in the document.

By modeling the document structure in the Knowledge Graph (e.g., TextChunk A -> ADJACENT_TO -> Image B), we ensure that when an LLM retrieves the text explanation, it automatically pulls the relevant diagram along with it. This creates a true Multimodal RAG experience that "sees" the document the way a human does.

Why SAP HANA Cloud?

Usually, building this architecture requires a complex stack: a vector database (like Pinecone), a graph database (like Neo4j), and a relational database to glue them together.

SAP HANA Cloud is unique because it is truly multi-model (yes it's also multimodal with this library). You can store your vectors, your RDF triples, and your relational metadata all in the same persistence layer. This simplifies the architecture immensely and reduces data movement, which is critical for enterprise security and latency.

A New Framework for SAP Developers

To prove this concept, I have developed a TypeScript framework designed specifically for Node.js environments on SAP BTP. It acts as a bridge, orchestrating the interaction between the LLM (via LiteLLM) and SAP HANA Cloud’s dual engines.

The framework handles:

Schema-Guided Extraction: Using LLMs to turn unstructured text into clean Knowledge Graph entities (Nodes and Edges).
Hybrid Retrieval: Performing a vector search and then traversing the graph to find related context (including images).
Unified Storage: Managing both the REAL_VECTOR data and RDF Triples in a single connection.

Learn More

If you are interested in building the next generation of context-aware AI agents on SAP BTP, I invite you to read the full technical breakdown here (collaboration on the repo welcome!):

👉 Read the full article on Medium: Beyond Vectors - Building Powerful Graph RAG on SAP BTP

Let’s move beyond simple similarity search and start building AI that truly understands the structure of our enterprise data.

Simplifying Time Series Analytics with Unified Time Series Interface

2026-01-08T23:36:27.942000+01:00

Time series analysis is fundamental in industries ranging from retail to finance, helping businesses forecast trends, predict anomalies, and optimize operations. Traditional approaches, however, often require complex preprocessing, data conversion, and algorithm selection, posing challenges for less technical users.

To address these issues, SAP HANA Predictive Analysis Library (PAL) has introduced a unified interface for time series algorithms. Following the successful implementation of its unified classification and regression interfaces, this update aims to make time series analysis more efficient and user-friendly.

In this blog post, we explore the latest features of this unified interface and showcase an example to illustrate its usage.

Key Highlights

Let’s dive into new interface's key features in detail:

Unified Workflow

The unified interface streamlines the management of PAL algorithms by providing a standardized structure for invoking them. This simplifies parameter handling and data preparation for individual algorithms, enhancing efficiency and ease of use. Supported algorithms include Additive Model Time Series Analysis (AMTSA), Auto Regressive Integrated Moving Average (ARIMA), Bayesian Structural Time Series (BSTS), and Exponential Smoothing (SMOOTH).

Automatic Timestamp Conversion

The datasets of different time series analysis tasks can have diverse time formats, therefore automatic timestamp conversion is introduced in new unified interface. This feature automatically detects and converts between integer timepoints and timestamp types. To convert timepoints to timestamps, users must define START_POINT and INTERVAL. INTERVAL represents the spacing between timestamps, measured in the smallest unit of the target type (TARGET_TYPE). For instance, if the target type is DAYDATE and a weekly interval is desired, the INTERVAL value would be set to 7. Conversely, converting timestamps to timepoints is automated, with the system generating consecutive integers based on input timestamps. However, the input timestamps should be evenly spaced for this conversion to function effectively.

Pivoted Input Data Format Support

Traditionally, additional steps are required to transform the pivoted data into a usable format. To simplify this data preparation process, the new unified interface directly supports pivoted input data formats. This feature is particularly beneficial for complex, multidimensional time series data. The structure of input data is defined in the metadata table, as illustrated below.

CREATE COLUMN TABLE PAL_META_DATA_TBL (
    "VARIABLE_NAME" NVARCHAR (50),
    "VARIABLE_TYPE" NVARCHAR (50)
);
INSERT INTO PAL_META_DATA_TBL VALUES ('TIMESTAMP', 'CONTINUOUS');
INSERT INTO PAL_META_DATA_TBL VALUES ('Y', 'TARGET');

Massive Mode Capability

When dealing with vast datasets, users can leverage "massive mode" in unified interface. This mode enables algorithms to process multiple datasets simultaneously, with each dataset being executed independently and in parallel. To learn more about massive mode, visit the page on Massive Execution of PAL Functions.

Example

Let’s demonstrate the new interface with an example. Note that the code provided is purely for illustrative purposes and is not intended for production use.

The dataset is the Beijing PM2.5 data from the UCI Machine Learning Repository. It comprises hourly recordings of PM2.5 levels (airborne particles with aerodynamic diameters less than 2.5 μm) collected by the US Embassy in Beijing between January 1, 2010, and December 31, 2014. Additionally, meteorological data from Beijing Capital International Airport is included. The objective is to predict PM2.5 concentrations using various input features.

This dataset contains 43,824 rows and 11 columns. During preprocessing, the year, month, day, and hour columns were merged into a single 'date' column, and rows with missing values were addressed. The restructured dataset included the following 9 columns.

date: Timestamp of the record

pollution: PM2.5 concentration (ug/m^3)

dew: Dew Point

temp: Temperature

press: Pressure (hPa)

wnd_dir: Combined wind direction

wnd_spd: Cumulated wind speed (m/s)

snow: Cumulated hours of snow

rain: Cumulated hours of rain

To make it more manageable for demonstration purposes, we selected the first 1,000 instances. From this selection, we allocated 990 instances to the training set and reserved the final 10 for the testing set. Here's a glimpse at the first five rows of the training set.

Once the data is loaded, the model can be trained, and results can be obtained using the following annotated SQL script.

--########## COLUMN TABLE CREATION ##########
CREATE COLUMN TABLE PAL_PARAMETER_TBL__0 ("PARAM_NAME" NVARCHAR(256), "INT_VALUE" INTEGER, "DOUBLE_VALUE" DOUBLE, "STRING_VALUE" NVARCHAR(1000));
CREATE COLUMN TABLE PAL_MODEL_TBL__0 ("INDEX" NVARCHAR (50), "CONTENT" NCLOB);
CREATE COLUMN TABLE PAL_STATISTICS_TBL__0 ("NAME" NVARCHAR (50), "VALUE_1" DOUBLE, "VALUE_2" DOUBLE, "VALUE_3" DOUBLE, "VALUE_4" DOUBLE, "VALUE_5" DOUBLE, "REASON" NVARCHAR (50));
CREATE COLUMN TABLE PAL_DECOMPOSE_TBL__0 ("TIME_STAMP" NVARCHAR (50), "TREND" DOUBLE, "SEASONAL" DOUBLE, "REGRESSION" DOUBLE, "RANDOM" DOUBLE);
CREATE COLUMN TABLE PAL_PLACE_HOLDER_TBL__0 ("OBJECT" NVARCHAR (10), "KEY" NVARCHAR (10), "VALUE" NVARCHAR (10));
CREATE COLUMN TABLE PAL_PREDICT_PARAMETER_TBL__0 ("PARAM_NAME" NVARCHAR(256), "INT_VALUE" INTEGER, "DOUBLE_VALUE" DOUBLE, "STRING_VALUE" NVARCHAR(1000));
CREATE COLUMN TABLE PAL_PREDICT_RESULT_TBL__0 ("TIME_STAMP" NVARCHAR (50), "FORECAST" DOUBLE, "VALUE_1" DOUBLE, "VALUE_2" DOUBLE, "VALUE_3" DOUBLE, "VALUE_4" DOUBLE, "VALUE_5" DOUBLE);
CREATE COLUMN TABLE PAL_PREDICT_DECOMPOSITION_TBL__0 ("TIME_STAMP" NVARCHAR (50), "VALUE_1" DOUBLE, "VALUE_2" NCLOB, "VALUE_3" NCLOB, "VALUE_4" NCLOB, "VALUE_5" NCLOB);
CREATE COLUMN TABLE PAL_PREDICT_PLACE_HOLDER_TBL__0 ("OBJECT" NVARCHAR (50), "KEY" NVARCHAR (50), "VALUE" NVARCHAR (50));

--########## TABLE INSERTS ##########
-- The training data is stored in PAL_DATA_TBL__0, and the prediction data in PAL_PREDICT_DATA_TBL__0.
--########## PAL_PARAMETER_TBL__0 DATA INSERTION ##########
-- Specify algorithm type, 0: AMTSA, 1: ARIMA, 2: BSTS, 3: SMOOTH
INSERT INTO PAL_PARAMETER_TBL__0 VALUES ('FUNCTION', 0, NULL, NULL);

--########## UNIFIED INTERFACE FOR TIME SERIES CALL ##########
DO BEGIN
  lt_data = SELECT * FROM PAL_DATA_TBL__0;
  lt_param = SELECT * FROM PAL_PARAMETER_TBL__0;
  CALL _SYS_AFL.PAL_UNIFIED_TIMESERIES (:lt_data, :lt_param, lt_model, lt_stat, lt_decom, lt_ph);
  lt_pdata = SELECT * FROM PAL_PREDICT_DATA_TBL__0;
  lt_pparam = SELECT * FROM PAL_PREDICT_PARAMETER_TBL__0;
  CALL _SYS_AFL.PAL_UNIFIED_TIMESERIES_PREDICT (:lt_pdata, :lt_model, :lt_pparam, lt_result, lt_decomp, lt_pph);
  INSERT INTO PAL_PREDICT_RESULT_TBL__0 SELECT * FROM :lt_result;
  INSERT INTO PAL_PREDICT_DECOMPOSITION_TBL__0 SELECT * FROM :lt_decomp;
END;

--########## SELECT * TABLES ##########
SELECT * FROM PAL_PREDICT_RESULT_TBL__0;
SELECT * FROM PAL_PREDICT_DECOMPOSITION_TBL__0;

--########## TABLES CLEANUP ##########
DROP TABLE PAL_PARAMETER_TBL__0;
DROP TABLE PAL_MODEL_TBL__0;
DROP TABLE PAL_STATISTICS_TBL__0;
DROP TABLE PAL_DECOMPOSE_TBL__0;
DROP TABLE PAL_PLACE_HOLDER_TBL__0;
DROP TABLE PAL_PREDICT_PARAMETER_TBL__0;
DROP TABLE PAL_PREDICT_RESULT_TBL__0;
DROP TABLE PAL_PREDICT_DECOMPOSITION_TBL__0;
DROP TABLE PAL_PREDICT_PLACE_HOLDER_TBL__0;

You can view the model, prediction results, and decomposition in the output tables. Below are illustrative snapshots of the output tables.

The composition of the resulting tables depends on the selected algorithm. For AMTSA, the result table includes the predicted values along with the lower and upper bounds of the uncertainty intervals. Additionally, the decomposition table provides various components, such as trend, seasonality, and others.

Summary

The unified interface is introduced to simplify the usage of PAL algorithms. This blog post highlights the key features addressing challenges in time series analysis, such as varied time formats, pivoted data structures, and handling large data volumes. This new interface makes it easier for users to unlock the potential of their temporal data.

New Machine Learning, NLP and AI features in SAP HANA Cloud 2025 Q3

2026-01-09T12:54:46.437000+01:00

With the SAP HANA Cloud 2025 Q3 release, several new embedded Machine Learning / AI functions have been released with the SAP HANA Cloud Predictive Analysis Library (PAL) and the Automated Predictive Library (APL).

An enhancement summary is available in the What’s new document for SAP HANA Cloud database 2025.28 (QRC 3/2025).

Time series analysis and forecasting function enhancements

Threshold support in timeseries outlier detection

In time series, an outlier is a data point that is different from the general behavior of remaining data points. In the PAL time series outlier detection function, the outlier detection task is divided into two steps

In step 1 the residual values are derived from the original series,
In step 2, the outliers are detected from the residual values.

Multiple methods are available to evaluate a data point to be an outlier or not.

Including Z1 score, Z2 score, IIQR score, MAD score, IsolationForest, DBSCAN
If used in combination, outlier voting can be applied for a combined evaluation.

Now, new and in addition, thresholds values for outlier scores are supported

New parameter OUTPUT_OUTLIER_THRESHOLD
Based on the given threshold value, if the time series value is beyond the (upper and lower) outlier threshold for the time series, the corresponding data point as an outlier.
Only valid when outlier_method = 'iqr', 'isolationforest', 'mad', 'z1', 'z2'.

Classification and regression function enhancements

Corset sampling support with SVM models

Coreset sampling is a machine learning technique to

select a small, representative subset (the "coreset") from larger datasets,
enabling faster, more efficient training and processing while maintaining similar model accuracy as using the full data.
It works by identifying the most "informative" samples, filtering out redundant or noisy data, and allowing complex algorithms to run on a manageable dataset sizes.

Support Vector Machine (SVM) model training is computationally expensive, and computational costs are specifically sensitive to the number of training points, which makes SVM models often impractical for large datasets.

Therefore SVM in the Predictive Analysis Library has been enhanced and now

offers embedded coreset sampling capabilities
enabled with the new parameters USE_CORESET and CORESET_SCALE as the sampling ratio when constructing coreset.

This enhancement significantly reduces SVM training time with minimal impact on accuracy.

AutoML and pipeline function enhancements

Target encoding support in AutoML

The PAL AutoML framework introduces a new pipeline operator for target encoding of categorial features

Categorical data is often required to be preprocessed and required to get converted from non-numerical features into formats suitable for the respective machine learning algorithm, i.e. numeric values
- Examples features: text labels (e.g., “red,” “blue”) or discrete categories (e.g., “high,” “medium,” “low”)
One-hot encoding converts each categorial feature value into a binary column (0 or 1), which works well for features with a limited number of unique values. PAL already applies an optimized one-hot encoding method aggregating very low frequent values.
Target encoding replaces the categorial values with the mean of the target / label column for high-cardinality features, which avoids to create large and sparse one-hot encoded feature matrices
- Example of a high cardinality feature: “city” column with hundreds-thousands of unique values, postal code, product IDs etc.

The PAL AutoML engine will analyze the input feature cardinality and then automatically decide if to apply target encoding or another encoding method. For medium to high cardinality categorial features, target encoding may improve the performance significantly.

By automating target encoding, the PAL AutoML engine aims to improve model performance and generalization, especially when dealing with complex, high-cardinality categorical features, without requiring manual intervention.

In addition, the AutoML and pipeline function now also support columns of type half precision vector.

Misc. Machine Learning and statistics function enhancements

High-dimensional feature data reduction using UMAP

UMAP (Uniform Manifold Approximation and Projection) is a non-linear dimensionality reduction algorithm used to simplify complex, high-dimensional feature spaces, while preserving its essential structure. It is widely considered the modern gold standard for visualizing targeted dimension reduction of large-scale datasets, because it balances computational speed with the ability to maintain both local and global relationships.

It reduces thousands of variables (dimensions) into 2D or 3D scatter plots that humans can easily interpret.
Unlike comparable methods like t-SNE, UMAP is better at preserving global structure, meaning the relative positions between different clusters remain more meaningful.
It is significantly faster and more memory-efficient than t-SNE, capable of processing datasets with millions of points in a reasonable timeframe.
It can be used as a "transformer" preprocessing step in Machine Learning scenarios to reduce large feature spaces before applying clustering (e.g., k-means, HDBSCAN) or classification models, often improving their performance.

The following new functions are introduced

_SYS_AFL.PAL_UMAP with the most important parameters N_NEIGHBORS, MIN_DIST, N_COMPONENTS, DISTANCE_LEVEL

_SYS_AFL.PAL_TRUSTWORTHINESS, used to measure the structure similarity between original high dimensional space and embedded low dimensional space based on K nearest neighbors.

Calculating pairwise distances

Many algorithms, for example clustering algorithms utilize distance matrixes as a preprocessing step, often inbuild to the functions. While often there is the wish to decouple though the distance matrix calculation from the follow-up task like the actual clustering. Moreover, if decoupled custom calculated matrixes can be fed into algorithms as input.

Most PAL clustering functions support to feed-in a pre-calculated similarity matrix

Now, a dedicated pairwise distance calculation function is provided

It supports distance metrics like Manhattan, Euclidien, Minkowski, Chebyshey as well as Levenshtein
The Levenshtein distance (or “edit distance”) is a distance metric specifically targeting distance between text-columns.
- It calculates the minimum number of single-character edits (insertions, deletions, or substitutions) needed to transform one word into another, acting as a measure of their similarity. A lower distance indicates a higher similarity.

Applicable use cases

It is useful in data cleaning, table column similarity analysis between columns of the same data type.
After calculating the column similarity across all data types, clustering like K-Means can be applied to group similar fields and propose mappings for fields within the same cluster

Real Vector data type support

The following PAL functions have been enhanced to support columns of type real vector

Spectral Clustering
Cluster Assignment
Decision tree
Sampling

In addition the AutoML and pipeline function now also support columns of type half precision vector.

Creating Vector Embeddings enhancements

The SAP HANA Database Vector Engine function VECTOR_EMBEDDING() has added support for remote, SAP AI Core exposed embedding models. Detailed instruction are given in the documentation at Creating Text Embeddings with SAP AI Core | SAP Help Portal

Python ML client (hana-ml) enhancements

The full list of new methods and enhancements with hana_ml 2.26 is summarized in the changelog for hana-ml 2.26 as part of the documentation. The key enhancements in this release include

New Functions

Added text tokenization API.
Added explainability support with IsolationForest Outlier Detection
Added constrained clustering API.
Added intermittent time series data test in time series report.

Enhancements

Support time series SHAP visualizations for AutoML Timeseries model explanations

You can find an examples notebook illustrating the highlighted feature enhancements here 25QRC03_2.26.ipynb.

SAP HANA Cloud release January 2026 Round-up

2026-01-14T11:36:32.644000+01:00

Dear SAP HANA Cloud Enthusiasts,

We are thrilled to share a comprehensive collection of the latest videos, blogposts, and resources from the SAP HANA Cloud Q4 2025 release.

	What’s New Teaser Discover the newest advancements in SAP HANA Cloud with Lead Product Manager Thomas Hammer, as he highlights his top features from the latest 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 December 2025" 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

Code Connect 2026 is Coming – Mark Your Calendars!

2026-01-16T10:17:39.514000+01:00

We’re excited to announce the return of Code Connect for its third edition, bringing together three dynamic events - UI5con, reCAP, and HANA Tech Con - under one roof. Mark your calendars for July 13 to 16, 2026, and join us in St. Leon-Rot, Germany, or online.

What is Code Connect?

Code Connect creates a unique opportunity to experience three specialized events in one location: UI5con, reCAP, and HANA Tech Con, allowing you to dive deep into different aspects of SAP development. Code Connect is designed for developers at every level: Whether you're an SAP veteran or just starting out, this is your chance to connect, learn, and innovate alongside a vibrant community of developers.

Your Week at Code Connect

July 13: Code Jam Sessions and Warmup

Kick things off with our Code Jam sessions - a hands-on way to sharpen your skills before the main event. Afterward, join us for a pre-conference networking event to meet fellow attendees in a relaxed setting.

July 14: UI5con

The official program kicks off with UI5con, bringing together UI5 enthusiasts to share insights, explore the latest innovations, and build new connections. Expect expert sessions, interactive workshops, and plenty of opportunities to engage with the UI5 community.

Learn more about UI5con.

July 15: reCAP

The next day focuses on the SAP Cloud Application Programming Model (CAP). At reCAP, developers, customers, and partners meet the CAP Product Team to discuss technical concepts, share project experiences, and explore future possibilities.

Learn more about reCAP.

July 16: HANA Tech Con

The week concludes with HANA Tech Con. Delve into the HANA universe and join development experts, users, and partners to exchange knowledge and ignite new ideas. If you've ever had questions about HANA that you haven't found answers to, this is your chance to get them resolved.

Learn more about HANA Tech Con.

Early Bird Process

Planning a longer trip? We offer a limited number of early bird tickets for attendees who need to arrange travel well in advance.

Check our FAQ document for details on how to secure your ticket.

Sponsorship Opportunities

Be a part of Code Connect 2026 and become a sponsor to support the developer community at UI5con, reCAP, and HANA Tech Con. By sponsoring Code Connect, you gain access to a diverse audience spanning front-end developers, backend specialists, and database experts – all in one event.

Read our sponsorship prospectus to check our sponsorship opportunities.

Call for Proposals

Our Call for Speakers runs from 26 January to 13 March. As a speaker, you’ll be an active part of Code Connect, shaping the conversation, sharing your expertise, and inspiring the developer community. Don’t wait and submit your session proposal by 13 March at the latest.

Important Dates

Call for Proposals: January 26, 2026 to March 13, 2026.
Registration Opens: April 10, 2026
Agenda Published: Early June 2026
Code Connect Week: July 13 to 16, 2026

Ready to Connect?

Code Connect 2026 represents more than just learning opportunities. It's about building relationships, sharing knowledge, and being part of a community that's shaping the future of SAP development.

Join us at Code Connect 2026 and be part of a community driving the future of technology. We can't wait to see you there!

Good to know: Analyzing Runtime Dump (SAP HANA Dump Analyzer vs Visual Studio Code)

2026-01-20T08:53:33.889000+01:00

last updated: 2026-01-20

Why was this blog post created?

SAP HANA Dump Analyzer is a well-known and long-used tool. Same analysis can be done in Visual Studio Code - Supportability tools for SAP HANA (SAP Extension). It's worth getting acquainted with the new tool.

Where can I find the most important information about the SAP HANA Dump Analyzer and Visual Studio Code - Supportability tools for SAP HANA?

SAP Community Article: Where can I find knowledge and information belongs to SAP HANA?

section Runtime Dump (RTE)
section SAP HANA Dump Analyzer

SAP Community Article: Where can I find information about the available tools for SAP HANA (all types of use)?

section Visual Studio Code - Supportability tools for SAP HANA
section SAP HANA Dump Analyzer

What are the experiences based on the comparison of the tools?

The same analysis can be performed with both tools. The presentation is slightly different, with Visual Studio Code providing a fresher, more modern look, but the information in the reports is exactly the same. If Visual Studio Code is already installed, you can access a very useful analytical tool, with just adding the necessary SAP extension.

	SAP HANA Dump Analyzer	Visual Studio Code - Supportability tools for SAP HANA
Design	Old school.	Modern.
Look and feel	Well structured.	Well structured but more compact.
What will be the generated result?	.HTML file	Result will be opened in the application.
Can the various details and data be cut and copied?	Yes.	Yes.
Export	.HTML file	N/A

Generated report in SAP HANA Dump Analyzer

The below example shows an outcome which generated via "Auto Analyzer" option. Other option is the "Expert Mode" - - > "Runtime Dump Mini Check". In some case there is a need to to generate both type of output for better understanding the issue.

Summary Info tab where system related information and detected issues presented.

In this example HANA Workload Analysis tab exists because this kind of issue has been identified.

Pie chart and highlighted statement hash gives us important information regarding the issue.

In this example Blocked Transactions tab exists because this kind of issue has been identified.

With Blocked Transaction wait Graph option we can get further details.

Generated report in Visual Studio Code - Supportability tools for SAP HANA

In Visual Studio Code we need to generate a work folder and import the files.

In this example High Workload tab exists because this kind of issue has been identified.

In this example Many Transactions Blocked tab exists because this kind of issue has been identified.

What is the conclusion?

Complete analysis can be performed using Visual Studio Code without installing the previously used SAP HANA Dump Analyzer. However, the old tool can be easily exported by saving it as a simple .html file, and with this action, the entire content can be stored offline and attached to an email, case, etc.

Do you have further questions?

Please do not hesitate to contact me if you have question or observation regarding the article.
Q&A link for SAP HANA: https://answers.sap.com/tags/73554900100700000996

Contribution

If you find any missing information belongs to the topic, please let me know. I am happy to add the new content. My intention is to maintain the content continuously to keep the info up-to-date.

Release Information

Release Date	Description
2026.01.20	First/initial Release of the SAP Blog Post documentation (Technical Article).

SAP RPT‑1: Why is it Essential for Predicting Business Outcomes in Today’s and Future Generative AI?

2026-01-26T05:55:37.670000+01:00

Ever since the introduction of ChatGPT in November 2022, Generative AI has reshaped the AI industry. Companies like Amazon, Google, Microsoft, and of course SAP have accelerated innovation, recognizing the enormous value Generative AI and Large Language Models (LLMs) bring to enterprise operations.

General‑purpose LLMs excel at understanding language, reasoning over text, and identifying patterns in unstructured information. They are creative, adaptive, and capable of leveraging data from files, documents, and multimedia across diverse data systems.

The Motive

However, when it comes to actually predicting business outcomes, LLMs fall short. Why?
Because they are not designed for high‑precision, multi‑step reasoning over large, enterprise‑grade tabular datasets.

And this is where the majority of business data resides: structured tables, such as GL accounts, invoices, inventory, sales records, financial transactions, and countless others. Not in free‑form text.

Everyone wants to be able to predict business outcomes like:

What is the probability of converting a sale?
Which customers are likely to pay late?
Who is at risk of churn?
...

Historically, answering these questions required traditional machine learning like classification models, linear regression, etc. (a.k.a Traditional AI or Narrow AI). The problem with this is that classical ML requires to train a model per task, which easily can lead to hundreds of separate models hard to maintain in the long run, making it very cumbersome, expensive and extremely difficult to scale.

The Solution: SAP RPT-1

To solve this, SAP introduced in TechEd 2025 the first foundation model specifically designed for structured enterprise data: Relational Pre‑Trained Transformer 1 (RPT‑1). The model is trained natively on tabular business datasets and is engineered to understand rows, columns, joins and business semantics out of the box. As the name suggests, RPT‑1 is:

Relational: optimized for structured relational business data
Pre‑trained: powered by tens of thousands of GPU hours (no more endless classical ML training cycles)
Transformer‑based: performs logical, not linguistic, transformations (e.g., filtering, joining, aggregating, and multi‑step reasoning)

Instead of hundreds of ML models, you now can use one single foundation model for many predictive tasks.

One of the most disruptive features of RPT‑1 is its in‑context learning capability. Instead of training or fine‑tuning multiple modes, you simple provide historical rows of data and request predictions for new rows. Prediction cases like:

Customer churn prediction
Late delivery prediction
Late payment prediction
Sales conversion prediction
And many more

RPT‑1 Performance Benchmark

RPT-1 outperforms both LLM and classical ML for tabular data and high value agentic cases. Here are some stats so far:

50x faster than LLMs
Up to 2x Prediction Quality vs Narrow AI/ML Models
Up to 3.5x Prediction Quality vs LLMs
100,000x fewer GPU FLOPs
50,000x Less Energy consumption vs LLMs*

*comparable tasks on a NVIDIA H100, as a benchmark. Sources (TechEd, Blog) .

Why are these stats so important? On top of the benefits you can already imagine like time and resource savings; according to Gartner 40% of agentic-AI projects are likely to be canceled by end of 2027, mainly because of high cost, complexity, or unclear business value (source). RPT‑1 directly addresses these challenges.

Sales Conversion Prediction Example Use Case

During SAP TechEd, a compelling demo showcased how RPT‑1 integrates with SAP’s Agentic AI.

Imagine a sales team wanting to prioritize leads based on their likelihood to convert. Instead of manually training an ML model, a data analyst can use Joule to generate SQL code leveraging RPT‑1’s PREDICT function.

Steps include:

Join sales inquiries, historical performance, customer attributes, and other relevant data into a Data Product in SAP Business Data Cloud.
Expose the Data Product to SAP HANA Cloud via zero‑copy.
Use RPT‑1 to instantly generate a new prediction column "sales_conversion_probability"; without training or tuning.

The model derives patterns directly from the historical data and produces high‑quality prediction scores.

You can watch the full demo here (jump to minute 35:23).

Available RPT‑1 Versions

SAP RPT‑1 has been generally available since Q4 2025. You can choose from:

SAP RPT‑1 Small: optimized for speed and efficiency
SAP RPT‑1 Large: optimized for highest accuracy by using more capacity
SAP RPT‑1 OSS (Open Source): available on HuggingFace and Github for exploration and learning

Try it yourself!

Don’t have access to a BTP account yet? here is an entry point:

Sign up for a 30-day SAP Generative AI Hub trial
Follow this step-by-step guide to get started by @sherene_tan

Conclusion

SAP RPT‑1 represents a major shift in how enterprises will deliver predictive insights in the GenAI era. While LLMs excel at language understanding, they are not built for structured, relational business data. RPT‑1 closes this gap and eliminates the complexity of traditional machine learning, drastically reducing cost and compute.

With SAP RPT-1's foundation model purpose‑built for enterprise-grade tabular data, the objective is to enable organizations to operationalize predictive insights faster, more efficiently, and more accurately than ever before.

Developing HANA ML models with SAP Databricks

2026-02-04T14:10:52.496000+01:00

Introduction

SAP HANA provides a rich set of Machine Learning capabilities natively which can be used via SQL or python interface. For an introduction to these capabilities you can refer to HANA Machine Learning and Developing Regression Models with the Python Machine Learning Client for SAP HANA learning journey and this excellent blog post from @YannickSchaper.

In this blogpost I will walkthrough the capabilities that enhance the power of hana-ml with the model tracking capabilities provided by mlflow . The python package hana-ml has supported the tracking and usability of trained ml models via mlflow which are covered extensively in these 2-part blogposts tracking-hana-machine-learning-experiments-with-mlflow-a-conceptual-guide from @stojanm and @martinboeckling . In this post I will focus on the Databricks managed mlflow as it greatly eases the use of mlflow without having to setup the mlflow server. These capabilities are available both in SAP Databricks from SAP Business Data Cloud(BDC) and Enterprise Databricks for customers who connect Databricks to BDC via bdc-connect. For this blogpost I will be using SAP Databricks provisioned with SAP Business Data Cloud.

With the launch of SAP Business Data Cloud, developers have a much more streamlined access to AI/ML capabilities both from SAP and Databricks. This applies to data available via the Unity Catalog or accessible via the SQL access. Here I will focus on the Notebook capabilities and Training and Inference on datasets in the HANA Cloud layer accessed via SQL and utilize the compute of HANA Cloud.

The datasets in HANA Cloud could be data persisted in HANA or remotely available via federation from HDLFS or BDC Data Products installed to embedded HANA Cloud from Datasphere.

Connect to ML datasets on HANA Cloud

To connect to data on the HANA Cloud, be it the embedded HANA Cloud of SAP Datasphere or a stand-alone HANA Cloud, one needs the 4 parameters which provide the url, port(443), username and password.

Prerequisites

In addition the HANA Cloud or Datasphere instance needs to have the Databricks IP to the Allow-list to enable connection.

The database user needs to have the following privileges which are provided by the HANA Cloud or Datasphere administrator

AFL__SYS_AFL_AFLPAL_EXECUTE_WITH_GRANT_OPTION
AFL__SYS_AFL_APL_AREA_EXECUTE
AFLPM_CREATOR_ERASER_EXECUTE

For Datasphere these privileges are enabled when the administrator creates the database user with OpenSQL access and Enables APL and PAL

Connect to HANA from Databricks

Here is a code snippet to connect to the HANA Cloud SQL layer for data access using Databricks secret. For this you need to create the secrets needed for HANA Cloud connectivity like snippet below

from databricks.sdk import WorkspaceClient
w = WorkspaceClient() 
scope = "<scope-name>"
w.secrets.create_scope(scope)
url =  "<hana-url>"
port = 443
user = "<hana-db-user>"
password = "<hana-db-password>"
w.secrets.put_secret(scope,"hana_url",string_value =url)
w.secrets.put_secret(scope,"hana_port",string_value =port)
w.secrets.put_secret(scope,"hana_user",string_value =user)
w.secrets.put_secret(scope,"hana_password",string_value = password)

create_secrets

import os
import hana_ml
from hana_ml import dataframe
import mlflow

print("hana_ml version:", hana_ml.__version__)
print("mlflow version:", mlflow.__version__)
scope = "<scope_name>"
os.environ['HANA_ADDRESS'] = dbutils.secrets.get(scope=scope, key="hana_url")
os.environ['HANA_PORT']    = dbutils.secrets.get(scope=scope, key="hana_port")
os.environ['HANA_UNAME']   = dbutils.secrets.get(scope=scope, key="hana_user")
os.environ['HANA_PASS']    = dbutils.secrets.get(scope=scope, key="hana_password")
import hana_ml.dataframe as dataframe
cc = dataframe.ConnectionContext(
    address=os.environ['HANA_ADDRESS'],
    port=os.environ['HANA_PORT'],
    user=os.environ['HANA_UNAME'],
    password=os.environ['HANA_PASS']
)
if cc.connection.isconnected(): 
    print(f'User {os.environ["HANA_UNAME"]} connected to HANA successfully')
    print(f"HANA Version: {cc.hana_version()}")

Otherwise you can also connect via the python-dotenv, especially if you are developing locally.

Develop the ML model with mlflow

Here I will use a sample dataset provided by hana-ml package to make it easier to test. This would be replaced by the appropriate dataset the user wants to use for training the ML model.

from hana_ml.algorithms.pal.utility import DataSets
# Load Dataset
bike_dataset = DataSets.load_bike_data(cc)#This creates the correspoding table on HANA Cloud 
# number of rows and number of columns
print("Shape of datset: {}".format(bike_dataset.shape))
# columns
print(bike_dataset.columns)
# types of each column
print(bike_dataset.dtypes())

# print the first 3 rows of dataset
print(bike_dataset.head(3).collect())

#Split the dataset into train & test
# Add a ID column for AutomaticRegression, the last column is the label
bike_dataset = bike_dataset.add_id('ID', ref_col='days_since_2011')

# Split the dataset into training and test dataset
cols = bike_dataset.columns
cols.remove('cnt')
bike_data = bike_dataset[cols + ['cnt']]
bike_train = bike_data.filter('ID <= 600')
bike_test = bike_data.filter('ID > 600')
print(bike_train.head(3).collect())
print(bike_test.head(3).collect())

We used a basic splitting methodology above, hana-ml provides splitting capabilities via hana_ml.algorithms.pal.partition.train_test_val_split to assist in this process.

Now that we have a training and test dataset, we can start the training process and use mlflow to track the results in Databricks experiments via the code below

mlflow.set_tracking_uri("databricks")
experiment_path = '<experiment_path>' 
mlflow.set_experiment(experiment_path)
# Here we are using AutomaticRegression to show the metrics automatically created and tracked via mlflow
from hana_ml.algorithms.pal.auto_ml import AutomaticClassification, AutomaticRegression
auto_r = AutomaticRegression(generations=2,
                             population_size=15,
                             offspring_size=5)

# enable_workload_class if you have workload_classes defined on HANA Cloud instance, here we disable it but in productive scenarios you would have it enabled
#auto_r.enable_workload_class(workload_class_name="PAL_AUTOML_WORKLOAD")
auto_r.disable_workload_class_check()
try:
    with mlflow.start_run(run_name="hana-ml-autoreg-bike") as run:
        auto_r.enable_mlflow_autologging(is_exported=True)
        auto_r.fit(bike_train, key="ID")
        runid = run.info.run_id
except Exception as e:
    raise e

The enable_mlflow_autologging function above enables the creation of key model metrics automatically, in this case suitable for regression without any additional effort from the user. These metrics would differ based on the algorithm. The user can easily log additional parameters, metrics, artifacts as desired and supported my mlfow.

When the above code is run we get the experiments logged with default metrics that hana-ml model logged automatically via mlflow for example R2, RMSE etc below.

Databricks Experiment and mlflow with hana-ml

One can then compare different runs and track model progression as parameters are changed.Compare hana-ml mlflow runs

For inferencing on data the hana-ml model can be loaded to HANA Cloud via the code below, the run_id is the run from the Databricks Experiments that you would like to use for inference and can be obtained from the overview of the Experiment

from hana_ml.model_storage import ModelStorage
bikemodel = ModelStorage.load_mlflow_model(connection_context=cc, model_uri='runs:/{}/model'.format(runid))

#Get the info for the loaded model
bikemodel.mlflow_model_info

#Use the trained model for prediction on test or new dataset
res = bikemodel.predict(bike_test.deselect('cnt') , key="ID")
print(res.collect())
bike_test.deselect('cnt').save("INFERENCE_BIKE_DATA_TBL") #Saving this here for using later via the Serving Endpoint

Serve the ML model for inferencing

The hana-ml model can be served on BTP if desirable by exporting the ml model or store and reload the model for inference from HANA Cloud hana_ml.model_storage , in this case the HANA Cloud instance would need to be same for training and inferencing.

Alternatively, it can be served on Databricks via the Serving endpoint, I describe these below.

Databricks does not natively support the serving for the hana-ml model. However, this can be achieved via the mlflow.pyfunc functionality to provide custom models. I will be using the "model from code" method as it has advantages over the legacy methods and recommended going forward. This requires passing the custom handler as separate code. For this we write the python file which handles the desired input to the serving endpoint. In my example, I want the user to pass in the name of table which exists in HANA Cloud(in our example we saved it as

INFERENCE_BIKE_DATA_TBL

and has the data that needs to be inferenced. The user sends the name of the table to the inference endpoint. The code can be modified to have the input say as a payload to the inference end-point, in that case the custom handler function(hana_ml_pyfunc_model) would then need to persist the payload as a HANA table so the hana-ml predict can be called on it.

Create the custom handler for hana-ml

# Save as script: hana_ml_pyfunc_model.py
# %%writefile "./hana_ml_pyfunc_model.py"
import mlflow
from mlflow import pyfunc
from mlflow.models import set_model
import hana_ml
from hana_ml import dataframe
from hana_ml.model_storage import ModelStorage
import os


class hana_ml_pyfunc_model(pyfunc.PythonModel):

    def connectToHANA(self, context):
        try:
            url =  os.getenv('hana_url') 
            port = os.getenv('hana_port')
            user = os.getenv('hana_user')
            passwd = os.getenv('hana_password')
            connection_context = dataframe.ConnectionContext(url, port, user, passwd)
            return connection_context
        except Exception as e:
            print(f"Exception occurred: {e}")
            raise e
            return "Exception:{e}", e
    @mlflow.trace
    def load_context(self, context):
        try: 
            with mlflow.start_span("load_context"):
                self.model = context.artifacts["model"]
                self.connection_context = self.connectToHANA(context)
                print("HANA_ML_MODEL loaded in load_context")
        except Exception as e:
            print(f"Exception occurred: {e}")
            raise Exception(f"Loading the context failed due to {e}")
    @mlflow.trace
    def predict(self, context, model_input):
        table_name = None
        try: 
            if self.connection_context.connection.isconnected() == False:
                with mlflow.start_span("connect_to_HANA"):
                    self.connection_context = self.connectToHANA(context)
                    if self.connection_context.connection.isconnected():
                        print("HANA Connection Successful")
                    else:
                        raise Exception("HANA Connection Failed")
       
            with mlflow.start_span("load_model"):
                hana_model = ModelStorage.load_mlflow_model(connection_context=self.connection_context, model_uri=self.model,use_temporary_table=False, force=True)
           
                print("HANA_ML_MODEL loaded in predict")
                print("model_input", model_input)
                table_name = str(model_input["INFERENCE_TABLE_NAME"][0]) 
                print("Table Name:", table_name)
            with mlflow.start_span("hana_ml_predict"):
                df = self.connection_context.table(table_name)
                if df.count() > 0:
                  
                    print(f"Running HANA ML inference on {table_name} with {df.count()} records")
                    prediction = hana_model.predict(df, key = "ID").collect()
                    print("Prediction completed")
                else:
                    raise Exception(f"HANA Inference Table {table_name} is empty")
        
            return prediction
        except Exception as e:
            print(f"Exception occurred: {e}")
            raise f"Exception:{e}"
        
set_model(hana_ml_pyfunc_model())

Log the custom pyfunc model

Then we log the above pyfunc model which can be registered to enable the creation of a Serving endpoint on Databricks

#Create the signature for the model input and output. In this example:
# the input is the name of an existing table in HANA which has the data that needs to be inferenced 
# the output is the "cnt" counts for the bike data and the associated score
import mlflow
from mlflow.models import ModelSignature, infer_signature
from mlflow.types.schema import Schema, ColSpec
signature = ModelSignature(inputs = Schema([ColSpec("string", "INFERENCE_TABLE_NAME")]))
signature.outputs = Schema([ColSpec("integer", "ID"), ColSpec("double", "SCORES")])


mlflow.set_tracking_uri("databricks")
runid="<run_id>" #runid from the training phase which is the chosen champion model to be served
model_uri='runs:/{}/model'.format(runid)
experiment_name = '<experiment_name>' 
mlflow.set_experiment(experiment_name)

model_file = "hana_ml_pyfunc_model.py" #This is the file that is written in step above and handles the calll to hana_ml for predict on the user-provided inference table

with mlflow.start_run() as run:
    mlflow.pyfunc.log_model(
            artifact_path="model",
            python_model=model_file,
            artifacts={"model": model_uri},
            pip_requirements=["hana-ml","ipython"],
            signature = signature,
            input_example={"INFERENCE_TABLE_NAME" : "INFERENCE_BIKE_DATA_TBL"},
    )
# Register the model #Need to register the model to enable it to be served on Databricks
model_uri = f"runs:/{run.info.run_id}/model"
registered_model_name = "<your_model_name>"
mlflow.register_model(model_uri=model_uri, name=registered_model_name)

Test the custom pyfunc model

To test the logged model in step above you can call the following code

## Code to test the model logged as custom pyfunc model which can be registered and deployed for serving
logged_model = 'runs:/run.info.run_id/model' #run from the pyfunc model logging
dataset = {"inputs": {"INFERENCE_TABLE_NAME" : "INFERENCE_BIKE_DATA_TBL"}}
loaded_model = mlflow.pyfunc.load_model(logged_model)
loaded_model.predict(dataset["inputs"])

Additionally the model endpoint can also be tested by using package uv with code below

run_id = run.info.run_id #run from the pyfunc model logging
model_uri = f"runs:/{run_id}/model"
dataset = {"inputs": {"INFERENCE_TABLE_NAME" : "INFERENCE_BIKE_DATA_TBL"}}
input_data = dataset
mlflow.models.predict(
    model_uri=model_uri,
    input_data=dataset["inputs"],
    env_manager="uv",
)

Create the Serving Endpoint

Now we have a registered model that can be deployed for serving. To do this I show the steps here to do it via the Databricks Serving UI via the serving endpoint, it can also be done with code via Rest API or sdks. Go to Serving and Create a new Serving endpoint. Choose the registered_model_name from step above and add the environment variables for the HANA Cloud connection so the serving code can connect to HANA and call the model inference on user provided table name

Creating Serving Enpoint

HANA credentials as environment variables for deployment

Test the Serving Endpoint

The deployment as usual takes some minutes. Once the serving endpoint is in ready state, it can be tested with the usual ways when pressing Use

Here is a sample screenshot for testing it in the Browser

Test Serving

Here is the corresponding code to test via Python

import os,json,requests
os.environ['DATABRICKS_TOKEN'] = "<Developer_Token>" #Token obtained by following https://docs.databricks.com/aws/en/dev-tools/auth/pat

def score_model(dataset):
    url = '<serving_url>'
    headers = {'Authorization': f'Bearer {os.environ.get("DATABRICKS_TOKEN")}', 'Content-Type': 'application/json'}
    data_json = json.dumps(dataset, allow_nan=True)
    response = requests.request(method='POST', headers=headers, url=url, data=data_json)
    if response.status_code != 200:
        raise Exception(f'Request failed with status {response.status_code}, {response.text}')
    return response.json()

dataset = {'inputs': {'INFERENCE_TABLE_NAME' : "<hana_cloud_table_name_for_inference>"}}
res = score_model(dataset)
print(res)

Endpoint Consumption

The serving endpoint created above can be used in applications via rest API calls. In production the API would need to be secured via OAuth authenication . Here is a blogpost from @Ian_Henry describing how such an endpoint can be triggered from SAP Analytics Cloud for example.

Conclusion

In this blogpost we show the power combination of using SAP HANA Cloud and model experiment tracking & serving capabilities from SAP Databricks via managed mlflow. This is suitable for usecases where data already resides in the HANA layer and the performance benefits from running hana-ml in data accessible via HANA Cloud in-memory is desirable while benefitting from model development support provided by SAP Databricks.

The code for the above is available here on SAP-samples/hana-ml-samples.

Consuming Data Products in SAP HANA Cloud via SAP Business Application Studio/SAP Build Code

2026-02-06T19:35:45.324000+01:00

This blog post guides you through the process of consuming SAP HANA Cloud Data Products within SAP Business Application Studio (BAS). We will cover everything from the initial SQL security configurations to creating the final Calculation View.

Once a Data Product is installed in your SAP HANA Cloud instance, it exists as virtual tables in a specialized schema. To use it in a Cloud Application Programming (CAP) or HANA Native project in BAS, you must access the virtual tables from your HDI container.

Before you begin this blog, ensure you have followed the initial setup steps to locate and install your data product. I highly recommend completing this guide written by my colleague (Dan Van Leeuwen) : Access and Query a Data Product in SAP HANA Cloud.

Step 1: Assign the roles & privileges (SQL)

To ensure the technical users (HDI Container users) have permission to see the Data Product, We use a Role-Based approach to manage these permissions.

1. Create a dedicated role: This role will act as a container for all permissions related to your Purchase Order data.

CREATE ROLE VIRTUAL_TABLE_ON_PURCHASE_ORDER_OO;
CREATE ROLE VIRTUAL_TABLE_ON_PURCHASE_ORDER_RT;

2. Grant Select with Grant Option: This is crucial. The WITH GRANT OPTION allows the HDI Container user to share these privileges further (e.g., to the end-user reporting tools).

GRANT SELECT ON "_SAP_DATAPRODUCT_sap_s4com_dataProduct_PurchaseOrder_v1_4a6dc5d7-7af5-4b74-8ac7-b9ed0d1e6e95"."_SAP_DATAPRODUCT_57af9989-cf07-4a75-bc36-fddb382b4020_purchaseorder.PurchaseOrder"
TO VIRTUAL_TABLE_ON_PURCHASE_ORDER_OO WITH GRANT OPTION;

GRANT SELECT ON "_SAP_DATAPRODUCT_sap_s4com_dataProduct_PurchaseOrder_v1_4a6dc5d7-7af5-4b74-8ac7-b9ed0d1e6e95"."_SAP_DATAPRODUCT_57af9989-cf07-4a75-bc36-fddb382b4020_purchaseorder.PurchaseOrder"
TO VIRTUAL_TABLE_ON_PURCHASE_ORDER_RT;

3. Grants SELECT to the objects.

Spoiler

Granting these roles globally to BAS HDI container object owners and runtime users means that all HDI containers and therefore all BAS developers will automatically gain access to the virtual tables. If your intention is universal access, this approach avoids granting roles individually. However, be aware that it effectively broadens access scope system-wide, which may have governance, security, or compliance implications if more restricted access was intended.

Granting these roles globally to BAS HDI container object owners and runtime users means that all HDI containers and therefore all BAS developers will automatically gain access to the virtual tables. If your intention is universal access, this approach avoids granting roles individually. However, be aware that it effectively broadens access scope system-wide, which may have governance, security, or compliance implications if more restricted access was intended.

GRANT  VIRTUAL_TABLE_ON_PURCHASE_ORDER_OO TO "_SYS_DI#BROKER_CG"."_SYS_DI_OO_DEFAULTS";

GRANT  VIRTUAL_TABLE_ON_PURCHASE_ORDER_RT TO "BROKER_USER"."RT_DEFAULTS";

Step 2: Create your Project in SAP Business Application Studio

1. Open SAP Business Application Studio.

2. Create a new SAP HANA Native Application or a CAP Project. In this demo we are showcasing the SAP HANA Native application.

3. Ensure your project is connected to the correct Cloud Foundry Space and SAP HANA Cloud instance.

4. In the SAP HANA Projects view, click the expand icon to view your project and to check the binding of the HDI Container.

Step 3: Create the Calculation View

Right-click the src folder and select New File -> CV_PurchaseAnalysis.hdbcalculationview.
Choose Data Category as the CUBE and click create.

3.In the aggregation editor, find the data source

4.Click the + sign on the Aggregation node and search for your Purchase Order Table and click on Create Synonym.

5. You will see the below dialog and click finish.

6. Go to the mapping tab, and map the necessary columns to the output column.

6. Save and Deploy the file by clicking the "Deploy" icon (the rocket ship) in the SAP HANA Projects panel.

Step 4: Preview the Data

To confirm everything is working:

Right click on the aggregation node on your calculation view and click on Graphical SQL Data Preview.
Database Explorer will open in your BAS window. You can drag and drop the required columns and analyze your purchase order details
You should now see the live data flowing from the SAP S/4HANA Data Product directly into your BAS environment.

By following these steps, you’ve successfully bridged the gap between raw SAP HANA Cloud Data Products and a flexible development environment in SAP Business Application Studio.

Special thanks to my colleague jan_zwickel for their support and expert review in making this blog.

Thank you for your time.

AI Is Transforming Sales Order Processing in SAP

2026-02-11T04:51:29.555000+01:00

Challenges in Manual Sales Order Processing

Inconsistent customer data: duplicate addresses, incorrect zip codes, or special characters.
Complex Sold-to / Ship-to relationships: a single customer may have multiple shipping addresses.
Manual verification of POs is time-consuming and prone to human error.

Ensuring timely delivery and customer satisfaction requires high workforce effort

AI & Machine Learning Workflow

The AI-assisted SAP workflow automates the sales order creation process as follows:

Step 1: Customer sends an email with a Purchase Order (PO).
Step 2: AI email reader parses the email.
Step 3: OCR and NLP extract the PO details.
Step 4: ML identifies the correct Sold-to / Ship-to relationship, even in cases of inconsistent or duplicate data.
Step 5: Data validation checks accuracy against authoritative sources (e.g., USPS address verification).
Step 6: SAP automatically creates the sales order.
Step 7: Customer receives order confirmation.

AI and ML pipeline automates PO processing, resolves Sold-to/Ship-to relationships, validates data, and creates sales orders in SAP.

Key Benefits

Increased Productivity: Automates repetitive manual tasks.
Reduced Errors: Correctly identifies Sold-to / Ship-to and validates data.
Time Savings: Faster order processing and reduced cycle time.
Enhanced Customer Satisfaction: Timely, accurate orders and confirmations.
Cost Efficiency: Reduces workforce dependency and operational costs.

Machine Learning for Sold-to / Ship-to Resolution

The ML system analyzes historical sales data and learns patterns to:

Resolve duplicate or inconsistent addresses.
Identify correct shipping addresses for multiple “Sold-to” customers.
Handle special characters and local language variations.
Ensure accurate SAP sales order creation.

This step is critical because errors in Sold-to / Ship-to mapping can delay shipments, cause billing issues, and reduce customer satisfaction

Integration with SAP

AI/ML connects via REST APIs or SAP AI Services.
Extracted and validated PO data is sent directly to SAP ERP, eliminating manual entry.
SAP automatically generates sales orders, streamlines accounting, and updates inventory.

Conclusion

Integrating AI and ML into SAP sales order processing transforms a manual, error-prone process into an efficient, automated workflow. By resolving customer data issues, identifying correct Sold-to / Ship-to relationships, and validating PO information, organizations can:

Enhance operational efficiency
Reduce costs
Improve customer satisfaction
Focus human resources on higher-value tasks

Innovate with SAP HANA Cloud, an agentic multi-model database service

2026-02-11T15:45:00.027000+01:00

Agents. Graphs. Vectors.

Now let’s connect the dots.

Join us for Innovate with SAP HANA Cloud, an agentic multi-model database service and see how elastic in-memory power meets Knowledge Graph and Vector Engines—inside one unified platform.

We’ll break down:

Multi-model capabilities that go beyond traditional databases
RAG scenarios with grounded, trustworthy answers
Extension patterns that enable side-by-side innovation
New agentic capabilities that simplify building intelligent applications

Short story? This isn’t theory. It’s architecture you can design, position, and deliver.

If you’re working with customers on AI-infused workloads or composable apps, this session will sharpen your edge. And yes—it’s packed with insights you can use immediately.

Spots fill quickly. Register now. https://partneredge.sap.com/en/library/education/psd/2026/jan/e_oe_te_w_PSD_WEB_00012762.html

#SAP #SAPBTP #SAPPartners #SAPHANACloud #EnterpriseAI #SAPInnovation #DataDriven

Are you ready to share your HANA insights with the community?

2026-02-13T16:52:59.761000+01:00

Are you ready to share your HANA insights with our community?

HANA Tech Con will take place on July 16, and we’re looking for experts, users, and partners to delight us with engaging and inspiring sessions.

Ready to submit your proposal? Here is how:

1: Go to the HANA Tech Con website and click “Call for Proposals” on the main menu:

You can also find this option directly on the page by clicking on the button “Become a Speaker”:

2: Once you are inside the Call for Proposals page, you will find detailed information about the topics we are looking for.

💡Tip: We especially appreciate original, relevant, and engaging content.

3: Scroll to the end of the page and click the “Submit Your Talk” button:

4: Once you reach the submission page, you’ll need to choose a title for your Session:

Here are some examples from the first HANA Tech Con edition:

- SAP HANA HotSpots

- Mastering HANA Performance

- Database Analysis Using the SAP HANA Cloud Knowledge Graph Engine

- How to optimize the SAP HANA Memory Sizing Predictions

5: Select your Session Type based on:

TALK (Spot Talk or Deep Dive Talk);
PPTless Demo;
OTHER (If no format that aligns with your vision, just don’t forget to use the remarks field, not description, to describe your proposed session format).
Extensive Talk.

The REMARKS FIELD is located just below the Description section:

6: Tell us about yourself!

If you’re presenting the session alone, please fill in your Name, E-mail and Company.

If your session includes another speaker, please click “Add Speaker” and complete their information as well. You can add up to eight speakers per session:

7: To submit your proposal, check the Consent Checkbox and click Submit Proposal.

MAKE SURE YOU HAVE SUBMITED YOUR PROPOSAL:

8: After submitting, you’ll see a confirmation page:

IMPORTANT INFORMATION:

Do NOT FORGET to verify your email, otherwise your proposal won’t be processed. You have 7 days after submitting your proposal to verify it.
Once verified, you will receive a link to view or edit your proposal.
You MAY submit more than one proposal.
Call for speakers closes at 11:59 pm on March 13, 2025.
Results will be communicated by email within 2–3 weeks after the deadline.

In case you have any questions, we’re here for you!

And of course: Stay connected! We’re looking forward to seeing you on July 16.

Cheers,

HANA Tech Con Team

Leveraging Past Technical Dialogues to Enhance Customer Support with SAP BTP

2026-02-16T10:57:12.850000+01:00

When a client opens a ticket for SAP software support into AMS services, time to resolve remain a relevant KPI.  S.P.A.R.K. (SAP Process Augmented Response Knowledge) is a Retrieval‑Augmented Generation (RAG) platform built entirely on SAP technology—SAP HANA Cloud, BTP AI services, and the Cloud SDK. It turns every resolved ticket into a searchable, conversational knowledge base, delivering the exact solution a consultant needs exactly where they work.

In this blog we’ll show how S.P.A.R.K. overcomes the challenges of technical dialogue data, why a native‑SAP stack matters, and the measurable impact on ticket‑resolution speed and consultant productivity. We’ll also highlight the scientific paper that documents the architecture and results—our first peer‑reviewed publication made possible thanks to SAP and Talan Research Center.

This blog post describe technical implementation and research outcomes led within SAP AMS delivery center at TALAN.

The Challenge: Unlocking Conversational Data

Unlike standard document retrieval, support tickets are messy. They are conversational, often asynchronous, and the critical information (the root cause and solution) is diluted across many messages. Furthermore, AMS support tickets present specific hurdles:

Data Privacy: Tickets contain sensitive info like client names and system IDs which must be protected.
Technical Jargon: Standard models struggle with the specific vocabulary of SAP as transactions and error codes.
Asymmetry: We need to match a new problem description against past resolved tickets that contain both the problem and the solution.

The Solution: A Secure, High-Performance RAG Architecture

To address these challenges, we designed a robust pipeline on SAP BTP that transforms raw noise into actionable insights. As illustrated in the figure below, the SPARK architecture follows a strict sequence to ensure data privacy and relevance. Whether processing historical archives (Database) or a live request (New Ticket), the data passes through 3 main steps.

1. Anonymization (Privacy Layer)

Before any data is processed by external AI models, it must be sanitized to protect sensitive information.

The system uses metadata (knowing who the client, consultant, and company are beforehand) to apply Regular Expressions (Regex). This systematically strips out names, first names, company names, and other specific identifiers.

To comply with legal confidentiality requirements and prevent "bias" in the similarity search (e.g., preventing the model from linking tickets solely because they share a company name rather than a technical issue).

2. Summarization (Resume Layer)

Raw conversation logs are often noisy, containing greetings, scheduling details, or digressions that dilute the technical content.

The data is sent to a Large Language Model (LLM) via the SAP GenAI Hub. The system uses a specific prompt to force the LLM to structure the output into three distinct sections:

PROBLEM: A description of the initial issue.
LEADS (Pistes): The diagnostic steps and hypotheses considered.
SOLUTION: The final resolution and implementation details.

The LLM generates synthetic data to augment and refine the initial dataset. By doing so, it enhances consistency, semantic relevance, and overall coherence, ensuring that the data better aligns with the target application.

3. Encoding (Vector Layer)

This step converts the text summary into a format that computers can compare mathematically.

The text is passed through an Embedding Model (such as OpenAI's text-embedding-ada-002 or others tested like SAP NEB). This model converts the text into a high-dimensional vector (a long list of numbers).

To store these vectors in the SAP HANA Vector Engine. When a new ticket arrives, its vector is calculated and compared against stored vectors using Cosine Similarity to instantly find the "N closest tickets" based on semantic meaning rather than just keyword matching.

All‑In‑One SAP‑Native Stack: The Technical Engine Behind the Solution

The solution is built entirely on a SAP‑native stack: all ticket texts are stored in SAP HANA Cloud, leveraging its in‑memory columnar engine for ultra‑fast reads, writes, and auditability.

Embeddings are generated and indexed by the HANA Vector Engine, which performs approximate‑nearest‑neighbor similarity searches directly inside the database, eliminating any external vector store and keeping latency in the single‑digit‑millisecond range.

For the generative layer, SAP AI Core on the Business Technology Platform orchestrates any LLM whether open‑source models or SAP‑tuned variants through a unified runtime that handles model loading, scaling, and secure inference & GPU/CPU provisioning.

The entire pipeline from vector retrieval to prompt engineering and response generation is exposed via the SAP Cloud SDK, ensuring a single, secure endpoint for consultants while keeping all data within the trusted HANA vault and benefiting from SAP’s built‑in compliance and monitoring capabilities.

Results: Finding the Perfect Model Combination

We evaluated dozens of model variants on a 100 thousand item dataset by relying on real‑world feedback from SAP consultants. Each answer was manually annotated as relevant, partially relevant, or not relevant, and those human judgments were used to rank and refine the models. This human‑centered evaluation ensured that the final solution meets the practical needs of consultants.

From a research perspective, we quantify this relevance with the classic Normalized Discounted Cumulative Gain (nDCG) metric, a staple in information‑retrieval evaluation. Using nDCG we compared several system configurations, manual prompting versus the automated “PromptPerfect” approach, and the impact of an additional Re‑Ranking (RR) step. The metric lets us clearly see how each variation lifts the relevance of the top‑ranked answers, guiding data‑driven decisions on which pipeline components to adopt.

According to these tests, the most effective configuration achieved a relevance score of 0.86. Interestingly, the best results (highlighted above) came from a "hybrid" approach: combining Gemini 1.5 Pro (accessed via GenAI Hub) for generating the summaries, paired with OpenAI’s Ada 002 model for generating the text embeddings.

This proves the value of SAP GenAI Hub: it allows developers to easily swap and combine models from different providers (like Google, Anthropic or OpenAI) to optimize for specific tasks without changing the underlying architecture.

Acknowledgments

We are grateful to the research community for the peer‑reviewed paper that introduced this work. You can read the full publication (in French) here:

https://aclanthology.org/2025.jeptalnrecital-industrielle.6.pdf

A sincere thank‑you to SAP for providing the end‑to‑end platform SAP BTP — SAP HANA Cloud, Vector Engine, AI Core, and Cloud SDK—that made the solution possible. Your technology and support have been essential to turning academic insights into real‑world value for SAP consultants.

Decision Logic Modernization in SAP Integrations: Using SAP-RPT-1 for Intelligent Routing Decisions

2026-02-16T19:54:29.244000+01:00

Integration Modernization concept is often discussed in two dimensions:
1) Platform modernization – moving from older stacks like SAP NetWeaver PI/PO, SAP Neo, or legacy 3rd party platforms to SAP Integration Suite.
2) Scenario modernization – shifting from legacy protocols to modern integration patterns such as APIs & event-driven architectures; upgrading ABAP / Java mapping to graphical mapping / groovy script; or moving from basic auth to OAuth 2.0 or client certificate based authentication, and so on.

But there is another Modernization opportunity at the scenario level: decision logic modernization.

In this blog, we explore how routing decision logic, as an orchestration step — can be modernized using SAP-RPT-1, SAP’s latest foundation model hosted on BTP AI Core (Generative AI Hub) — applied to an outbound delivery routing scenario.

The Traditional Approach: Static Rules, Lookups, and Growing Complexity:
In SAP PI/PO and Integration Suite, routing decisions are typically implemented using deterministic, rule-based logic. These decisions often control how a scenario behaves – including which receiver system to call, or which transformation branch to follow. The common approaches include:

Static routing via Routers based on payload elements or fields
Dynamic configurations, such as externalized parameters passed at runtime
Lookups to external systems (e.g., via JDBC, SOAP, RFC lookups) to evaluate conditions at runtime — achieved in Integration Suite via patterns like Request-Reply or Content Enricher

These mechanisms work — but they come with growing challenges:

Rules get combinatorially complex with more conditions and evolving business scenarios
Lookup tables become burdensome to maintain
Decisions become rigid and hard to evolve over time

As a result, rule-based decisioning becomes harder to maintain as business requirements evolve. Agility suffers. Adaptation becomes expensive.

What if, instead of relying on static rule-based logic, iflows could make decisions based on historical business patterns — applying predictive machine learning without the overhead of training and managing custom models? With the in-context learning capabilities of SAP’s latest foundation model, SAP-RPT-1, such predictions can be performed on-the-fly at runtime.

Enter SAP-RPT-1: Foundation Model for Predictive Tasks:
SAP-RPT-1 is a pre-trained foundation model available via BTP AI Core (Generative AI Hub). Unlike traditional ML services that require dedicated data science setup, SAP-RPT-1 offers:

Pre-trained model, ready for “plug and play” in your scenario
No ML infrastructure setup
No data science expertise required
No-code consumption via API
Faster time-to-market
Democratization of AI capabilities across IT functions

SAP-RPT-1 is pre-trained specifically for predictive tasks such as classification and regression over ERP tabular data, unlike many general-purpose GenAI models that are primarily trained on large corpora of natural language text. Instead of building and managing a full ML lifecycle, integration developers can now leverage predictive intelligence directly into iflows — without any data science related heavy-lifting.

If you are new to SAP-RPT-1, I recommend that you read this introductory blog.
Also, explore this SAP-RPT-1 playground.

Business Scenario: Intelligent Outbound Delivery Routing with SAP-RPT-1:
SmartSense Technologies (SST), a global provider of smart security devices, faces challenges in routing outbound deliveries from its manufacturing plants to distribution centers, retail stores, and end customers. Their current routing logic, embedded in integration flows, relies on static rules and lookup tables – employing a combination of Material, Quantity, Delivery priority, Material group, Ship to location, and so on. This leads to frequent shipping delays, cost overruns, and SLA violations whenever logistics conditions change and sub-optimal 3PL partner is chosen.

To overcome these limitations, SST decides to leverage SAP Integration Suite together with SAP-RPT-1 foundation model. By embedding machine learning–driven decision-making into its integration flow, SST aims to dynamically select the optimal logistics partner for each delivery based on historical performance, cost, and delivery times. While SAP-RPT-1 is capable of solving predictive tasks such as classification and regression, we will be using it for classification task — i.e. to classify given delivery (defined by delivery header & item attributes) to most optimal 3PL logistics provider.

The following diagram illustrates the target architecture implemented by SST for intelligent outbound delivery routing using SAP Integration Suite and SAP-RPT-1 model, hosted on BTP’s Generative AI hub:

Step 1: Outbound Delivery Creation
An outbound delivery is created in SAP S/4HANA, which triggers an outbound notification event. The event is consumed by the iflow, which then calls S/4HANA OData API to fetch the following delivery related header and item attributes.

Delivery header fields: DeliveryDate, SalesOrganization, ShipToParty, SoldToParty, DeliveryDocumentType, CreationDate, ShippingPoint, DeliveryPriority, IncotermsClassification, TransactionCurrency

Delivery item fields: Material, DeliveryDocumentItemText, MaterialGroup, ActualDeliveryQuantity, DeliveryQuantityUnit, Plant, StorageLocation, ItemGrossWeight, ItemWeightUnit, ControllingArea, DistributionChannel, GoodsMovementType, ProfitCenter

Step 2: Context Selection – Random Historical Records
We store historic labeled data i.e. delivery headers, items and corresponding optimal 3PL partner data in SAP HANA Cloud. The iflow is configured to fetch a random set of this historic data from HANA Cloud. As recommended in this blog, for most enterprise use-cases, where you have about hundred thousand to million lines of labelled data, depending on how diverse your scenario data is, you may choose the context size, by iterating and finalizing the apt number of historical records to pick. By picking random records, we are able to provide statistically diverse examples, improve prediction quality and avoid bias from sequential records.

The Iflow executes the following query on the HANA Cloud DB:

SELECT TOP ${property.NumberofRecords}
"DeliveryDate",   "DeliveryDocumentNumber",  "CreationDate", "DeliveryPriority",  "IncotermsClassification",  "Material", "DeliveryDocumentItemText", "MaterialGroup",  "ActualDeliveryQuantity", "DeliveryQuantityUnit", "ItemGrossWeight", "ItemWeightUnit", "DistributionChannel", "PartnerNumber"
FROM "RPT1"."historic_3pl_selections"
ORDER BY RAND()

Step 3: Constructing the SAP-RPT-1 Request
We now combine:

Historical random records (known 3PL partner)
The current outbound delivery (3PL partner to be predicted)

The current transaction includes a placeholder: [PREDICT]

The request payload contains:

900 historical labeled rows
1 new outbound delivery row marked for prediction

For detailed info on payload construction, refer to the official documentation page and the GitHub repository (sample Postman/Bruno collections available for experimentation).

Further, while creating the inferencing request to SAP-RPT-1, we trim the columns from original 24 down to only 14 columns of delivery attributes, by removing fields like Sales Org, Controlling Area, Profit centre that do not influence partner selection. This is one of the best practices to achieve best possible predictive outputs. Read more recommended best practices here.

Step 4: Deploying SAP-RPT-1 model in Generative AI Hub

Step 5: SAP-RPT-1 inference response
The response contains Number of predicted records, predicted field (here optimal 3PL partner) along with Confidence score.

Response from our example scenario:

You can also send multiple unknown records in one batch. To read more about the number of max. records and columns supported by SAP-RPT-1, check out this help page.

Step 6: Intelligent Routing in the Iflow
The Iflow now:

Reads the predicted PartnerNumber
Evaluates confidence threshold (optional safeguard)
Routes outbound delivery to the optimal 3PL partner
Optionally, logs decision + confidence for traceability in HANA Cloud.

When AI in Iflows Brings Real Business Value

When routing decisions directly impact business outcomes
If sub-optimal routing can lead to SLA breaches, shipment delays, higher costs, or customer dissatisfaction, intelligent decision logic creates measurable advantage.
When rule-based logic becomes complex and brittle
As business variables multiply (products, regions, priorities, partners), static rules become hard to maintain and scale. ML handles multi-dimensional patterns more effectively.
When historical ERP data contains predictive patterns
If past delivery and fulfillment data reflects consistent business behavior, ML can learn from it and improve future routing decisions beyond deterministic conditions.
When business context evolves over time
With changing product mixes, customer bases, or distribution models, retrainable ML models adapt dynamically — avoiding constant manual rule maintenance.

Not every integration scenario requires ML capabilities. But where routing decisions carry operational or financial impact, replacing rigid rule sets with adaptive decision logic can significantly improve resilience and maintainability. Decision logic modernization is therefore not about adding AI everywhere — it is about applying it where it meaningfully improves orchestration.

Note: This blog revisits our earlier implementation in light of the planned deprecation of SAP BTP Data Attribute Recommendation service, demonstrating an updated approach using SAP-RPT-1 model.

Action Required: Update your certificate trust stores for enhanced SAP HANA Cloud security

2026-02-23T10:10:00.017000+01:00

To enhance the security of our cloud services, SAP is updating the root certificate authority (CA) for various services, including the SAP BTP, Cloud Foundry environment, SAP BTP, ABAP environment, and SAP HANA Cloud. We are transitioning our server certificates signed by DigiCert Global Root G2 and G1/G5 cross-signed CAs to the newer and more secure "DigiCert TLS RSA4096 Root G5" CA, as DigiCert will stop signing new server certificates with the old root certificate.

This change is necessary to align with the latest industry security standards and recommendations, which call for stronger cryptographic keys. The new G5 certificate chain uses RSA-4096, providing a higher level of security for your connections.

What Does This Mean for You?

If you have client applications or services that connect to SAP HANA Cloud, you may need to take action to ensure a seamless transition and avoid connection failures.

Call to Action: Review the official notes and update your Trust Stores as needed

To prevent any disruption to your services, it is crucial that you update the trust stores for your client applications and services, as needed. Please review the officially provided SAP notes, giving more guidance:

SAP Note 3397584: HANA Cloud Connections will switch from "DigiCert Global Root CA" to "DigiCert TLS RSA4096 Root G5"
SAP Note 3399573: HANA Cloud Switch of DigiCert Root Certificate

Rollout Timeline

The switch to the G5 root CA for existing SAP HANA Cloud regions is planned for the second quarter of this year. The timeline for your landscape will be communicated via established communication channels begin of March. This blog post will also be updated with further information once available.

Further Information and References

As the root certificate change is not only impacting SAP HANA Cloud usage, but also other SAP BTP services, we highly recommend reviewing the below mentioned references/notes, to ensure the highest degree of business continuity:

SAP Note 3566727: Root Certificate Replacement in the SAP BTP, Cloud Foundry Environment
Blog Post: SAP BTP Cloud Foundry: Switching to higher security level Root Certificate Authority
Blog Post: SAP BTP ABAP Environment – New Root Certificate Authority
GitHub: SAP BTP Trust Store

To ensure your applications continue to operate smoothly and securely, we suggest you take the necessary steps to update your trust stores as soon as possible.

Thanks,

Meet Your Ops Agents - Powered by SAP Automation Pilot and Joule

2026-02-23T11:10:00.063000+01:00

Building on our latest innovation around SAP Automation Pilot and AI-powered IT Operations, I am excited to share that we are already seeing real productive use cases for Day-2 Operations Agents which are powered by SAP Automation Pilot content and consumed directly in Joule in a truly agentic manner.

🎥 Meet Your Ops Agent

See an example about Ops Agent powered by SAP Automation Pilot and discover how easy it is to set up an MCP server, expose automations, and trigger them in an agentic way through Joule.

This approach unlocks a completely new way to ops automation where AI agents can reason, execute, and orchestrate operational tasks seamlessly following customers requests and needs.

The demonstration walks through a scenario about an S/4HANA Health Monitoring Ops Agent in Joule, designed to:

Provide system health & diagnostics insights;
Perform automated analysis & deliver actionable recommendations;
Proactively send alerts when potential issues are detected;

📖Just the beginning

There is an unlimited range of Ops Agent scenarios enabled through SAP Automation Pilot, including for example:

SAP BTP Operations (e.g. Cloud Foundry applications, SAP HANA Cloud, SAP cTMS, etc.);
SAP Build and Day 2 Operations for your apps;
SAP Integration Suite checks and actions via automated API calls;
Integrations with custom solutions;
And many more …

Stay tuned as we will be revealing more real-life agentic operations scenarios in the coming weeks.

🚀 Get involved: Join Our Customer Engagement Initiative

If you would like to bring your own automation scenario and experience first-hand the AI-driven operations capabilities of SAP Automation Pilot and Joule, join our Customer Engagement Initiative: Agentic AI Operations with SAP Automation Pilot

⏳Registration is open until March 15, 2026 - secure your spot soon!

Learn More

If you would like to explore MCP servers in more detail or start using them in your own landscapes, please check out the SAP Automation Pilot official documentation which provides further insights:

Looking forward to collaborating and shaping the future of agentic IT operations together.

Gregor Wolf

2026-02-23T18:24:58.182000+01:00

About Gregor

Germany | SAP Mentor since 2007 | Follow Gregor on LinkedIn

I am an independent SAP solution architect, developer and SAP Mentor. I focus on SAP Business Technology Platform, SAP Cloud Application Programming Model (CAP), Node.JS, SAP Fiori Elements and Security. I've supported several customers during their SAP Cloud ERP Private Edition (S/4HANA On Premise) implementation. Since the end of 2024 I support the technical topics at an SAP Cloud ERP Public Edition Customer.

Topics of interest: SAP Business Technology Platform, SAP Cloud Application Programming Model (CAP), SAP Cloud ERP public and private, SAPUI5, OpenUI5, SAP Fiori, SAP HANA Cloud

Gregor, what inspired you to become an SAP Mentor?

A key influence early in my SAP Community journey was Mark Finnern. He is the father of the SAP Community. Mark encouraged me to move beyond answering questions and start sharing detailed technical how-to's but also event reports in blog posts. In 2007 Mark also founded the SAP Mentors program which gave me the opportunity to provide structured, experience-based feedback to SAP product teams and help bridge the gap between product vision and real-world implementation.

What advice would like to share with other SAP community members?

My advice to other SAP Community members is simple: contribute consistently and think long-term.

Start by answering questions and helping others solve real problems - but don’t stop there. Document your lessons learned, share architectural insights, and write about what worked and what didn’t. That’s how collective expertise grows. And you will be amazed how often you research years later and find your own answers and blog posts to solve a problem you're just facing. Despite all the new stuff SAP has quite a long tail that doesn't change quickly.

Engage constructively, challenge respectfully, and focus on signal over noise. The community is not just a support forum - it’s an ecosystem where practitioners can influence product direction, elevate standards, and shape the future of SAP together.

Part 1: Creating and Deploying a SAP CAP Application with SAP HANA on SAP BTP (Cloud Foundry)

2026-02-25T07:35:57.804000+01:00

Note: This blog is the First Part of series - Building and Deploying SAP CAP Applications on BTP: From Database to Work Zone

Introduction

SAP Cloud Application Programming Model (CAP) is often demonstrated through local examples, but its real value becomes clear when the application is deployed to SAP Business Technology Platform (BTP) and backed by a managed database.

In this blog, we will go through creating a basic SAP CAP application using the SAP Business Application Studio (BAS) CAP template, binding it to SAP HANA Cloud, and deploying it to SAP BTP using the Cloud Foundry runtime.

The goal here is not to build a complex application, but to establish a clean, working reference point. I start with a minimal CAP project to keep the focus on deployment rather than domain complexity.

This blog serves as a baseline for a series where the same CAP application will later be deployed using different databases and runtimes. The focus here is not application complexity, but establishing a clean, working reference point.

Pre-requisites:

Please make sure that you have these before starting the development:

SAP BTP Account
Cloud Foundry instance
Active Hana Cloud Instance
SAP BAS / VSCode for development
If using BAS, have a dev space running
If using VSCode then make sure that you have installed Node.js and CLI installed

Now, let’s start with the development.

Create a CAP Project from Template given in the BAS:

SAP Business Application Studio provides a template for creating a CAP project with the required structure. The positives of using the template is that it automatically builds your Multi-Tenant Application file (mta.yaml) with the required deployment modules.

Follow the following steps:

Open BAS
Click on the Side Menu on the top-left corner
Click on File
Click on New Project From Template
Select CAP Project
Configure the project as follows:
- Project Name: cap-hana-app
- Runtime: Node.js
- Database: SAP HANA Cloud
- Deployment Environment: Cloud Foundry
- Runtime Capabilities: XSUAA
Click on Finish

CAP Project creation wizard with SAP HANA selected

This will create a CAP project for you with mta.yaml automatically updated. The generated project follows standard CAP structure:

app – UI
db – Schema and data files
srv – Service Definition

Now that the project is created, let’s get into development.

Development:

Follow the following steps:

Define a Simple Data Model:

If you have schema.cds under db/ folder, then update it with the following code snippet. If you do not have schema.cds, then create one.

namespace com.mycompany.capapp;
entity Products {
    key ID          : UUID;
        name        : String(100);
        description : String(500);
        price       : Decimal(10, 2);
        stock       : Integer;
        category    : String(50);
        createdAt   : Timestamp;
        modifiedAt  : Timestamp;
}

Expose the Model via CAP Service:

If you have service.cds under srv/ folder, then update it with the following code snippet. If you do not have service.cds, then create one.

using com.mycompany.capapp from '../db/schema';

service CatalogService {
    entity Products as projection on capapp.Products;
    }

CAP automatically exposes this service as an OData endpoint without requiring manual REST configuration.

Add Data:

Run the following in the project terminal:

cds add data --records 5

Run the Application locally:

Run the following command:

cds watch

You should be able to see the data in the Products

You can also use the SQLite as a database while running locally. Execute these before starting the application:

cds build
cds deploy

Add a Managed Approuter:

Right click on mta.yaml
Click on Create MTA Module from Template
Select Approuter Configuration
Fill in the required details
Click Finish

This is important to view the data once deployed.

Prepare the Project for Deployment:

Since we have created the project from the BAS Template, we already have the mta.yaml updated and deployment ready. This file already includes:

CAP Service Modules
SAP HANA HDI Container
Required Service Bindings

Build the CAP Project:

First things first, install node modules. Run the following in the Terminal:

npm i

To build the project, you can either run the following in the terminal:

mbt build

or can do it manually:

Right click on mta.yaml
Select Build MTA Project

This will build your project for deployment. Watch-out at the project structure. You might see a new addition to the structure mta_archives which consists the mtar file of the project.

Deploy the Application:

To deploy the application to your BTP using Cloud Foundry, you will have to login to Cloud Foundry. Run the following in Terminal:

cf login

This will ask for your subaccount credentials. Provide them and you will be logged in successfully. Remember to map the correct space and org.

Once you are logged in successfully, you are ready to deploy the application. Remember the file generated while building the CAP project, this is the same file that will be deployed.

Run the following command:

cf deploy mta_archives/cap-hana-app_1.0.0.mtar

or, you can just right click on cap-hana-app_1.0.0.mtar under mta_archives folder, and click on Deploy MTA Archive.

Successful Cloud Foundry deployment

During deployment:

HDI Container is created
Database schema is deployed
CAP Service is bound to the database automatically

Confirm the Deployed Instances

Verify the Deployed Application:

When the deployment is successful, you will get a application route. Copy the same and open it in the new tab of your browser and access the service endpoint: /catalog/Products

If the deployment is successful, you can see the data displayed in a JSON format.

Browser showing the OData service response

Conclusion

With that, we have successfully created a minimal SAP CAP application, connected it to SAP HANA Cloud, and deployed it to SAP BTP using the Cloud Foundry runtime. While the application itself is intentionally simple, the deployment pipeline we established here — from schema definition to MTA build to Cloud Foundry deployment — reflects a production-ready workflow that scales well as complexity grows.

The key takeaways from this exercise are that the BAS CAP template significantly reduces boilerplate by auto-generating the mta.yaml with the necessary modules and bindings, the HDI container handles schema deployment seamlessly, and CAP's convention-over-configuration approach means your OData service is ready without any manual REST wiring.

This baseline will serve as the foundation for the rest of this series, where we will explore deploying the same application with different databases, runtimes, and configurations — making it easier to understand the trade-offs of each approach. Stay tuned for the next part!

Next Steps

In the upcoming blogs, we will focus on creating the same application using a PostgreSQL, Hyperscaler Option.

Mass Invoice Reversals Without Customer Panic: A Clean Core, BTP Driven Strategy for ModernUtilities

2026-02-27T13:18:41.584000+01:00

Mass Invoice Reversals Without Customer Panic: A Clean‑Core, BTP‑Driven Strategy for Modern Utilities

Executive Summary

If you’ve spent any time around utility billing operations, you know mass reversals aren’t rare — they’re part of the job. Sometimes it’s a rate issue, sometimes a meter read problem, and sometimes it’s just one of those unexpected data surprises that ripple across months of billing, these reversals often span multiple billing cycles and thousands of customers. While the operational process may take days to complete, the customer impact is immediate: as soon as reversals post, customers see large credits on their online portals. This triggers confusion, social media chatter, call‑center spikes, and reputational risk before corrected bills are ready.

What I want to share here is a practical way utilities can handle this without rewriting IS‑U or scrambling teams at 6 AM. We used SAP BTP to create a small visibility layer that sits between IS‑U and the customer portal — and honestly, it solved a problem that has bothered billing teams for years, event‑driven architecture, and lightweight AI to prevent premature credit visibility without modifying SAP IS‑U or customer‑facing systems. The solution introduces a “Billing Visibility Orchestration Layer” that controls what customers see during mass reversals, ensuring operational accuracy without customer panic.

The Practitioner Reality: When a Simple Reversal Becomes a Public Crisis

Every utility billing team has lived through this scenario:

A mass correction requires reversing 8–12 months of invoices.
The reversal job runs for hours or days.
As soon as reversals post, customers see large credits on the portal.
Screenshots appear on social media: “Utility X just gave me $900 credit!”
Call centers are overwhelmed.
Regulators ask questions.
The billing team is still in the middle of the correction.

The root cause is simple: SAP IS‑U posts reversals immediately, and customer portals read them immediately. And here’s the part nobody talks about: IS‑U has not built‑in buffer. The moment a reversal posts, the customer sees it. There’s no ‘hold this until we’re done’ button. That’s where the trouble starts. Utilities cannot legally notify customers in advance, and they cannot delay the operational correction. This creates a structural gap between internal billing processes and external customer visibility.

Why This Happens: A Technical Gap in Traditional IS‑U

SAP IS‑U was designed with a real‑time posting model:

Reversal document posts →
FICA updates →
Portal reads →
Customer sees credit

There is no concept of:

“Temporary suppression”
“Billing in progress”
“Visibility hold”
“Batch publish”

This is not a failure of IS‑U — it’s simply a design that predates modern digital customer expectations.

The Modern Solution: A Billing Visibility Orchestration Layer on SAP BTP

Instead of modifying IS‑U or customer portals, utilities can introduce a lightweight, clean‑core extension on SAP BTP that controls visibility, not billing.

This layer sits between:

SAP IS‑U → BTP → Customer Portal / CIS / Mobile App

It does not change billing logic. It does not alter FICA. It does not modify the portal. It simply orchestrates when billing information becomes visible.

Key Capabilities

Detect mass reversals in real time
Flag accounts as “under correction”
Temporarily suppress credit visibility
Replace credit display with a neutral message
Release final billing once corrections are complete

This simple layer kept customers from seeing half‑baked credits and gave the billing team the breathing room they needed to finish the job properly.

Textual Representation

How It Works Using BTP Services

1. SAP Event Mesh — Detect Reversals in Real Time

Event Mesh listens for:

Billing document reversals
FKK document reversals
Mass job triggers

When reversal volume exceeds a threshold (e.g., >500 accounts), it triggers the suppression workflow.

2. SAP BTP Workflow — Manage the Correction Window

Workflow orchestrates:

Start of reversal window
Suppression period
Completion of rebilling
Release of final invoice

This creates a controlled, auditable process.

3. SAP BTP Business Rules — Define Visibility Logic

Rules can be configured without coding:

“If reversal count > X, suppress visibility for Y hours.”
“If account is in correction, show neutral message.”
“If rebill fails, extend suppression.”

This keeps the solution clean‑core and upgrade‑safe.

4. SAP HANA Cloud — Temporary Data Store

Stores:

Accounts under correction
Suppression flags
Workflow status
Rebill completion indicators

No changes to IS‑U tables.

5. SAP BTP AI — Predict and Prevent Customer Impact

AI can:

Identify accounts likely to call
Detect social media spikes
Predict rebill duration
Recommend suppression windows
Flag anomalies in reversal patterns

This turns a reactive process into a proactive one.

What the Customer Sees Instead

Instead of a large credit, the portal displays:

“Your billing is being updated. Your final balance will be available shortly.”

This avoids:

Panic
Misinterpretation
Social media escalation
Call center overload

Clean‑Core Alignment

This approach is fully clean‑core because:

No IS‑U modifications
No FICA changes
No portal rewrites
No custom Z‑tables in SAP
All logic runs on BTP
Fully upgrade‑safe
Works with ECC and S/4HANA

This is exactly what SAP means by “extensibility without modification.”

Practitioner Example

In one of the utilities I worked with, we had to reverse nearly 10 months of bills for over 180,000 customers. Within 45 minutes, screenshots of huge credits were all over social media. The call center was drowning. Regulators were pinging leadership. It was chaos — and all because the portal updated too early.

After implementing a BTP‑based visibility layer:

Mass reversals ran silently
No customer saw temporary credits
No social media chatter
No call center spike
Corrected bills were published cleanly

The billing team completed the same process with zero customer disruption.

Conclusion

Mass invoice reversals will always be part of utility operations. But customer visibility does not need to be immediate or uncontrolled. By introducing a Billing Visibility Orchestration Layer on SAP BTP — powered by Event Mesh, Workflow, Business Rules, HANA Cloud, and AI — utilities can protect customer experience, reduce operational risk, and maintain clean‑core principles.

This is modernization where it matters: not in rewriting billing logic, but in orchestrating how and when customers see the results.

Automating SAP HANA Cloud (Other Environment) DB Lifecycle Management with SAP Automation Pilot

2026-02-28T10:56:26.280000+01:00

In our recent updates around AI-enabled Ops Operations, we demonstrated how SAP Automation Pilot boosts structured, scalable, and intelligent automation for Day-2 Ops Agents through Joule.

Today, I am excited to take this one step further.

🚀 We are expanding our automation coverage to fully address SAP HANA Cloud lifecycle management in the Other Environment - bringing operational excellence to database management at scale.

From Standard Catalogs to Broader Lifecycle Automation

SAP Automation Pilot already provides a built-in catalog for managing SAP HANA Cloud database instances running in the Cloud Foundry environment - that is the the well-known SAP BTP Database Lifecycle Management (dblm-sapcp) Catalog.

This catalog has successfully helped customers automate essential lifecycle tasks directly within SAP BTP.

However, many customers also operate SAP HANA Cloud instances in the Other Environment, where lifecycle management is equally critical and operationally sensitive. While SAP Automation Pilot already offers all the technical capabilities required to automate those tasks, we recognized the need to package common scenarios into a structured, reusable, and publicly available catalog.

That is exactly what we have now delivered!

Introducing: SAP HANA Cloud Lifecycle Management Sample Catalog (Other Environment)

We have consolidated a wide range of SAP HANA Cloud lifecycle scenarios into a dedicated public sample catalog, now available in our GitHub repository here: SAP HANA Cloud Lifecycle Management Sample Catalog (Other Environment)

This catalog provides a comprehensive and validated set of automation commands for managing SAP HANA Cloud instances at subaccount level using Service Manager.

Instead of executing repetitive and sensitive database operations manually, you can now automate domains such as: 🔹 Instance Lifecycle Management 🔹Backup & Recovery 🔹 Snapshot Management 🔹 Instance Configuration🔹 Upgrades & Plugins 🔹 Elastic Compute Nodes (ECN), etc.

✅ All commands are validated and ready to be explored by our users - to help you minimize manual effort, reduce risk, and standardize operational procedures.

Beyond Automation: Toward Intelligent Database Operations

While structured lifecycle automation already delivers immediate value, the real transformation begins when automation becomes agentic.

Because all HANA Cloud-related commands are exposed through SAP Automation Pilot, they can be orchestrated, combined, and consumed in higher-level operational workflows.

This naturally leads to the next evolution - AI Ops Agents for HANA Cloud enabled with SAP Automation Pilot and Joule!

📖Be Part of the Journey - Join Our Customer Engagement Initiative

As we continue expanding agentic AI operations, collaboration with customers remains key.

If you would like to gain hands-on experience with AI-enabled Ops automation and help shape the future of intelligent database operations, we invite you to subscribe in our ongoing Customer Engagement Initiative: Agentic AI Operations with SAP Automation Pilot

Through this initiative, you can:

Explore real-world AI-driven automation scenarios;
Bring your own use cases and operational challenges;
Provide direct feedback to the product team;
Influence upcoming capabilities;

⏳ Registration is open until March 15, 2026 - secure your spot soon!

From structured lifecycle automation to fully agentic database operations - this is the next chapter of operational excellence with SAP Automation Pilot.

Let’s build it together!

SAP Community - SAP HANA Cloud

Beyond Vectors: The Next Evolution of RAG on SAP BTP using SAP HANA Cloud

Introduction

The Limitations of "Flat" Data

The Solution: Hybrid GraphRAG

Multimodal RAG: Keeping Context Intact

Why SAP HANA Cloud?

A New Framework for SAP Developers

Learn More

Simplifying Time Series Analytics with Unified Time Series Interface

Key Highlights

Unified Workflow

Automatic Timestamp Conversion

Pivoted Input Data Format Support

Massive Mode Capability

Example

Summary

New Machine Learning, NLP and AI features in SAP HANA Cloud 2025 Q3

Time series analysis and forecasting function enhancements

Classification and regression function enhancements

AutoML and pipeline function enhancements

Misc. Machine Learning and statistics function enhancements

Creating Vector Embeddings enhancements

Python ML client (hana-ml) enhancements

SAP HANA Cloud release January 2026 Round-up

What’s New Teaser

What’s New blogpost

What's New Webinar

Code Connect 2026 is Coming – Mark Your Calendars!

What is Code Connect?

Your Week at Code Connect

July 13: Code Jam Sessions and Warmup

July 14: UI5con

July 15: reCAP

July 16: HANA Tech Con

Early Bird Process

Sponsorship Opportunities

Call for Proposals

Important Dates

Ready to Connect?

Good to know: Analyzing Runtime Dump (SAP HANA Dump Analyzer vs Visual Studio Code)

Why was this blog post created?

Where can I find the most important information about the SAP HANA Dump Analyzer and Visual Studio Code - Supportability tools for SAP HANA?

What are the experiences based on the comparison of the tools?

Generated report in SAP HANA Dump Analyzer

Generated report in Visual Studio Code - Supportability tools for SAP HANA

What is the conclusion?

Other articles

Do you have further questions?

Contribution

SAP RPT‑1: Why is it Essential for Predicting Business Outcomes in Today’s and Future Generative AI?

Developing HANA ML models with SAP Databricks

Introduction

Connect to ML datasets on HANA Cloud

Prerequisites

Connect to HANA from Databricks

Develop the ML model with mlflow

Serve the ML model for inferencing

Create the custom handler for hana-ml

Log the custom pyfunc model

Test the custom pyfunc model

Create the Serving Endpoint

HANA credentials as environment variables for deployment

Test the Serving Endpoint

Test Serving

Endpoint Consumption

Conclusion

Consuming Data Products in SAP HANA Cloud via SAP Business Application Studio/SAP Build Code

AI Is Transforming Sales Order Processing in SAP

Innovate with SAP HANA Cloud, an agentic multi-model database service

Are you ready to share your HANA insights with the community?

Leveraging Past Technical Dialogues to Enhance Customer Support with SAP BTP

The Challenge: Unlocking Conversational Data

The Solution: A Secure, High-Performance RAG Architecture

1. Anonymization (Privacy Layer)

2. Summarization (Resume Layer)

3. Encoding (Vector Layer)

All‑In‑One SAP‑Native Stack: The Technical Engine Behind the Solution

Results: Finding the Perfect Model Combination

Acknowledgments