SAP Community - SAP HANA

SAP HANA Cloud release January 2026 Round-up

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

Dear SAP HANA Cloud Enthusiasts,

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

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

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

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

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

All the best,

Andrea on behalf of the SAP HANA Cloud team

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

#whatsnewinsaphanacloud

Code Connect 2026 is Coming – Mark Your Calendars!

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

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

What is Code Connect?

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

Your Week at Code Connect

July 13: Code Jam Sessions and Warmup

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

July 14: UI5con

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

Learn more about UI5con.

July 15: reCAP

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

Learn more about reCAP.

July 16: HANA Tech Con

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

Learn more about HANA Tech Con.

Early Bird Process

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

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

Sponsorship Opportunities

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

Read our sponsorship prospectus to check our sponsorship opportunities.

Call for Proposals

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

Important Dates

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

Ready to Connect?

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

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

Transfer of medical instruments and implants in Medical device Industry using S/4 HANA

2026-01-18T21:33:24.252000+01:00

Introduction:

This blog outlines the leading medical device industry business process steps to Transfer medical instruments and implants needed in a surgery from one branch to another branch and provide visibility, tracking, and logistic support to the business process using S4 HANA

In the field instruments and implants can be physically transferred from branch to another branch based on demand and utilization, this process needs to accurately be captured in the SAP system.

When a request is received for transfer of instrument and implants between branches (consignees), from Branch A to Branch B, The SAP data model requires the execution of two transactions; first, a Consignment Pickup Order that pulls the product back to warehouse stock in the “plant of origin” and purpose-built “transfer storage location” not visible to ATP from Branch A and immediately transfer to Branch B with transfer-specific Consignment Fill Order that moves the product to the new branch.

Pre-requisite:

The goods requested for transfer are consigned in the system against branch A
Virtual storage location set up in S4 to move stock between the rep and not visible to ATP
Hospitals and branches must be set up as customers
Instruments and Consumables set up separate materials.

Setup Steps:

Configure new consignment document type: -

Step 1: Define Consignment fill up and pick up document types

SPRO – Sales and Distribution – Sales document- Sales document header – Define sales document type.

Consignment Pick up – To pick up inventory from branch A back to the warehouse and virtual storage location

Consignment Fill up. – To deliver inventory to sales rep B

Step 2: Define item categories.

SPRO – Sales and Distribution – Sales document- Sales document item – Define item categories

Consignment pick-up item category

Consignment Fill-up Item category.

Step 3: Schedule lines

SPRO – Sales and Distribution – Sales document- Schedule lines – Define schedule lines.

Consignment Pickup Schedule line.

Consignment Fill up the schedule line

Step 4: Assign document type to the sales area.

SPRO – Sales and Distribution – Sales document- Sales document header – Assign Sales Area to Sales Document Types

Step 5: Assign Item Categories

SPRO – Sales and Distribution – Sales document- Sales document item - Assign Item Categories

Step 6: Assign Schedule Line Categories

SPRO – Sales and Distribution – Sales document- Schedule lines - Assign Schedule Line Categories

Process steps: -

Step 1: - Create pick up order (KA) To pick up inventory from branch A

Step 2: Create Inbound delivery and receive goods in the warehouse of origin and virtual storage location.

Step 3. Create a Consignment fill up (KB) order transfer/deliver goods to branch B

Step 4: Create an outbound delivery with reference to the KB Order. Pick, pack, and Issue from the virtual storage location to rep B

Step 5: Asset updated with the new functional location

Conclusion:

After going through the above blog, the user should have learned how to transfer goods from one branch to another using S4 HANA
Please provide your feedback/comments. You can ask Question / Answer for the open Questions in the SAP Community here

Reference:

SAP Help Portal

Authors: Mohan Kaliyamoorthy and Immanuel Godwin Johnson

Fulfillment of Trial request to the field in Medical Device Industry using S/4 HANA

2026-01-18T21:42:14.791000+01:00

Introduction:

This blog outlines the leading industry business process steps to fulfill and track customer request for trials in the field providing visibility to all stakeholders.

It is common practice in the medical industry for customers to request trial of new or modified products to determine effectiveness before placing orders.

The trial products sent out from the warehouse to field must be tracked and stored appropriately when returned as these can be used across customers and geographies. This document details the fulfillment of trial products

Pre-requisite:

Hospitals must be set up as customers and sales representatives as employees
Instruments and Consumables set up separate materials
Dedicated storage locations inside warehouses to store trial products

Process Steps for Trial

Consignment Fill up. – To deliver trial inventory to customer

Consignment Pick up – To pick up inventory back to warehouse and dedicated storage location after trial

Step 2: Define item categories.

SPRO – Sales and Distribution – Sales document- Sales document item – Define item categories

Consignment Fill-up Item category.

Consignment pick-up item category

Step 3: Schedule lines

SPRO – Sales and Distribution – Sales document- Schedule lines – Define schedule lines.

Consignment Fill up the schedule line

Consignment Pickup Schedule line.

Step 4: Assign document type to the sales area.

SPRO – Sales and Distribution – Sales document- Sales document header – Assign Sales Area to Sales Document Types

Step 5: Assign Item Categories

SPRO – Sales and Distribution – Sales document- Sales document item - Assign Item Categories

Step 6: Assign Schedule Line Categories

SPRO – Sales and Distribution – Sales document- Schedule lines - Assign Schedule Line Categories

Process steps: -
Step 1. Create a Consignment fill up (KB) order send goods on trial from dedicated trial storage location

Step 2: Create an outbound delivery with reference to the KB Order. Pick, pack, and Issue from the virtual storage location to rep B

Step 4: Asset updated with the new functional location. Equipment identified as trial

Step 5: - Create pick up order (KA) To pick up inventory from customer location after trial

Step 2: Create Inbound delivery and receive goods in the warehouse of origin and virtual storage location.

Conclusion:

After going through the above blog, the user should have learned how to fulfill a customer request for trial of products using S4 HANA
Please provide your feedback/comments. You can ask Question / Answer for the open Questions in the SAP Community here

Reference:

SAP Help Portal

Authors: Mohan Kaliyamoorthy and Immanuel Godwin Johnson

Expired Product Management in Medical Device Industry using S/4HANA

2026-01-19T18:18:41.852000+01:00

Introduction:

This blog outlines th leading medical device industry business process steps to return expired products from the field and to replenish for the depleted stocks due to return of expired products.

In the field instruments and implants can expire for various reasons, companies regularly monitor products on the field for expiration and pull them of the shelves and replenish them with new stocks. This process prevents expired products from reaching the customers.

Pre-requisite:

The goods due expiration in the field consigned to customers or branch
The materials are tracked using reports generated out of S4
Hospitals and branches must be set up as customers
Instruments and Consumables set up separate materials.

Process Flow:

Process Flow: Replenishment

Process Flow: Return Expired

Consignment Fill up. – To deliver inventory to sales rep B

Step 2: Define item categories.

SPRO – Sales and Distribution – Sales document- Sales document item – Define item categories

Consignment pick-up item category

Consignment Fill-up Item category.

Step 3: Schedule lines

SPRO – Sales and Distribution – Sales document- Schedule lines – Define schedule lines.

Consignment Pickup Schedule line.

Consignment Fill up the schedule line

Step 2: Create Inbound delivery and receive goods in the warehouse of origin and virtual storage location.

Step 3. Create a Consignment fill up (KB) order transfer/deliver goods to branch B

Step 4: Create an outbound delivery with reference to the KB Order. Pick, pack, and Issue from the virtual storage location to rep B

Step 5: Asset updated with the new functional location

Conclusion:

After going through the above blog, the user should have learned how to pull back expired products from the field and replenish them with new stock in S4 HANA
Please provide your feedback/comments. You can ask Question / Answer for the open Questions in the SAP Community here

Reference:

SAP Help Portal

Authors: Mohan Kaliyamoorthy and Immanuel Godwin Johnson

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

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

last updated: 2026-01-20

Why was this blog post created?

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

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

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

section Runtime Dump (RTE)
section SAP HANA Dump Analyzer

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

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

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

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

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

Generated report in SAP HANA Dump Analyzer

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

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

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

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

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

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

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

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

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

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

What is the conclusion?

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

Do you have further questions?

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

Contribution

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

Release Information

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

Creating value in airlines

2026-01-21T17:04:27.656000+01:00

MOST PROFITABLE, LARGEST, AND MOST VALUABLE ARILINE

As we travel back from the holidays, or into year-start meetings, it may be a good time to reflect on the companies that make such travel possible. In this case, let’s examine Delta Air Lines’ transformation journey with SAP.

Specifically, let us zoom in on three related areas of transformation:
1. Delta’s strategy of top customer experience, which among other things means on-time flights.
2. Workforce optimization to enable upward mobility for some 100,000 people.
3. Improving financial close, which was historically burdened with significant non-linearity.

These areas of Delta’s evolution show a clear connection between passenger experience, Delta’s own resources, and share- and debt-holders as providers of capital.

Let’s start from the customer excellence.

ON-TIME ARRIVAL
You can see the comparison of Delta with other major global airlines: horizontally plotted are percentages of flights with on-time arrival and vertically plotted are the number of flights per year. Delta, with some of the highest number of flights in the world, is constantly improving its on-time arrival statistics and currently stands at 84%. This is an amazing achievement for such a large operation. The accolades from the media and experts are well deserved.

But let’s look at what it took to achieve such operational excellence.

For now, let us focus on the processes part of the equation; we will talk about people soon.
The major reason for delayed flights, apart from the weather, is supplies. Catering, to be more specific. Before Delta embarked on the journey to significantly overhaul its operations, the state of the union was as follows:

Very large operations across the globe… but email communications with the suppliers.
Multiple items of supplies… but some not even recorded in Delta’s inventory system. For example, there were stories of half a million dollars' worth of earbuds and a million dollars' worth of blankets left in various airports without any visibility for Delta’s operational colleagues.

That had to change, and Delta did change them. To support its in-sourcing processes, the company adopted SAP IBP and SAP SAC to enable some 155 locations, 255 suppliers and 8 warehouses worldwide.
As a result of demand sensing and inventory optimization, Delta was able to optimize its catering, including the weight aspect of the supplies (for example, the number of food and beverage items based on the passenger count). This, in turn, led do significant fuel savings, which cumulatively accounted for some $100m cost savings in 2024.

To sum it up, for the first strategic transformation area, not only did Delta improve its on-time arrival KPI but it also removed some costs. This brings us to the people side of the equation…

Workforce mobility
Operational excellence goes hand in hand with the people excellence. Especially when you know that people expenses account for a quarter of your revenue or some $15 billion, and they grow faster than revenues.
The company decided to do a few things:
1. Lower the educational requirements and rather train people on the job.
2. Give people opportunities to advance.
3. Lower the “extra shift costs” where possible.

Why this was critical becomes clear when you look at Delta’s workforce…
Delta’s people represent a very diverse human resource organization, by location, type of job performed, and typical challenges.

So let us, together with Delta, look at one typical employee…
Like many large organizations, Delta sees two significant workforce drivers: Source & Recruit and Enable & Develop.
It’s the second one where the company realized it was missing a lot. Meet Eleanor, a typical high-achiever, who – through her effort on the ground – became a top performer (“red coat” in Delta’s language) but wants to push herself even higher. When Eleanor searched the corporate portal for job opportunities in Finance, some 1,100 results appeared – an impossible number to comprehend and take action on. This is what Delta’s colleagues call the “foggy gap”: the desire to learn and grow is present, but no enabler exists for that.

When the managers considered the traditional approach, they quickly realized its limitations and resulting frustration, both for the employees and for the hiring managers.

Therefore, Delta adopted its own, unique approach: FOCUS ON SKILLS, NOT JOB DESCRIPTION.

During the transformation, Delta created a repository of SKILLS making it available to employee and tying skills the Delta’s HR needs. This enables the employees to focus on what they either have to have to develop, as opposed to searching through numerous job postings and trying to decipher them. The results of this approach are quite telling. Half of the managerial positions are filled with experience Delta veterans ensuring upward mobility and job satisfaction, and the central skills repository is easy to maintain and update.

But most important is the overall outcome: employees who feel taken care of by Delta, take good care of the Delta customers.

Now that we have reviewed two strategic initiatives – on time flight arrival and employee mobility – we can look at another challenge Delta faced throughout the years.

Nonlinearity
It is January 1. Or April1. Time to close the year or quarter. Yet during this first week of January or April, Delta receives the vast majority of its invoices including from contractors for the previous period. The week is literally flooded with work. For the year close, we are talking about some $30 billion in gross debits! That’s half of the total annual business.

Such contracted services come from different sources, including companies such as Unifi, an approximately $2bn and 40,000 employee strong largest provider of air services in North America. (link)

Services such as plane taxying, cleaning, baggage loading, special needs passenger transportation, tie back to the on-time flight departure and arrival as well, so they are critical to Delta’s strategy...
…and for Delta, such services spell into some $4 billion cost item, i.e., approximately $1bn each quarter.

Before the transformation, most of such reconciliation and postings were manual. To automate this process, Delta utilized SAP HANA as the main source of flight data, coupled it with the AI tools from Blackline, creating a more automatic incoming invoice matching and posting process.

As a result, some 2/3 ds of the accruals became automatic matches, and that trend continues. Overall, this automation significantly lessens the strain of period close and compresses the time to close, freeing oCFO colleagues’ time for higher added value work.

But the amazing by-product of the automation is a much shorter time to publish quarterly reports. Among the major US airlines, Delta is the fastest to file its 10-Qs, the quarterly reports, therefore improving its stance with the share- and debt-holders.

So, the question is, does the market notice all these Delta’s efforts to evolve across the three strategic imperatives?

Recap
The answer is unequivocal yes. Through its incredible journey to improve customer service, create workforce mobility, and combat non-linearity for faster financial close, in the past 5 years, Delta grew its Enterprise Value by 1.4x or at approximately 7.6% CAGR. Delta has become one of the most profitable and the most valuable airline. I am proud to say that SAP has supported Delta in every step.

* * *

Big debt of gratitude to my partners at SAP and, most importantly, to Delta – for being an SAP customer!

