SAP Community - SAP HANA Cloud

Building Enterprise-Grade RAG: Seven Architectural Innovations Beyond Vector Search

2026-03-16T05:36:58.019000+01:00

Building Enterprise-Grade RAG: Seven Architectural Innovations Beyond Vector Search

A concise technical guide for production RAG systems

Executive Summary

Traditional Retrieval-Augmented Generation (RAG) systems rely primarily on semantic similarity through vector embeddings, but this approach fails in enterprise environments with large, diverse document collections. This article presents seven architectural innovations that address fundamental RAG limitations, delivering 60-75% faster queries, 85-95% precision, and 60-75% token reduction compared to traditional approaches.

The Five Problems with Traditional RAG

Problem 1: Semantic-Only Retrieval Cannot Distinguish Context

Traditional RAG encodes queries and searches all embeddings by cosine similarity, assuming semantic closeness equals relevance. This breaks down when users need contextual filtering: "show me vendor A contracts from 2024" retrieves any semantically similar contract language regardless of vendor identity, document type, or fiscal year. Vector embeddings capture meaning but not categorical properties—two vendor contracts from different years produce nearly identical embeddings because they use identical legal language and pricing terminology. Result: 30-50% false positives from wrong vendors, wrong years, or wrong document types. Users must manually verify every result, defeating automation's purpose.

Problem 2: Structural Blindness Destroys Document Organization

Character-count chunking (typically 1000 characters with 200 overlap) ignores document structure, splitting at arbitrary boundaries regardless of semantic sections. A document with clear sections-Introduction, Technical Specifications, Pricing, Compliance gets carved into chunk 1, chunk 2, chunk N without preserving these boundaries. When users query "show me technical specifications," the system retrieves random paragraphs mentioning "technical" scattered across the document rather than the complete specifications section. Even perfect vector search cannot overcome structural destruction during chunking, related content sits in disconnected chunks requiring manual reconstruction.

Problem 3: Table Destruction Loses Critical Structured Data

Tables contain 40-60% of critical enterprise information-pricing matrices, technical specifications, comparison charts, timelines, responsibility assignments. Text-based chunking catastrophically fails: a 20-row pricing table gets split across chunks, each missing column headers or context. Converting tables to linear text loses two-dimensional relationships. Worse, tables are typically introduced by explanatory paragraphs ("The following pricing applies to annual contracts only...") that get separated during chunking, leaving the LLM to interpret data without crucial qualifiers. Result: 60-80% of tables rendered unusable or misinterpreted.

Problem 4: Chat History Token Explosion from AI Response Storage

Most RAG systems store complete conversation history-user messages plus AI responses for follow-up context. A typical 5-turn conversation: user message 1 (50 tokens) + AI response 1 (2000 tokens) + user message 2 (30 tokens) + AI response 2 (1800 tokens) + user message 3 (40 tokens) + AI response 3 (2200 tokens) = 6,120 total tokens stored. Actual new information: 120 tokens from user messages. AI responses are synthesized from documents already in the database—storing them is pure redundancy adding no new context. As conversations extend to 10-15 turns, history consumes 20,000-30,000 tokens, leaving less context window for retrieved documents and increasing API costs exponentially.

Problem 5: One-Size-Fits-All Responses Waste Resources

Traditional RAG treats all queries identically: embed → vector search → retrieve → generate LLM response. But 30-40% of enterprise queries want document inventory (lists, counts, metadata): "list all contracts," "how many technical documents?" These need simple database lookups returning structured lists , not vector searches followed by verbose LLM generation. The remaining 60-70% need content extraction: "summarize technical requirements," "compare pricing across vendors." These require full RAG pipeline. Traditional systems waste compute and time generating responses for inventory queries that should be instant metadata lookups, degrading user experience with slow, verbose responses when users want clean, fast lists.

The Seven Innovations

Innovation 1: LLM-Powered Document Classification

Use an LLM to classify each chunk into semantic section types (Introduction, Technical Specifications, Requirements, Pricing, Timelines, Compliance, Risks) based on content analysis rather than arbitrary character boundaries. After standard text splitting creates chunks, pass each through a zero-temperature LLM with constrained classification prompt returning a single category label stored as chunk metadata. This adds some time consumed per chunk during ingestion but enables powerful section-aware retrieval and saves time during retrieval, users can query "show me pricing sections" and retrieve complete, focused pricing content rather than scattered paragraphs. Classification uses temperature=0 for deterministic results and minimal token output to reduce latency. Impact: Section-specific queries improve from 50-70% precision to 85-95%, with 60-80% reduction in irrelevant chunks.

Innovation 2: Dual-Stream Chunking (Text + Tables)