Creating value in airlines

2026-01-21T17:05:46.747000+01:00

MOST PROFITABLE, LARGEST, AND MOST VALUABLE ARILINE

Very large operations across the globe… but email communications with the suppliers.
Multiple items of supplies… but some not even recorded in Delta’s inventory system. For example, there were stories of half a million dollars' worth of earbuds and a million dollars' worth of blankets left in various airports without any visibility for Delta’s operational colleagues.

Now that we have reviewed two strategic initiatives – on time flight arrival and employee mobility – we can look at another challenge Delta faced throughout the years.

* * *

Big debt of gratitude to my partners at SAP and, most importantly, to Delta – for being an SAP customer!

Violent Geometry of Gold: from Flatlandia to Spacelandia

2026-01-27T18:17:00.724000+01:00

Let us talk gold. And Newmont Corp:

Newmont Corporation (stock ticker NEM) is the world’s largest gold miner. And one of the top SAP customers. Same is true for Barrick Mining (B), its competitor and – in certain areas – a partner. For example, Barrick-Newmont JV in Nevada is the world’s largest gold complex. Barrick is also an SAP customer.

Just to put things in perspective, here is the heat map of the EV for the various players in metals and mining:

WHY GOLD RETURNS? AND PAIRING GOLD-STOCK RETURNS

Recent gold's ascension to unprecedented value prompted many to examine its return dynamics and correlations with various other returns. We are decided to follow suit.

First, we define returns: stock price changes in NEM and B vs price changes in gold. Specifically, the raw price data allows us to create time series of returns: first for Newmont Corporation’s stock and the second for gold. In both cases, monthly returns are defined as

Dataset: we took 1985-2025 (40 years) gold prices from the World Gold Council (gold.org) and Newmont stock prices (NEM) from Yahoo Finance, turning both into returns. The resulting data contains 490 monthly returns.

date	nem_return	gold_return
1985-01-01
1985-02-01	(0.037)	(0.011)
1985-03-01	0.038	0.073
1985-04-01	0.000	(0.019)
1985-05-01	0.020	0.020
1985-06-01	(0.075)	(0.015)
1985-07-01	0.072	0.006
1985-08-01	0.011	0.001
1985-09-01	(0.069)	0.016
1985-10-01	0.059	0.081
1985-11-01	0.076	0.109
1985-12-01	(0.018)	0.014
1986-01-01	0.077	(0.061)

And most recent ones:

Let us zoom in on the first pair of returns: 1985 February saw NEM stock price decline by 0.037 and gold decline by 0.011, i.e., the two monthly returns were -0.011 and -0.037 respectively.

Pairing these returns essentially answers the following question: “Given gold moved by this amount in month t, how did Newmont move in the same month?”

Statistics call this a bivariate observation (or observation from a joint distribution)
Finance calls this a paired return realization (or joint asset-factor return where gold is a factor)
Mathematically, such paired return is point or vector in, i.e., in two-dimensional space. We will prefer the vector nomenclature here.

With the vector of returns definition in mind, we have the following for February 1985:

Plotting all such paired returns produces the following scatterplot:

As we established, each dot is a vector of returns. Visually and intuitively, the vector is an arrow starting at the origin [0,0] and extending to such observation coordinates

as shown on the plot below:

Put plainly, in February of 1985, both assets - gold and NEM – were down, i.e., produced negative returns. This is why the vector resides in the 3rd quadrant.

What is the magnitude, i.e., length of this vector?

This vector magnitude conveys the length of that month’s movement, i.e., how large the combined movement was across both gold and Newmont in February 1985. How “violent” the month was.

Close up on this vector allows us to see it in greater detail:

Specifically, we can visualize the movement: Newmont moved much more down than gold moved left. This specifically means: both moves into the “negative territory” but Newmont moved much more.

We estimate the angle in two ways.

Recalling SOHCAHTOA,

Since we start from the origin and go counter clock-wise to the red vector, the angle is

Put another way, measuring θ from the positive x-axis, we have tan(θ) = y / x, which captures relative sensitivity of NEM to gold for that month (for that realization only). This is local sensitivity, not structural beta (yet).

We use -180 degrees to match the polar coordinates.

Alternatively, using atan2(y, x), the angle naturally places the vector in Quadrant III, confirming a joint negative regime.

Our economic interpretation is simple: the move happened in quadrant III, i.e., negative economic regime (decline for both) and we know that NEM realized over 3x of the gold negative return.

We contrast February 1985 with March, where both Newmont stock and gold went up producing positive returns:

Here, the gold went up 2x of NEM. In other words, gold rallied strongly, NEM participated but more conservatively. Therefore,

Angle of 45 degrees would indicate equal movement, but our angle here is only 27.5 degrees which again indicates x-dominated change as opposed to the y-dominated one. That month, gold won.

In relative magnitude terms.

But what is important for our inference about the relationship is how much gold’s movement that month “showed up” in NEM’s return? Answer: approximately 50%. This is where the interpretation becomes interesting since we observe realization of sensitivity. We are not estimating NEM’s beta yet; but are observing the sensitivity – via vectors. In other words, we already see some asymmetry: when gold moved down in February, NEM moved down 3x. When next month gold moved up, NEM moved 0.5x.

So, we can reformulate our findings so far in this way:

We can start generalizing now.

HOW MUCH OF NEM’s MOVEMENT IS EXPLAINED BY GOLD MOVEMENT?

This question can be reformulated in “vector terms”: what is the projection of the joint NEM/gold return vector onto the gold direction?

We already established that for any given month in our dataset,

Therefore, the gold direction vector is

This is a unit vector representing no NEM component.

Now we want to know how much our joint return vector – the red arrow – projects onto gold. In this particular situation, the case is trivial because the gold resides on x axis and the coordinate 0.073 easily depicts such projection. However, we want to generalize this rule for the more complicated cases where the factor (e.g., gold) direction vector is not easily located on x-axis. The projection

Where the dot product of this projection is visually intuitive here: hypothenuse * cos (adjacent angle theta) = adjacent side (x coordinate):

Note: full dot product identity is

We can verify the 0.073 projection by calculating the dot product:

(r * g) = (0.073, 0.038) * (1, 0) = 0.073 * 1 + 0.038 * 0 = 0.073

Alternatively,

In plain English, the red vector points 0.073 in the gold direction, or the gold-aligned component has magnitude of 0.073. Financially, we can say that in March 1985, 0.073 of the total movement is explained by gold (that month).

We can now reverse the logic of the dot product definition, or, put another way, we can create a second question:

Our first question	--> Our second question
How much r (i.e., total magnitude of this month’s combined change) projects onto gold?	What fraction of the total vector’s length, i.e., \|\|r\|\| lies in the gold direction?
Hypothenuse x cos(theta) = adjacent size:

Scalar – in this case length along x axis	Ratio inside the triangle =
How many percentage points of this month’s NEM+gold move lie along gold.	Fraction of the joint vector aligned with gold. Explanatory share. Early “predecessor” of R2 in OLS.

Since we asked the question how much the joint movement is gold-aligned, we ought to investigate the other part as well:

WHAT HAPPENS TO THE PART WHICH IS NOT GOLD-ALIGNED?

Financially, this question centers on non-gold, i.e., NEM-idiosyncratic returns (movements in price). These movements are uncorrelated with the gold movements. Well, “uncorrelated” applies to the entire data set, so for one month, the lack of relationship here is better explained as orthogonal to the gold direction by construction (uncorrelated only in aggregate). We define orthogonality month by month; we discover correlation across the entire period.

Let us again use March 1985 since we are familiar with this month’s returns. Mathematically, we express the “gold unrelated” NEM movement (return) as orthogonal vector. In plain English, this is the “leftover” which has zero alignment with gold:

In vector form, this orthogonal vector (perpendicular to the gold projection) is

i.e., difference between two vectors: joint movement vector – its projection onto gold. Why is this vector perpendicular to the “gold vector”? Because we made gold our explanatory variable. If we were to use the typical regression language, gold return[s] is the independent (predictor) variables while NEM’s return[s] is the dependent (predicted) variable. Clearly, the relationship in reality may be bi-directional and more nuanced, but for now we made “an executive decision”, so to speak: treat gold as the explanatory and NEM as the explained variable (x and y respectively). This is why the orthogonal vector (blue arrow) is perpendicular to the “gold vector.”

Financially,

the dotted line vector along the x axis (the “gold vector”) says, “What did NEM return because of the gold movement this month?” (assuming linearity, not causality, and no stability over time)
while the vertical blue vector says, “What did NEM return that cannot be explained by gold this month?”

Given this distinction, we can treat the orthogonal (blue) vector as a residual: it provides the gold-unexplained return on the NEM stock. In other words, the projection of the joint vector onto gold represents the gold-explained component of NEM, while the blue vector depicts the gold-unexplained portion of the NEM return.

Now that we defined the joint return vector as

we can plot the gold returns on the x-axis and such residuals on the y-axis:

Geometry

Mathematics

Statistic

Finance

We can see that the residual vectors reside in the direction perpendicular to gold. We do not see any systematic tilt left: the cloud of the returns is centered on y=0 and appears symmetric. In other words, we observe typical orthogonality in

This is the “geometric heart” of the OLS regression.

From construction:

By definition of projection (our earlier dot product definition):

Fitted line is approximately flat, so correlation is

corr(Gold,rt,⊥)≈−0.016

We estimate beta as:

This means that when gold moves by 1 unit, NEM moves by 0.075 units. In other words, +1% gold month corresponds, on average, to +0.075% month for NEM price change. NB! this beta reflects monthly decimal returns and should not be compared directly to conventional annualized betas.

Residual:

Beta of gold is the systematic gold-driven component of NEM (linear approximation). This is important for the decision to hedge, increase or decrease gold exposure (via NEM stock), and alleviate macroeconomic shocks.

The residual is everything else specific to NEM: mine issues, management decisions and execution, even market noise (equity moves unrelated to gold).

In sum: this plot shows that once we remove the gold-aligned component of NEM’s returns, what remains is geometrically orthogonal, statistically uncorrelated, and economically idiosyncratic.

MANY VECTORS: WHICH ONE BEST DESCRIBES THEM ALL?

As we established earlier, dot product of two vectors measures how much one vector moves along the other, like joint vector movement along gold we described earlier. Given we have many joint returns (490 precisely), i.e., vectors v1, v2, …, vn (depicted in different colors above), how can we find a single direction vector u such that vectors have large projections onto u? Let us define “large” first.

If we sum just the projections, some resulting scalars will have negative sign and some positive, so some positive and negative months would cancel. We would get “net drift” but this is a different story. So, what do we do?

Like we do in estimate variance, we square the projections:

Therefore, we are looking for the unit vector u which maximizes such sum of squares, or “squared projection”:

With the NEM/Gold example, this algorithm chooses a joint Gold–NEM movement direction that explains as much total magnitude of monthly co-movement as possible, regardless of the sign.

Here is the resulting projection. Given the maximization of the “squared projection” algorithm above, this line has the following meaning: when we orthogonally project all monthly vectors onto this line, the total squared length of those projections is maximized.

· Line is almost vertical, which means that NEM returns dominate

· This is a line, meaning direction +/-u are equivalent: bulls and crashes equally matter

· Interestingly, our data is clustered around the x axis and is horizontally distributed… but clustering near the x-axis means large directional alignment with the x-axis, but not necessarily large magnitude-weighted projections: even modest-angle but high-magnitude vertical component yt dominates the squared length (magnitude is quadratic).

In other words, many small calm months near horizontal “yield to” fewer crisis / equity-shock months with large vertical magnitude.

· Gold moves often, but modestly

· NEM moves less often, but violently

· Our algorithm rewards violent months quadratically, i.e., though high energy of such months

These findings may feel counter-intuitive at first, therefore we ought to explore it with the vector magnitudes in mind.

We recall that each joint movement vector (paired return vector which we started with) has the following length, or magnitude:

But we remember that our maximization algorithm squares such vector:

In plain English – perhaps not entire correctly but intuitively – vector length is the hypothenuse. Its projection (the adjacent side) is hypothenuse multiplied by cos(angle) – this comes from the Pythagorean identity. But the maximization algorithm, squares such projection (the dot product of v and u above). The hypotenuse measures how large each vector is but contains no information about orientation, so it cannot distinguish between directions; projections introduce directional dependence, and squaring them yields a rotation-sensitive, non-canceling measure of how much joint movement lies along a candidate direction.

	Panel 1 on the top plots each vector (i.e., joint movement as a vector from the origin). Most months live in a tight band near zero, but a few months spike dramatically (1987, 1998, 2008, 2015, 2020).
Pane 2 in the middle conveys the energy. Since monthly returns are max 0.77 for NEM and 0.18 for gold, squaring them makes them smaller. But the relative importance of such violent months rises.
Panel 3 conveys that clearly: out of 490 months (40 years of data), just 12 (!) have over a quarter of energy.

Our geometric findings map to the financial interpretation:

Most months: small, noisy co-movement between gold and NEM
Rare months: systemic stress or regime shifts
- 1987 crash
- 1998 LTCM / Russia default
- 2008 GFC
- 2020 COVID
Those months define the economic meaning of “joint movement”

What surprises me here: though most months cluster near the horizontal axis, a few high-energy months dominate the squared-projection algorithm; consequently, the optimal direction aligns with those violent joint movements rather than with the calm majority.

So, we might have proven that violent / high energy months translate into the near vertical orientation of the optimized line, the line that represents single direction of all 490 vectors. What does it mean? It does not mean that gold returns are irrelevant or NEM returns are completely independent. Rather, we can conclude that the dominant joint-movement direction in 1985-2025 is driven by NEM’s variability, not by gold’s average alignment.

The economically meaningful joint shocks between gold and Newmont are equity-driven, not metal-price-driven.

CROSS-PRODUCT: WHAT CAN IT TELL US ABOUT NEM AND GOLD?

We will be quickly moving from the ‘Flatlandia’ (to paraphrase Edwin Abbott) into ‘Spacelandia’ or into

Let us pick two months: February and March of 1985. We remember that the joint movement (or joint return) vectors had the following coordinates (see table above):

Their cross product is defined as

We can see this cross product as the 3rd axis vector sticking up, i.e., perpendicular to the plane of the two original vectors. Small red vector here:

This red upward looking vector is small because we multiply numbers which are each below |1|. Interestingly, the magnitude of this vector represents the area of the parallelogram formed by the two original vectors,

To check ourselves, let us calculate the area of this parallelogram “by hand”:

Let us find the length of each vector:
Now, let us use the green vector as the base. Area of parallelogram is given by the A=base * height where height = slanted side * sin(angle between slanted and base).
- To find the sine of the angle we use the dot product and then the relationship between the dot product, magnitude, and angle.
- Dot product is

I find it amazing that this barely visible “z-axis” orthogonal vector – the cross product of our two Feb and March vectors – is indeed the area of the parallelogram formed by the two vectors.

What does the cross-product vector – or the parallelogram area – mean for NEM and gold? The magnitude of the orthogonal vector (or area of the parallelogram) represents the joint “volatility” volume, or the degree of uncorrelated movement between gold and NEM. Well, more correctly, the area measures directional misalignment x magnitude across two realizations.

The larger the area of such parallelogram (or the height of the orthogonal vector), the more NEM and gold moved freely independently, and the smaller the area, the more they acted “in sync”. If gold and NEM were perfectly “correlated” (this is not correlation yet – which requires many observations) during these two months, the parallelogram would collapse into a single line and the orthogonal vector would be zero in length. Therefore, in such a scenario, a portfolio of two assets – NEM and gold – would offer no diversification benefit for those realizations.

On the other hand, ideal diversification scenario for these two realizations would be the maximum parallelogram area, where

and the orthogonal vector is maximal in length (magnitude).

As a recap for our two asset / two vector situation:

Two joint-return vectors (Month 1 and Month 2) form a parallelogram
Its area equals the magnitude of the cross product
Zero area ⇔ perfect directional alignment
Area measures directional change + scale (not correlation in statistics)

Now we can ask ourselves about multiple month pairs within the entire 1985-2025 time horizon: what may the cross product of such pairs tell us?

There is no cross product of the entire period, but we can calculate multiple cross products of month pairs and plot the distribution of such parallelogram areas (aka cross product orthogonal vectors).

As a reminder: the smaller the area, the more in sync gold and NEM moved (more colinear) and the larger the area, the more different the returns were: regime break (exogenous events perhaps) and strong directional disagreement / magnitude mismatch.

Rolling 2 adjacent months, i.e., 489 2-month pairs (t, t+1)	All possible month pairs, i.e., 119,805 pairs
How do co-movements (joint returns) for gold and NEM change month to month?	Global cloud geometry

We see how right skewed data is. Again, many calm months witness relatively “synchronized” movements of gold and NEM returns (left handside). But there are “violent” months where returns are very “uncoordinated” both in direction (angular disagreement) and magnitude. In sum, the right handside area of this boxplot represent macroeconomic events and market stress.	This full-pair geometry reinforces the same idea, just with many more pairs.
Calm months dominate in count, violent months dominate in impact. Consistent with our earlier findings.

3D “SPACELANDIA” WITH A 3RD ASSET: WHAT CAN WE LEARN?

First, let us add another company: Barrick Mining.

With this addition, our raw data of returns has one more column:

Let us now visualize the 3D space of December 2025:

Here i, j, k denote the standard unit vectors along the Gold (x-), NEM (y-), and Barrick (z-) axes, respectively.

This single 3D joint-movement vector represents one realization (joint movement returns) in Gold–NEM–Barrick space.
To examine diversification and independence across the three assets, we zoom in on how such vectors span three-dimensional space across time.

While in Flatlandia (2D) the cross product of two vectors - two joint return vectors for Gold and NEM – produced the area of parallelogram (how coordinated or uncoordinated return moves), in Spacelandia (3D), the triple scalar product of three vectors produces the volume of a parallelepiped:

Thus, this means that now we are looking at three months, e.g., December, November, and October 2025.

In other words,

and so on.

What does the formula mean geometrically?

is vector perpendicular to the plane spanned by

Its magnitude
is the area of the parallelogram built on
Then
takes the component of
in the perpendicular direction, i.e., “height”
So, volume = base area × height.

What does “big vs small volume” mean financially? How many independent directions did the system move across those 3 months.

Volume ≈ 0: the 3 monthly joint-movement vectors are nearly coplanar / linearly dependent.
Across these three months, the Gold–NEM–Barrick system mostly moved in one common pattern; nothing ‘new’ happened in the 3-asset relationship.
Large volume: the three months span a genuinely 3D chunk of space.
Across these three months, the relationship among Gold, NEM, and Barrick produced a new linearly independent shock pattern—these assets did not just scale up/down together; their co-movement structure shifted.

Like we did in the Flatlandia with the cross products across the entire time period (490 months – 1 because of rolling adjacent 2-month convention), for Spacelandia, we can perform the same for the rolling adjacent 3 month parallelepiped volumes:

We observe somewhat similar picture: there are a lot of calm months where the volume of the RD parallelepiped is small (joint return movements appear synchronized in direction and magnitude) and there are “violent” months where such joint return movements are misaligned in direction and magnitude (volume of the resulting parallelepiped is high).

Finance Color #1: It clicked: diversification is episodic, not average

Our geometry shows that diversification between gold and mining equities (NEM and B) is state-dependent, not constant:

Most months: small areas / volumes → assets behave as if driven by a common macro regime
Rare months: large areas / volumes → diversification suddenly becomes real

Therefore,

long-run correlations look “moderate”
but portfolio protection often shows up only during stress

In other words, this geometry captures when diversification matters, not just whether it exists on average.

Finance Color #2: Volumes identify regime transitions, not just volatility

This is the “value add” by geometry:

Large magnitudes = volatility
Large areas = change in pairwise structure
Large volumes = change in system structure

So, a large rolling 3-month volume is not “just a volatile period” — it is a period in which the relationship among Gold, Newmont, and Barrick itself changed. Financial models break down, hedging become unstable, new factors emerge and/or replace previous ones.

As an extra step, I re-examined the history of various events “surrounding” such extreme returns on the right handside. Picking just a few of those located on the most far end of the x-axis, yields the following picture and details below:

Rare large-volume rolling 3-month windows (chronological)

1986-04 → 1986-06

Macro / markets: Post-Volcker disinflation environment (CPI in us at 10-14% so Feds increased the rate beyond 20%); USD strength and falling inflation expectations.
Gold: Weak and unstable price action as real rates rose.
Miners: Equity-specific adjustments amplified moves relative to gold.
Why volume spikes: Gold and miners responded differently to shifting rate expectations, breaking the usual “gold proxy” behavior.

1987-08 → 1987-10

Macro / markets: Lead-up to and aftermath of the October 1987 stock market crash (on Oct 19, 1987 Dow Jones lost 22%).
Gold: Initially mixed, then benefited as a crisis hedge.
Miners: Extreme equity volatility dominated fundamentals.
Why volume spikes: Equity shock introduced a new independent direction orthogonal to gold’s behavior. Liquidity “evaporated” so the correlation is almost 1.

1998-08 → 1998-10

Macro / markets: Russian default (domestic debt and subsequent ruble devaluation) + Long-Term Capital Management crisis (ironically, LTCM, a hedge fund, was founded by Nobel Prize laureates in Economics including Robert Merton and Myron Scholes); severe global risk aversion.
Gold: Safe-haven demand surged after prolonged weakness.
Miners: Sharp equity dislocations due to leverage and funding stress.
Why volume spikes: Breakdown of historical gold–miner co-movement during systemic stress.

1999-09 → 1999-11

Macro / markets: Late-cycle equity exuberance (NASDAQ is in vertical ascent) approaching dot-com peak. Traditional valuations? Dismissed.
Gold: Structural weakness, including sales (not purchases!) by Central banks.
Miners: Equity market forces overwhelmed commodity linkage. They traded like ordinary stocks rather than gold-linked assets.
Why volume spikes: Miners decouple from gold amid speculative equity flows.

2008-09 → 2008-11/12 → 2009-02

Macro / markets: Systemic collapse after Lehman, followed by rapid stabilization via extraordinary monetary intervention.
Gold: Immediate safe-haven surge during panic, then sustained strength as QE and monetary debasement expectations formed.
Miners: Initial collapse with equities despite rising gold, followed by a violent rebound once equity markets stabilized.
Why volume spikes: Two-phase regime shift — first forced deleveraging overrides gold linkage, then re-alignment as the system transitions into a new equilibrium.

2016-01 → 2016-03 — Global growth scare → commodity & gold rebound

Macro / markets: Early-2016 global risk-off driven by an oil collapse (oil drops to some $26/barrel – lowest in a decade), China growth fears, and recession concerns; sentiment stabilized by March. Feds: in late 2015 raise rates to 0.5% first time since 2006 (akin to “emergency policy is about to end”)
Gold: Strong rally as investors sought safety and repriced lower real rates.
Miners: Sharp rebound as gold surged and balance-sheet fears eased. Both NEM and B enter 2016 deeply out of favor. Had spent years cutting costs, selling assets, and repairing balance sheets.
Why volume spikes: Sudden regime shift — from deflation panic to reflation relief — forced rapid repositioning in gold and mining equities.

These simple bullet points provide just some color to how high can the volumes go. As a reminder: the volumes here (triple scalar product) represent how different the returns were. Large volumes - the outliers we discuss – indicate situations where gold returns continued but NEM and B returns changed drastically; key is that these returns moved differently relative to each other.

RECAP: GEOMETRY = FRIEND OR FOE?

In this note we examined the relationship between gold and Newmont returns through a geometric lens, gradually expanding the dimensionality of analysis. Then we added Barrick returns and therefore examined even more nuanced interplay of gold and equities as well as time (regimes such as calm months vs. economic and market stress).

First came monthly gold–Newmont returns as joint movement vectors in two-dimensional space. Vector projections allowed decomposing each month’s movement into a gold-aligned component and an orthogonal component. This orthogonal residual is geometrically perpendicular to the gold direction by construction, statistically uncorrelated in aggregate, and economically interpretable as NEM-specific behavior (e.g., disposition of a mine, acquisition, or any other NEM-specific and gold-agnostic corporate and market factor). This construction reveals the geometric foundation of linear regression without invoking probabilistic assumptions.

Moving beyond individual months: many joint-return vectors simultaneously allow – via the maximized squared projections direction - showing that a small number of high-energy months dominate the long-run joint behavior of gold and Newmont (joint return-wise). Calm months are numerous but economically secondary; crisis periods define the dominant co-movement structure.

The cross product starts bridging Flatlandia to Spacelandia allowing to examine how joint return behavior changes across time. The area of the parallelogram formed by two monthly joint-movement vectors - or the resulting orthogonal vector magnitude - captures directional misalignment and scale across realizations. Rolling and global distributions of these areas reveal a strongly right-skewed structure: most months are synchronized, while rare episodes reflect regime breaks and stress. Calm months dominate in count; violent months dominate in impact. In a sense, the newly formed “z-axis” cross-product confirms the findings of the [purely 2D] squared projections.

Adding Barrick Mining price moves turns this into the 3D “Gold–Newmont–Barrick space.” Here, diversification and independence are no longer captured by areas but by volumes, measured via the scalar triple product of three joint-movement vectors. Rolling three-month volumes quantify whether the system behaves as effectively two-dimensional or explores genuinely three-dimensional dynamics. Periods of large volume correspond to shifts in the joint structure of returns rather than simple increases in volatility. Our findings here are consistent with those above (projections and cross-products):

The economic meaning of gold–mining equity (NEM an B) relationships is defined not by average behavior, but by rare, high-energy episodes in which co-movement geometry changes. Vector geometry provides a unified language to describe projection, residuals, regime shifts, and diversification in a way that is intuitive, rigorous, and directly interpretable for financial decision-making.

Perhaps this picture for the 24 years of the market from Visual Capitalist (link) provides an independent validation for our findings:

ANOTHER RECAP: “SO WHAT” REGARDING THE VECTORS AS ANALYTICAL TOOLS?

Throughout the analysis, it was becoming clearer to me that, on one hand, findings from the previous layer of complexity – e.g., projections and simple orthogonal vector – repeated with the next level of complexity. So, the question becomes, ‘Why go to another level of complexity then?” On the other hand, certain additional insights emerge with the growing complexity and increasing dimensionality of the analyses (from ‘Flatlandia’ to ‘Spacelandia’).

This table attempts to summarize the incremental value of the growing dimensionality: from “simple 2D” to “transitional 2D” (cross product and resulting orthogonal vector) to the “full 3D”:

Layer / Tool	Dimensional Regime	Mathematical Object	What It Measures (Plain English)	What It Adds Beyond Previous Layer	*Concrete Insight in This* Note**	Executive-Level “So What”
Vector Projection (starting point)	1D (within 2D space)		How much a month aligns with the main co-movement direction	Establishes baseline linear relationship	Most months weakly aligned; few dominate	“Most months don’t move the needle.”
Squared Projection	1D (within 2D space)		Energy contributed along that direction	Removes sign noise; highlights dominance	Tail months dominate total energy	“Risk contribution is extremely uneven over time.”
Orthogonal Component	2D (full plane)		How much of the move cannot be explained by the main relationship	Separates expected vs. unexpected behavior	Large deviations cluster in turbulent periods	“This is when the hedge breaks down.”
Cross Product (Area)	Bridge: 2D → 3D		Month-to-month instability in direction & magnitude	Introduces dynamics and curvature	Right-skewed: calm regimes, violent breaks	“Relationships don’t drift — they snap.”
Scalar Triple Product (Volume)	True 3D space		Whether movements require three independent dimensions	Tests incremental diversification	Large volumes occur only in crisis windows	“The third asset matters only under stress.”

What feels like increasing mathematical complexity may be a controlled expansion of dimensional freedom.

Earlier tools deliberately restrict the analysis to one direction inside a plane: is there a dominant relationship at all?
Orthogonal components then allow full 2D freedom: when does that relationship fail?
The cross product is the bridge—while still living in 2D, it produces a vector that points out of the plane, signaling instability and curvature over time.
Finally, the scalar triple product moves fully into 3D, asking the hardest question: do three assets truly span independent risk space, or are they effectively planar?