Implement parallel extraction pipelines-one for flowing text, one for structured data. During document processing, detect and extract tables, charts, and matrices as complete units separately from text extraction, preserving internal structure entirely. Convert tables to Markdown format for LLM readability, capture surrounding context (preceding 2-3 paragraphs explaining scope and assumptio, and infer semantic category from position. Store tables as independent chunks with specialized metadata: structure type, dimensions, contextual flags. Enrich table content with context prefix: "Context: The following pricing applies to annual contracts only. [Table: Pricing Matrix] | Plan | Cost | ..." This embeds business meaning with data structure, dramatically improving semantic search. Impact: 100% table structure preservation (vs 20-30% with text splitting), 90%+ precision for structured data queries, 50-70% better semantic relevance from context enrichment.

Innovation 3: Rich Metadata Layer

Attach comprehensive hierarchical metadata at three levels: folder/organizational (inherited from directory structure), document (file properties and custom business tags from document management systems), and chunk (section classification). Metadata captures identity (name, type, author), organizational context (department, region, category), temporal attributes (creation date, fiscal period), and custom business tags (vendor, client, project, status). Use inheritance pattern: folder-level tags apply to all contained documents, document-level tags override folder tags, chunk-level tags add section granularity. Store metadata as structured JSON alongside embeddings, enabling efficient database queries. On initialization, scan corpus to discover available metadata values across dimensions, building a catalog of unique vendors, document types, regions, years. Impact: Enables precise contextual queries combining 3-5 filters, reducing search space by 95-98% before vector operations.

Innovation 4: Metadata Pre-Filtering Before Vector Search (The Game Changer)

Execute metadata filtering BEFORE vector similarity search, reducing search space by to only contextually relevant candidates. Five-stage process:
(1) Discover available metadata by scanning corpus—vendors, regions, document types, fiscal years,
(2) LLM extracts relevant filters from user query given the discovered catalog, returning structured constraints like {vendor:[A,C], doc_type:[contract], year:[2024]}.
(3) Build database query matching extracted metadata conditions.
(4) Execute filter reducing 50,000 chunks to 500-1000 pre-qualified chunks (98%+ reduction).
(5) Compute vector similarity only on filtered subset. Modern vector databases (like HANA Cloud) support hybrid queries combining metadata filters with vector similarity.
Impact: 3x faster, precision jumps from 15% to 95%+ because all results are contextually correct, 60-75% token reduction from tighter context.

Innovation 5: Smart Chat History (User Messages Only)

Store complete conversations in database for audit, but retrieve only user messages from time window (e.g., last 12 hours) when building context for new queries. AI responses are synthesized from documents already in database they add no new information, only consuming tokens. Use context retrieval of user messages only filtered by time window. Pass user-only history to LLM for query consolidation: "Given prior user queries [list], interpret new query in context." Time windowing captures typical work session duration while preventing stale context interference and naturally limiting context growth. Impact: 90-97% token reduction on chat history, faster query processing, better context quality focusing only on user intent refinement trail.

Innovation 6: Intent-Based Query Routing

Classify user intent before processing, routing to appropriate pipeline: lightweight metadata retrieval for inventory queries, full RAG for content extraction. Use fast keyword matching for unambiguous queries ("list documents," "how many," "find all" → LIST intent; "what are," "summarize," "compare," "extract" → ANSWERING intent). LIST intent executes database query returning document names/counts/categories as structured HTML list (no LLM). ANSWERING intent executes full enhanced RAG with metadata filter, vector search, and LLM generation. For ambiguous queries, use lightweight LLM classification or default to ANSWERING. Impact: 10x faster responses for inventory queries, 40-60% lower API costs, better UX matching response type to user expectation (clean lists for inventory, comprehensive synthesis for extraction).

Innovation 7: Production-Grade Resilience

Implement fault-tolerant batch processing for enterprise-scale ingestion (1000+ documents, 100,000+ chunks). Four-layer defense: (1) Batch processing with rate limiting-split into small batches (10-20 chunks per call) with delays between batches (1-2s) and documents (3-5s), (2) Independent document processing-each document is autonomous unit, failure doesn't abort batch, successful documents commit immediately, (3) Progress tracking—real-time logging, error categorization, partial success reporting ("150 succeeded, 8 failed"). (4)Before processing, check database for existing documents by source URL (prevents deduplications and saves time as everytime it runs it only uploads delta documents).
Impact: Reliable operation at scale, survives transient API failures without intervention, clear progress visibility, partial success delivery (

Performance Impact: Traditional vs Enhanced

Metric	Traditional RAG	Enhanced RAG	Improvement
Query Latency	2-4 seconds	0.5-1.2 seconds	60-75% faster
Chunks Searched	10,000-100,000+ (all)	500-2,000 (1-5% of corpus)	95-98% reduction
Precision	50-70% relevant	85-95% relevant	30-40pp increase
False Positives	30-50% of results	5-15% of results	70-85% reduction
Token Usage (input)	12,000-20,000 tokens	3,000-8,000 tokens	60-75% reduction
Chat History Overhead	6,000-8,000 tokens	150-300 tokens	95-97% reduction
Inventory Query Time	2-4 seconds (full RAG)	0.1-0.3 seconds (metadata)	90-95% faster
Table Retrieval Success	20-40% intact	95-100% intact	3-4x improvement
Ingestion Success Rate	60-80% (fails on errors)	90-98% (fault tolerance)	15-30pp increase

The Core Architectural Insight:
Metadata filtering before vector search beats pure vector search. By filtering 95-98% of irrelevant chunks using structured metadata before expensive semantic similarity calculations, we achieve simultaneous improvements in speed, accuracy, and efficiency—the rare engineering win-win-win.

Traditional RAG

The New Pipeline

Conclusion:
These seven innovations transform RAG from prototype demo to production-grade system users can trust. The patterns are platform-agnostic and applicable to any enterprise RAG system over large, diverse document collections with organizational hierarchies, temporal dimensions, and categorical properties.

A Developer's Coin Toss: App Data or Enterprise Data

2026-03-16T19:50:18.485000+01:00

Maya leans back from the whiteboard while a test run finishes and flips a coin into the air. Chris catches it, glances at their architecture, and says, “Heads, we optimize the data design for the app. Tails, we optimize for everything that comes after the app.” Maya laughs and reaches for the coin. “That is not how coin flips work,” she tells him. “We need both and you do not get to call both sides because you keep guessing wrong.” Chris sets the coin flat on the table between them and points at the diagram on their laptops. “That is the problem though,” he says. Then he highlights the rest of the diagram, where analytics, data products, and AI flows are sketched in different colors. “We no longer can build apps that work in isolation.”

Maya studies the drawing again and sees his point. Heads is the application, tails is the company’s business data fabric, and neither side makes sense without the other. Their new app still must perform, but the rest of the business also needs its data for analytics and AI. They may be separate solutions with different responsibilities, but the final design should share the application's data with the rest of the enterprise. Maya smiles after a quick thought, points back at the coin, and light-heartedly says, “Maybe you should stick with what you are good at.” Chris grins, because this time he is not guessing outcomes.

Architecting for SAP HANA Cloud

From a design perspective, SAP HANA Cloud does not force an architectural split between operational processing, analytical access, and AI-oriented data work. It is an in-memory database platform built for applications, analytics, and AI. However, this point is key - HANA Cloud gives applications one place to work with transactional and analytical patterns without immediately fragmenting the design. This consideration really comes into play when an application starts simple and then grows into something critically needed by the business.

A practical advantage for developers (and support teams) is the combination of multi-model engines, multi-store options, and AI capabilities in the same platform. An app can follow a store-data-once philosophy and still work with relational structures, graph relationships, spatial data, vector embeddings, JSON content, and predictive or machine learning-oriented patterns when the use case calls for them. That type of simplicity changes how development teams design their solutions. Instead of solving each new requirement with another specialized persistence layer, they can extend the data schema while pushing more logic into the database.

That design gets stronger when performance and storage are treated as part of the same conversation. Hot data can stay in memory for data needed in the moment. Less frequently accessed data can move to disk-based storage, and data with slower access requirements can move to the data lake tier without forcing the team to rethink the whole model. For developers and database administrators, that means they can optimize for response time, scale, and cost without turning the application into a map of disconnected databases.

AI Solutions That Extend Business Processes

AI becomes useful inside an application when it participates correctly in the business process. That means the service must receive the right context at the right handoff point, perform the right inference or retrieval step, and then pass a usable result into the next step in the flow. If any of those pieces sit too far away from the operational data, latency increases, context gets weaker, and the implementation usually starts depending on extra synchronization jobs or partial copies of data.

The SAP HANA Cloud vector engine and the knowledge graph engine live alongside the application data instead of being pushed into separate infrastructure from the start. The vector engine gives developers a way to encode embeddings and search by similarity, which makes it useful for memory-like retrieval patterns, semantic lookup, recommendation flows, and other use cases where likeness matters more than exact matching. That is often the first capability developers reach for when they want a generative AI experience to reference business context rather than produce generic output.

The knowledge graph engine addresses a different problem. It connects facts and relationships so an application can search through a domain of known information instead of relying only on nearest-neighbor similarity. In practice, that means a developer can ground an AI workflow in a connected business context such as entities, dependencies, roles, and process relationships. When that context is modeled well, the application becomes better at choosing the right supporting information before it asks a model to generate or recommend anything.

The important architectural point here is that these capabilities are available from the same database that already stores the application data. That reduces data sprawl, avoids unnecessary handoffs, and keeps retrieval and grounding close to the transaction or event that needs them. For a technical team, that is the difference between bolting AI onto a workflow and extending the workflow with AI in a way that remains understandable and maintainable.

Easily Share Data with the Business Data Fabric

Custom applications no longer live in isolation. Even when a team builds for a narrow operational use case, the data from that application quickly becomes relevant to analytics, planning, and AI across the wider enterprise. That “community” aspect of data is why the application's database as well as the business data fabric should not be treated as competing destinations for the same dataset. Even though their underlying systems are separate parts of the physical architecture, their use becomes more valuable when the application is designed to participate cleanly in the larger fabric.

Access to enterprise data is where SAP Business Data Cloud enters the conversation as an equal participant, but with a different role. If the application needs trusted, governed, business-ready data from the wider landscape, data products are a design concept to consider. They provide curated data sharing between producers and consumers versus ad hoc extracts or hand-built point integrations. Instead of pushing every integration burden back onto the application team, data products let the broader architecture expose reusable, semantically meaningful data for consumption across applications, analytics and AI scenarios.

Regarding the integration of the application back into the data fabric, every process does not necessarily require the duplication of data. SAP Datasphere can consume data from SAP HANA Cloud virtually, which is often the cleanest option when the performance of live access is sufficient. The data can also be replicated when persistence makes the better choice. Ultimately, the option to choose between integration methodologies gives teams a practical decision rather than a forced one. They can preserve operational integrity in the application while still making its data available to the broader business data fabric in a technically sensible way.

Thus, the real lesson behind Maya and Chris’s coin game. Heads and tails equally add value to the same object. In the same way, SAP HANA Cloud does not become SAP Business Data Cloud, and SAP Business Data Cloud does not replace the application database. Each solution plays its own role. The business truly benefits when "both sides of the coin" are designed to complement one another.

Conclusion

Application data and enterprise data no longer must live as separate worlds. They can function together like two sides of the same coin, with SAP HANA Cloud supporting the operational and AI-ready application foundation while SAP Business Data Cloud supports the governed, reusable, enterprise-wide data context. When those roles are designed intentionally, there is less guessing about whether the right answer lives on the “heads” side or the “tails” side. The architecture is already prepared for both.

If your team is researching a database solution for its next application or AI solution, start with the SAP HANA Cloud basic trial. It gives hands-on access to an in-memory, multi-model, multi-store database and includes guided material that helps a developer move from first setup into core platform capabilities. Next, try the Discovery Center mission on generative AI with SAP HANA Cloud Vector Engine. It builds naturally from the fundamentals into a more advanced path that combines vector storage and similarity search so you can see how application data, retrieval, and AI handoffs work together in a realistic pattern. After that, keep the momentum going by working through the getting-started tutorial and joining the Data Professionals community group. These next steps give you a useful mix of hands-on practice, deeper technical content, and peer discussion with other developers and data professionals.

Finally, take some time today and challenge a colleague to guess a couple of coin tosses. If you want, share in the comments: “What data design did you two implement that looking back you would have done differently?”

Recommended Resources

Blog Post: What are data products?

Blog Post: What is a business data fabric?

Hand-on: SAP HANA Cloud - Basic Trial: https://www.sap.com/products/data-cloud/hana/trial.html

Hands-on: SAP HANA Cloud - Getting Started Tutorial: https://developers.sap.com/mission.hana-cloud-get-started.html

Hands-on: SAP HANA Cloud - Vector Engine – Discovery Mission: https://discovery-center.cloud.sap/missiondetail/4405/

Social: SAP Data Professionals Community: https://community.sap.com/t5/data-professionals/gh-p/data-professionals

Langchain Hana Cache

2026-03-18T07:36:35.841000+01:00

Introduction

When building AI agents your first priority is to make this bad boy work. Get the RAG pipeline properly aligned, check retrieval correctness and check the overall answer usefulness. The task is not an easy one when you work with clients that have thousands or millions of documents that must be ingested properly.

Eventually you reach the point where you deploy the agents in production. You enjoy the good engineering results until the next BTP invoice shows up. You check the token usage and realize you need to do something about it because, well, it is a lot.

So you check your traces, and discover that while there is a ton of interaction with the agent, a big portion of those calls are variations of the same questions. Different users, slightly different wording, but the same answer every time. "How do I reset my password", "password reset help", "I forgot my password." Three different prompts, three LLM calls, three times you pay. Same answer.

That's where I found myself after deploying LangGraph agents on SAP BTP with HANA Cloud. The pipeline worked well. The retrieval was solid (I'd already built langchain-hana-retriever for hybrid search). The agent state was persisted (using langgraph-checkpoint-hana). But the token bill kept growing with every new user asking the same things in different words.

So I decided to also built a semantic cache for HANA Cloud, that will enhance the langchain/langraph solution that I'm using with my SAP clients and their rag Pipelines.

The idea

Pretty straightforward: before calling the LLM, embed the user's prompt and check HANA for a stored response to a similar prompt. If the similarity is high enough, return the cached answer and skip the API call entirely. If there's no match, call the LLM normally and cache the result for next time.

HANA Cloud already has COSINE_SIMILARITY for vector search. It's the same function that powers RAG retrieval. Here I'm just pointing it at prompts instead of documents.

User sends a prompt
Embed the prompt into a vector
Search HANA for cached entries using COSINE_SIMILARITY
If there's a match above the threshold, return the cached response. No LLM call.
If no match, call the LLM, store the prompt embedding + response in HANA, return the response

Installation and setup

as usual pretty straight forward

pip install langchain-hana-cache

The package implements LangChain's BaseCache interface. You set it as the global cache and every LLM call in your application checks HANA first. You don't need to change anything else in your code:

import hdbcli.dbapi
from langchain_hana_cache import HANASemanticLLMCache
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_core.globals import set_llm_cache

connection = hdbcli.dbapi.connect(
    address="your-host.hanacloud.ondemand.com",
    port=443,
    user="DBADMIN",
    password="your-password",
    encrypt=True,
)

embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

cache = HANASemanticLLMCache(
    connection=connection,
    embedding=embeddings,
    table_name="LLM_CACHE",
    similarity_threshold=0.95,
)

set_llm_cache(cache)

llm = ChatOpenAI(model="gpt-4o")

# First call: hits the API, caches the result
response1 = llm.invoke("What are the reporting requirements for article 12?")

# Second call with similar wording: cache hit, no API call
response2 = llm.invoke("Tell me about article 12 reporting requirements")

That second call comes back instantly. Same answer, zero tokens consumed.

What I actually saw when I tested it

I ran three consecutive calls against my HANA Cloud instance to see what happens. First a new question, then the same question but rephrased, then something completely different:

     ======================================================================
       HANASemanticLLMCache Demo
     ======================================================================

     [1] Connecting to SAP HANA Cloud...
         ✓ Connected

     [2] Creating semantic cache (table: LLM_CACHE_DEMO_85DFB4)...
         ✓ Cache ready (vector dim auto-detected)

     [3] First LLM call (cache MISS expected):
         Prompt: "What are the three laws of thermodynamics? Explain briefly."
         Response: The three laws of thermodynamics are fundamental principles...
         ⏱  Time: 9.46s

     [4] Second LLM call (cache HIT expected, similar prompt):
         Prompt: "Explain the 3 laws of thermodynamics in a short summary"
         Response: The three laws of thermodynamics are fundamental principles...
         ⏱  Time: 0.41s

     [5] Third LLM call (cache MISS expected, different topic):
         Prompt: "What is the recipe for a classic French omelette?"
         Response: A classic French omelette is simple yet elegant...
         ⏱  Time: 8.16s

     ======================================================================
       Results Summary
     ======================================================================
       Call 1 (MISS):  9.46s  LLM called, response cached
       Call 2 (HIT):   0.41s  served from HANA cache!
       Call 3 (MISS):  8.16s  different topic, LLM called

       Speedup on cache hit: 23.0x faster (96% latency reduction)
     ======================================================================

9.46 seconds down to 0.41. That's 23x faster. And the omelette question correctly missed the cache because it has nothing to do with thermodynamics. The thing actually works.

Tuning the similarity threshold

This is the one knob you need to care about. The similarity_threshold controls how close two prompts need to be for a cache hit:

0.98: very strict. Only nearly identical prompts match. Safe, but you won't save much.
0.95: what I use. Catches rephrasings without being too loose.
0.90: aggressive. You save more, but you risk serving a wrong answer when two different questions happen to look similar to the model.

I started with 0.95 and haven't needed to touch it. If your agent handles very repetitive questions (think support desk), you could try going lower and see what happens.

Dealing with stale answers

Once this is running in production you'll think about the next problem: what if the source documents change? If someone updates a policy and a user asks about it, the cache might still serve the old answer. TTL (time-to-live) takes care of that:

cache = HANASemanticLLMCache(
    connection=connection,
    embedding=embeddings,
    table_name="LLM_CACHE",
    similarity_threshold=0.95,
    ttl_seconds=86400,  # entries expire after 24 hours
)

# Manual cleanup when you need it
cache.evict_expired()
cache.evict_lru(max_entries=1000)
cache.clear()

What the cache table looks like

Under the hood, the package creates a single table in HANA with:

PROMPT_HASH: SHA256 of the exact prompt to prevent storing duplicates
PROMPT_TEXT: the original prompt text
PROMPT_EMBEDDING: the vector for semantic matching (REAL_VECTOR column)
LLM_STRING: which model generated the response. GPT-4o cache won't serve GPT-3.5 queries.
RESPONSE: the serialized LLM response
CREATED_AT, LAST_ACCESSED, HIT_COUNT: for TTL and eviction

The vector dimension is auto-detected from whatever embedding model you pass in. You don't have to think about it.

When all this makes sense?

Well, this is not something you add on day one to a rag pipeline. As I told at the beginnig of this article, you add it after your agent is working and you're looking at how to make it sustainable, you have to also check whether you are making use the llm cache capabilities, taking care of cache invalidation, the agent making good use of the retrieval tools, etc... In my experience it pays off when:

Multiple users are hitting the agent with variations of the same questions
You're on an expensive model and the monthly bill reflects it
The answers stay valid for hours or days (policies, regulations, product docs, internal knowledge bases)

It makes less sense when every query is truly unique, or when your data changes so fast that the cache is always stale.

Also one thing to keep in mind: every cache lookup needs an embedding call to compare the incoming prompt against stored ones. If your LLM is super cheap, the embedding might actually cost more than just calling the model.

What's next

This is v0.1.0, focused on LLM response caching. I'm working on two more pieces:

Retriever cache: cache the retrieved document chunks so similar queries skip the embedding + vector search step entirely
Pipeline cache: cache the full pipeline result, retrieval + LLM together, for maximum savings on repeated queries

Each one targets a different part of the cost. Together they should cover most of the optimization you'd want after getting a RAG pipeline into production.

Conclusion

Building the agent is the hard part. Making it affordable is the next challenge, and it's a much more tractable one. This cache lives in the same HANA instance as your business data. No extra infrastructure, just one more table. I saw 23x speedups on cache hits in my tests and the token savings add up fast once you have real users hitting the agent every day.

Give it a try and let me know how it goes.

PyPI: https://pypi.org/project/langchain-hana-cache/
GitHub: https://github.com/stubborncoder/langchain-hana-cache

A Use Case for HANA Cloud Knowledge Graph: AI‑Driven Tender Analysis

2026-03-19T16:08:09.126000+01:00

Introduction

Many companies face the same challenge: they need to match unstructured text, such as tenders, applications, or support tickets, with their internal data to make informed decisions. In our project, we tackled exactly this problem and worked on an application that connects text understanding, semantic search and structured data. Our primary objective was to acquire knowledge about the tools SAP offers for developing applications of this nature. We undertook this project as part of SAP’s Early Adopter Care program for the SAP HANA Cloud Knowledge Graph Engine.

Our concrete use case was an internal tender analysis scenario within our company, focusing on public-sector calls for tenders. Deciding about potential participation requires answering several questions: Does the topic fit our company's portfolio, which skills and experience are required and do the required skills exist in our organization, are the necessary resources available? Instead of manually searching for this information through documents and databases, we wanted to automate this process. The goal was to build a system that can read and interpret the tender text, understand the company's internal skill profiles, and combine both to produce a meaningful recommendation.

To achieve this, we combined three capabilities:

semantic structuring of employee data using a knowledge graph
semantic representation of competency descriptions and CVs using vector embeddings
LLM-powered analysis to interpret and connect both worlds

This architecture allowed us to bring together unstructured text and structured data enabling precise matching and explainable results, thus building a foundation that can be reused for many other AI scenarios.

We implemented the application using SAP Cloud Application Programming Model (CAP), a cloud-native framework that seamlessly integrates with SAP HANA Cloud, SAP AI Core and the Generative AI Hub (GenAI Hub). To give you a clear picture of how these components work together, the solution diagram below illustrates the overall flow, from data ingestion to semantic processing to the final application.

Solution Diagram

Provisioning the Resources

To implement this architecture, we provisioned a set of cloud resources in SAP BTP , each of which contribute a specific capability to the overall workflow.

At the center of the setup is SAP HANA Cloud, which provides both the Knowledge Graph Engine (KGE) and the Vector Engine (VE), and in which the CAP application data is persisted. The KGE is not enabled by default; it must be activated when the HANA instance is created and comes with some technical requirements:

Triple Store activation: The KGE relies on the HANA Triple Store, which must be enabled as part of the instance configuration. Without this, RDF triples cannot be stored or queried.
Minimum memory requirement: The KGE requires a HANA instance with at least 48 GB memory. This is necessary because storing the graph, executing SPARQL and SQL statements, and inference processes such as subclass inference, domain/range inference, and transitive property expansion operate in-memory. Smaller instances cannot activate Triple Store at all.

For the AI workflows, we provisioned AI Core which includes the GenAI Hub. AI Core runs the embedding and LLM processing jobs, while the GenAI Hub provides access to the models used for these tasks. This allows the application to generate semantic representations of text documents (tenders and CVs in our use case) and to retrieve information of documents via prompts.

The application layer itself is deployed as a CAP service running in a Cloud Foundry environment. CAP binds to the HANA Cloud, AI Core, and GenAI Hub service instances through standard service bindings, i.e. by receiving all required credentials and endpoints through environment variables.

This provisioning model keeps the architecture modular: each capability (knowledge graph, vector search, AI processing, and application logic) is provided as a separate cloud resource. It also makes the system easy to extend.

Knowledge Graphs and Embeddings: The Semantic Foundation of Our Architecture

Before diving into the SAP-specific components, it is useful to look at the two core concepts that shape our solution: knowledge graphs and embeddings. Both address the same challenge from different angles: turning human-readable meaning into structured, machine-interpretable representation.

Knowledge Graphs: Representing Relations between Data Entities

A knowledge graph stores information not as tables, but as entities and relationships. Instead of using foreign keys and joins, it forms an explicit network of connected facts. This makes it easier to express complex relationships, integrate data, and run queries that follow semantic structures rather than rigid schemas.

At the heart of every knowledge graph is an ontology: a structured definition of entities, properties, and relationships that the graph represents. An ontology defines:

classes (e.g., Person, Skill, Project)
properties that connect them (e.g., hasSkill, requiresSkill)
hierarchies and subclasses (e.g., abstract classes or hierarchical organization units)
constraints and expected value types (e.g., each identifiable entity has exactly one ID of type int)

The ontology gives the graph its semantic structure. It tells the system what kinds of things exist in the domain and how they relate to each other. Without an ontology, a knowledge graph would be just a collection of disconnected triples.

Knowledge graphs are typically stored as RDF (Resource Description Framework) triples, with the following general structure:

Subject – Predicate – Object

Subject: the thing we are talking about
Predicate: the property or relationship
Object: the value or another entity

For example:

Person123 – hasSkill – Python

This triple structure is simple but flexible and extensible. It is especially suitable for representing domains where the data model evolves over time.

To query RDF data, we use SPARQL, a graph-oriented query language. Instead of specifying joins explicitly – as is required in SQL – SPARQL expresses patterns that should appear in the data. This approach is particularly powerful for dynamic or AI-generated queries, where the structure of the query may not be known in advance. While SQL’s traditional query optimization excels when working with predefined schemas and foreign keys, it becomes less flexible when relationships or entity types vary. SPARQL, by contrast, is built to operate on semantic relationships and can naturally accommodate evolving graph structures.

The conceptual difference becomes clear when comparing a typical SQL query—which depends on rigid tables and join conditions—with an equivalent SPARQL query, where relationships are expressed in a way that is closer to how users understand the domain. In SPARQL, entities and relationships are simply assumed to exist in the graph without requiring predefined foreign-key constraints.

SQL-Query example

SELECT
    u.UserID,
    u.JobPosition,
    u.OrgUnitID,
    s.SkillName,
    us.SkillLevel,
    us.SkillLevelName,
FROM Users u
JOIN UserSkills us ON u.UserID = us.UserID
JOIN Skills s ON us.SkillID = s.SkillID
WHERE u.Active = 1

SPARQL-Query example

PREFIX : <http://example.org/my-project#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

SELECT ?person ?position ?skill ?skillName ?level
WHERE {
    ?person rdf:type :Person ;
            :isActive true ;
            :hasJobPosition ?position ;
            :hasUserSkill ?userSkill .
    ?userSkill :connectsToSkill ?skill ;
               :hasSkillLevel ?level ;
               :hasSkillLevelName ?levelName .
    ?skill :hasSkillName ?skillName .   
}

In short:

SQL is designed for handling stable, well-defined tabular schemas with fixed relationships.
SPARQL is designed for handling semantic relationships, flexible graph structures, and dynamically changing query shapes, making it well suited for AI-generated scenarios.

Embeddings: Encoding Text Semantics as Vectors

Embeddings take a different approach. Instead of modelling explicit relationships, they encode the semantic meaning of text as high-dimensional vectors. Similar texts end up close to each other in vector space while unrelated texts are far apart. This enables semantic search, similarity matching and clustering. Embeddings are essential when working with documents like tenders or CVs, where meaning is not explicitly structured but must be inferred.

How This Maps to the SAP World: KGE and VE

SAP HANA Cloud provides built-in components that implement these concepts directly inside the database:

The Knowledge Graph Engine (KGE) stores RDF triples and executes SPARQL queries. It gives us explicit, queryable relationships between entities such as people, skills, and projects.
The Vector Engine (VE) stores embeddings and provides functions for calculating the cosine similarity between embeddings, which simplifies similarity searches. It allows us to compare tender documents with CVs or skill profiles on a semantic level.

Together, KGE and VE combine explicit knowledge in the form of the knowledge graph structure with implicit meaning in the form of text embeddings. This dual representation enables our application to extract relevant information from tender documents and map it to our data model of employee competencies.

In the next section, we will look at how we designed the ontology and processed the data to populate both engines.

Building the Knowledge Graph

Creating the knowledge graph was a multi-step process that combined data engineering, domain modeling, and graph construction. While some parts of the pipeline can be automated, the core design work requires domain knowledge and deliberate modeling decisions. In our project we followed a three-stage approach.

Selecting and Structuring Relevant Data

The first step was to identify which data should become part of the knowledge graph and how these pieces of information relate to each other. This is a classic data engineering task: understanding the domain, exploring the available data sources, and deciding which entities and relationships are relevant for the scenario.

In our case, this meant analyzing the existing SQL-based data model (employees, skills, projects, roles, and assignments) and determining which parts of it contain meaningful information for matching tenders with internal capabilities. This step cannot be easily automated; it requires domain knowledge to decide which entities and relationships between them matter for the business question and which attributes are relevant for which entity type.

Creating An Ontology

Once the structure of the ontology has been decided on, it can be translated into classes, properties, hierarchies, and constraints that structure the graph.

Our ontology is defined using Turtle (Terse RDF Triple Language), a human-readable syntax for expressing RDF data. Turtle is a W3C standard that provides a compact and intuitive way to describe semantic relationships. It is based on the following key syntax elements:

Prefixes: Define namespace shortcuts for cleaner code

@prefix : <http://example.org/our-project#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

Classes: Define entity types using a owl:Class

:Person a owl:Class ;
    rdfs:label "Person" ;
    rdfs:comment "Individual employee or consultant" .

Properties: Define relationships (ObjectProperty) or attributes (DatatypeProperty)

:possessesSkillWith a owl:ObjectProperty ;
    rdfs:domain :Person ;
    rdfs:range :UserSkill .

This links a person to their skill instances which include, e.g., proficiency levels and experience.

Triples: The fundamental RDF structure (Subject-Predicate-Object)

:Person rdfs:subClassOf :IdentifiableEntity .

This reads as: "Person is a subclass of IdentifiableEntity"

The semicolon notation allows defining multiple properties of the same entity without repeating the subject. The following statement is equivalent to four separate triples, but much more readable:

:Person a owl:Class ;
    rdfs:label "Person" ;
    rdfs:comment "Individual employee" ;
    rdfs:subClassOf :IdentifiableEntity .

To organize related concepts, we introduced abstract classes. They reduce redundancy by collecting shared properties in one place instead of repeating them across many similar classes. This makes the ontology easier to maintain and ensures consistency because updates to shared properties only need to be made once.

In addition to structuring the model, the ontology also defines formal constraints that describe how data in the knowledge graph is expected to look. These constraints specify rules and cardinalities, such as requiring each person to have exactly one UserID or ensuring that each project includes a start date. While SAP HANA Cloud cannot automatically enforce these constraints without a reasoner, they still serve as valuable documentation and help implementing validation checks using Shapes Constraint Language tools.

Creating Instances

The knowledge graph contains instances that are generated from data stored in a relational database. To connect both worlds, we defined a mapping that links SQL tables and columns to ontology properties. For example, the ontology property hasUserID corresponds to the column UserID in the table Users in an SQL database. This declarative mapping makes it possible to extract relational data and convert it into semantic triples .

Simple one‑to‑one and one‑to‑many relationships can be handled directly. For many‑to‑many relationships, we added an extended mapping layer that can follow junction tables in the relational schema.

Because SAP HANA Cloud’s RDF Store does not include a reasoner, inverse properties cannot be inferred automatically. They must be created explicitly during triple generation. To support this, our mapping configuration allows us to define inverse property pairs (e.g., tagsProject ↔ projectTaggedWith), so the parser generates both directions of the relationship automatically.

The triple generation pipeline runs in several steps. First, it creates datatype property triples (literal attributes), automatically assigning the correct types based on the ontology. Then it generates object property triples (links between entities), using an in-memory index to quickly look up target URIs. For large datasets, the system uses chunked batch processing to load triples in bulk, which improves performance and reduces memory usage.

Each ontology class is written into its own RDF graph, allowing updates to specific entity types without reloading the entire knowledge base. Finally, the system serializes these graphs into Turtle (.ttl) files and uploads them to the SAP Knowledge Graph Engine (i.e., SAP HANA Cloud’s RDF Store).

Requirement Analysis and Evaluation

Extracting required skills and experience levels via Prompts

To extract information from tender documents, we developed an LLM‑based pipeline that first checks whether a tender fits the company’s domain. For tenders that match the business profile, the pipeline automatically generates a concise text summary and extracts the skills referenced in the document. For each identified skill, it captures the skill name, and its stated importance level in the tender — classified as must-have, should-have, or nice-to-have (when explicitly indicated in the text).

Skills and priorities

Skill Matching

This structured extraction turns free‑text requirements into machine‑readable skill profiles that can be directly queried within our knowledge graph. For these queries, the system needs to match the skills extracted by the LLM with the skill names stored in the employee database. These names rarely match exactly because of synonyms or different wording. We have implemented this matching by first looking up the top-k skills most similar in terms of word embedding using the Knowledge Graph Engine and subsequently filtering out entries that are unrelated to the skill mentioned in the tender via a prompt (for example, matching “Python” in the tender to entries like “Python 3” or “Python Programming” in the employee database).

Once the skill mapping is complete, the matched skills are inserted into a predefined SPARQL query. This query returns all employees who have these skills, including their proficiency levels, enabling automated candidate identification for tender requirements.

By combining embeddings with LLMs, the system can handle linguistic variations while still generating precise SPARQL queries.

Users matching

Requirement Evaluation

Once employees with the required skills are found through the SPARQL queries, the system calculates a skill score based on their proficiency levels. A skill receives a score of 1.0 if at least one employee is an expert, 0.8 for intermediate proficiency, 0.5 for beginner-level proficiency, and 0.0 if no one in the company has that skill. This gives an overall picture of how well the organization covers each required competency.

The skill scores are aggregated within the importance levels (must‑have, should‑have, nice‑to‑have) using a simple average. The result is a score for each importance level that shows how well the company’s employees' competencies match the tender requirements at different levels of importance.

Aggregated scores

Supplementary Analysis: Comparing Employee CVs and Tender Text

Beyond the structured skill matching outlined above, we added a second analysis pipeline which determines the suitability of candidates for a given tender document by evaluating the semantic similarity between employee CVs and tender text based on embeddings.

Employee CVs are split into meaningful chunks (up to 6,000 tokens each) so that related information about projects and skills stays together. Each chunk is then embedded using a suitable model deployed through the SAP AI Core and stored in SAP Vector Engine (i.e. SAP HANA Cloud’s vector database) for semantic search. Tender documents go through the same embedding process, turning unstructured text into dense vectors that capture meaning beyond simple keywords.

To identify suitable candidates, the system compares CV embeddings with tender embeddings using cosine similarity, ranking employees according to how closely their experience aligns with the project requirements. By capturing semantic similarity rather than relying on exact keyword matches, this approach enables accurate matching even when different wording or terminology is used.

By combining precise skill matching through the knowledge graph with semantic search across CV embeddings, the system provides a comprehensive way to find candidates based both on explicitly listed competencies and experience descriptions.

Outlook

As a next step, we plan to enable fully automated tender analysis where LLMs generate SPARQL queries directly from the tender text, without relying on predefined templates. This means the LLM would translate project requirements into precise knowledge graph queries on its own. For example, if a tender asks for “three senior Java developers with cloud architecture experience and at least five years in the financial sector,” the LLM would automatically create a SPARQL query that filters employees by skill levels, domain experience, and project history, returning all candidates who meet these criteria in one step.

Introducing Performance Analyzer in SAP HANA Cloud Central

2026-03-24T00:07:25.343000+01:00

Overview

SAP HANA Cloud Central now includes the Performance Analyzer, a new capability for visualizing and analyzing historical performance data of SAP HANA Cloud database instances. This feature enables administrators to identify performance issues, investigate root causes, and make data-driven decisions based on up to 42 days of historical metrics.

This blog post provides an overview of the Performance Analyzer, its key features, and guidance on how to use it effectively.

Background

Performance troubleshooting in cloud database environments requires visibility into historical data. While real-time monitoring provides insight into current system state, identifying the performance degradation or correlating issues with specific events requires access to historical metrics.

The Performance Analyzer addresses this need by providing comprehensive historical data visualization, interactive exploration capabilities, and customizable views for different analysis scenarios.

Key Features

Load History Chart

The Load History chart serves as the primary navigation tool within the Performance Analyzer. It displays up to 42 days of historical data for selected key performance indicators (KPIs), enabling administrators to:

Identify time periods with anomalous behavior
Select specific time ranges for detailed analysis
Correlate performance changes with system events

The chart includes two sections: an overview panel showing the full 42-day history, and a detail panel that displays granular data for the selected time range.

Chart Library

The Performance Analyzer includes a Chart Library containing visualization components organized by category:

CPU, Memory, Lock, Transaction, Workload, Delta merge, Statement, Session, Savepoint

Administrators can browse charts by category, search for specific visualizations, and preview charts before adding them to the current view.

Preset and Custom Views

The Performance Analyzer provides preset views optimized for common analysis scenarios:

CPU: Charts relevant to processor utilization and statement performance

Memory: Charts focused on memory consumption patterns

Lock: Charts for transactional lock and concurrency analysis

Administrators can also create custom views by modifying preset configurations, adding charts from the library, and saving personalized layouts for future use.

Interactive Exploration

All charts within the Performance Analyzer support interactive data exploration:

Tooltips display precise values when hovering over data points
Time range selections synchronize across all charts in the view
Zoom and pan controls enable detailed examination of specific periods

Accessing the Performance Analyzer

The Performance Analyzer is accessible through multiple entry points within SAP HANA Cloud Central:

Side Navigation

Select the Performance Analyzer icon in the left navigation panel to access the tool directly.

Instance Overview

From the instance Overview page, navigate to the Memory or Compute cards and select "Analyze Performance."

Alerts Integration

When viewing alerts related to CPU, memory, or transactional locks, select "Analyze Performance Issue" in the alert details to open the Performance Analyzer with the relevant time context.

Command Palette

Open the Command Palette, search for "Performance Analyzer," and select the target instance from the results.

Joule Integration

The Performance Analyzer is also accessible through Joule. Request performance analysis or enter "Performance Analyzer" to receive navigation assistance.

Use Cases

Analyzing CPU Utilization

To investigate CPU-related performance issues:

Access the Performance Analyzer and select the CPU preset view
Use the Load History chart to identify periods of elevated CPU usage
Select the time range of interest to view detailed metrics
Add relevant charts such as "Total Execution Time by Statement Hash"

Analyze which statements or operations contributed to CPU consumption

Investigating Memory Consumption

To examine memory usage patterns:

Select the Memory preset view
Review the Load History chart for unusual consumption trends
Add memory allocator charts to identify contributing components

Examine host allocator visualizations to determine memory distribution

Troubleshooting Performance Degradation

To investigate general performance degradation:

Use the Load History chart to establish baseline performance patterns
Identify the time when degradation began
Compare metrics from before and during the performance issue

Add relevant charts to analyze changes in system behavior

Summary

The Performance Analyzer in SAP HANA Cloud Central provides administrators with comprehensive tools for historical performance analysis. By combining extensive data retention, flexible visualization options, and multiple access methods, it enables efficient identification and resolution of performance issues in SAP HANA Cloud environments.

What’s New in SAP HANA Cloud – March 2026

2026-03-24T16:54:37.626000+01:00

We’re kicking off 2026 with a new set of innovations in SAP HANA Cloud, continuing our evolution as the database that AI was looking for.

The Q1 2026 release introduces capabilities that enhance automation, flexibility, and intelligent data interaction, from infrastructure expansion and improved scalability to new agent-driven approaches for exploring enterprise data. Together, these innovations help organizations reduce complexity, optimize performance, and unlock faster insights.

Let’s dive into some of the key highlights of this release.

SAP HANA Cloud agents

Following our announcement at TechEd 2025, we are excited to bring you the Data & Discovery Agent Procedures in SAP HANA Cloud.

As part of our journey toward a more agentic and AI-native data platform, these agent procedures combine knowledge graph–based discovery with AI-driven query generation. This allows users to engage with their data in a more intuitive, conversational way, reducing the need for deep SQL expertise.

With the SAP HANA Cloud Data & Discovery Agents, business users and developers alike can more easily bridge the gap between business questions and complex data models, accelerating access to insights and enabling more efficient data exploration.

To support early adoption and gather valuable feedback, this capability is now available through a Beta Program, with registration starting April 1. We invite you to participate, explore the features firsthand, and help shape the future of agent-driven data interaction in SAP HANA Cloud.

Register here for the Beta Program:
https://url.sap/399tsd

For more information, check out this blogpost by @shabana

Machine Learning and NLP services Updates

With the Q1 2026 release of SAP HANA Cloud, we continue to strengthen embedded Machine Learning and AI capabilities across the Predictive Analysis Library (PAL), and the Natural Language Processing (NLP) services. These enhancements focus on making tabular AI predictions using custom AI models or semantic data retrieval scenario easier to use and applied to real business application data.

Key highlights of this release are:

A new Text column TFIDF with truncatedSVD transformer operator in AutoML, for simplest and efficient text feature processing for use cases like Service Ticket Intelligence
A new dimension reduction function for stored text embedding vectors, allowing to reduce high cardinality vectors to lower cardinality of 62, 128 or 256 dimensions for faster processing while retaining key semantic insights
A new feature space reduction function Feature Agglomeration, allowing to group correlated feature columns into compact, interpretable clusters, thus reducing feature dimensionality
Support for clustering of Vector columns using the Affinity Propagation clustering function
Faster text classification function, supporting float precision for better performance
Introducing a SQL CROSS_ENCODE function, for more precise semantic re-ranking of search retrieval results using the SAP HANA Cloud NLP services
The python Machine Learning client for SAP HANA 2.28 supporting several new functions like text log parsing, cross encoder and parameter optimization with the multi-task multilayer perception neural network function.

Calculation View Modeling

As with every release, numerous new capabilities and enhancements were added to Calculation View Modeling in SAP HANA Cloud. One of the highlights clearly is the ability to semantically import SAP HANA Cloud Calculation Views into SAP Business Data Cloud, for reuse purpose without data duplication.

To learn more about additional Calculation View Modeling innovations, check out this blogpost by JanZwickel.

Reuse Calculation Views in SAP Business Data Cloud (BDC)

Combined, SAP HANA Cloud and SAP Business Data Cloud are a strong foundation for your data and analytics use cases.
Semantic onboarding in SAP Business Data Cloud enables calculation views from SAP HANA Cloud to be leveraged in BDC without transferring data, only semantics are transferred, creating BDC proxies.
As such, we enable uses to re-use existing investments made into calculation views, in SAP BDC. Moreover, we foster a HANA-native approach of modeling, tightly integrated with BDC capabilities; enabling you to extend our HANA-based data marts with SAP BDC. Untimely, allowing you to benefit from both solutions in combination.

AT the moment, two integration modes are available:

Flat View: Onboards views as flat structures (not for Dimension Views). Use for minimal BDC enhancements.
Construction Kit: Imports only private attributes, allowing flexible recombination in BDC. Supports Dimension Views.

Onboarded semantics include input parameters, variables, currency/unit conversion, labels, hierarchies, and information about star-join dimensions. Further enhancements are planned, and roadmap is driven by customer feedback.

Are you eager to adopt the bi-directional integration between SAP HANA Cloud and SAP Business Data Cloud? If yes, learn more about our SAP HANA Cloud Customer Care Program down below.

SAP HANA Cloud Customer Care Program

Calculation Views in the Context of SAP Business Data Cloud

To further support customers and partners exploring integration scenarios between SAP HANA Cloud and SAP Business Data Cloud, we are introducing a dedicated SAP HANA Cloud Customer Care Program focused Calculation Views in the Context of SAP Business Data Cloud

This program is designed to help participants explore how existing SAP HANA Cloud calculation views can be leveraged in the context of SAP Business Data Cloud, particularly through semantic onboarding, which enables reuse of models without requiring data replication. In addition, participants can evaluate scenarios such as building new calculation views on top of SAP Business Data Cloud Data Products.

Through this initiative, we aim to work closely with customers and partners who are actively working on, or planning, projects in this space. Participants will have the opportunity to gain early insights into new capabilities, receive guidance during implementation, and provide direct feedback that helps shape future enhancements.

Participation in the program is limited and based on alignment with the program scope and project requirements.

Register here for the Customer Care Program:
https://url.sap/qw0rnu

SQL Tools for Administration in SAP HANA Cloud Central

SQL Console Code Completion

With the Q1 Release, the SQL console in HANA Cloud Central now includes enhanced code completion that suggests both SQL snippets and schema objects as you type, making it quicker and easier to work with SQL. As users begin typing, the console will display recommended snippets such as CREATE TABLE, CREATE PROCUDURE, or GRANT. When the user selects a statement, it will insert a complete template automatically. It also provides lookups for tables, views, and columns within the current schema, reducing errors, and helping users find the objects they need. These improvements boost productivity for experienced users and make the SQL experience far more approachable for those who are new to SQL.

SQL Console GenAI

The SQL Console now includes new GenAI‑powered actions that make working with SQL faster and more accessible. Within the Run menu, users will find three new options: Run Prompt, Explain SQL Statement using AI, and Optimize SQL Statement using AI.

By selecting text in the SQL Console and choosing Run Prompt, users can generate SQL statements directly from natural‑language instructions. The Explain option provides clear natural‑language explanations of SQL statements, including complex queries, while Optimize SQL Statement uses AI to refine and improve existing SQL for better performance. These enhancements help users work more efficiently and make SQL much easier for those who are new to it.

SAP HANA Cloud Clients

Addition of the SAP HANA database client to the package manager for .NET

The SAP HANA database client is officially available on NuGet, making it easier than ever for developers to integrate SAP HANA Cloud into their applications. By adding the SAP-provided packages directly from the SAP profile and NuGet, developers can quickly include both the HANA .NET driver and Entity Framework Core provider without needing manual downloads or custom setup. Users can also now see the updated tutorials on Connecting Using the Microsoft Entity Framework Core (EF Core) and SAP HANA .NET Interface.

Direct connection option for replicas

The SAP HANA Client supports a direct connection option for replicas, enabling applications to explicitly route read-only workloads away from the source system. Developers can now use a SQL hint such as WITH HINT (RESULT_LAG('hana_sr')) to target replica nodes for read‑only queries or specify the connection property replicationRole=REPLICA to ensure the connection is established directly with a replica. This capability improves cost efficiency and performance by offloading analytical workloads from the source system while still maintaining full high‑availability readiness. We also have this new tutorial on Routing queries to a read only replica.

New installation program for the data lake client

The data lake client now includes a new installation program based on the SAP HANA database lifecycle manager, providing a more unified and streamlined setup experience. This installer will be available through the SAP Software Center and supports Microsoft Windows, Linux x64, and Linux ARM64. When downloaded from the SAP Software Center, it also includes the required cryptographic libraries, simplifying deployment, and ensuring secure operation. This harmonized installation process makes it easier for customers to install and manage clients for SAP HANA Cloud.

Enabling HTTP proxy support for the data lake client

The data lake client now supports connecting through an HTTP proxy, enabling better compatibility with enterprise network environments. Users can enable proxy usage by configuring the settings proxyHTTP=true, along with proxyHost, proxyPort, proxyUser, and proxyPassword. These options allow the client to route traffic through an organization’s proxy infrastructure while maintaining secure and controlled access. This enhancement ensures the data lake client fits seamlessly into enterprise deployments that rely on HTTP proxy requirements.

Performance Analyzer in SAP HANA Cloud Central

With the Q1 2026 release, SAP HANA Cloud Central introduces the Performance Analyzer, a new capability for analyzing historical performance data of SAP HANA Cloud database instances.

The Performance Analyzer provides access to up to 42 days of historical metrics, enabling administrators to identify performance issues, investigate root causes, and correlate system behavior over time. This complements real-time monitoring by adding the historical visibility required for effective troubleshooting.

Key capabilities include:

Load History Chart
A central entry point for analysis, allowing users to identify anomalies, select time ranges, and correlate performance changes with system events across a 42-day history.
Chart Library
A collection of predefined visualizations across categories such as CPU, memory, locks, transactions, and workload, which can be added dynamically to analysis views.
Preset and Custom Views
Predefined views for common scenarios such as CPU, memory, and lock analysis, with the ability to create and save custom views tailored to specific needs.
Interactive exploration
Support for tooltips, synchronized time selection, and zooming, enabling detailed analysis of specific time periods.

The Performance Analyzer is integrated across SAP HANA Cloud Central and can be accessed through multiple entry points, including the side navigation, instance overview, alerts, command palette, and Joule.

Typical use cases include analyzing CPU utilization, investigating memory consumption, and troubleshooting performance degradation by comparing historical system behavior.

To learn more, please check out this blogpost by @Hai

Data Integration

Smart Data Access: Support for a New Cloud MySQL Remote Source Through the Data Access Agent

With the Smart Data Access (SDA) Data Access Agent introduced in QRC 03/2025, readonly access to a new remote source, MySQL in the cloud, will be available starting in QRC 01/2026.

Configuration and usage remain the same as for previously supported remote sources. For newly provisioned Data Access Agents, all new adapters are activated by default. To activate new adapters on an already provisioned Data Access Agent, refer to SAP Note 2600176, SAP HANA Smart Data Access Supported Remote Sources, for details on activation and support information.

Elasticity

Elastic Compute Node: Automated ECN Provisioning and Deprovisioning Through ECN Policy

SAP HANA Cloud introduces a significant enhancement to Elastic Compute Node management with the new ECN policy feature, available starting with QRC 01/2026. Previously, ECN Advisor recommendations required manual action. With ECN policies, the system can now automatically provision and deprovision ECNs based on your workload patterns. After running the ECN Advisor, you can choose scheduled scaling for predictable usage or demand based scaling for more dynamic environments.

Scheduled scaling allows you to define recurring timebased rules to add or remove ECNs. Demand based scaling adjusts capacity automatically according to system load, and the initial release provides two scaling focuses, Availability and Cost. These options determine how aggressively the system reacts to load changes, with the ability to scale up to sixteen ECNs sequentially. Table replication continues to require separate handling, and each instance supports one demand based policy with the option to configure multiple scheduled policies. More details can be found in the About ECN Policies section.

Further news:

SAP HANA Cloud Datacenter expansion

In Q1 2026, we are expanding the global availability of SAP HANA Cloud in four new BTP regions:

Germany (Frankfurt) and UK (London) on Microsoft Azure,
Japan (Tokyo) and US East (Sterling) on SAP Cloud Infrastructure (SCI).

With these additions, SAP HANA Cloud is now available in more than 40 public cloud locations worldwide. While most regions run on hyperscalers, SAP HANA Cloud continues to strengthen its footprint on SAP Cloud Infrastructure (SCI), which now spans seven regions (see Figure 1). This expansion provides customers with greater flexibility to choose both the infrastructure provider and deployment region that best align with their business, performance, and regulatory requirements.

EU22—the second Microsoft Azure region in the EU—lays the foundation for future multi-region disaster recovery within the EU. Similarly, US01—the second SCI presence in the United States—prepares the groundwork for future multi-region disaster recovery capabilities in the US. For the latest updates on the availability timeline for multi-region disaster recovery in these regions, please refer to SAP Roadmap Explorer.

SAP HANA Cloud Public Cloud Locations 

Expanded Performance Class Options Across Hyperscalers

SAP HANA Cloud continues to enhance flexibility in sizing and performance across supported infrastructures.

On Alibaba Cloud, SAP HANA database instances now support additional performance classes and instance sizes. With the QRC 01/2026 update, you can provision configurations tailored to different workload requirements, ranging from memory-intensive scenarios with up to 8 TB of memory to more compute-focused setups. This provides greater flexibility to align system sizing with specific application needs.
More details about the available options can be found SAP HANA Database Size.

On AWS, a new 16 GB instance size is now available, designed specifically for low-throughput and lightweight workloads. This option enables more efficient deployment of smaller applications, development and testing environments, and cost-sensitive use cases, helping avoid overprovisioning.

This instance size will also be made available on Google Cloud Platform and Microsoft Azure, further extending consistent sizing flexibility across all hyperscalers supported by SAP HANA Cloud.

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

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

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

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

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

Calculation View Features of 2026 QRC1

2026-03-25T08:21:00.192000+01:00

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

Reuse of Existing Calculation Views in SAP Business Data Cloud (BDC)

To reuse existing calculation views in the context of BDC, calculation views can be semantically onboarded. This offers the opportunity to leverage calculation views in SAP HANA Cloud standalone and at the same time to also use and extend the calculation views in BDC. This way the best of both solutions can be used.

Semantic onboarding transfers the semantic and logic of the calculation view without moving the source data into BDC. It creates BDC proxies ready for use in BDC modeling.

Semantic Onboarding

1. Start the semantic onboarding process in BDC by selecting a BDC Integration mode in SAP Business Application Studio:

Integration Mode

"Flat View": This mode onboards calculation views as a flat structure that includes the private and shared attributes of the calculation views. This integration mode is not available for Dimension Views

Use this option if you do not anticipate larger enhancements in BDC and are looking for a quick integration

"Construction Kit": This mode imports only the private attributes of cubes giving you the freedom to recombine or change the structure of the original calculation views in BDC. Also Dimension Views can be imported in this mode.

Use the Construction Kit approach if you require flexibility in recombining calculation views in BDC

All integration modes create BDC proxies for the calculation views. Queries targeted to these proxies will be directed to the source calculation view.

2. Continue with the semantic onboarding in BDC (requires upgraded version of SAP Datasphere. Below are lab-preview screenshots of what is planned to become available end of April 2026)
:

Onboarded Semantic

Currently, the following semantic information of calculation views is reused by the Analytic Model:

Input Parameters
Variables
Currency and unit conversion information
Labels for user-friendly displays
Shared hierarchies for dimensional analysis
Information about Dimensions of star-joins

Use semantic onboarding to leverage existing calculation views in the context of SAP Business Data Cloud

Data Classification

Different data classifications can be assigned to calculation views to indicate how data that are returned by a calculation view should be treated.

Setting Data Classification of Calculation View

Assign data classification levels to your calculation views to clearly indicate how the returned data should be handled. Simply define the classification under "View Properties". The available ratings are sourced from the _SYS_BI.BIMC_SENSITIVITY_CLASSIFICATION table.

The data classification of a calculation view can be read from column SENSITIVITY_CLASSIFICATION of table _SYS_BI.BIMC_ALL_AUTHORIZED_CUBES

When a calculation view is opened or a Data Source added a warning is shown if the current calculation view has a lower classification than any of the directly consumed calculation views. You’ll be offered the option to upgrade the rating to match the highest sensitivity level of the directly consumed calculation views, ensuring consistent data governance.

Use data classifications to support the consistent handling of classified data throughout your company

MDS Cube: Incremental Loading

Use incremental loading for your MDS Cubes - a smart approach that updates only newly added records since the last load, dramatically reducing both processing time and resource consumption.

How to enable it

Define an MDS Cube attribute as an Incremental Column:

The selected column must increase with each record that is added to the result set of the calculation view.

During incremental loading only records are loaded that have higher values in this column than the highest value at the last time of loading.

Use the Update command to start incremental loading.

Use incremental update when loading MDS Cubes to speed up loading and to reduce CPU and memory consumption

Copy Nodes with Descendants

Need to replicate complex calculation logic across multiple views? The "Copy with Descendants" feature makes it simple.

1. Right-click the node you want to copy with its feeding structures and select "Copy with Descendants" :

2. In the target view right-click an empty space and select "Paste":

Your entire node structure, including all feeding components, is duplicated saving you valuable development time.

Leverage "Copy with Descendants" to reuse calculation view logic across calculation views

Working with Data Sources

Easily copy element texts such as the data source name or calculation view name using a right-click or a keyboard short-cut:

Data sources are now included in the Outline panel giving you an instant overview of which sources are used throughout your calculation view and exactly where they appear:

Use the Outline to get an overview of which data sources are used in a calculation view and in which nodes

Key Column Indicator

Visual key column indicators help you quickly identify which columns belong to a data source’s key - essential information when defining joins or cardinality information.

The information of the key indicator is based on the primary key definition in case of table data sources and on the Semantics key in case of calculation views as data sources. The visual key column indicators are shown in the join definition and mapping displays.

A key indicator can appear in gold or grey and can be solid or dashed:

A golden icon visualizes a complete key. All key columns are present.

A dashed icon indicates an incomplete key. Only some columns from a multi-column key are projected.

Grey indicates that some intermediate operations (joins, unions, or table functions) potentially removed the key property.

Use information about key columns e.g., when deciding on join columns

Spill To Disk Hints in Execution Hints List

For queries where performance isn’t critical, Spill To Disk hints let you trade execution speed for lower memory consumption. These hints are now conveniently available in the pre-defined hint list:

Decrease memory consumption for queries that are not performance critical using the Spill To Disk Hints

Visualize Blockers of Filter Push-Down

Filters typically work best when applied early in query execution, reducing record volumes from the start. However, certain node types and modeling patterns can block filter push-down due to their impact on results. Dedicated options exist to enforce the push-down of filters also in this case.

Nodes or modeling patterns that block the push-down of filters are now marked by a icon so that it becomes easier to detect and deal with filter blocking operations.

Below is an example where a Rank node blocks filter push-down:

If you enable the filter push-down the icon disappears:

Similarly for multi-consumer patterns:

Quickly identify potential blockers for filter push down and decide based on your business needs whether to remove the blockers or not

Architecting Electronic Bill of Lading on SAP BTP - Rethinking Paper-Based Trade (Part 1 of 3)

2026-03-27T10:29:07.001000+01:00

Introduction

After participating in the SAP Multidimensional Architect Program at the SAP Academy in California during Fall 2025, I was particularly inspired by a session titled “From Blueprint to Real Architecture,” which showed how to design end-to-end solutions, one of the cases presented, was international trade scenario, area of my personal interest over the last few years. That experience motivated me to write this Proof of Concept.

This article focuses on the scenario of Ocean Carriers transitioning from paper-based processes to a fully digital platform, aiming to reduce CO₂ emissions while ensuring security and transparency among stakeholders. The solution implements the Electronic Bill of Lading using IMDA's TradeTrust , an open-source framework that enables the creation of digital trade documents represented as NFT(ERC-721 tokens) on a blockchain network.

This PoC demonstrates how this capability can be deployed on SAP Business Technology Platform, aligned with Digital Container Shipping Association (DCSA) standards.

Article Summary

This three-part series demonstrates how international trade can move from paper-based operations to secure and automate processes while helping organizations achieve their sustainability goals

Part 1 – Case Study: Introduces the shift in global trade from paper-based documents to Electronic Bills of Lading.
Part 2 – Blueprint: Describes the key building blocks of the solution, including: event-driven architecture, SAP BTP, Automation, TradeTrust Framework, UI, and the architecture diagram.
Part 3 – End-to-End Scenario: Shows the lifecycle of the Electronic Bill of Lading through a real-world scenario.

1. Case Study

The global shipping industry, responsible for approximately 90% of world trade, faces pressure to reduce its environmental footprint. Traditional paper-based Bills of Lading, critical for international trade, contribute to deforestation, water pollution, and greenhouse gas emissions through their production, transportation, and disposal.

2. Business Context

Paper Bills of Lading(BL) plays a crucial role in international trade, serve as Receipt, Contract and Document of title. This document is been the core of international trade for centuries.

Receipt: The BL, which is issued by the carrier, serves as proof that the cargo has been loaded onto the vessel, documenting the quantity and condition of the goods at the time of shipment.
Contract: It acts as a contract of carriage between the shipper, carrier and consignee, defining the agreed terms and conditions of transportation.
Document of title: It acts as a document of title, representing ownership of the goods while they are in transit. Possession of the original bill of lading allows the holder to claim the goods upon their arrival or arrange transfer ownership of the cargo to another party in the supply chain.

The process typically starts with the carrier issuing the BL to the shipper/seller upon receiving the goods. The shipper/seller then sends the original bill of lading to the buyer, often through a bank, to ensure that the seller receives the payment before the goods are released to the buyer. Finally, the consignee/buyer presents the original bill of lading to the carrier at the destination port to take possession of the goods.

Problem

Traditionally, this has been paper-based, the document must travel physically between banks and buyers across countries, requiring couriers, manual signatures, and physical handovers. Each party checks it manually, which takes 5-10 days, and if the cargo is traded while the ship is at sea, the bill changes hands multiple times. This often causes ships to wait at port, creates demurrage costs, and forces parties to use risky workarounds like letters of indemnity, which carry legal and financial risks.

Total time needed for B/L transfer via express courier service: 5-10 days

Solution

The emergence of blockchain technology has enabled the development of Electronic Bills of Lading(eBL), offering not only enhanced security and efficiency but also the potential for a substantial reduction in paper consumption and associated carbon emissions.

Blockchain provides a decentralized and transparent system to manage eBL. The data is not controlled by a single party, but shared across a network where all participants can verify the transactions. Every action, such as issuing or transferring the eBL, is recorded on the blockchain and can be traced by authorized parties. Transactions are validated almost in real time, allowing the eBL to be transferred within minutes instead of several days required with paper documents sent by courier.

By eliminating millions of paper documents and the need for courier shipments, organizations can reduce delays, lower operational costs, minimize the risk of errors, and decrease carbon footprints while aligning with ESG commitments. Electronic bills of lading on an Ethereum Layer 2 can cut carbon emissions by ~96% compared to traditional paper B/Ls.

Electronic Bill of Lading Lifecycle[4]

The benefits of the eBL are many and huge. In the announcement, DCSA wrote: “Switching away from the transfer of physical paper bills of lading could save $6.5 billion in direct costs for stakeholders, enable $30-40 billion in annual global trade growth, transform the customer experience and improve sustainability.”

Payment Settlement in International Trade

In traditional international trade, payments are typically secured through banking instruments such as Letters of Credit, documentary collections, or bank guarantees. In these models, banks act as trusted intermediaries that verify trade documents, including the Bill of Lading, before releasing payment from the importer to the exporter. While these mechanisms provide security, they are often manual, time-consuming, and highly dependent on paper-based documentation.

As trade processes move toward digital documentation, new opportunities emerge to integrate payment mechanisms directly with Electronic Bills of Lading.

By combining digital payments with eBL, parts of the trade process could be automated. For example, a smart contract on a blockchain funded by the importer could hold the payment until predefined conditions are met. Once ownership of the eBL is transferred to the importer, the smart contract could automatically release the funds to the exporter. In this context, stablecoins may play an important role by enabling fast and programmable digital settlement.

At the same time, modern banks increasingly provide APIs for Letter of Credit verification and trade finance services. Through networks such as SWIFT, financial institutions can exchange standardized payment messages and verification data. These capabilities can be integrated into digital trade platforms, helping automate document verification.

Although payment is not explored in detail within the scope of this Proof of Concept, the architecture presented here is designed to support such capabilities in the future, allowing payment orchestration to be incorporated as the trade ecosystem continues to evolve.

The Future of Global Trade

In February 2023, DCSA announced a multi-carrier agreement to get to 100% usage of electronic Bills of Lading by 2030.

Thomas Bagge, chief executive officer, DCSA stated, “The digitalization of international trade holds vast potential for the world economy by reducing friction and, as trade brings prosperity and the eBL will further enable trade, helping bring millions out of poverty. Document digitalization has the power to transform and requires collaboration from all stakeholders.”

3. Solution Implementation

In order to develop a fully digitalized solution for international trade that leverages blockchain technology for the Electronic Bill of Lading, the solution should be aligned with industry standards to ensure interoperability, operational efficiency, and regulatory compliance. The solution follows the guidelines established by the Digital Container Shipping Association (DCSA) and the United Nations Centre for Trade Facilitation and Electronic Business(UN/CEFACT) .

To support the implementation of the Electronic Bill of Lading, this Proof of Concept leverages TradeTrust , an open-source framework developed by the Infocomm Media Development Authority (IMDA) . TradeTrust provides a neutral infrastructure for the digitization and secure exchange of trade documents, aiming to make international trade safer, faster, easier, and more cost-effective.

The framework uses a public blockchain to maintain a single source-of-truth record of document ownership and aligns with the principles of the MLETR(Model Law on Electronic Transferable Records) , established by the UNCITRAL(United Nations Commission on International Trade Law).

How TradeTrust Works

Conclusion

In Part 1, I explored the benefits of the Electronic Bill of Lading and its potential to transform the industry—driving sustainability, improving transparency across the supply chain, and accelerating global trade operations.

🔗In Part 2 , I’ll walk through the technical design and core building blocks behind the solution.

Architecting Electronic Bill of Lading on SAP BTP - Blueprint (Part 2 of 3)

2026-04-02T00:23:19.930000+02:00

Introduction

In Part 1 , we explored the transformative potential of the Electronic Bill of Lading in international trade, highlighting its impact on sustainability, enhanced supply chain transparency, and accelerated business processes.

Part 2 presents the building blocks used to implement the solution and includes an architecture diagram illustrating how the SAP BTP services and components are integrated.

1. System Context

The ocean carrier already operates an established core system that manages transactional data such as bookings, shipping instructions, and transport events on SAP Cloud ERP( S/4HANA Transportation Management).

SAP Cloud ERP

2. SAP Business Technology Platform

The foundation of this solution is SAP BTP, a cloud platform that brings together application development, data management, integration, and AI capabilities. It provides the core infrastructure and services needed to build enterprise applications.

To support the transition to digital trade, the Electronic Bill of Lading capability is implemented on SAP BTP as a side-by-side extension.

3. Electronic Bill of Lading: TradeTrust Framework

The open-source TradeTrust Framework serve as the foundation for implementing a fully digital and verifiable Electronic Bill of Lading solution. It can be deployed as a Node.js application on Cloud Foundry, which provides the runtime for developing and running cloud-native applications on SAP BTP.

On this PoC, the TradeTrust framework uses the Ethereum blockchain whereby the ERC-721 provides a widely-used smart contract API used on non-fungible tokens (NFTs) to allow transfer of ownership whilst providing assurance of integrity, singularity, and control.

Blockchain technology is a decentralized digital ledger system that records and verifies transactions across a network of computers in a secure and transparent manner. It consists of a chain of blocks, each containing a list of transactions thatare linked and secured using cryptographic techniques. Once a block is added to the chain, its data become immutable through a distributed ledger system, ensuring the integrity and permanence of the transaction records. This immutability and transparency enable blockchain to facilitate the exchange of anything of value, whether tangible assets including physical goods or intangible items such as digital assets.[11]

4. Terminal Operating System

Terminal Operating System (TOS) is the port terminal’s operational platform that manage and monitor container and vessel activities. Leveraging IoT-enabled equipment and sensors, the TOS generates real-time operational events such as container loading, vessel arrival, and departure. These events are distributed through a publish–subscribe model, pushing notifications to a configured endpoint. To ensure authenticity and integrity, the messages are encrypted and digitally signed.

5. Event-Driven Architecture

SAP Integration Suite running on SAP BTP provides the capabilities that enable Event-Driven Architecture within the solution. The Cloud Integration is the middleware layer responsible for routing, transforming, and exchanging messages between external systems and SAP services. Under the hood, it uses the open-source Apache Camel Framework, enabling integration flows based on enterprise integration patterns.

For event orchestration SAP Event Mesh is the message broker, it facilitates asynchronous communication by receiving events from the terminal/port and routing them to the subscribed consumer Events-To-Business Actions Framework, that leverages the decisions capability of SAP Build Process Automation to initiate business actions.

6. Automation

For the process automation, a workflow is managed on SAP Build Process Automation

7. UI

Stakeholders access the application through SAP Build Work Zone, where authentication is handled by SAP Cloud Identity Services integrated with a custom Identity Provider (IdP) that validates blockchain wallet signatures. Authorization is then enforced via role collections, ensuring access only to permitted functionalities.

8. Diagram

The Terminal Operating System generates an operational event(Load, Departure, Arrival). The event is published to the event broker SAP Event Mesh.
Event-to-Business-Actions framework is subscribed to SAP Event Mesh topics to receive the events.
Based on the rule outcome, the processor triggers a workflow on SAP Build Process Automation to orchestrate the business process.
The workflow calls SAP Integration Suite to start the process.
An Integration Flow retrieves the required Ocean Freight Booking from SAP S/4HANA and builds the payload to issue the eBL.
The Integration Flow invokes the TradeTrust Framework.
The Electronic Bill of Lading is issued on Ethereum Network.

9. Data Context

Conclusion:

Part 2 outlined the essential building blocks and architectural components for implementing the eBL solution on SAP Business Technology Platform.

In Part 3, I’ll walk through a complete end-to-end global trade scenario, illustrating how the architecture operates in practice, from container loading event to eBL issuance, ownership transfer, and final surrender.

Architecting Electronic Bill of Lading on SAP BTP - End-to-End Scenario(Part 3 of 3)

2026-04-02T19:09:58.380000+02:00

Introduction

In Part 1 – Case Study and Part 2 – Blueprint, we introduced the concept of the Electronic Bill of Lading and walked through the key steps required for its implementation.

The Part 3 presents a complete end-to-end global trade scenario, beginning with a container loading event emitted by the Terminal Operating System, continuing through the issuance of the electronic Bill of Lading, and ending with the surrender of the eBL when the importer claims the goods.

Teaser

The recently announced trade agreement between the European Union and Mercosur (January 2026) opens new opportunities for smaller producers to gain greater market access and visibility in cross-border commerce. Additionally, the European Union will contribute with €1.8 billion through the Global Gateway initiative to support Mercosur’s green and digital transition. As trade volumes grow, Electronic Bills of Lading help by enabling faster, more secure, and fully digital handling of one of the most important documents in international trade.

Scenario

A Brazilian Coffee Exporter contracts an Ocean Carrier to ship a container of coffee beans to an European Coffee Importer:

Stakeholders: Buyer, Seller and Carrier
Origen: Port of Santos, Brazil
Destination: Port of Antwerp, Belgium
Goods: Arabica Coffee Beans
Amount: 18 tons
Container: 1 TEU

Booking Request

The exporter requests transportation from the ocean carrier by submitting a booking request.

The booking page of the app call the FREIGHTBOOKING API to create the Ocean Booking on SAP Cloud ERP

Stakeholder Onboarding

Before the shipment process begins, key participants such as the exporter, importer, and carrier are onboarded to the platform. During this step, each party registers its digital identity and public key, enabling secure signing, verification, and ownership transfer of the Electronic Bill of Lading.

Electronic Bill of Lading Lifecycle

The eBL lifecycle is based on the events generated by the Terminal Operating System:

1. Event: Load

Port/Terminal Operating System: confirms the container has been loaded on a vessel

Event Payload:

{
  "event_id": "evt-load-0001",
  "event_created_date_time": "2026-03-16T10:15:30Z",

  "event": {
    "journey_type": "EQUIPMENT",
    "event_classifier": "ACT",
    "event_type": "LOAD",
    "transport_mode": "VESSEL",
    "empty_indicator": "FULL"
  },

  "facility": {
    "facility_type": "POTE",
    "location": {
      "location_code": "BRSSZ",
      "location_name": "Port of Santos"
    }
  },

  "transport": {
    "vessel_name": "Atlantic Pearl",
    "voyage_number": "VY-2024-095"
  },

  "equipment": {
    "container_number": "MSKU1234567",
    "iso_equipment_code": "22G1"
  },

  "shipment": {
    "commodity": "Green Coffee Beans",
    "gross_weight_kg": 18000
  },

  "destination": {
    "location_code": "BEANR",
    "location_name": "Port of Antwerp"
  }
}

On step 1, the event is published on a topic of SAP Event Mesh

On the step 2, the event is consumed by the Event-to-Business Actions framework that triggers the workflow on SAP Build Process Automation.

On the step 3, an integration flow is triggered on Integration Suite:

Integration Suite

On step 4, Integration flow fetches the Ocean Freight Booking on SAP Cloud ERP(Step 5) according to the 'Container ID' and 'Voyage ID' and then proceed with the creation of the Electronic Bill of Lading via TradeTrust Framework.

Business Partners:

Container:

Shipping Instructions

After SAP Integration Suite fetch the data from the backend, it generate a payload.

Electronic Bill of Lading Payload:

{
  "$schema": "https://schema.tradetrust.io/ebl/1.0/schema.json",
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://schema.trustvc.io/credentials/v1"
  ],
  "id": "urn:uuid:sap-ebl-trustvc-001",
  "type": [
    "VerifiableCredential",
    "ElectronicBillOfLading",
    "TradeTrustDocument"
  ],
  "issuers": [
    {
      "name": "Carrier",
      "documentStore": "0x0908aD5481673E19c3D03f1379E0032458118881",
      "identityProof": {
        "type": "DNS-TXT",
        "location": "carrier.example.com"
      }
    }
  ],
  "issuanceDate": "2026-03-16T11:00:00Z",
  "credentialSubject": {
    "id": "did:ethr:0x562eeBbaBB405db740f2e607F87f152989a10b7E",
    "origin": "Port of Santos, Brazil",
    "destination": "Port of Antwerp, Belgium",
    "goods": "Green Coffee Beans",
    "amount": "18 tons",
    "container": "1 TEU",
    "holder": "0x562eeBbaBB405db740f2e607F87f152989a10b7E",
    "consignee": "0x5C1d8d47784d8302B3839436e0e82E094D8e234f"
  }
}