I expected the higher dimensionality tools to overturn some earlier results. But they kept confirming them. Perhaps the fact that all layers of complexity for all assets – gold, NEM and Barrick - converge on the same story is actually a sort of validation. Each added dimension removes a potential excuse: “it’s just linear,” “it’s just volatility,” “it’s just scale.” Remaining is a conclusion: risk, instability, and diversification all concentrate in rare, high-stress episodes. This is the insight from 40 years of gold, NEM and B returns.

SAP CodeJam Roadshow 2026 - Brazil edition 🇧🇷 (Kicking off in March and continuing in April)

2026-01-30T12:35:15.511000+01:00

Oi SAP Developers!

I've got some exciting news to share with you. The SAP CodeJam roadshow is coming back to Latin America! This time, we will do a special edition in Brazil. We will have many stops on the roadshow starting the 1st week of March, doing CodeJams as part of SAP Inside Tracks, organised by local community members, and then continuing in April. Also, we'll organise a couple of meet-ups as we've done in previous year. :-).

Keep an eye on this blog post as more events will be announced as part of the roadshow shortly

SAP CodeJam events and meetups part of the roadshow (Register Now!)

Below is a listing of the SAP CodeJam events and quedadas (meetups) on the roadshow schedule:

Dates	CodeJam topic	Location	Registration
2 Mar	Build AI services using the CAP and Generative AI Hub	Campinas, Brazil 🇧🇷	Link
3 Mar	Joule Studio: Create Joule Skills and Agents Without Coding	São Paulo, Brazil 🇧🇷 🇧🇷	Link
3 Mar	São Paulo meetup	São Paulo, Brazil 🇧🇷	Link
4 Mar	SAP Build: Create Event-Based Processes	São Paulo, Brazil 🇧🇷	Link
5 Mar	Getting started with Generative AI Hub on SAP AI Core	Rio de Janeiro, Brazil 🇧🇷	Link
13 Mar	Getting started with Generative AI Hub on SAP AI Core	Joinville, Brazil 🇧🇷	Link
14 Mar	SAP Inside Track - Joinville	Joinville, Brazil 🇧🇷	Link
20 Mar	Getting started with Generative AI Hub on SAP AI Core	Belo Horizonte, Brazil 🇧🇷	Link
21 Mar	SAP Inside Track - Belo Horizonte	Belo Horizonte, Brazil 🇧🇷	Link
6 Apr	Combine SAP CAP with SAP HANA Cloud to Create Full-Stack App	São Paulo, Brazil 🇧🇷	Link
7 Apr	ABAP AI: Capabilities in SAP Joule for Developers CodeJam	São Paulo, Brazil 🇧🇷	Link
8 Apr	ABAP AI: Capabilities in SAP Joule for Developers CodeJam	Londrina, Brazil 🇧🇷	Link
10 Apr	Getting started with Generative AI Hub on SAP AI Core	Curitiba, Brazil 🇧🇷	Link
10 Apr	SAP HANA Cloud for AI Applications: ML, Vectors, and Knowledge Graphs	Ribeirão Preto, Brazil 🇧🇷	Link
13 Apr	SAP HANA Cloud for AI Applications: ML, Vectors, and Knowledge Graphs	São Leopoldo, Brazil 🇧🇷	Link
14 Apr	Build code-based AI Agents on SAP BTP	São Leopoldo, Brazil 🇧🇷	Link
16 Apr	SAP HANA Cloud for AI Applications: ML, Vectors, and Knowledge Graphs	Recife, Brazil 🇧🇷	Link
17 Apr	Build code-based AI Agents on SAP BTP	Recife, Brazil 🇧🇷	Link

Make sure to register to secure your place. It is likely that the places available will go fast.

What if the CodeJam topics do not cover the SAP technology that you focus on? We've organised additional local meetups just to get together and have a chat. See you all somewhere in Brazil on the roadshow!

SAP HANA and ABAP Performance Tuning: A Guide to Caches and Buffers

2026-02-05T17:48:55.189000+01:00

Background

It is a common misconception that S/4HANA is inherently faster simply because it runs on SAP HANA. In reality, achieving optimal performance for complex calculations and joins requires the use of tuning objects. These repository objects allow developers to define technical settings that optimize runtime behavior independently of the underlying data models.
In the S/4HANA 2025 environment, these objects minimize the "distance" between application logic and data in two ways:

ABAP Tuning Objects buffer records in the application server’s shared memory to eliminate unnecessary data transport.
HANA Tuning Objects implement database-layer caches to significantly reduce CPU and thread utilization for intensive aggregations
The core purpose of buffering is to minimize database load, hence increasing the overall system throughput and decreasing CPU consumption on SAP HANA database. Buffering avoids the high cost of repeated data transport between the Application Server (AS) and the Database. By keeping a local copy of data in the AS layer, the system can fulfill requests without ever reaching out to the network or the DB disk.

Performance tuning is not just about raw speed for a single user; it is about system-wide efficiency. By offloading repetitive row-level reads to the application layer, you free up the HANA database to focus on what it does best: complex calculations and massive data processing.

Sequence of Data Access

Apart from code pushdown introduced with CDS views, it is important to understand that when data is requested using CDS views, below is the sequence of steps:

The Initial Request: System checks the local Entity Buffer. This is the ABAP Shared memory of the individual Application server instance. If data is not found then it is a cache miss and the ABAP SQL interface sends the query to SAP HANA database.
The Storage Phase: From SAP HANA DB, the data is placed into Shared Memory of current Application server automatically by ABAP SQL Interface
Subsequent Queries: For any requests henceforth, the ABAP SQL Engine acts as localized DB manager bypassing HANA DB entirely and reading data directly from ABAP Shared Memory

ABAP Tuning Objects

Our first choice of buffering should be entity buffering in ABAP Layer - it uses ABAP Shared Memory of the application server.

It is not enabled by default. The annotation @AbapCatalog.entityBuffer.definitionAllowed: true should be mentioned in CDS entity. Below are different buffer types available in ABAP layer:

View Entity Buffer: This buffer is meant for CDS View Entities and supports standard ABAP buffering types - Single, Generic and Full as well as DELEGATED
Table Entity Buffer: This buffer is meant for DDIC tables and was introduced in S/4HANA 2025 edition. Supports standard ABAP buffering types - Single, Generic and Full but DELEGATED is not supported
Propagated Buffer: This buffer is meant for CD View Entities and uses path expressions to process joins in the buffer. Pre-requisite of this buffer type is the data source of propagated fields must be Fully Buffered. It allows ABAP SQL engine to process joins locally on application server by using data already available in the buffer hence preventing round trip to HANA DB. This can be very effective for a complex DB join.

Scenarios

When primary goal is to avoid repeated data transport between AS ABAP and DB Server
Data that is rarely updated such as localized text
Joins can be processed locally on application server itself by utilizing data in the buffer

Implementation

Ensure annotation @AbapCatalog.entityBuffer.definitionAllowed: true exists in target CDS entity and define the buffer in ADT using below statements as applicable:

DEFINE VIEW / TABLE ENTITY BUFFER ON cds_entity
LAYER CORE
/ LOCALIZATION
/ INDUSTRY
/ PARTNER
/ CUSTOMER
TYPE SINGLE
/ {GENERIC NUMBER OF KEY ELEMENTS number}
/ FULL
/ DELEGATED| NONE

DEFINE VIEW / TABLE ENTITY BUFFER ON cds_entity
LAYER CORE
/ LOCALIZATION
/ INDUSTRY
/ PARTNER
/ CUSTOMER
TYPE SINGLE
/ {GENERIC NUMBER OF KEY ELEMENTS number}
/ FULL
/DELEGATED / NONE

PROPAGATE VIEW ENTITY BUFFER ON cds_entity
{
propagated_field1[,
propagated_field2][,
...]
}[;]

Monitoring & Maintenance

Buffering is automatically handled by ABAP SQL engine. Monitoring typically occurs through standard ABAP Shared Memory (SHMM).

HANA Tuning Objects

These objects are stored in memory of SAP HANA DB to save database resources and are oriented towards saving database resources such as memory and CPU consumption during heavy aggregations on massive tables. These are known as result cache used to improve performance by reusing previously queried data rather than reprocessing it from HANA Database everytime it is requested. They are defined in ABAP dictionary and implement technical settings directly on SAP HANA Database. Below are the types of result cache available in S/4HANA:

Static Result Cache: This caches results for the specific CDS Entity View for a user defined retention period and is refreshed once that period expires. Best suited for complex views, KPIs, quarterly calculations where slightly stale data is acceptable to maximize performance.
Dynamic Result Cache: This caches aggregated results for single-table SQL views. Best suited for heavy aggregation workloads on massive tables where real time data is required. It automatically updates using delta records when source table changes ensuring most recent results.

Scenarios

Heavy Aggregation Workloads such as SUM, COUNT or AVG on massiv tables like ACDOCA or CDPOS (Dynamic Result Cache)
Analytical scenarios such as KPIs for complex views or quarterly calculations (Static Result Cache)

Implementation

SAP HANA tuning objects can be created from ADT using below syntax:

DEFINE STATIC CACHE cache_name
ON view_entity_name
{ element_list }
[RETENTION retention_in_minutes]
[SEGREGATE CACHE DATA BY filter_cond]
[CREATION CONFIGURABLE DEFAULT {ON|OFF}];

DEFINE DYNAMIC CACHE cache_name
ON dbtab
{ projection_list }
[WHERE filter_cond]
[SEGREGATE CACHE DATA BY filter_cond]
[CREATION CONFIGURABLE DEFAULT {ON|OFF}];

Use tcode S_DBCACHE_CONFIG to manually toggle the "DB Status" and activate the cache.

Monitoring & Maintenence

Use DBACOCKPIT to monitor cache objects. The query M_DYNAMIC_RESULT_CACHE for real time hit rates and M_DYNAMIC_RESULT_CACHE_EXCLUSIONS to see views that failed to cache (e.g., due to 1GB size limits). For static caches use RESULT_CACHE. Use ALTER SYSTEM CLEAR DYNAMIC RESULT CACHE to globally remove all entries or ALTER SYSTEM REMOVE... for a specific cache ID.

Conclusion

Leveraging both ABAP and HANA tuning objects in S/4HANA 2025 provides a robust framework for optimizing system performance while maintaining data integrity. The Dynamic Result Cache is essential for high-performance, real-time scenarios—such as aggregating the Universal Journal (ACDOCA) - because it guarantees transactionally consistent, non-stale results. By defining these as transportable ABAP Dictionary objects and managing them through tools like S_DBCACHE_CONFIG, you can significantly reduce CPU consumption and database response times across your landscape. While Dynamic Caches are ideal for real-time accuracy, Static Caches remain a strategic choice for complex views where periodic refreshes meet business needs.

Reimagining Utility Transformation: Clean Core Principles Powered by SAP BTP

2026-02-06T07:51:30.744000+01:00

Introduction

Across the utility industry, one message appears in every transformation discussion: “Keep the core clean.” The guidance is sound, especially for organizations preparing for S/4HANA. But inside SAP IS‑U—where regulatory complexity, legacy billing logic, and decades of Z‑programs coexist—this principle often feels contradictory.

Utilities must modernize rapidly while protecting the stability of their revenue engine. This creates a familiar tension: innovation requires speed, but the core requires caution.

This post explores why that tension exists, how SAP BTP resolves it, and how utilities can operationalize a Clean Core strategy without compromising business continuity.

Main Body

1. The Customization Cage: How Utilities Got Here

For many years, utilities solved business needs by customizing the ERP core:

Custom ABAP for tariffs
Modified standard tables for regulatory fields
Embedded workflows inside IS‑U
Enhancements tightly coupled to billing and device management

These decisions were practical at the time—but over decades, they created a Rigid Core that is difficult to upgrade, expensive to test, and slow to evolve.

Resulting challenges:

High upgrade risk
Long regression cycles
Slow innovation
Technical debt that compounds every year

Your first diagram captures this reality perfectly.

Diagram 1 — The Customization Cage

2. Clean Core + SAP BTP: The Agility Layer Utilities Needed

A Clean Core strategy is not about reducing capability—it’s about relocating capability.

SAP Business Technology Platform (BTP) provides the architectural separation utilities have needed for years:

S/4HANA Core → Stable, standardized, upgrade-friendly
SAP BTP → Custom logic, workflows, APIs, event-driven processes

This separation transforms the ERP into a system of record, while BTP becomes the system of innovation.

Key benefits:

Faster delivery cycles
Reduced regression testing
Lower upgrade effort
Event-driven operations
Extensibility without core modification

3. A Practical Framework for Utility Clean Core Adoption

SAP Community readers expect actionable, practitioner-focused guidance. Here is a structured approach utilities can follow.

Step 1: Start With a Core Assessment

Identify:

Business-critical customizations
Redundant or obsolete logic
Enhancements blocking upgrade cycles
High-change areas suitable for BTP

This reframes Clean Core as risk reduction, not cleanup.

Step 2: Move High-Variability Logic to BTP First

Ideal candidates include:

Rate and tariff changes
Regulatory reporting
Credit & collections workflows
Meter-to-cash orchestration
BPEM automation

These areas generate the most upgrade friction—and deliver the fastest BTP wins.

Step 3: Use SAP Event Mesh to Break the Batch Mindset

Utilities can begin shifting toward real-time operations by triggering events for:

Move-in / move-out
Billing determinants
Meter read exceptions
Payment events
Outage notifications

This enables a hybrid model: batch where necessary, real-time where possible.

Step 4: Establish Governance That Protects the Core

No custom code in S/4 unless SAP mandates it
BTP-first evaluation for all new logic
Standard APIs and events as default patterns
Quarterly architecture reviews to prevent “core creep”

Governance is the long-term safeguard of Clean Core.

Step 5: Treat BTP as a Business Platform

Executives respond when BTP is positioned as:

A revenue protection tool
A regulatory accelerator
A customer experience enabler
A technical debt reduction mechanism

Step 6: Build a 24‑Month Roadmap

A practical roadmap includes:

Phase 1: Core assessment + quick wins
Phase 2: Event-driven architecture rollout
Phase 3: Predictive and AI-driven use cases
Phase 4: Full Clean Core enforcement + S/4 readiness

This provides clarity, sequencing, and measurable ROI.

4. The Modern Utility Innovation Stack

Your second diagram illustrates the future-state architecture:

A stable S/4HANA core
A flexible BTP layer
A connected utility ecosystem

Diagram 2 — The Utility Innovation Stack

Conclusion

A Clean Core is not a limitation—it is a strategic advantage.

Utilities preparing for S/4HANA should shift the conversation from:

“How do we migrate everything we built?” to “How do we protect the core and modernize the business at the same time?”

SAP BTP provides the answer:

Keep the core stable
Move innovation to the agility layer
Adopt event-driven operations
Reduce technical debt
Build a future-ready architecture

Utilities that embrace this model will be better positioned to innovate, comply, and scale in the decade ahead.

Welcome to the Technology Learning Group!

2026-02-09T10:28:41.705000+01:00

We’re excited to welcome you to our brand-new Technology Learning group – your go-to space for learning SAP technologies and growing your skills together with a global community of learners.

This is where SAP technology enthusiasts come together to explore topics such as SAP HANA, ABAP, authorizations in SAP S/4HANA, SAP Fiori, and SAP Cloud ALM (CALM). Connect with SAP experts, exchange ideas with fellow learners, and stay inspired on your learning journey.

As a member of the Technology Learning group, you’ll be the first to hear about new courses, course updates, live learning sessions, and certification news. We’ll keep you informed and help you stay one step ahead as SAP technologies continue to evolve.

This community is all about learning. It complements—rather than replaces—the existing SAP Community groups that focus on product-specific discussions and troubleshooting. For deep dives into product features or technical issues, those groups remain the best place to connect with developers and consultants.

Here, the focus is on learning content: courses, learning journeys, certifications, and live sessions. It’s a welcoming and supportive space where no question is too small. Everyone here is learning—just like you—so feel free to ask, share, and join the conversation.

We’re here to support you every step of the way, whether you’re getting started with a new topic, progressing through your learning journey, or preparing for certification. Watch out for expert blog posts, tips, and guidance designed to help you succeed.

Join us and take the next step in your SAP Technology Learning journey

AI Is Transforming Sales Order Processing in SAP

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

Challenges in Manual Sales Order Processing

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

Ensuring timely delivery and customer satisfaction requires high workforce effort

AI & Machine Learning Workflow

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

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

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

Key Benefits

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

Machine Learning for Sold-to / Ship-to Resolution

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

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

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

Integration with SAP

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

Conclusion

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

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

Everything about SAP migration and Palantir : A basis POV

2026-02-12T17:18:56.953000+01:00

In this blog, I discuss the Palantir platform and its value proposition in the context of SAP landscapes and SAP modernization programs.

Disclaimer: The information shared in this blog is derived from publicly available sources. The views expressed are based solely on my personal understanding and interpretation and should not be considered official guidance, implementation instructions, or vendor-approved documentation.

1.Understanding Palantir

Palantir is an enterprise platform that helps organizations use their data to run real operations and make decisions. It is not just about reporting or creating dashboards. It is ment to help users take action, track decisions and measure imapact using trusted data.

The core parts of Palantir are :

1. Data layer:

This is where Palantir stores data as datasets (like very large Excel tables) and every data has lineage. That is , Palantir always remembers where data came from, what transformations were applied, what dataset produced what dataset.

2. Object layer (Ontology):

Source:https://blog.palantir.com/how-anyone-can-integrate-sap-data-in-hours-17f23d0bd2e8

In this layer, Palantir converts datasets into:

Objects (Customer, Material, Asset, Employee, Purchase Order)
Links (Customer to Orders, Vendor to Deliveries, Asset to Maintenance)
Actions (approve, update, assign, escalate, create)

This Ontology creates a digital model of the organization, thus enabling business users to understand the data in business context rather than just a raw tables.

The typical use case of Palantir involves time-bound projects that support decision-making processes, such as inventory optimization. alert monitoring and resolution, sales territory planning, supply chain risk management.

2.Palantir architecture

Palantir’s standard architecture is built on three integrated platforms:

1. Foundry

2. AIP

3. Apollo

All these together are positioned as an Enterprise Operating System.