On step 6, Integration Suite sends the payload to the TradeTrust framework to issue the eBL(step 7) :

Tradetrust framework Node.js deployed on Cloud Foundry.

const fs = require("fs");
const path = require("path");
const { Wallet, ethers } = require("ethers");
const { signDocument, SUPPORTED_SIGNING_ALGORITHM } = require("@tradetrust-tt/tradetrust");
require("dotenv").config();

const RPC_URL = "https://rpc.sepolia.linea.build"; // Linea Sepolia RPC
const PRIVATE_KEY = process.env.PRIVATE_KEY; // Carrier wallet 
const NFT_CONTRACT_ADDRESS = "0x6fD6DB343c5d84Baa7fDaeD5CedDA15652451a8f";

// Stakeholders
const EXPORTER = "0x562eeBbaBB405db740f2e607F87f152989a10b7E";
const IMPORTER = "0x5C1d8d47784d8302B3839436e0e82E094D8e234f";

The payload is wrapped with OpenAttestation metadata and cryptographically signed using the carrier’s key pair (public and private keys).

let rawWrapped = fs.readFileSync(WRAPPED_JSON, "utf-8");
    const wrappedDocument = JSON.parse(rawWrapped);
    console.log("✅ Wrapped document loaded");

    // Sign document with carrier key
    const keyPair = {
      public: "did:ethr:0x9843Cd2834010A4dca776d3035117750d20b3C01#controller",
      private: PRIVATE_KEY
    };

    const signedDocument = await signDocument(
      wrappedDocument,
      SUPPORTED_SIGNING_ALGORITHM.Secp256k1VerificationKey2018,
      keyPair
    );

    fs.writeFileSync(SIGNED_JSON, JSON.stringify(signedDocument, null, 2));
    console.log("Document signed successfully");

Prepare parameters

// Connect wallet & contract
    const provider = new ethers.JsonRpcProvider(RPC_URL);
    const wallet = new Wallet(PRIVATE_KEY, provider);

    console.log("🧾 Wallet (carrier):", wallet.address);
    const balance = await provider.getBalance(wallet.address);
    console.log(" ETH balance:", ethers.formatEther(balance));
    if (balance === 0n) throw new Error("Wallet has ZERO ETH — fund it for gas");

    const contract = new ethers.Contract(NFT_CONTRACT_ADDRESS, EBL_ABI, wallet);

    // Check wallet is carrier
    const carrierAddress = await contract.carrier();
    if (wallet.address.toLowerCase() !== carrierAddress.toLowerCase()) {
      throw new Error(`Wallet is not the carrier. Contract carrier is ${carrierAddress}`);
    }

    //Prepare issueEBL parameters
    const tokenId = BigInt(Date.now()); // PoC uniqueness
    const merkleRoot = signedDocument?.signature?.merkleRoot;
    const documentHash = toBytes32(merkleRoot);

    // Estimate gas + send
    const gasEstimate = await contract.issueEBL.estimateGas(
      tokenId,
      EXPORTER,
      IMPORTER,
      documentHash,
      tokenURI
    );

    const gasLimit = percentBuffer(gasEstimate, 25);

    const maxPriorityFeePerGas = ethers.parseUnits("1", "gwei"); // tip
    const maxFeePerGas = ethers.parseUnits("5", "gwei");         // must be >= priority
    
    const tx = await contract.issueEBL(
      tokenId,
      EXPORTER,
      IMPORTER,
      documentHash,
      tokenURI,
      {
        gasLimit,
        maxFeePerGas,
        maxPriorityFeePerGas
      }
    );
    

    console.log("📤 Transaction sent:", tx.hash);
    const receipt = await tx.wait();
    console.log("✅ Mint/Issue confirmed in block:", receipt.blockNumber);

NFT Minted on Blockchain

From this point onward, all TradeTrust-related steps will be demonstrated using the TradeTrust viewer. However, these operations can also be implemented programmatically using the TradeTrust Node.js library.

Electronic Bill of Lading created:

2. Event: Departure

Once the vessel leaves the port and start the journey, the Terminal Operating System emits the event Departure:

{
  "event_id": "evt-depa-0001",
  "event_created_date_time": "2026-03-16T18:40:00Z",
  "journey_event": {
    "journey_type": "TRANSPORT",
    "event_classifier": "ACT",
    "event_type": "DEPA",
    "transport_mode": "VESSEL",
    "facility_type": "POTE"
  },
  "shipment_location": {
    "type_code": "POL",
    "location_code": "BRSSZ"
  },
  "transport": {
    "vessel_name": "Atlantic Pearl",
    "voyage_number": "VY-2024-095"
  },
  "shipment": {
    "transport_document_reference": "BL-SANTOS-ANT-0001"
  }
}

The vessel starts to transmit telemetry(stored on a Hana DB) which is used for tracking and trace:

Once the goods are in transit, the buyer is notified via SAP BPA to provide the payment:

Once the payment is verified, the ownership of the Electronic Bill of Lading can be transferred to the Importer:

3. Event: Arrival

This event notifies the consignee via SAP Process Automation that the goods have arrived at the destination port and it is ready for pick up

Payload:

{
  "event_id": "evt-arri-0001",
  "event_created_date_time": "2026-03-26T07:20:00Z",
  "journey_event": {
    "journey_type": "TRANSPORT",
    "event_classifier": "ACT",
    "event_type": "ARRI",
    "transport_mode": "VESSEL",
    "facility_type": "POTE"
  },
  "shipment_location": {
    "type_code": "POD",
    "location_code": "BEANR"
  },
  "transport": {
    "vessel_name": "Atlantic Pearl",
    "voyage_number": "VY-2024-095"
  },
  "shipment": {
    "transport_document_reference": "BL-SANTOS-ANT-0001"
  }
}

Journey completed:

The Importer surrenders the electronic Bill of Lading to the carrier for cargo release at the destination port.

The surrender step marks the end of the workflow and completes the trade process.

Endorsement Chain completed:

Conclusion:

This Proof of Concept demonstrates how an electronic Bill of Lading can be issued, verified, and transferred using a blockchain technology integrated with SAP Business Technology Platform.

Given that modern container vessels can carry thousands of containers, the proposed architecture is designed to scale and process a high volume of operational events efficiently.

Looking ahead, AI agents could be integrated to further enhance the solution. These agents could monitor events, detect potential issues, automate operational tasks, and trigger workflows when required.

Combined with digital payment mechanisms such as on-chain settlement, this approach has the potential to significantly transform how international trade processes are executed.

Sources: SAP BTP Guidance Framework, SAP Application Extension Methodology , SAP Integration Solution Advisory Methodology , Integration Architecture Guide.

References:

[1] ICC Academy: Break the eBL silos: Why interoperability is the missing link in digital trade

[2] CargoX: Environmental impact of digitalisation in shipping documentation: Carbon footprint comparison of paper and electronic bills of lading

[3] Weareprocarrier

[4] Intracen: International Trade Centre

[5] IMDA: TradeTrust Legal Analysis Article

[6] Smart Ports Bynder

[7] GitHub - Event to Business Action

[8] Irishweekly: Europe Greenlights Massive Mercosur Trade Deal, Ending Long Stalemate

[9] 93degreescoffeeroasters

[10] ICC Academy: Ebl digital trade

[11] Intracen: Expediting Trade Through Electronic Bills of Lading

Good to know: "SQL Statement Collection" the Swiss army knife for SAP HANA database administrators

2026-04-04T11:21:44.192000+02:00

🎓The blog contains SAP Learning references. 📺

last updated: 2026-04-04

Why was this blog post created?

The SAP HANA database comes with a set of tools that support the work of database administrators, developers, and other support teams. The tools are available both internally (SAP Employees) and externally. Knowledge of this set of tools is essential for SAP HANA database operators.

Where can I find the most important information about SQL Statement Collection reports?

The following SAP Note is the central source of the toolkit 🔧 called "SQL Statement Collection".

📘 1969700 - SQL Statement Collection for SAP HANA

There are huge number of reports available for different purposes. There is a SAP Knowledge Base Article created to explain the reports one-by-one in details.

📕 3311408 - Bookmark of SQL Statement Collection reports for SAP HANA

The SAP Knowledge Base Article is under construction and will contain more reports in the future.

SAP Help Portal - SAP HANA Troubleshooting and Performance Analysis Guide - Using the SQL Statement Collection for Analysis and Health Checks

Where to find learning materials?

SAP Learning - SAP HANA - Installation and Administration - Using the SAP HANA Statement Library

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.04.04	First/initial Release of the SAP Blog Post documentation (Technical Article).

Meet Your HANA Cloud Lifecycle Agent: Enabled by Joule and SAP Automation Pilot

2026-04-07T09:07:22.826000+02:00

In a previous blog post, we explored how SAP HANA Cloud lifecycle management can be automated end-to-end using SAP Automation Pilot, outlining various automations capabilities and scenarios: from instance operations to backup and recovery. We also have demonstrated how SAP Automation Pilot can help Ops / DevOps / IT Admin team to bring Agentic Ops into action, see this blogpost: From Automation to Agentic Ops: MCP Servers in SAP Automation Pilot

Now, it is time to take the next step. What happens when all available HANA Cloud automations in SAP Automation Pilot are no longer triggered manually, but instead are consumed and orchestrated by AI agents?

Welcome to the world of HANA Cloud Ops Agents powered by Joule and SAP Automation Pilot and a true HANA Cloud Lifecycle Management agent - powered by SAP Automation Pilot content and consumed directly in Joule in a truly agentic manner.

🎥 Meet Your HANA Cloud Lifecycle Management Agent

See an example about HANA Cloud Lifecycle Agent enabled by SAP Automation Pilot and find out how easy it is to set up an MCP server, expose automations, and trigger them in an agentic way through Joule.

From Automation to Agentic HANA Cloud Operations

With SAP Automation Pilot, DevOps and Ops teams can already automate complex operational workflows using prebuilt and custom commands. At the same time, Joule is evolving into an intelligent orchestrator of AI agents that can observe, reason, and act across SAP landscapes. Bringing these two together unlocks a new operational model where Joule Agents orchestrate and trigger automations based on intent and context (see diagram below):

SAP HANA Cloud operations typically involve a wide range of recurring, critical activities. With Automation Pilot and Joule Agents, these can now be exposed as reusable, governed capabilities.

Let’s look at some concrete examples as 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);

…and Many More

These scenarios are just a starting point.

Any operational workflow automated in SAP Automation Pilot can be exposed via MCP Servers and consumed by Joule Agents - enabling a flexible, extensible, and truly agent-driven operations model across SAP HANA Cloud and beyond.

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.

🔖 Try SAP HANA Cloud LM MCP Server in SAP Automation Pilot Yourself

Interested in exploring the SAP HANA Cloud Lifecycle Management MCP Server in SAP Automation Pilot? You can import it directly and experience how easy it is to set up and use by building your own AI agent in Joule Studio.

Just follow the steps below to get started:

Import in your SAP Automation Pilot tenant the SAP HANA Cloud Lifecycle Management catalog published in our Github repo. Direct link to the catalog itself is here. Tip: more details on how to import catalogs are described in Getting Started section.
In your SAP Automation Pilot tenant there is a catalog named: "Welcome". Create an Input with Input key "ServiceManager" as described within the Requirements section.
Import the MCP server in SAP Automation Pilot - we have also published for free exploration in Github following this link. Tip: more details on how to import MCP Servers are provided in the help documentation here: Managing MCP Servers;
Setup your project in Joule Studio and build your AI Agent using the MCP Server endpoint provided by SAP Automation Pilot to bring the needed automation to your agent.

📚 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.

Partner Learning Accelerator: Data engineer - SAP HANA

2026-04-07T16:00:00.031000+02:00

Getting certified as a data engineer on SAP HANA Cloud can feel like a big step. The content is deep, the exam is detailed, and time is always tight.

That’s exactly why we created this Partner Learning Accelerator.

In this 3-hour live session, you’ll walk through key topics like data modeling, provisioning, and exam structure. You’ll see real examples, ask questions in real time, and get practical tips that go beyond slides. Plus, we’ll close with a focused exam wrap-up so you know what to expect.

If you’re working with SAP HANA Cloud or planning to, this is a strong way to build confidence before the C_HAMOD certification.

The thing is, preparation becomes much easier when you know where to focus.

Join us and move one step closer to certification.

#SAP #SAPBTP #SAPPartners #SAPEcosystem #SAPHANA #DataEngineering #SAPLearning #CloudSkills

Building a CAP App with Fiori Integration – Part 1: Environment & HANA Cloud Setup

2026-04-08T08:32:43.137000+02:00

In this blog series we are going to see how to create a Basic CAPM Application from scratch through BTP Trial Account and Integrate it with Fiori.

--> The First Part of this series will explain all the Pre-Requisites to be done before creating CAP Application.

--> Second Part of this series will explain how to create CAP Application and Integrate it with Fiori.

Cloud Based Applications may look complex from outside but when blocks are perfectly aligned even a beginner can build a powerful CAP application using BAS. Let’s dive in and start arranging those blocks from the ground up.

Tools Required: BAS, HANA Cloud Central

At end of this series we can able to successfully run a CAP Application in Fiori Generated App and able to create entries in HANA Cloud Central based DB from the Fiori App.

1. Create a BTP Trial Account/Use existing Global Account for the Development Process. Access to your SubAccount as below from Account Explorer -> SubAccounts.

2. Now get into Sub Account and Navigate to Instances and Subscriptions as below and then click Create Button.

3. Under Services tab -> Select SAP HANA Cloud & in Plan select Tools/hana-cloud which makes service compatible for shareable instance.

Note: If SAP HANA Cloud is not showing under services tab then add it from Entitlements->Add service Plans.

4. After Creation, the SAP HANA Cloud Central tool will be added to subscription as below along with Business Application Studio. Note: Incase if BAS is not added then add that as well from Create Button.

5. Once the HANA Cloud and BAS set up is done, then navigate to Security->Users and assign these Roles.

Roles Required :

Note: These roles should be assigned to the user and with that HANA Cloud can be accessed.

Before moving into next point lets have a quick overview on what is SAP HANA Cloud Central and BAS.

SAP HANA Cloud Central - It manages SAP HANA Cloud instances within the SAP Business Technology Platform (BTP). It acts as a centralized dashboard to create, monitor, and maintain both SAP HANA database instances and Data Lake instances.

SAP BAS - SAP Business Application Studio is a cloud-based Integrated Development Environment (IDE) designed specifically to build and extend SAP applications.

Basically SAP HANA Cloud Central helps to manage data through cloud instances and BAS helps in building data. We can decide how the data should look/maintained from BAS.

Now let's continue with the Pre-Requisites;

6. As a next step, navigate to Cloud Foundry->Spaces and ensure if space dev is available. If that is not there then create dev space using Create space Button. This Space is really important as it acts as a deployment target from CAP where code is deployed and executed.

7. Navigate to HANA Cloud and click on Create Instance. Again, Creation of HANA Cloud Instance is as important as creation of dev space in cloud foundruy. It acts as the database-as-a-service (DBaaS) where application’s data is permanently stored. HANA Cloud instance also contains HDI Containers which act as a bridge between design-time code from BAS into run-time database objects like tables and views.

8. On Type section select Instance configuration as Configure Manually ( Select other options if you want to configure instance in different way ) and Instance type as SAP HANA Database as we are creating Instance for HANA DB. If Data Lake is expected then select Data lake instead of HANA DB.

9. In section SAP HANA Database General, Cloud foundry tab to be navigated for filling instance related details as the deployment happens for Cloud Foundry. But it is disabled by default. Henceforth user should select Sign in to cloud Foundry Environment and after sign in the Cloud Foundry tab will be enabled. In that tab fill the details as below.

10. Post filling the important section as above, navigate to other sections where Connection Details and Advanced settings needs to be mentioned. For a Minimalistic App execution these tabs are not required and henceforth I've skipped it. It needs to be filled based on Business expectations.

11. Enable Data lake if required and click on create instance as below.

12. Once above process is done, Test Instance will be created for SAP HANA Cloud central as below and it acts as DB for the Developments made from CAP Project.

13. Now SAP HANA Cloud is all set, Let's Navigate to BAS and create Dev Space. Get back to your subaccount. Navigate Instances and Subscriptions -> Business Application Studio. Click on create Dev space.

14. Define Dev space name and select Full Stack cloud Application option as below.

15. With that Dev space will be created in BAS.

From here, let's continue on Part - 2 where full stack CAP Application will be built and Deployed/Integrated with SAP HANA Cloud.

What we did till now.

-> Created Trial Account

-> Enabled necessary subscriptions and Roles

-> Set up SAP HANA Cloud Central

-> Created Instance and ensured Dev space is available

-> Set up BAS Dev space.

PART: 2 Link - Build BTP CAP App with Fiori Integration – Part 2: Implementing End to End App

What's New in SAP BTP - Q1 2026 Innobytes

2026-04-08T08:38:08.906000+02:00

This first quarter has set the tone for 2026, bringing in new ideas and innovations all around Data, Joule and more. Let’s dive into some of the highlights Q1 has brought us.

AI & Data Foundation Highlight

Discovery and Data Agent in SAP HANA Cloud

The new Discovery and Data Agents are lowering learning barriers for developers and data users who just need answers. These new agents make it easier to explore, analyze, and act on data without needing deep knowledge of the underlying artifacts.

To see this demo in action, watch the video (starting at 0:11).

Learn more

Integration Highlight

Fresh Connections in SAP Integration Suite

New adapters for SAP Integration Suite on SAP BTP help transform your integration landscape, breaking down data silos, streamlining operations, and allow rapid adoption of new capabilities to innovate faster.

The latest release offers:

The BambooHR adapter enables receiving and processing employee lifecycle data effectively.
The Microsoft Outlook Sender and Receiver adapter allows seamless integration for calendars, mail, attachments, and messaging directly into your mission-critical workflows.

For Edge Integration Cella:

The File adapter, enabling secure file exchange with NFS systems
The OFTP2 adapter for compliant B2B connections to securely exchange messages from business partners.

See the new integration content (starting at 2:14).

Learn more:

Agent & Application Development Highlights

API based Action Error Handling

In real-world automation, failures are inevitable. What matters is how the system handles them. This innovation brings precision and predictability to API error handling in SAP Build Process Automation on SAP BTP. When configuring an API-based Action step, enable error handling and define specific errors, handling authentication failures precisely. You can create generic categories, such as 4XX or 5XX, handling broader client or server issues.

The inability to define category overlap eliminates ambiguity, and deterministic runtime behavior is guaranteed. When an error occurs, precedence is strictly enforced:

Specific errors first
Generic category second
Undefined fallback last

At the Action level, you can configure retries that define the number of attempts and the delay between them. Afterwards, the error handling logic is executed. Every stage is fully logged in Monitoring, ensuring complete traceability and turning error handling from a black box into a controlled, observable workflow decision.

Watch the demo (starting at 3:35).

Conversational Work in SAP Build Work Zone

There is now a powerful new way to work in SAP Build Work Zone. Save time by simply asking Joule what you need instead of clicking through multiple pages.

In the demo (starting at 5:33), a new project workspace for a cross-functional initiative is set up through a short conversation with Joule, enabling easy navigation, no technical steps, and only one screen. SAP Build Work Zone becomes more conversational, more intuitive, and more aligned with how people actually work.

Learn more:

Joule in SAP Build Work Zone

Core Platform Highlight

SAP Automation Pilot and Joule: Unlocking AI-Powered Ops Agents

The SAP Automation Pilot and Joule turn repeatable operational tasks into intelligent, agent-driven capabilities on SAP BTP.

By starting with a real operational process like a S/4HANA health check, use Automation Pilot’s low-code/no-code interface. Here, the necessary steps, inputs and validations can be collected and grouped into a Model Context Protocol (MCP) Server. The MCP Server exposes these automations as governed, reusable tools that can be safely consumed by AI agents without writing custom APIs.

Once published, connect it to Joule Studio to build a Joule Ops Agent that understands when and how to invoke these tools. The Ops Agent can now detect issues or fetch system status, triggering the right automation behind the scenes.

The DevOps or Admin team can simply ask the Ops Agent in Joule to ‘check my HANA Cloud and App instances health and remediate common issues’ by using the MCP Server to execute these steps securely, consistently, and audibly.

For a demo, watch the video (starting at 7:35).

Learn more:

Share your thoughts

These videos are for YOU, and we would love to hear your impressions. How do you like the video? How can we improve upcoming videos? Please share your feedback by liking this post or leaving a comment below.

Thank you for your support and happy viewing, sharing, and enjoying!

SAP HANA Cloud release March 2026 Round-up

2026-04-08T12:46:34.453000+02: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 Q1 2026 release.

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

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

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

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

All the best,

Andrea on behalf of the SAP HANA Cloud team

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

#whatsnewinsaphanacloud

SAP HANA Cloud: Expert-Guided Implementation Workshop Series

2026-04-08T16:32:37.714000+02:00

SAP HANA Cloud is a fully managed, in-memory cloud database service as part of the SAP Business Technology Platform (BTP). It delivers high-speed processing and real-time analytics, which is especially valuable for data-intensive applications. The platform supports multiple data models, including relational, graph, spatial, JSON, and document store, allowing developers to work with different types of data in one environment. It also includes built-in data virtualization and integration capabilities, enabling organizations to access and combine data from SAP and non-SAP sources.

SAP HANA Cloud provides a comprehensive environment for building intelligent, data-driven solutions. It supports advanced analytics, machine learning, and predictive capabilities directly within the database, which reduces data movement and accelerates insight generation. Developers can use familiar tools and languages such as SQL, Java, Node.js, and Python to create applications and services.
The platform also includes data lake functionality for storing and processing large volumes of less-frequently accessed data at a lower cost, while still allowing seamless querying alongside in-memory data. Its multi-tier storage approach helps organizations balance performance and cost by automatically managing where data resides. Overall, SAP HANA Cloud enables organizations to modernize their data landscape, support real-time decision-making, and drive digital transformation initiatives.

🚀 Empower Your Data Journey: Introducing Our New SAP HANA Cloud Expert Guided Implementation Series

In today’s fast-paced digital landscape, speed of transformation is a must. Businesses across the globe are evolving to make faster, smarter, and more connected decisions by building intelligent, data-driven solutions using advanced analytics, machine learning, and predictive capabilities. To support this evolution, we’re excited to announce our renewed series of Expert-Guided Implementation workshops (EGI) from SAP Enterprise Support designed to help you upskill, modernize, and future-proof your business processes. Whether you're looking to modernize legacy systems, harness the power of cloud data, or unlock real-time insights through analytics, this workshop series offers targeted enablement for every stage of your development.

*The following EGI sessions will run throughout the year, with quarterly updates to the schedule.
Each session is limited to 30 individual customer participants. 
**Registration links below direct to SAP Learning content for SAP Enterprise Support, which requires a one-time registration with a valid S-user.

Configuration, Administration, Security and Monitoring topics for SAP HANA Cloud

In this live EGI session we will guide you through the SAP HANA Cloud capabilities as DBaaS, demonstrate the key features available in the latest quarterly release of the tool and show the benefits of using the administration tools for DB Monitoring, security and configuration. For details, please read the abstract here.

Agenda:

Introduction to SAP HANA Cloud
Overview of SAP BTP
Introduction and usage of Administration tools

SAP HANA Cloud Central
SAP HANA Cockpit
SAP HANA Database Explorer

Managing, Monitoring and Alert Notification in SAP HANA Cloud
Workload Management:

Managing Tables
HANA NSE

SAP HANA HDI Overview
Introduction and usage of Cloud Foundry CLI
Security Administration and User management

Register Here*

SAP HANA Cloud Modeling

In this live EGI session, we will guide you through the process of modeling in SAP HANA Cloud. After the completion of the session, you will have the knowledge of calculation view usage and design in SAP HANA Cloud utilizing the SAP Business Application studio. Also, we showcase the core capabilities of SAP HANA Cloud for calculation view graphical modelling and provide help on about SQL Script procedures and implementing functions using the SAP Cloud Application Programming Model (CAP). For details, please read the abstract here.

Agenda:

Introduction to SAP BTP and SAP HANA Cloud
Usage of SAP Business Application Studio and Administration tools
Deploy SAP Business Application Studio
Introduction and modeling Calculation views
Modeling with SAP Business Application Studio and using Database Explorer
Modeling features
Generating restricted and calculated columns
SQL Script usage
Performance Analysis, Debug mode & SQL Analyser
Overview of Best Practices

Register Here*

SAP HANA Cloud Multiple Model Programming including Vector Engine and Knowledge Graph

In this live EGI session, we empower customers with the knowledge of SAP HANA Cloud multiple model programming using the latest concepts including vector engine, knowledge graph engine and retrieval augmented generation. After the completion of the workshop, customers will have the knowledge of multiple model engines and how to incorporate artificial intelligence and retrieval augmented generation capabilities.

Agenda:

Introduction to SAP BTP and SAP HANA Cloud
Understand SAP HANA Cloud architecture and deployment options
Introduction to multiple model programming
Data Tiering considerations for multiple model programming
Overview of SAP Business Application Studio
Spatial data concepts in SAP HANA Cloud
Understanding spatial features and functions
Spatial data modeling and processing
Graph processing in SAP HANA Cloud
JSON document store in SAP HANA Cloud
Automated machine learning (AutoML) in SAP HANA Cloud
SAP HANA Cloud vector database
Capabilities and benefits of multiple model processing with vectors
SAP HANA Cloud knowledge graph engine
Knowledge graph and Retrieval Augmented Generation (RAG)
Real-world applications for Retrieval Augmented Generation

Register Here*

Pro-code cloud application programming development through SAP Build and AI (Joule)

In this live EGI session we will empower you with the knowledge of cloud application programming development in SAP HANA Cloud. After the completion of the session, you will have the knowledge of CAP CDS development and design in SAP HANA Cloud and understand how to build and deploying cloud application projects from scratch and with reduced costs utilizing pro-code development using SAP Build Code with Joule. For details, please read the abstract here.

Agenda:

Introduction to SAP BTP and SAP HANA Cloud
Introduction to SAP Build Code and Prompt Engineering
CAP Architecture and SAP Business Application Studio features
Build and deploy a CAP project using SAP Business Application Studio
Modeling in SAP HANA Cloud using CAP CDS
Modeling in SAP HANA Cloud Optimization
Building Application using SAP Build Code and Joule
Modeling in SAP HANA Cloud Management and Administration

Register Here*

Learning Outcomes from the EGI Series:

Configuration, Administration, Security and Monitoring topics for SAP HANA Cloud:
Master SAP HANA Cloud configuration, performance monitoring and secure user management using standard administration tools.
SAP HANA Cloud Modeling:
Develop Calculation views and SQL Script procedures within SAP Business Application Studio.
SAP HANA Cloud Multiple Model Programming including Vector Engine and Knowledge Graph:
Implement advanced Vector Engine, Knowledge Graph, and Spatial Data capabilities to power Generative AI and Retrieval Augmented Generation scenarios
Pro-code cloud application programming development through SAP Build and AI (Joule):
Build and deploy end-to-end CAP applications efficiently using SAP Build Code and Joule

Who Should Attend?

This workshop series is ideal for developers, modelers, business analysts, system administrators, database administrators and SAP customers looking to transform their business processes. Whether you're just getting started or want to go deeper into SAP's modern toolset, there’s a session tailored for your needs.

GET MORE CONTENT LIKE THIS!

SAP Enterprise Support Value Maps — your go-to team for Foundational Success Plan support and empowerment — have a dedicated SAP Community Group.

As part of your SAP cloud subscription, you get access to:

Expert-led resources
Tailored recommendations
Advisory services
…all designed to help you accelerate innovation and success.

👉 Visit our Community Group
Sign in with your S-user ID or Universal ID, then hit “Subscribe” to stay updated.

Looking to dive deeper into data-driven innovation?
Within the group, explore the Data & Analytics Value Map to connect with your Foundational Support team. Simply click “Join Group”, and once inside, you can even request a call with a topic expert to get personalized guidance and enablement support.

Quicklinks

Build BTP CAP App with Fiori Integration – Part 2: Implementing End to End App

2026-04-09T10:05:19.668000+02:00

A quick Recall - So far we have completed the Pre-Requisites and set up the BTP Environment for creating/Deploying CAP Application. BTP Trail Account has been created and within Trail sub-account necessary cloud related roles have been assigned. Post that SAP HANA Cloud instance has been created and BAS Set up has been done.

PART 1 Link - Building a CAP App with Fiori Integration – Part 1: Environment & HANA Cloud Setup

As a part of second episode in this CAP Application blog series, we are about to develop an end to end CAP Application with layers of validation of security in a detailed way. This blog helps beginner to build end to end CAP Application.

Flowchart giving overview for complete Process

Ever struggled to deploy a CAP app with HANA + XSUAA + App router?.

I did. After multiple failures, here is a complete working guide 👇

BACKEND BUILD :

1. Navigate to BAS->Dev Space and Create new project from Template.

After creating CAP Project Run these Below terminal Commands which has unique operation.

a. This below terminal command to be added which will prepare the CAP project for a real-world cloud environment i.e. SAP BTP. add hana will switch database from SQLITE to HANA Cloud & add xsuaa will enable authorization for the project. Also When we ran the command cds add xsuaa --for production then CAP automatically generates the security folder xs-security.json.

cds add hana,xsuaa --for production

b. Below terminal command will add blueprint for deployment.

cds add mta

c. Below terminal command will install libraries.

npm install

2. Select CAP Project Option and name the project and select options as below.

3. Click on Finish after selecting all the options.

4. Once Project is created it will be available in the Workspace.

5. We can view the path of the project created using below Terminal command. ( Note : Use Ctrl + ~ to open terminal ).

user: CRUDApp $ pwd

Once this Terminal command is entered the response will come as /home/user/projects/CRUDApp.

6. Now the Project is created. The Aim is to create service instance in Cloud Foundry space dev which I shown in PART 1 and through the service instance the linkage to HANA Cloud central DB Instance will be triggered with runtime HDI Container created. Through this HDI Container the Deployment data will be mapped to runtime DB.

Before getting into next point. Let me give a quick overview on different folder paths/ files in CAP Project that has been created. ( Refer to the workspace image from Point 4. )

a) db/ - This is database schema where we will create CDS Entities/tables and it's relationships. It’s is the source of data structure.

b) app/ - In this folder the front end Fiori Generator App will be mapped which has further navigations to Controllers and views. From here only we will write front end logic.

c) srv/ - This is service folder where api services will be created from backend and if required custom logic can be enabled using node js in js file.

d) .vscode - This is a hidden folder containing configurations specific to Visual Studio Code or BAS. It stores things like your launch configuration and recommended extensions for the project.

e) mta.yaml - Multi-Target Application file is the provides instruction to cloud. It tells SAP BTP how to package and deploy your app, which database to create, which security services to bind, and how much memory to use.

f) package.json - This is the Project Meta data which holds libraries to run project.

Now let's continue with further steps from Backend.

7. Create a file schema.cds as below to /db folder and create Entity bookshop. This Entity is designed to store Book details. The same will be created as table in SAP HANA Cloud.

namespace my.bookshop;

entity Books {
  key ID    : Integer;
  title     : String;
  stock     : Integer;
  author    : String;
}

8. Create a file schema.cds as below to /srv folder. In this Service folder we are adding annotation @requires: 'Admin' which indicates Role required for Authorization.

using { my.bookshop as my } from '../db/schema';

service CatalogService {
    @requires: 'Admin'  // XSUAA Role Required
    entity Books as projection on my.Books;
}

FRONT END BUILD:

1. Click Ctrl + Shift + P and select Open Fiori App Generator as shown below.

2. Since this is a basic app and henceforth Select List Report Template as below.

3. Now select Data source as Local CAP Project and select CAP Project and OData service. After this select on Next button.

4. Give Name to App and Module.

5. Then Deployment configuration should be auto-picked as cloud foundry and If required fill Destination. For this app Im not creating Destination and henceforth selection the option as None. After this select Finish option which will create Fiori App in Project Folder.

VALIDATION :

1. Create a file cat-service.js as below to /srv folder.

const cds = require('@sap/cds')

module.exports = cds.service.impl(async function() {
    const { Books } = this.entities;

    // Logic: Validation BEFORE creating a record
    this.before('CREATE', 'Books', req => {
        const { title } = req.data;
        if (!title || title.length < 3) {
            // This is like an 'E' message in ABAP
            req.error(400, 'Title is too short! Minimum 3 characters required.');
        }
    })
})

2. As per above logic, we are adding some validation before SAVE using Node JS Function. As per this validation if Title length is less than 3 then error will be thrown. Similarly we can use other functions as well to perform business operation which triggers during save, After save etc.

SECURITY:

1. When the Environment was set up in BACKEND BUILD->1.a), we ran the command cds add xsuaa --for production which in turn created the folder xs-security.json.

2. Now the aim is to deploy the app to production and create HTML5 App in BTP. So here we are adding a security layer which tells only Authorized user can access the data. While defining the service in BACKEND BUILD->8. where Admin role is annotated to books entity.

3. Lets create Approuter now and configure JSON to add necessary roles.

4. There are two options for adding Approuters.

a. Right click on mta.yaml file and select Create MTA Module From Template and then select Managed Approuter.

b. If Managed Approuter option is not showing, then below terminal command is a reliable 'Reset' button. It cleans up the MTA configuration and sets up a standalone router that works independently of external BTP subscriptions.

cds add approuter

5. Currently Im going with 4.b) with manual terminal command for adding Approuter. Once that is done then approuter will be added as below in app/ folder.

6. Add below JSON to folder xs-security.json in project which will define the role which is binded in service and yaml.

{
  "xsappname": "my-bookshop",
  "scopes": [
    {
      "name": "$XSAPPNAME.Admin",
      "description": "Admin"
    }
  ],
  "role-templates": [
    {
      "name": "AdminRole",
      "scope-references": [ "$XSAPPNAME.Admin" ]
    }
  ],
  "attributes": [],
  "authorities-inheritance": false
}

DEPLOYMENT:

1. So till now we have built this CAP Application in "Vertical Stack" (Database → Logic → Security → Routing → UI).

2. Now before final deployment lets test the things done till now is correct. Use below terminal command. If everything is fine then You see your database schema, custom logic, approuter config, and Fiori manifest listed.

ls -R | grep -E "schema.cds|cat-service.js|xs-app.json|manifest.json"

3. Now compile all the files to check if any error occurs. Use below terminal commands.

cds compile db/
cds compile srv/
cds compile srv/ --to xsuaa

Note: All these commands should not throw error to proceed with next steps.

4. After Sanity checks, run below command to login to terminal. Note: It will ask for Api Endpoint for first time during login. It can be found from BTP Cockpit -> Overview -> Cloud Foundry Environment -> API End Point.

cf login

5. Now run Deployment command in terminal. This is done to test the app locally. Once testing is completed the app needs to be deployed to Production.

cds deploy --to hana --profile hybrid

6. If cds deploy is not working properly then define step by step process of creating service instance, HDI Containers etc. through terminal commands below. Note: cds deploy will create everything by default so dont use these in combination. use these terminal commands only if cds deploy is not working.

cf create-service hana hdi-shared my-cap-app
cds bind --to my-cap-app
cds env get requires.db --profile hybrid
cds deploy --to hana --profile hybrid

7. Run below commands to deploy the app to production.

mbt build

8. When finished, a new folder named mta_archives/ will appear as below containing Project file.

9. Now do a login again with below command. Give appropriate API Key and user details.

cf login

10. Run below command to Complete final HTML5 App deployment.

cf deploy mta_archives/CRUDApp_1.0.0.mtar

Note: Sometimes Deployment will fail. To avoid these common pitfalls, "Only include essential resources (HANA, XSUAA, Destination, and HTML5) in your mta.yaml and ensure your xsappname in xs-security.json is consistent throughout the project to prevent service plan unavailability and identity mismatch errors on Trial accounts." If something fails, make these changes and delete the service and redeploy. After redeployment dont forgot to add role collections again to make sure Approuters will not cause auth errors.

TESTING

1. Run below Terminal command to test the app locally.

cds watch --profile hybrid

2. After this the app will open in next screen to test it from web level. Note: Make sure your HANA DB Instance is running in HANA Cloud Central which will create entry in DB Level.

3. Now while testing this app we can see the user login screen which will ask for mail and password for login. This is happening due to XSUAA and Approuter. While trying to make entry to the app it will show error forbidden as below.

4. Now run this command below to create service Instance first. Even after cds deploy this is required because cds deploy only talks to the Database (HANA). It does not talk to the Security Service (XSUAA). In SAP BTP, the database (CRUDApp-db) and the security (XSUAA) are two completely separate buildings. This terminal logic is required to enable link.

cf create-service xsuaa application CRUDApp-auth -c xs-security.json

5. Post this navigate to BTP Cockpit -> SubAccount -> Security -> Role Collections and click on Create Button as below.

6. Create Role collection Bookshop_Admin_Group with its Description as below.

7. Now Navigate to the Role collection Bookshop_Admin_Group and click on Edit. Open value help of Role and select the App name from Application Identifier dropdown. After selecting Role Admin which enables Authorization, click save. Follow below images sequentially.

8. After saving, the role will be available in Role collection as below.

9. Now refresh the app and try running, It will work !. Note: Sometimes Auth error will still occur if you test locally. In that case assign your URL to user Alice or deploy and test the app.

10. Also once deployed to HTML5 Apps or Dev space, the app can be directly tested from there as well.

FINAL APP EXECUTION🔥:

1. Now, lets open the app as below.

2. Lets create some incorrect entries as below.

3. Validation Error occurs as per Node js logic for incorrect inputs.

4. While creating valid records, Data gets created as below without any auth error/Forbidden as the custom role collection created and mapped to Admin Role. Note: Unique UUID will be generated for each record as per CAP Entity definition made. The UUID can be viewed in Cloud DB.

5. Now navigate to SAP HANA Cloud and click on ... dots. select option "OPEN IN SAP HANA Database Explorer".

4. Once SAP HANA Database Explorer opens then login to cloud foundry Environment from there.

5. Now select the "+" icon and select HDI Containers options and then select app container specific to app name.

7. From CRUDAPP-db HDI Container, Navigate to Tables and select open data.

8. The Data created from Fiori App is available in Cloud Table as below along with UUID auto-generated.

CONCLUSION:

Hence the overall flow looks as below.

Fiori UI
↓
App router
↓
CAP Service
↓
HANA DB (HDI Container)

With this blog series we learned how to set up environment, enable cloud instance, create end to end CAP Full stack application which has capability to communicate with SAP HANA Cloud instance and create entries over there, enable App routers to CAP App and Enable validation while creating entries.

I hope this blog will be helpful for enthusiasts who are learning CAP !. In future I will create add-on series with steps to deploy this app to SAP Build work zone.

I tricked Datasphere into running my custom scaler functions

2026-04-09T10:20:07.454000+02:00

Introduction - Welcome, once again.

Hello, and welcome to an easter edition of my hit-series of blogposts, where I try to help my fellow developers get to grips with SAP Datasphere .

Easter is over, but today I've put on my Reverse-Easter-Bunny costume, and have dug up a few golden easter eggs for you.
Even if you think the word "Scalar Functions" sounds like scary techno-babble, I still think there is something of values in here, that you might find useful.

And do not worry, if you are hoping for my usual sprinkling of sarcasm or was hoping I would make fun of SAP and their interesting design decisions, you will not be disappointed. My God, are we going to cry. I mean laugh. Laugh. Yes.

Today we will be going through the following:

What is a Database User Group, and why you should learn to love it.
How to re-enable SYS.DUMMY functionality (because shouldn't we?)
How to build and implement custom scalar functions across your Datasphere solution
Jail-break the Graphical View editor, so we can gas-light it into doing its f#!&ing job.

Happy reading 🙂

1: Why you should always create a "Database User Group"

So, if you have ever been in an hour-long townhall meeting, you might have mindlessly scrolled through the Datasphere documentation (Only me? Alright then), in hope of stumbling over something good.

On one such occasion, I came across how to create a database user group, and thought myself:

"What the hell is that? Why should I care?"

In the documentation, we get the following:

"Users with an administrator role can create database user groups in SAP Datasphere to allow users to work in a sandboxed area in the underlying SAP HANA Cloud database, unattached to any space. These users can transfer an existing data warehouse implementation into the SAP Datasphere database or do any other work in SAP HANA Cloud and then make it available to one or more spaces as appropriate"

Which is a pretty boring few sentences, but here is the key value: You can create database objects, that can be accessed across your solution.
This allows you to use the full suite (almost, let's not get ahead of ourselves) of HANA SQL functionality, which can offer a lot more programmability than Datasphere in general.

1.1: Setup your Database User Group

You can follow the documentation to create the "Admin" user for your group.
Open the "Database Explorer", provide the password, and open the SQL console.

Note: I've used CHR_GRA as the namespace in my examples, you can use whatever fits you.

In your SQL console, you will now have to:

Create a non-admin user
Create a schema

-- Step 1: Create User, Schema and role.
CREATE USER DWCDBGROUP#<YOUR_NAMESPACE>#<USER> PASSWORD Password123 SET USERGROUP DWCDBGROUP#<YOUR_NAMESPACE>;
CALL "DWC_GLOBAL"."CREATE_USERGROUP_SCHEMA"
(
	SCHEMA_NAME => 'DWCDBGROUP#<YOUR_NAMESPACE>#<SCHEMA_NAME>',
	OWNER_NAME => 'DWCDBGROUP#<YOUR_NAMESPACE>#<USER>'
					);

Technical side-note: By default, HANA creates a unique schema for each user. So it's good practise to create a separate schema, that is independent of any user.

1.2: Switch user

In the left side of the Database Explorer, right-click on your database and select "Add Database with Different User":

Use the user ID and password you created above.

Open a new SQL console, and validate that you are now connected to your user:

1.3: Cool... Now what?

Now you can do whatever you want.
You can create custom tables, views, functions and procedures in the schema you set up and expose it to the spaces in your solutions.

2: Re-enabling SYS.DUMMY

So, if you've ever read any of the documentation for HANA SQL, you'll see endless references to a table called DUMMY.

An example could be getting today's date

SELECT current_date
FROM sys.dummy;

Which may seem odd, but the (somewhat simple) explanation is that HANA will not execute a query without a source.
So, the table SYS.DUMMY only ever contains one row, so you can use it as a workaround, for cases where you don't want to query data, but needs to execute something else.

In SAP Datasphere , the above query will fail, if you try it in an SQL view:

But hell, sometimes you just want a query without a source. So, how can we re-establish it?

In our database your schema, we can create a dummy view, and expose it in our space:

SET SCHEMA DWCDBGROUP#<YOUR_NAMESPACE>#<SCHEMA_NAME>; 

CREATE OR REPLACE VIEW "DWCDBGROUP#<YOUR_NAMESPACE>#<SCHEMA_NAME>"."DUMMY" AS SELECT "DUMMY" from "SYS"."DUMMY";

Which creates a wrapper view.
Why is that required? Because your spaces will always try to execute an SQL query inside it's own schema, and will not be able to find the SYS schema.

When the view is created, you'll have to grant access to your space by running the following SQL:

CALL "DWC_GLOBAL"."GRANT_PRIVILEGE_TO_SPACE" (
	OPERATION => 'GRANT', 
	PRIVILEGE => 'SELECT', 
	SCHEMA_NAME => 'DWCDBGROUP#<YOUR_NAMESPACE>#<SCHEMA_NAME>', 
	OBJECT_NAME => '', 
SPACE_ID => '<YOUR_SPACE>');

In your Datasphere space, you can now deploy the view, and you're back in action!

"But Christian, can't I just create a local table in my space and do the exact same thing?"

Well yes. But I think this served as a nice example of how you can use your DB user group to access system information, that is not otherwise available to you.

3: Implementing custom scalar functions

Alrighty, so on to the real magic.

If you are not familiar with SQL development, a bit of background might be useful.

In SQL in general, and HANA SQL as well, you can build User-Defined Functions, that allow you to implement more complex SQL logic, such as control structures (loops) and logical operators, and execute dynamic SQL. HANA offers two kinds of User-Defined Functions that you can build.

Table function: Which returns a full view, that you can call from a SELECT statement.
Scalar function: Which are functions you can call within a view, and returns a single value for each row.
When you create a "Calculated column" in your views, you are using a scalar function. Functions such as IFNULL, COALESCE, LOWER and so on are all scalar functions, that you can use in your views.

The value of scaler functions is that they allow you to create re-usable custom logic, that can be utilized across your entire solution.
In this post, I'll create two functions as a few examples, which should give you an idea of how to utilize scalar functions in your solution.

3.1: Example 1 - Harmonization of amount columns

One challenge we always encounter in a data warehouse is the standardization of data formats when combining data from several sources. An example that may be very common now with the introduction of Seamless Planning, is combining planning data with actuals data from an ERP system.

By default, measures from SAC will be decimals with 7 decimals; whereas actuals from wither BW or SAP will be a decimal with 2 decimals. When combining the numbers in Datasphere, it will do it's best, but it may lead to either a loss of precision, or an ungodly amount of decimals in your reports.

So, what if you want to enforce a consistent data format across your solution? Well, you could use a scalar function.

In this example, I have decided I want all my amounts to be a Decimal(17, 2). Why? Because I grew up with BW, and 17,2 just feels like the objectively correct format. You may disagree (and you would be objectively wrong) and choose another format.

So, open your Database Explorer, and open an SQL console, and make sure it's connected to the user your created in step 1.1.

First, set the correct schema:

SET SCHEMA DWCDBGROUP#<YOUR_NAMESPACE>#<YOUR_SCHEMA>;

Then you can create your function as below:

CREATE OR REPLACE FUNCTION clean_amount_column (
	in_amount DECIMAL
)
returns out_amount decimal(17,2) -- Defines return type
LANGUAGE SQLSCRIPT
SQL SECURITY DEFINER -- Definer means it will use your DB user's rights, not whoever is using your report.
READS SQL DATA -- Makes sure the function is READ-ONLY. Functions almost always are, but it will help the compiler optimize function calls.
DETERMINISTIC -- Tells the compiler that the function will always return the same output, that means the results are cached for the runtime session, and can improve performance.

as 
BEGIN


DECLARE v_num DECIMAL(34,10);

    -- Null handling: If NULL, return 0. 
    IF in_amount IS NULL THEN
        out_amount := 0;
    ELSE 
		-- Convert to highest possible precision. Ensure we can handle scientific magnitude numbers. 
	    v_num := TO_DECIMAL(:in_amount, 34, 10);
		v_num := ROUND(v_num,2); -- Round to two decimals.
	    out_amount := TO_DECIMAL(:v_num, 17, 2); -- Convert to final DECIMAL(17,2)
    END IF;

END;

A few notes on the script:

CREATE OR REPLACE: If a function with that name, in that schema already exists, it will be overwritten. You may not want to accidently overwrite existing objects. In that case, you can use CREATE.
SQL SECURITY DEFINER: This means that the function will run with the rights of your DB user, rather than the user calling. This may not be what you want, so change to Invoker if you need that instead.
DETERMINISTIC: Is something you can use if you can promise the server that your function will always return the same result, given the same input, which improves performance, because results can be cached. Functions that require NOW() or TODAY() or CURRENT_DATE can not be deterministic.

When you have run the script, you should be able to find your function in your DB Schema:

You can right-click and select "Generate SELECT Statement", and test your function.

SELECT 12.747456 as Input, '12.76' as ExptectedOutput, "DWCDBGROUP#CHR_GRA#REPORTING"."CLEAN_AMOUNT_COLUMN"(12.764456).OUT_AMOUNT AS OUT_AMOUNT FROM DUMMY
UNION
SELECT 124545678.767456 as Input, 124545678.77 as ExptectedOutput, "DWCDBGROUP#CHR_GRA#REPORTING"."CLEAN_AMOUNT_COLUMN"(124545678.767456).OUT_AMOUNT AS OUT_AMOUNT FROM DUMMY
UNION
SELECT NULL as Input, 0.00 as ExptectedOutput, "DWCDBGROUP#CHR_GRA#REPORTING"."CLEAN_AMOUNT_COLUMN"(NULL).OUT_AMOUNT AS OUT_AMOUNT FROM DUMMY
UNION
SELECT '123.678' as Input, '123.68' as ExptectedOutput, "DWCDBGROUP#CHR_GRA#REPORTING"."CLEAN_AMOUNT_COLUMN"('123.678').OUT_AMOUNT AS OUT_AMOUNT FROM DUMMY

I've tested with a few values, including NULL and even a string

INPUT	EXPTECTEDOUTPUT	OUT_AMOUNT
NULL	0	0.00
123.678	123.68	123.68
12.747456	12.76	12.76
124545678.767456	124545678.77	124545678.77

When you are happy with your function, you need to provide access to your spaces. To do this you will need to:

Create a public synonym for your function
Grant EXECUTE rights to your space to functions in your schema.

The following statement may not make sense, but the technical reasons why this works is way beyond the scope of this post. So you'll just have to trust me.
If you want the technical breakdown; let me know, and I might include an appendix to this post at some point.

-- Create a public synonym - DO NOT REPLACE any existing synonyms.
-- If you're a puritan, you can always add a Z to your function and / or synonym. 
CREATE PUBLIC SYNONYM ZCLEAN_AMOUNT for DWCDBGROUP#CHR_GRA#REPORTING.clean_amount_column;

The public synonym is the name your function will have in your views, so give it a name good name.

Get the ID of the space you want to give access to. Then run the following commands in an SQL console:

GRANT SELECT, EXECUTE ON SCHEMA "DWCDBGROUP#<YOUR_NAMESPACE>#<YOUR_SCHEMA>" TO "<SPACE_ID>"."<SPACE_ID>::default" WITH GRANT OPTION;
GRANT SELECT, EXECUTE ON SCHEMA "DWCDBGROUP#<YOUR_NAMESPACE>#<YOUR_SCHEMA>" TO <SPACE_ID> WITH GRANT OPTION;

Note: the format is important. The quotes ( " ) must be there, otherwise you'll get errors.

So, how do you implement it?

Back in Datasphere, go to the space you granted access to, and create an SQL view.
You can now call your function by it's synonym, and feed it your inputs:

Important note: Datasphere, however, will not correctly derive the return type of your custom scalar functions, but will inherit the datatype of your input.
In my case, "Lines" is an integer, and the hard-coded values is a double, so I had to go in and manually change the format.

"But Christian, if I have to manually adjust the data type anyway, what is the value here?"

Well, yeah, that is a pain. However, even so, I would still argue that things like consistent null-behaviour, string-conversions etc., still have value.
Also, please remember that Datasphere dosen't know it actually supports customer scalar functions. This is basically me gaslighting it into running my functions, so a few quirks are to be expected.

3.2: Example 2: Consistent Date-conversions

Another colossal pain in the backend in any data modelling scenario is how to manage dates.
One absolute banger of timewaster is to get the CALMONTH (YYYYMM) from a date. Year, month, week, etc. all have standard functions implemented, but CALMONTH does not.
The formula is pretty simple, but so help me God, do I always manage to get it wrong, for some reason. (I am fully prepared to accept that the reason may be that I'm an idiot, but there is no reason to personal).

So, for this example, I'll show you another happy little easter egg: A scaler function can return several values, and can act like a class with different methods.

In this example, we'll take a basic SAP datestring (YYYYMMDD) and provide a single function, that can return year, month, calmonth, calweek, halfyear and quarter.
You can append it as you prefer.

SET SCHEMA DWCDBGROUP#<YOUR_SCHEMA>#<YOUR_SCHEMA>; 

CREATE OR REPLACE FUNCTION transform_sap_date (
	in_datestring nvarchar(8)
)
returns 
	out_year nvarchar(4), --YYYY
	out_month nvarchar(2), -- MM
	out_calmonth nvarchar(6), --YYYYMM
	out_calweek nvarchar(6), -- YYYYWW
	out_quarter nvarchar(1), -- Q
	out_halfyear nvarchar(1) --H
LANGUAGE SQLSCRIPT
SQL SECURITY DEFINER 
READS SQL DATA 
DETERMINISTIC 

as 
BEGIN

DECLARE lv_sql_date date;

    -- Null handling: If NULL, null. 
    IF in_datestring IS NULL or length(in_datestring) != 8 THEN
		out_year := null;
		out_month := null;
		out_calmonth := null;
		out_calweek := null;
		out_quarter := null;
		out_halfyear := null;
    ELSE 
    	lv_sql_date := to_date(:in_datestring);
		out_year := to_nvarchar(year(:lv_sql_date));
		out_month := lpad(month(:lv_sql_date),2,'0');
		out_calmonth := concat(:out_year, :out_month);
		out_calweek := concat(:out_year, lpad(week(:lv_sql_date),2,'0'));
		out_quarter := left(ROUND( month(:lv_sql_date) / 3, 0, ROUND_UP),1);
		IF month(:lv_sql_date) < 6 then
			out_halfyear :=  '1';
		else
			out_halfyear :=  '2' ;
		end if;
		
    END IF;

END;

-- Create a public synonym - DO NOT REPLACE any existing synonyms.
-- If you're a puritan, you can always add a Z to your function and / or synonym. 
CREATE PUBLIC SYNONYM ZDATE for DWCDBGROUP#<YOUR_SCHEMA>#<YOUR_SCHEMA>.transform_sap_date;

You can now test your function. You can get each output by specifying it with a .<IDENTIFYER> in each column:

SELECT 
	'20260408' as InputDate,
	"ZDATE"('20260408').OUT_YEAR AS OUT_YEAR,
	"ZDATE"('20260408').OUT_MONTH AS OUT_MONTH,
	"ZDATE"('20260408').OUT_CALMONTH AS OUT_CALMONTH,
	"ZDATE"('20260408').OUT_CALWEEK AS OUT_CALWEEK,
	"ZDATE"('20260408').OUT_QUARTER AS OUT_QUARTER,
	"ZDATE"('20260408').OUT_HALFYEAR AS OUT_HALFYEAR
FROM DUMMY

So, .OUT_YEAR gives you the year, and so on. Which gives you the following result:

Which is a great success!

So, in your view, you can now pass a date or a datestring to a function, and get whatever you need:

Note: Again, DSP gets confused about the datatype, and wants to give me a string(100):

So you will have to change that, but you can't have it all.

3.3: A few notes

Alrighty! So now we've seen how to create and implement custom, reusable logic across your Datasphere solution.

But it is not without headaches.
First and foremost, SQL artifacts can't be included in the transport packages, so you will have to repeat the process for each system in your landscape.

So, when transporting, the sequence is: (1) Make sure all the spaces are created, (2) create your DB group, schema and user, (3) Create or replace all the SQL objects, (4) Import your Datasphere views and models.

4: Jailbreaking the Graphical Editor

So, you may have noticed that up until now I've created SQL views to test my functions.
The reason is quite simple: The Graphical editor has access to fewer functions than the SQL editor.

However, that is easily fixed, if you are willing to fiddle with the debug console a bit.

Note: This works now, but technically it is a bit on the naughty side, so SAP may patch it out in the future.
However, it they patch it with the same speed that the add new features, I'm guessing this should make it to at least 2027Q3 before they notice.

So, the "allowed functions" in the graphical viewer is loaded once as a static list, the first time the editor is opened.

When you "Validate" and "Deploy" your view, the functions are validated against the static list, before it is deployed. If a function is not in that list, the view will not deploy.

So, the obvious fix is to smack in a breakpoint when the list is loaded, manually add your functions, and then deploy the view as always.

Note: This process must be repeated every time a view is opened, and must be done when the editor initially loads.

So, here is what you do.

Open the view you want to change, or click "New Graphical View"
Once the view has loaded open the development console for your browser (either press F12, or right-click -> 'Inspect')
Go to 'Sources' and right-click the folder with your tenant name and 'Search in all files':
Then, search for the following: FUNCTION_NAME_TO_FUNCTION. This might take a minute or two. You'll get results that look something like this:

In the file with the most hits, click any to open up the chunk.
In the open chunk, locate a function that contains "class a", and place a breakpoint AFTER the end of that function:
Refresh the page, but do not close the debugger.
When the debugger hits your breakpoint, find the console.
Locate your black trench-coat, 90s hacker glasses. Take a deep breath.
Mandatory step. Say "I've hacked the mainframe" out loud. You may also whisper, "I'm in", if you are currently in an open office setup.
In the console, you can type a.ALL to see an array of all the functions:
You can now see all the info required for a function to be included.
(Optional step) Open one of the functions and inspect the elements. Please take special note that the documentation in a RAW-string HTML document.
If you feel like it, you can either roll your eyes, do a facepalm or a similar display of "what the actual **bleep**".
From here, you can now push your functions to the class, and they will be legal in your graphical view.

a.ALL.push({Function: 'ZCLEAN_AMOUNT', InTypes: 'decimal', Inputs: 1, Return: 'decimal', definition: 'amount Converter (UDF)', items: [{"key": ""}], prepared: true})

Then, you also have to add the function to the FUNCTION_NAME_TO_FUNCTION dictionary:

a.FUNCTION_NAME_TO_FUNCTION['ZCLEAN_AMOUNT'] = {Function: 'ZCLEAN_AMOUNT', InTypes: 'decimal', Inputs: 1, Return: 'decimal', definition: 'amount converter (UDF)', items: [{"key": ""}], prepared: true}

I'm not sure why, but I'm sure there are good, complex, technical reasons why (🙃).

Resume the script (F8) and let the view load finish:
You can now close the debugger.
Your function is now legal, you can use it, deploy your view, and everything will compile and run without issue.
And why shouldn't it? SQL views and Graphical views both compile to the same HANA server.
The only reason graphical views behave differently is because SAP has actively restricted it. The only trick is to trick the graphical editor to not check.

Note: In all fairness, the Graphical view has to translate a graph to an SQL query, so there has to be some logic / special handling. Buuuuuut the list has remained static for over a year, so at this point it is just negligence.

So, that's it!
And please note you can add any number of functions while the debugger is open.
Both your own, or any function from the function reference that you need.
Want to use JSON_QUERY functions for JSON extractions? No problem. Add it in, deploy, enjoy.

Note: Be careful to add window functions, or aggregate functions, that are not supported. The view may compile and deploy, but it may behave oddly.

Unfortunately, you'll have to repeat this process every time you open a graphical view.
Opening a view that contains a jail-break function, without adding it to the legal list, will result in an error, and prevent you from deploying.

4: Conclusion

So, congratulations for making it all the way through that. I've tried my best to hit a balance between technical details, without it becoming overwhelming.

If you've any questions or if anything was unclear, please leave a comment and I'll either reply or update the post, to improve clarity.

So, by now you've learned :

How to access the HANA Cloud tenant, and create custom SQL objects to implement reusable code.
Allow your spaces to consume said objects in your modelling
Jail-break the graphical view editor, to include missing functions, without waiting 6 years for a feature request.

Happy reading, happy coding and I hope you had a wonderful easter.

Stay Connected with the HANA Community: Join Us at HANA Tech Con 2026!

2026-04-09T16:23:33.509000+02:00

HANA Tech Con 2026, part of the Code Connect event series, brings together developers, users, and partners who are passionate about HANA. More than just a technical event, HANA Tech Con focuses on collaboration and shared learning. Participants will have the chance to connect with experts and peers from around the world, discover new perspectives, and explore potential partnerships within the vibrant HANA ecosystem.

Learn from Experts and Real-World Experiences

Industry experts will share their experience through technical sessions, and interactive demonstrations. These sessions highlight the latest HANA features, modern development approaches, and proven best practices.

Attendees will also get the chance to explore real-world use cases and see how HANA technologies are implemented in practice.

Support the Event as a Sponsor

Supporting the event offers a great opportunity to engage directly with a highly focused community of developers, partners, and SAP users.

Sponsors benefit from strong visibility throughout the event, including brand presence in key areas of the venue and recognition during major sessions. Companies can also promote their solutions through event communication channels and interact directly with attendees who are interested in HANA technologies.

For those who want to showcase their products or services, an optional booth space can be included as part of the sponsorship package.

Check all the benefits and sponsorship options here: LINK

Registration will be opening soon!

Mark your calendar: Registration opens on April 16, 2026.

Tickets are free, so make sure to secure your spot as soon as registration goes live: they tend to go fast!

Highlights from Last Year

‌👉‌ Follow the event on LinkedIn to stay up to date with the
latest news on speakers, sessions, and announcements for HANA Tech Con 2026: LINK

Stay Connected, and see you at HANA Tech Con 2026!