Foundry is the core data operations layer for data management, transformation logic, Ontology development, analytics, and workflow building.
AIP (AI Platform) adds the generative AI layer, enabling secure access to LLMs and providing tooling for agents, automations, AI apps, and governance through evaluation frameworks. (For more information on AIP, refer to URL https://www.palantir.com/docs/foundry/architecture-center/aip-architecture/ )
Apollo runs underneath as the continuous delivery and infrastructure orchestration platform, enabling large-scale, zero-downtime upgrades across the entire service mesh.

Conceptually, Palantir describes AIP and Foundry as a set of nine capability areas spanning the Ontology system, data and workflow services, analytics, automations, and product delivery. These capabilities are supported by shared foundational components such as storage, compute, networking, security, governance, and workspace, all powered by Apollo. The combined stack is positioned as the backbone for operational, AI-enabled applications across industries like healthcare, aviation, utilities, and defense.

3. How to access the Palantir platform

Refer to below documentation from Palantir site to access the platform

https://www.palantir.com/docs/foundry/getting-started/login/

4.Palantir and data connectivity

Foundry positions itself as more than a standard ETL or ELT tool. It is designed as an enterprise-grade data integration backbone that reduces the long-term cost of integration by combining connectivity, transformation, pipeline management, and governance into a single operating layer. The goal is to take data from complex environments and continuously deliver curated, operationally trusted datasets, not just move data into storage. A key part of this is Data Connection which is foundry’s application for synchronizing data from external systems into Foundry for use across the data integration, modeling, and Ontology layers. Data Connection also supports outbound connectivity, enabling writeback to external systems via exports and Webhooks.

At the connectivity layer, Foundry supports structured, semi-structured, and unstructured sources, and multiple ingestion patterns such as batch, micro-batch, streaming, and CDC. A “source” in Foundry represents a connection to an external system such as Postgres, S3, Linux file systems, SAP, or REST APIs. Connectivity can be established directly when the source is reachable from Foundry, or through a Foundry agent when sources are hosted in a separate private network such as on-prem. Agents are downloadable programs installed inside the customer network and managed from Data Connection. They provide controlled network access to private systems and securely ingest data into Foundry using restricted tokens. Once a source is created, teams configure syncs (most commonly batch syncs) through the Data Connection UI, schedule runs, and write the results into versioned Foundry datasets with full lineage and auditing.

Beyond ingestion, for transformation, Foundry adds production-grade pipeline management through tools like Pipeline Builder, which provides point-and-click pipeline creation, Git-style change management, scheduling, and health checks so only compliant datasets reach production. Data quality and governance are treated as first-class features through role-based and marking-based controls, end-to-end lineage, and built-in diagnostics when issues occur. Finally, Data Connection supports outbound patterns such as dataset exports, outbound Webhooks for triggering external workflows from Foundry applications, and inbound event listeners (beta) for low-latency event feeds from systems that cannot directly integrate with standard Foundry APIs. This combination makes Foundry a bidirectional integration layer that not only brings data in, but also operationalizes insights by pushing results back into the enterprise landscape.

5.Palantir's HyperAuto and SAP

Palantir also extends integration beyond basic syncing through HyperAuto, which programmatically generates pipelines for ERP and CRM data, rapidly normalizing and harmonizing it into curated datasets that can feed the Ontology and power downstream analytics, workflows, and AI use cases. HyperAuto is Palantir’s source-to-value automation layer designed to accelerate how enterprise data is extracted, standardized, and made usable in Foundry and the Ontology. HyperAuto V1 (also known as SDDI or Bellhop) was the first generation of this capability and is still supported for several source types such as Salesforce, Oracle NetSuite, and SAP, although SAP customers are strongly advised to use HyperAuto V2, which is specifically released and optimized for SAP.

Architecturally, HyperAuto automates the journey from raw source systems to curated, Ontology-ready data using three building blocks: secure connectors for high-scale data transfer, guided source exploration for rapid discovery and bulk sync creation, and automatic pipeline generation that transforms raw extracts into curated Foundry datasets and Ontology object types. HyperAuto analyzes ERP metadata to generate robust, extensible pipelines that denormalize and reconstruct business objects through automatically created transformations, so that the teams do not need deep expertise in proprietary ERP schemas. The generated pipelines typically include source-specific preprocessing, standardized cleaning libraries, core enrichment steps such as renaming and de-duplication, and derived elements like join tables and time-series datasets. HyperAuto can also generate the Ontology automatically, enabling users to immediately search, analyze, and build operational applications on top of SAP and non-SAP data.

In addition, HyperAuto can publish the integrated and curated data to external cloud platforms such as Google BigQuery, Snowflake, AWS Redshift, and others, or push it into the Foundry Ontology in just a few clicks, where data is organized into easy-to-understand semantic objects so business users can self-serve and make operational decisions.

For more information refer to URL https://www.palantir.com/docs/foundry/hyperauto/v1-getting-started/

6.Connecting SAP and Palantir

Palantir uses the Palantir Foundry Connector 2.0 for SAP Applications, which is:

An SAP-certified ABAP add-on
Installed in SAP using SAINT
Exposes SAP data through HTTPS (SICF services)
Works via the SAP application layer (not direct DB access

Foundry defines the extraction logic (tables, filters, schedules), and the sync jobs are executed by Foundry’s Data Connection services. SAP security remains SAP security, because Foundry calls SAP using an SAP user with SAP authorizations and is DB agnostic as reads happens from SAP application layer rather than DB layer.

Supported SAP extraction objects include:

SAP application tables
CDS views
BW InfoProviders / BEx queries
Extractors (ODP-enabled)
SLT (ODQ queues)
Function modules/BAPIs

Installation steps in SAP (At high level):

Components:

SAP Add-on (ABAP) installed using SAINT
Foundry Agent installed in customer network and managed via Foundry Data Connection

SAP Prerequisites:

The source must be SAP NW 7.4 SP5 or 7.5 systems. If the source is below 7.4 SP5 a remote agent pattern required.

Generally supported deployment patterns for data extraction are:

Direct to SAP ECC/S/4/BW
Via SAP SLT Replication Server (ODQ queues / CDC)
Remote via Gateway (RFC based)

At SAP level:

For Palantir add-on installation follow below steps:

Login to client 000
Run SAINT
Load package: FOUNDRY-SAPCONN-INST-SP00SPXX.SAR
Select components: PALANTIR and PALCONN
Execute install (dialog for preparation, background for remaining phases)
Run Post installation wizard through t-code /n/PALANTIR/POST_INST . It will automatically below tasks.

Activate SICF services
Generate roles and assign to Foundry SAP user
Maintain default parameters (/n/PALANTIR/PARAM)
Check ICM settings and generate test URLs
Health checks (connector, authorization, SLT, RFC, jobs)

At Palantir Foundry level:

In Foundry Data Connection, create SAP source using YAML:

type: magritte-sap-source
url: https://<host>:<port>/sap/palantir
usernamePassword: <username>:{{password}}

Followed by this, sync between source and Foundry must be configured. Create syncs for required object types (tables/CDS/BEx/SLT/functions). Example:

type: magritte-sap-source-adapter
sapType: tcode
obj: ZTEST_ALV

(For more information please refer https://www.palantir.com/docs/foundry/sap/install-sap)

7.Sample demo screen shots of integrating SAP data with Palantir's HyperAuto to extract SAP ECC data into a S3 bucket

Source: https://blog.palantir.com/how-anyone-can-integrate-sap-data-in-hours-17f23d0bd2e8

NOTE: I have only provided the screen shots with high level explanation so that the readers could get a look and feel of how SAP data gets extracted into Palantir. I would strongly recommend the interested readers to read it in depth at above blog for complete understanding

Below are the high-level steps involved:

The upcoming steps and screenshots demonstrates how HyperAuto accelerates SAP integration by allowing us to explore SAP tables visually, select only what we need, and automatically generate ingestion syncs and transformation pipelines. In this example, a data engineer at a manufacturing firm builds a supply chain view by ingesting SAP data, cleaning and integrating it in Foundry, and exporting the curated datasets to an S3 bucket.

Connect SAP to Foundry using the official SAP-certified connector and ensure the SAP source is available in the Data Connection app.

Step 1-2:

a. Access the SAP source in Data Connection: In Data Connection, locate your SAP source (typically listed with type magritte-sap-source) and open it.

b. Explore SAP data in HyperAuto: Launch Explore and create syncs. HyperAuto reads SAP tables on-demand (including custom Z tables) and provides a “shopping cart” style selection flow. This approach helps avoid unnecessary heavy queries and reduces risk of disruption to the ERP system.

Step 3:

a. Start with a pre-packaged workflow: From the Workflows tab, select a pre-built workflow such as Supply Chain Disruption. HyperAuto automatically adds the required SAP tables and relationships needed for the workflow and prepares logic for the use case.

b. Add extra tables (customization): Extend the workflow by selecting additional tables. Example: add MARM (Units of Measure for Material) from the Modules tab.

Step 4-5:

a:Discover relationships without knowing SAP schema: HyperAuto helps explore linked tables visually. It also translates technical SAP table/field names into human-readable descriptions (like an automatic data dictionary). Use table relations to discover and add missing dependencies (example: add the Clients table related to Material Descriptions).

b: Configure syncs: Review the selected tables and configure ingestion settings. Choose ingestion strategies such as:

Snapshot (full extract)
Append / incremental (delta ingestion)

Step 6-10:

a.Then confirm by selecting Ingest & Integrate Data → Create syncs.

b.Auto-generate pipeline code (PySpark): HyperAuto generates:

ingestion sync configuration
transformation pipelines
PySpark code for cleaning and integration

All code is version-controlled via Git and created through a pull request workflow, enabling review and controlled deployment.

Step 12-15:

a.Run raw ingests: Using the SDDI/HyperAuto flow, run the syncs to ingest raw SAP data and supporting metadata.

b.Review pipeline lineage: Open the pipeline graph in Data Lineage to visualize dependencies between raw datasets and transformed outputs.

Step 16-18:

a.Build the cleaning and integration pipeline: Select all datasets and trigger a build. HyperAuto runs the generated transformations to produce clean, denormalized, analytics-ready datasets.

b.Validate the final datasets:Preview the cleaned datasets and review the transformation logic that produced them.

Step 19-21:

a.Create an S3 data connection source

In Data Connection, create a new S3 source, select an agent for the export, and configure bucket details. Save it in a project folder with correct permission.

Step 22-29:

a.Configure an export task: Create a Data Connection Task of type export-s3-task, define the output path, and add the finalized datasets as inputs. Configure outputs for tracking export results.

b.Run the export (or schedule it):Build the export task to push curated datasets to S3. This can later be automated on a schedule or triggered by upstream dataset updates.

At the end of the workflow, we will have:

SAP data ingested and integrated using HyperAuto
Cleaned, denormalized datasets ready for analytics
Data exported to S3 (or optionally used directly in Foundry tools)

This creates an extensible data foundation that can be enriched with other enterprise systems and advanced data types (time-series, geospatial, etc.) for broader operational intelligence.

8.Palantir’s SAP migration narrative

Palantir positions SAP migrations (especially ECC to S/4HANA) as slow and expensive largely because teams work in silos. Extraction, transformation, validation, business SMEs, and compliance often operate independently. When validation fails, organizations can lose weeks doing “data archaeology” to identify root causes and coordinate fixes across teams.

Palantir’s claim is that AIP shifts migration from a linear, phase-by-phase process into a context-connected, end-to-end workflow where data understanding, mapping, transformation, and validation are linked. Validation becomes continuous rather than a final gate. SMEs can describe fixes in plain language, and AI propagates those corrections through the pipeline quickly. This is often explained using the “octopus” analogy, meaning multiple specialized AI capabilities coordinated by a single contextual brain that understands legacy structures, target requirements, business rules, and compliance.

It claims to complete an ECC to S/4 HANA conversion within 2 weeks of time.

9.Palantir’s position on testing

In practical terms, Palantir claims that when testing fails, we do not lose weeks coordinating across teams. The platform preserves end-to-end context such as source, mapping logic, transformation, business rule, and target expectation. This helps identify the root cause faster. Fixes can then be applied by SMEs and automatically propagated through the pipeline.

Palantir’s testing model is central to its positioning:

Testing is not a separate phase at the end.
Validation is continuous and embedded throughout the migration pipeline.
Data quality, mapping correctness, and compliance checks update continuously as transformations run.

10.My point of view on SAP migration and Palantir usage:

Based on my understanding, I believe Palantir might be of use for selective data migration for SAP environment to certain extent than for typical brownfield.

a. Why this aligns more with SDT than brownfield

Palantir's strengths are largely aligned to a Selective Data Transition (SDT) or data transformation-led migration model, where complexity is dominated by:

data harmonization
mapping rules
transformation logic
repeated reconciliation and validation cycles

In a true brownfield conversion, the core work is fundamentally different. The focus is on:

system conversion using SUM/DMO
technical readiness and remediation
custom code adaptation
integration compatibility
downtime optimization
controlled cutover execution

Since brownfield conversions typically do not involve large-scale remapping, consolidation, or business-unit redefinition of data, Palantir’s key value propositions (continuous transformation, SME-driven mapping, and AI-based validation loops) are not the primary effort drivers.

b. Where Palantir could be strongest

Palantir’s value proposition could becomes far more credible in SDT scenarios, where organizations are not just converting ECC technically but actively reshaping their data, organizational structures, and business processes while moving to S/4HANA.

In these programs, migration is not a single system conversion event. It is an extended transformation journey where enterprises often:

run legacy and target environments in parallel
migrate in waves
consolidate business units
remap master data
continuously validate outcomes

In this context, Palantir’s narrative around contextual awareness, continuous validation, and SME-driven rule definition aligns with real SDT challenges.

c. Summary

Palantir is a non-SAP platform (Foundry and AIP) focused on integration, semantic modeling (Ontology), analytics, and AI-driven operational workflows.
It prepares S/4-ready datasets outside SAP using governed pipelines for mapping, transformation, and continuous validation.
It is a DB agnostic tool as the data gets extracted / read from SAP application layer rather than from the underlying DB.
It is not a replacement for SAP-native brownfield conversion tooling like SUM/DMO.
SUM DMO brownfield conversions are much simpler and straightforward .
Palantir needs relatively deeper functional knowledge when compared to assisted selective data migration using SNP or other similar tools.
The often-cited claim of completing a migration in two weeks typically does not represent the full end-to-end SAP migration timeline. In reality, a standard SAP migration (Bluefield or Brownfield) following the SAP Activate methodology includes several critical phases such as unit testing, functional testing, system integration testing (SIT), mock runs, and cutover rehearsals, all of which significantly extend the overall timeline.
Palantir is an intelligent platform for data integration, analytics, and AI-driven decision support, rather than a typical SAP migration tool .
It can significantly accelerate SDT or bluefield-style (to certain extent) programs by:

reducing discovery time
enabling AI-assisted mapping
minimizing reconciliation cycles through continuous, context-aware testing

11. Sample use cases Palantir highlights

Palantir also positions its architecture as delivering value beyond migration by enabling enterprises to build operational applications mid-stream. For example, a customer returns processing app can be built during migration with Palantir with below steps:

It pulls customer data from ECC.
It enriches it with intelligence from other integrated systems.
It writes validated transactions into S/4HANA.
This is coordinated through Palantir’s unified data layer (Ontology).

Palantir also highlights the flexibility of deploying AI in ways that augment human expertise rather than replacing it, with appropriate levels of automation based on task complexity and risk tolerance. For example, with Palantir AIP a procurement lead could type, “for New London products, swap overseas suppliers for the highest-volume domestic alternative before S/4 upload.” The pipeline reexecutes, validation metrics update, and the change is implemented without filing a ticket, scheduling a sprint, or involving external consultants.

This supports the idea of migration as business continuity plus continuous improvement rather than a disruptive cutover, and again fits more naturally with SDT than pure brownfield conversion.

12.Relationship between Palantir and SAP Business Data Cloud (BDC)

Palantir and SAP Business Data Cloud (BDC) are connected through a strategic partnership intended to combine SAP’s governed, zero-copy business data foundation with Palantir Foundry’s Ontology and AIP.

The joint positioning is:

SAP BDC provides a trusted SAP semantic layer and harmonized data products.
Palantir extends this into an enterprise-wide ontology that fuses SAP and non-SAP data.
Together they enable AI-driven operational intelligence, simulation, and execution.

13. Palantir and archive data access

Palantir can support archive data access by acting as a unified governed layer that pulls data from SAP archives and legacy sources and exposes it in a searchable, analytics-ready way. This is useful for reporting, audit, and compliance after ECC decommissioning.

However:

Palantir does not replace SAP’s archiving mechanism itself.
The value lies in consuming archived and legacy data through connectors, blending it with non-SAP sources, and organizing it in the Ontology so users can query it like live business entities.

Hope you enjoyed reading!

Do not forget to click on LIKE if you enjoyed this blog!

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

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

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

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

Ready to submit your proposal? Here is how:

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

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

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

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

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

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

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

- SAP HANA HotSpots

- Mastering HANA Performance

- Database Analysis Using the SAP HANA Cloud Knowledge Graph Engine

- How to optimize the SAP HANA Memory Sizing Predictions

5: Select your Session Type based on:

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

The REMARKS FIELD is located just below the Description section:

6: Tell us about yourself!

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

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

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

MAKE SURE YOU HAVE SUBMITED YOUR PROPOSAL:

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

IMPORTANT INFORMATION:

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

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

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

Cheers,

HANA Tech Con Team

Understanding SAP HANA High Availability - Technical Scope, Mechanisms, and Design Boundaries

2026-02-15T18:00:00.016000+01:00

Introduction
SAP HANA provides a set of explicitly documented mechanisms to support high availability (HA) in productive landscapes. These mechanisms are designed to minimize unplanned downtime, enable fast continuation of operations, and preserve transactional consistency when specific failure types occur.

High availability in SAP HANA is not a single feature. It is an architecture composed of multiple building blocks, each with a clearly documented technical objective, scope, and boundary. These building blocks are described across the SAP HANA Administration Guide and related SAP Help Portal documentation.

This article consolidates SAP-documented SAP HANA high-availability mechanisms into a single technical view.
Its purpose is to make scope, interaction, and design boundaries explicit, enabling technically sound architecture design, realistic availability expectations, and precise discussions.

All statements are derived from official SAP documentation.

1. High Availability in SAP HANA - Technical Definition
From a technical perspective, high availability in SAP HANA focuses on:

minimizing unplanned downtime
enabling fast system continuation after certain failure types
preserving transactional consistency during failover or takeover

High availability is explicitly distinct from:

backup and recovery, which restore data to a previous state
disaster recovery, which addresses site-level or regional failures

This separation of objectives is consistently reflected in SAP HANA documentation and tooling.

Key boundary
High availability mechanisms maintain continuity of operation, not historical restore points.

2. SAP HANA High Availability Building Blocks
SAP HANA high availability is achieved by combining several documented mechanisms:

Host Auto-Failover
SAP HANA System Replication
Scale-Up and Scale-Out topologies
SAP-supported cluster frameworks on certified operating systems (for example, Pacemaker)

Each mechanism addresses specific failure classes and operates within a defined technical scope. No single mechanism covers all failure scenarios.

3. Host Auto-Failover - Technical Scope and Boundaries
3.1 Purpose and Mechanism
Host Auto-Failover is designed to handle host-level failures within a SAP HANA landscape.
In supported configurations:

a standby host is configured
SAP HANA detects a host failure
database services are automatically reassigned to the standby host

This reassignment is performed by SAP HANA itself based on internal monitoring and configuration.

SAP Help Portal reference
SAP HANA Host Auto-Failover

3.2 Technical Objective
Host Auto-Failover focuses on:

host failure detection
service reassignment
automatic continuation of operations

It does not:

provide historical restore points
protect against logical data errors
replace backup or recovery mechanisms

Key boundary
Host Auto-Failover preserves service execution, not data history.

4. SAP HANA System Replication in the HA Context
4.1 Technical Role
SAP HANA System Replication (SR) is a core building block for high availability and disaster tolerance scenarios.
In the HA context, SR:

continuously transfers data changes from a primary system to a secondary system
enables fast takeover in case of primary system failure
preserves transactional consistency at takeover time

SAP Help Portal reference
SAP HANA System Replication - Overview

4.2 Replication Modes and Availability Behavior
SAP HANA System Replication supports different replication modes, such as synchronous and asynchronous replication.
From a high-availability perspective:

the replication mode defines when changes are acknowledged
the secondary system reflects the current state of the primary system

Logical changes, deletions, or corruptions on the primary system are replicated as part of normal operation.
This behavior is inherent to replication and aligns with the documented objective of SR as an availability mechanism.

SAP Help Portal reference
SAP HANA System Replication - Replication Modes

Key boundary
System replication maintains current state, not historical restore points.

5. Cluster Management and Pacemaker – Technical Role
5.1 Purpose of Cluster Frameworks
In supported Linux-based SAP HANA environments, cluster frameworks such as Pacemaker are used to orchestrate:

system and service monitoring
failover and takeover actions
role coordination between primary and secondary systems

Pacemaker does not replace SAP HANA availability mechanisms.
It coordinates and automates actions around them.

SAP HANA System Replication with Cluster Management (Pacemaker)
(Implementation is covered by OS-vendor specific best-practice guides, not by a single SAP HANA Platform help page.)

5.2 Design Boundary
From a technical perspective:

Pacemaker does not replicate data
Pacemaker does not provide restore points
Pacemaker does not replace SAP HANA logic

It acts as an orchestration layer for documented HA mechanisms.

6. Failure Classes and HA Coverage
SAP HANA high-availability mechanisms address specific failure classes:

Host failures
handled by Host Auto-Failover and cluster-managed restarts
Primary system failures
handled by system replication and takeover
Service-level failures
handled by internal SAP HANA restart logic and cluster coordination

Coverage depends on:

architecture
topology (scale-up vs. scale-out)
configuration

No single mechanism covers all failure types.

7. High Availability vs. Recovery and Disaster Recovery
From a technical standpoint:

High availability minimizes downtime
Backup and recovery restore data to a previous state
Disaster recovery handles site-level failure domains

Although system replication may appear in both HA and DR designs, objectives, assumptions, and validation criteria differ.

High availability focuses on:

continuity
fast takeover
minimal disruption

Recovery and DR focus on:

reconstruction
historical restore points
controlled recovery after broader failures

8. Design Boundaries and Architectural Implications
From an architecture perspective:

high availability is achieved through combination, not a single feature
each HA mechanism has explicit limits
realistic availability expectations require alignment between:
- failure scenarios
- documented mechanism scope
- operational readiness

Understanding these boundaries is essential for technically sound SAP HANA availability design.

Summary
SAP HANA provides a comprehensive, well-documented set of high-availability mechanisms.

High availability is not defined by a single feature, but by the interaction of multiple documented components, each addressing specific failure scenarios within defined technical boundaries.

By understanding the scope, mechanisms, and limits of Host Auto-Failover, System Replication, and cluster-based coordination, SAP HANA landscapes can be designed with clear, realistic availability expectations.

Flexible Workflow: Dynamically control workflow steps based on custom condition

2026-02-16T08:11:58.421000+01:00

Hello Everyone!!!

In this blog, I will try to explain how we can dynamically control steps of a particular flexible workflow based on certain condition. We can also control the triggering of a flexible workflow dynamically based on start condition, if multiple active flexible workflows are configured. So there are two options:

Control/skip steps (approval level) of a particular flexible workflow.
Control triggering of flexible workflow based on start condition if multiple workflows are active for same business process.

Requirement: Before we start, lets understand our particular business requirement . For demonstration, SES flexible workflow WS00800321 will be used. In this requirement, lean SES can be created in two ways in S4.

Through custom code written in BADI ARBCIG_ADVANCE_SHIPMENT_NOTICE (method: IF_ARBCIG_ADVANCE_SHIP_NOTICE~POST_PROCESSING) when Ariba sends shipment notice.
User can manually create Lean SES using standard Fiori App "Manage Service Entry Sheet" .

For both the scenarios, WS00800321 workflow will be triggered when lean SES is created in the system. However, the SES created from Ariba will be having two levels of approver (Project owner and Cost Center Director) but manually created one will be having only one level (Cost Center Director). So for SES created through ARIBA flow, it has an extra approval step at 1st Level.

In system, there is only one active flexible workflow for SES configured for service entry sheet. Let's see how we can skip the 1st level (Project Owner) when SES is manually created through Fiori app and directly go to Cost Center Director for approval.

Code: To achieve this, we have to implement two BADIs.

SWF_WORKFLOW_CONDITION_DEF : Define custom pre-condition / step condition
SWF_WORKFLOW_CONDITION_EVAL.: Evaluate pre-condition / step condition and take decision.

Both the BADIs are filter dependent and we need to maintain the WF number as SCENARIO_ID. Here the SES flexible workflow WS00800321 has been maintained.

in GET_CONDITION method of *DEF BADI, write the below code. The ID is a unique number assigned to the name which will be appearing in the dropdown list when configuring flexible workflow. Please refer below screenshots from flexible workflow configuration.

    APPEND VALUE #( id = '1' subject = 'BADI: Lean SES Creator (Approver Skip)'
        type = if_swf_flex_ifs_condition_def=>cs_condtype-start_step ) TO ct_condition.

    APPEND VALUE #( id = '1' name = 'BADI: Lean SES Creator (Approver Skip)'
      xsd_type = if_swf_flex_ifs_condition_def=>cs_xstype-string
      mandatory = abap_true ) TO ct_parameter.

Similarly, we need to maintain the SCENARIO_ID for *EVAL BADI also.

In method EVALUATE_CONDITION, write below code to compare the values maintained for the parameter in flexible workflow. If the creator's user ID is ARIBA_INT (Ariba user id in S4 system), there will be two level approval process for SES workflow.

    CASE is_sap_object_node_type-sont.
      WHEN 'PurchaseRequisition'.
        banfn = is_sap_object_node_type-sont_key_part_1.
      WHEN 'PurchaseOrder'.
        ebeln = is_sap_object_node_type-sont_key_part_1.
      WHEN 'ServiceEntrySheet'. 
*&&-- Get the Service Entry Sheet number                          
        lv_ses = is_sap_object_node_type-sont_key_part_1.   
      WHEN OTHERS.
    ENDCASE.

*&&- Reading the value maintained in the parameter in flexible workflow.
DATA(st_parameter_value) =  VALUE #( it_parameter_value[ name = 'BADI: Lean SES Creator (Approver Skip)' ] OPTIONAL ).

CASE is_sap_object_node_type-sont.
      WHEN 'PurchaseRequisition'.
      WHEN 'PurchaseOrder'.
      WHEN 'ServiceEntrySheet'.
                CASE st_parameter_value-name.
          WHEN 'BADI: Lean SES Creator (Approver Skip)'.

        SELECT SINGLE crea_uname
              FROM mmpur_ses_header
          INTO (lv_ses_creator)    " Creator of SES
          WHERE serviceentrysheet = _ses.
        IF sy-subrc = 0.
          CASE lv_ses_creator.
            WHEN st_parameter_value-value.
*&&- 1st level approver (step) will be triggered if the condition satisfy.
              cv_is_true = abap_true.
            WHEN OTHERS.
*&&-- Skip the 1st level approver if SES is manually created(Creator other than ARIBA).
              cv_is_true = abap_false.
          ENDCASE.
        ENDIF.       
      WHEN OTHERS.
ENDCASE.

Let's see where we have to use this custom condition and value in SES flexible workflow Fiori app: Manage Workflows for Service Entry Sheets

The newly added parameter "BADI: Lean SES Creator (Approver Skip) " and its value "ARIBA_INT" should be maintained at step level of the workflow. The parameter option will be coming in dropdown when configuring steps.

If the requirement was to trigger different workflow for SES based on start condition, we would have selected the option here instead of steps. In that case first workflow would have 2 steps configured (for ARIBA created SES) and second workflow would have 1 step configured (Manually created). Based on this parameter value we could control which workflow to trigger.

Let's come back to our single SES workflow based scenario. The agent determination logic to identify Project Owner and Cost Center Director is written in another BADI MMPUR_WORKFLOW_AGENTS_V2. You can write your custom logic in Method IF_MMPUR_WORKFLOW_AGENTS_V2~GET_APPROVERS to determine approvers. Apart from SES, this BADI can be used for PO, PR as well and it contains filter parameter.

Outcome: We created a SES through ARIBA interface. We can notice in the below example that both the approvers have been determined correctly. 1st level approver has already approved the SES and now its pending with 2nd level approver.

When the SES is manually created through SES Fiori app, the 1st level has been skipped because Creator user ID is not ARIBA_INT and directly going to 2nd level approver who is cost center director.

In this way we can control the flexible workflow steps dynamically based on values configured in custom condition parameter.

There is another example in SAP Help portal. You can refer this as well.

Custom Conditions for Marketing Plan Approval Workflow

Cheers !!,
Sugato

How I Loaded 1.2 Billion Records into SAP HANA Without Crashing the Server (Or my Sanity)

2026-02-23T17:03:13.389000+01:00

Most SAP HANA performance discussions live in the comfortable world of millions of records. Benchmark slides, proof-of-concept demos, and architecture diagrams all look clean at that scale. But enterprise reality has a way of handing you something an order of magnitude larger and expecting the same SLA.

The Setup: When Scale Stops Being Theoretical

In this case, the table in question was a virtual table — a HANA object that sits on top of a remote data source via Smart Data Access (SDA). The underlying dataset: 1.2 billion rows. The requirement: a daily delta load capturing changes since the last run, landing data into a local HANA columnar table for analytics consumption.

On paper, straightforward. In practice, the first execution ended in under two minutes — not because it was fast, but because it had already failed.

ERROR: Numeric value out of range: 2147483648 > 2147483647 (integer overflow)

If you've spent any time in SAP HANA internals, you recognize this immediately: a 32-bit integer overflow. The row count counter had exceeded the maximum value of a signed 32-bit integer — roughly 2.1 billion — when accounting for internal processing metadata. At 1.2 billion source records, certain HANA execution nodes were attempting to track intermediate results using data types that simply could not hold the numbers involved.

Diagnosing the Real Problem

The instinct in situations like this is to find a workaround — filter the dataset, process it in chunks, hope that the next HANA revision patches the behavior. We resisted that instinct because workarounds at this scale become permanent architecture decisions. The fix needed to be designed, not hacked.

The diagnostic phase revealed three compounding issues:

The virtual table had no physical partitioning. All query execution was being funneled through a single HANA node, creating both the overflow condition and a severe memory bottleneck.
The delta detection logic used a naive MAX(timestamp) comparison across the full source table. At 1.2 billion rows, even this baseline query was scanning far more data than necessary.
The target columnar table had been created with default settings, meaning no partition pruning was possible during write operations — every insert had to compete for the same table-level lock structures.

Any one of these would be a problem at scale. All three together made the load procedure functionally impossible without architectural changes.

The Architecture Decision: Hash-Based Distribution

The core decision was between range-based partitioning and hash-based distribution. Range partitioning is intuitive — split the data by date, by region, by some natural business boundary. But it creates a dangerous assumption: that your data arrives evenly across those boundaries. Delta loads rarely do. Business activity spikes, month-end processing creates surges, and range partitioning under uneven load creates hot partitions that defeat the purpose entirely.

Hash-based distribution solves this by distributing rows across partitions based on a hash of one or more key columns, regardless of value. The distribution is mathematically even by construction, not by assumption about your data. For a delta load pattern where the arrival distribution is unpredictable, this was the right choice.

Key insight: Hash distribution trades partition pruning capability (you can't easily skip partitions by value range) for guaranteed load distribution. For delta loads where you're always processing "new records since last run" rather than querying a specific range, this trade-off is almost always worth it.

The implementation used a composite key — a combination of the source system identifier and the record's primary key — as the hash input. This ensured that records from the same source system were spread across partitions rather than concentrated, which mattered because the source systems themselves had uneven record volumes.

The Procedure: Key Implementation Decisions

The delta load procedure was rebuilt from scratch with four core changes. I'll walk through the logic rather than exact client-specific code, but the patterns are directly replicable.

Step 1 — Establish the delta boundary without touching the full table:

-- Get last successful load timestamp from a control table

SELECT MAX(load_timestamp) INTO lv_last_load

FROM delta_control_table

WHERE load_status = 'SUCCESS';

This is a small but important detail. The previous implementation read the MAX timestamp from the source table itself — a full scan of 1.2 billion rows just to establish a starting point. Moving this to a dedicated control table eliminated what was effectively a full table scan before the actual work even began.

Step 2 — Partition the work at the procedure level, not just the table level:

-- Process in hash-distributed batches using modulo on source key

FOR i IN 0..7 DO

INSERT INTO target_table

SELECT * FROM source_virtual_table

WHERE MOD(CAST(source_key AS BIGINT), 8)= i

AND change_timestamp > lv_last_load;

END FOR;

The CAST to BIGINT here is the direct response to the original overflow. By explicitly casting the key to a 64-bit integer before the modulo operation, we moved the arithmetic out of the implicit 32-bit context that was causing the failure. The number 8 is the partition count — adjustable based on your HANA node count and available parallelism.

Step 3 — Explicit memory management between iterations:

-- Release intermediate results between batch iterations

EXEC 'UPDATE STATISTICS ON target_table';

Without this, HANA's query optimizer was working with stale statistics mid-procedure, leading to increasingly poor execution plans as the load progressed. Updating statistics between batches added modest execution time but dramatically improved consistency across the full load window.

The Results: Numbers That Justify the Redesign

Metric	Before Redesign	After Redesign
Load completion	Failed (overflow)	Consistent success
Execution time	N/A (failed)	~47 minutes avg
Peak memory per node	Unbounded (OOM)	~18 GB controlled
Delta detection scan	1.2B rows (full)	Control table only
Partition hot-spotting	Single node	Even 8-way distribution

What Generalizes: A Decision Framework for Your Next Billion-Record Load

If you take nothing else from this, take this decision tree. These are the questions I now ask before designing any large-scale HANA load procedure:

Is your row count approaching or exceeding 500 million? If yes, assume you will hit 32-bit arithmetic constraints somewhere in the execution path. Design BIGINT handling in explicitly from day one.
Is your delta arrival distribution predictable by a natural business key? If yes, range partitioning may work. If no — or if you're unsure — default to hash distribution.
Are you reading the delta boundary from your source table? Move this to a control table immediately. You are doing a full scan of your largest table to answer a question your database should already know.
Is your target table using default partition settings? For tables that will receive regular bulk inserts above 100 million rows, explicit partitioning is not optional — it is the difference between a load procedure and a production incident.

What I Would Do Differently

The honest answer is that the control table should have been part of the original design. Delta load architectures at any scale need a separate tracking mechanism — treating the source data as the source of truth for load state is a design flaw, not just a performance issue. At 1.2 billion records it becomes catastrophic, but it would have been wrong at 100 million too.

I would also have instrumented the procedure differently from the start. Adding execution time logging between each batch iteration, with row counts and memory snapshots, would have made the performance profiling much faster. We added this in a subsequent revision and it has saved significant debugging time on every load since.

Final Thoughts

SAP HANA is genuinely capable of handling data at this scale — but it requires you to work with its architecture rather than assuming it will absorb whatever you throw at it. The columnar engine, the distributed execution model, and the memory management system are all designed with specific usage patterns in mind. When you align your load procedures to those patterns, the performance characteristics are exceptional. When you don't, the failures are fast and unambiguous.

The 1.2 billion record delta load now runs reliably every night. It takes about 47 minutes, uses predictable memory, and has not failed since the redesign was deployed. That feels unremarkable today, which is exactly what good infrastructure architecture should feel like.

If you're working through a similar challenge, I'm happy to discuss in the comments. The specifics of hash key selection, batch count tuning, and control table schema design all depend on your environment — but the principles are consistent.

End-to-End Automatic Order to Billing Process in SAP SD (Low-Coding Approach)

2026-02-24T07:29:02.824000+01:00

In line with the customer requirement, an automatic process was designed covering delivery creation, goods issue posting, and billing immediately after sales order creation.

The solution was implemented based entirely on standard SAP SD principles and designed under a low-coding approach, minimizing custom developments while preserving full control over the process.

1. Excluding Specific Customers from the Automatic Process

During the analysis phase, it became necessary to exclude certain customers from the automated flow.

To achieve this:

A custom indicator field was defined under Business Partner – SD (FLCU01) view.
Using transaction CMOD, field KDGRP4 was renamed as “Automatic Billing Exclusion”.
For customers that must remain outside the automated process, value “X” is maintained via customizing.

This design ensures flexibility and allows business users to control participation in the automated process without additional development.

2. Sales Document Configuration (VOV8)

Within VOV8 sales document type configuration, the relevant document types were adjusted by activating the Immediate Delivery setting.

This configuration enables the system to automatically trigger delivery creation directly from the sales order.

3. Dynamic Control in MV45AFZZ (SAVE_DOCUMENT_PREPARE)

At enhancement point MV45AFZZ – SAVE_DOCUMENT_PREPARE, a class-based method was implemented instead of writing logic directly into the include.

The method dynamically reads Business Partner data and manipulates field TVAK-LISOF depending on defined conditions.

Key Logic Summary:

If the document creator is not the workflow user (SAP_WFRT), automation is cancelled.
KNVV-KVGR4 is checked for the exclusion flag.
If the customer is marked with “X”, the automation flag (TVAK-LISOF) is cleared dynamically.
Otherwise, the process continues automatically.

This approach ensures that:

Standard configuration remains intact.
Automation can be centrally controlled.
Sales document level settings can be programmatically overridden when necessary.

METHOD zsd_save_document_prepare_1.

* inserted by serdar ulgen. 19.01.2026 11:01:55 .

  i_knvv-kunnr = i_vbak-kunnr.
  i_knvv-vkorg = i_vbak-vkorg.
  i_knvv-vtweg = i_vbak-vtweg.
  i_knvv-spart = i_vbak-spart.

  FIELD-SYMBOLS <lv_lisof> TYPE any.
  ASSIGN ('(SAPMV45A)TVAK-LISOF') TO <lv_lisof>.
  IF sy-subrc <> 0.
    RETURN.
  ENDIF.

  IF i_vbak-ernam <> 'SAP_WFRT'.
    CLEAR <lv_lisof>.
    RETURN.
  ENDIF.

  SELECT SINGLE kvgr4
    FROM knvv
    INTO @i_knvv-kvgr4
    WHERE kunnr = @i_knvv-kunnr
      AND vkorg = @i_knvv-vkorg
      AND vtweg = @i_knvv-vtweg
      AND spart = @i_knvv-spart.

  IF i_knvv-kvgr4 = 'X' AND <lv_lisof> = 'A'.
    CLEAR <lv_lisof>.
  ENDIF.

* if u any question please contact with me.

4. Automating Goods Issue and Billing

After completing the Sales → Delivery flow, the next phase covered:

Goods Issue posting
Billing creation

Alternative Approach (Not Preferred)

An alternative solution could involve sequential BAPI calls for goods issue and billing within a custom program.

Although technically feasible, this method requires careful handling of:

ENQUEUE / DEQUEUE locks
Document synchronization
LUW management

Improper lock handling may lead to document conflicts.

5. Leveraging Standard Output Type REA0

In this implementation, we leveraged the fact that standard SAP output type REA0 can directly trigger billing.

The approach:

The standard program used in REA0 was copied.
A Goods Issue BAPI call was added at the beginning.
Billing creation was kept as standard.
Output determination was assigned correctly to the relevant delivery types using VV21.

This step is critical — without correct output assignment, the automation will not execute.

6. Technical Highlights

Goods issue is triggered via WS_DELIVERY_UPDATE_2
Billing is created via /SPE/CREATE_NEW_BILLING_CALL
Error handling is managed through NAST protocol updates
Separate LUW handling is ensured via /SPE/CALL_PROC_IN_NEW_LUW
Minimal custom coding
Maximum reuse of SAP standard structures

REPORT  zsd_***_****.

TABLES: nast.
CONSTANTS: c_allready_billed TYPE fkstk VALUE 'C'.
DATA: gs_nast            TYPE nast,
      lt_delivery_data   TYPE leshp_delivery_t,
      ls_delivery_data   TYPE LINE OF leshp_delivery_t,
      lt_delivery_items  TYPE leshp_delivery_item_t,
      ls_doc_pos_ver_req TYPE /spe/doc_pos_ver_req,
      lt_doc_pos_ver_req TYPE /spe/doc_pos_ver_req_t,
      lv_dummy_message   TYPE bapiret2-message,
      lt_bapiret2        TYPE bapiret2_t,
      ls_bapiret2        TYPE bapiret2,
      ls_leshp_data      TYPE leshp_data.

FIELD-SYMBOLS: <ls_billing_req> TYPE LINE OF leshp_delivery_item_t.

*&---------------------------------------------------------------------*
*&      Form  ENTRY
*&---------------------------------------------------------------------*
*       create new bill
*----------------------------------------------------------------------*
FORM entry USING returncode  TYPE sy-subrc
                 use_screen  TYPE c.

  DATA: ls_vbeln_vl TYPE vbeln_vl,
        lv_leave    TYPE c,                                 "n_1238590
        lv_error    TYPE c,
        ls_vbkok    TYPE vbkok,
        lt_prot     TYPE TABLE OF prott,
        lv_text     TYPE t100-text,
        lv_delivery TYPE vbeln_vl.

  FIELD-SYMBOLS: <ls_return> TYPE bapiret2.

  IF sy-uname = 'SAP_WFRT'.

  lv_delivery = nast-objky.
  ls_vbkok-vbeln_vl  = lv_delivery.
  ls_vbkok-wadat_ist = sy-datum.
  ls_vbkok-wabuc     = abap_true.

  CALL FUNCTION 'WS_DELIVERY_UPDATE_2'
    EXPORTING
      synchron      = abap_true
      vbkok_wa      = ls_vbkok
      delivery      = lv_delivery
    TABLES
      prot          = lt_prot
    EXCEPTIONS
      error_message = 1
      OTHERS        = 2.

  LOOP AT lt_prot ASSIGNING FIELD-SYMBOL(<error>).
    IF <error>-msgty = 'E' OR <error>-msgty = 'A'.

      SELECT SINGLE text FROM t100 INTO @LV_text WHERE sprsl = @SY-langu AND arbgb = @<error>-msgid AND msgnr = @<error>-msgno.

      IF sy-subrc = 0 AND lv_text IS NOT INITIAL.
        MESSAGE lv_text TYPE 'E'.
      ELSE.
        MESSAGE ID <error>-msgid TYPE 'E' NUMBER <error>-msgno.
      ENDIF.

      returncode = 1.
      RETURN.
    ENDIF.
  ENDLOOP.

ENDIF.


* Redirect this NAST processing to separate LUW - in case it is
* called with dispatching time 4 (immediate processing)
* during update task                                        "v_n_1238590
CALL FUNCTION '/SPE/CALL_PROC_IN_NEW_LUW'
  EXPORTING
    is_nast  = nast
  IMPORTING
    ef_leave = lv_leave.
IF NOT lv_leave IS INITIAL.
*   Per default we set the status on error, so that it can be reprocessed
*   in error processing (RSNAST0F) if there is any syntax error / update
*   termination / ... in the decoupled NAST processing.
  returncode = 4.
  RETURN.
ENDIF.                                                    "^_n_1238590

returncode = 0.
* Get Item Data of Delivery
*  ls_leshp_data-item = 'X'.                                  "n_1822545
* Get Status of Outbound Delivery
ls_leshp_data-head_status = 'X'.
* Copy Nast Entry
gs_nast = nast.
ls_vbeln_vl = nast-objky.

CALL FUNCTION 'LE_DELIVERY_GET_BUFFERED'
  EXPORTING
    if_vbeln               = ls_vbeln_vl
    is_data                = ls_leshp_data
  CHANGING
    cx_deliveries          = lt_delivery_data
  EXCEPTIONS
    no_item_selected       = 1
    selected_item_enqueued = 2
    no_key_specified       = 3
    OTHERS                 = 4.
IF sy-subrc <> 0.
  MESSAGE e267(/spe/vl) WITH ls_vbeln_vl INTO lv_dummy_message.
  returncode = sy-subrc.
ELSE.

* only one delivery can be found by premisses (VBELN).
  READ TABLE lt_delivery_data INDEX 1 INTO ls_delivery_data.
  IF sy-subrc = 0.
    IF ls_delivery_data-head_status-fkstk = c_allready_billed.
* Allready billed.
      returncode = 0.
      MESSAGE i265(/spe/vl) WITH ls_vbeln_vl INTO lv_dummy_message.
    ELSE.
*        lt_delivery_items = ls_delivery_data-item.         "v_n_1822545
*        LOOP AT lt_delivery_items ASSIGNING <ls_billing_req>.
*          MOVE-CORRESPONDING <ls_billing_req> TO ls_doc_pos_ver_req.
*          APPEND ls_doc_pos_ver_req TO lt_doc_pos_ver_req.
*        ENDLOOP.
      ls_doc_pos_ver_req-vbeln = ls_delivery_data-head-vbeln.
      APPEND ls_doc_pos_ver_req TO lt_doc_pos_ver_req.    "^_n_1822545

      CALL FUNCTION '/SPE/CREATE_NEW_BILLING_CALL'
        EXPORTING
          it_billing_req     = lt_doc_pos_ver_req
          iv_version_checked = 'X'
        IMPORTING
          et_return          = lt_bapiret2.
      LOOP AT lt_bapiret2 ASSIGNING <ls_return>.
        IF <ls_return>-type = 'E'.
          lv_error = 'X'.
        ENDIF.
      ENDLOOP.
      IF lv_error = 'X'.
        returncode = 1.
        use_screen = ' '.
      ELSE.
        returncode = 0.
      ENDIF.
    ENDIF.

  ELSE.
* No Entry found !!!
    MESSAGE e267(/spe/vl) WITH ls_vbeln_vl INTO lv_dummy_message.
    returncode = 9.
  ENDIF.
ENDIF.
CALL FUNCTION 'NAST_PROTOCOL_INITIALIZE'.
LOOP AT lt_bapiret2 ASSIGNING <ls_return>.
  IF <ls_return>-type = 'E'.
    lv_error = 'X'.
  ENDIF.
  PERFORM protocol_update_return USING <ls_return>.
ENDLOOP.
IF lv_error = 'X'.
  returncode = 1.
  use_screen = ' '.
ELSE.
  returncode = 0.
ENDIF.

IF sy-subrc <> 0.
  PERFORM protocol_update.
ENDIF.
ENDFORM.                    " ENTRY

*---------------------------------------------------------------------*
*       FORM PROTOCOL_UPDATE                                          *
*---------------------------------------------------------------------*
*       The messages are collected for the processing protocol.       *
*---------------------------------------------------------------------*

FORM protocol_update.

  CALL FUNCTION 'NAST_PROTOCOL_UPDATE'
    EXPORTING
      msg_arbgb = syst-msgid
      msg_nr    = syst-msgno
      msg_ty    = syst-msgty
      msg_v1    = syst-msgv1
      msg_v2    = syst-msgv2
      msg_v3    = syst-msgv3
      msg_v4    = syst-msgv4
    EXCEPTIONS
      OTHERS    = 1.

ENDFORM.                    "PROTOCOL_UPDATE
*&---------------------------------------------------------------------*
*&      Form  protocol_update_return
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*      -->P_<LS_RETURN>  text
*----------------------------------------------------------------------*
FORM protocol_update_return USING p_return TYPE bapiret2.

  CALL FUNCTION 'NAST_PROTOCOL_UPDATE'
    EXPORTING
      msg_arbgb = p_return-id
      msg_nr    = p_return-number
      msg_ty    = p_return-type
      msg_v1    = p_return-message_v1
      msg_v2    = p_return-message_v2
      msg_v3    = p_return-message_v3
      msg_v4    = p_return-message_v4
    EXCEPTIONS
      OTHERS    = 1.

ENDFORM.                    " protocol_update_return

7. Final Architecture Principle

Standard-first approach

Low-coding strategy

Dynamic control via enhancement

Output-driven automation

Controlled customer-based exclusion

Lock-safe execution

8. Conclusion

This solution delivers a fully automated Order → Delivery → Goods Issue → Billing process while maintaining:

High adherence to SAP standards
Minimal custom development footprint
Flexible customer-level control
System stability and scalability

By combining standard configuration (VOV8, VV21), enhancement logic (MV45AFZZ), and output-based processing (REA0), an end-to-end automated and maintainable SD process was successfully implemented.

SAP Community - SAP HANA

SAP HANA Cloud release January 2026 Round-up

What’s New Teaser

What’s New blogpost

What's New Webinar

Code Connect 2026 is Coming – Mark Your Calendars!

What is Code Connect?

Your Week at Code Connect

July 13: Code Jam Sessions and Warmup

July 14: UI5con

July 15: reCAP

July 16: HANA Tech Con

Early Bird Process

Sponsorship Opportunities

Call for Proposals

Important Dates

Ready to Connect?

Transfer of medical instruments and implants in Medical device Industry using S/4 HANA

Fulfillment of Trial request to the field in Medical Device Industry using S/4 HANA

Expired Product Management in Medical Device Industry using S/4HANA

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

Why was this blog post created?

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

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

Generated report in SAP HANA Dump Analyzer

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

What is the conclusion?

Other articles

Do you have further questions?

Contribution

Creating value in airlines

Creating value in airlines

Violent Geometry of Gold: from Flatlandia to Spacelandia

Rolling 2 adjacent months, i.e., 489 2-month pairs (t, t+1)

All possible month pairs, i.e., 119,805 pairs

How do co-movements (joint returns) for gold and NEM change month to month?

Global cloud geometry

What does the formula mean geometrically?

What does “big vs small volume” mean financially? How many independent directions did the system move across those 3 months.

Finance Color #1: It clicked: diversification is episodic, not average

Finance Color #2: Volumes identify regime transitions, not just volatility

1986-04 → 1986-06

1987-08 → 1987-10

1998-08 → 1998-10

1999-09 → 1999-11

2008-09 → 2008-11/12 → 2009-02

2016-01 → 2016-03 — Global growth scare → commodity & gold rebound

SAP CodeJam Roadshow 2026 - Brazil edition 🇧🇷 (Kicking off in March and continuing in April)

SAP CodeJam events and meetups part of the roadshow (Register Now!)

SAP HANA and ABAP Performance Tuning: A Guide to Caches and Buffers

Background

Sequence of Data Access

ABAP Tuning Objects

HANA Tuning Objects

Conclusion

Reimagining Utility Transformation: Clean Core Principles Powered by SAP BTP

Introduction

Main Body

1. The Customization Cage: How Utilities Got Here

2. Clean Core + SAP BTP: The Agility Layer Utilities Needed

3. A Practical Framework for Utility Clean Core Adoption

Step 3: Use SAP Event Mesh to Break the Batch Mindset

Step 4: Establish Governance That Protects the Core

Step 5: Treat BTP as a Business Platform

Step 6: Build a 24‑Month Roadmap

4. The Modern Utility Innovation Stack

Conclusion

Welcome to the Technology Learning Group!

AI Is Transforming Sales Order Processing in SAP

Everything about SAP migration and Palantir : A basis POV

1.Understanding Palantir

2.Palantir architecture

3. How to access the Palantir platform

4.Palantir and data connectivity

5.Palantir's HyperAuto and SAP

6.Connecting SAP and Palantir

7.Sample demo screen shots of integrating SAP data with Palantir's HyperAuto to extract SAP ECC data into a S3 bucket

8.Palantir’s SAP migration narrative

9.Palantir’s position on testing

10.My point of view on SAP migration and Palantir usage: