SAP Community - Cloud

Linux Shell Script for automating graceful startup and shutdown of SAP S4HANA System

2025-10-07T12:03:15.762000+02:00

Linux Shell Script for automating graceful startup and shutdown of SAP S4HANA [Only meant for Single Tier System] in SUSE Linux VMs/Instances inside cloud environment.

This post is purely focusing on the OS level scripting and is not associated with nor related with any of the cloud console level automation using serverless concepts, for example AWS Lambda.

Running SAP S4HANA on virtual machines in cloud environments like Azure, AWS, or Google Cloud comes with its unique challenges—especially when it comes to starting and stopping services reliably and cost-effectively.

As most of us are familiar, when a VM or Instance boots up, post the OS booting process, it’s critical to start the SAP HANA database *before* the SAP application to avoid issues/failures. Similarly, during a VM shutdown, the SAP application must stop *before* the database to ensure all processes close gracefully, preventing data corruption or downtime.

Leaving SAP systems running idle can also cause unnecessary cloud billing, especially in PoC or Demo setups where uptime directly impacts costs.

To address the above mentioned two of the key issues, I developed simple yet effective shell scripts that automate the controlled start and stop sequence of SAP S4HANA based on the VM’s lifecycle. These scripts can be manually invoked or integrated into cloud startup/shutdown hooks, ensuring SAP services respond correctly whenever the OS boots or halts.

This automation enhances reliability and saves effort and rework by enabling the graceful shutting down of SAP S4HANA App and DB.

Here’s how it works:

To achieve the above-mentioned automation, you need to follow the steps mentioned below

Logon with root user on the VM/instance where SAP DB & Application is hosted.
Gain the clean root environment with default variables and path using the command: sudo su -
Navigate to the path: /etc/systemd/system/
vi sap-s4hana.service
enter the following contents in this file.

Note: Please refer to the path used in this file content, you need to use same or in case you want to change the path or file naming convention etc., you may document the changes accordingly.

[Unit]

Description=SAP S/4HANA single-tier startup/shutdown orchestrator (HANA + App)

After=network.target

[Service]

Type=oneshot

ExecStart=/usr/local/bin/sap-start.sh

ExecStop=/usr/local/bin/sap-stop.sh

RemainAfterExit=yes

TimeoutStartSec=1800

TimeoutStopSec=1800

[Install]

WantedBy=multi-user.target

save the file
Update the permissions of this file: chmod +x sap-s4hana.service
Update file ownership of this file: chown root:root sap-s4hana.service
For creating the shell script for starting the SAP S4HANA DB and SAP S4 Application, Navigate to the path:

/usr/local/bin

vi sap-start.sh

10. enter the following contents in this file:

Note: Please refer to the path used in this file content, you need to use same or in case you want to change the path or naming convention, you may document the changes accordingly.

Ensure to update the relevant user id, SAP SID, Instance Numbers in this content,

#!/bin/bash

LOGFILE="/var/log/sap-start.log"

exec >> "$LOGFILE" 2>&1

echo "===== [$(date)] Starting SAP S/4HANA DB ====="

# Start HANA DB

sudo -u xxxadm /usr/sap/XXX/HDB02/HDB start

echo "HANA DB start command executed."

# Wait for DB

sudo -u xxxadm /usr/sap/hostctrl/exe/sapcontrol -nr 02 -function WaitforStarted 600

echo "HANA DB started successfully."

echo "===== [$(date)] Starting SAP Application ====="

# Start SAP App

sudo -u xxxadm /usr/sap/hostctrl/exe/sapcontrol -nr 00 -function StartSystem

echo "SAP Application start command executed."

# Wait for SAP App

sudo -u xxxadm /usr/sap/hostctrl/exe/sapcontrol -nr 00 -function WaitforStarted 300

echo "SAP Application started successfully."

echo "===== [$(date)] SAP System Startup Completed ====="

11. save the file
12. Update the permissions of this file: chmod 777 sap-start.sh
13. Update the ownership of this file: chown root:root sap-start.sh

14. For creating the shell script for stopping the SAP S4 Application & SAP S4HANA DB, continue in same folder, and follow the steps below:

/usr/local/bin

vi sap-stop.sh

#!/bin/bash
LOGFILE="/var/log/sap-stop.log”
17. exec >> "$LOGFILE" 2>&1
18. echo "===== [$(date)] Stopping SAP Application ====="
# Stop SAP App
20. sudo -u xxxadm /usr/sap/hostctrl/exe/sapcontrol -nr 00 -function StopSystem
21. echo "SAP Application stop command executed."
# Wait for SAP App
23. sudo -u xxxadm /usr/sap/hostctrl/exe/sapcontrol -nr 00 -function WaitforStopped 300
echo "SAP Application stopped successfully."
25. echo "===== [$(date)] Stopping HANA DB ====="
# Stop HANA DB
sudo -u xxxadm /usr/sap/XXX/HDB02/HDB stop
28. echo "HANA DB stop command executed."
# Wait for DB
30. sudo -u xxxadm /usr/sap/hostctrl/exe/sapcontrol -nr 02 -function WaitforStopped 600
31. echo "HANA DB stopped successfully."
32. echo "===== [$(date)] SAP System Shutdown Completed ====="
33. save the file
34. Update the permissions of this file: chmod 777 sap-stop.sh
35. Update the ownership of this file: chown root:root sap-stop.sh
During your copying of the above-mentioned commands and scripts in the linux host, quite often the files might get appended with carriage returns (^M , \r ), this can be concluded during checking of the above created files using the cat command, if fould, you can use one of the following command to clean for each of the three files created above :

sudo dos2unix filename [or]

sudo sed -I ‘s/\r$//’ filename

37. Further to the completion of above steps, navigate to the path /etc/systemd/system

sudo systemctl daemon-reload

sudo systemctl enable sap-s4hana.service

38. If you have not started the SAP S4HANA DB and S4 Application, you can proceed to execute

sudo systemctl start sap-s4hana.service

By executing this command, you must check the progress of DB status and Application status using the sapcontrol command

39. Post checking the proper starting of the SAP S4HANA DB and S4 Application, you can also check the proper stopping by executing the following command

sudo systemctl stop sap-s4hana.service

By executing this command, you must check the progress of DB status and Application status using the sapcontrol command

Why This Matters

- Protects SAP data integrity with clean startups and shutdowns

- Saves cloud costs, ideal for PoC / Demo / Dev environments

- Makes manual intervention unnecessary, cutting operational overhead

Sizing Your Success: A Guide to SAP Cloud ERP Private

2025-10-13T08:08:25.486000+02:00

From my perspective, effective sizing is one of the most underestimated yet critical aspects of any SAP transformation. While SAP offers a standardized and well-defined architecture, every customer’s landscape, data footprint, and performance expectations are unique. This makes it essential for customers and their implementation partners to take ownership of sizing, validation, and optimization activities.

For SAP customers, partners, and technical teams navigating the shift to SAP S/4HANA and other solutions within SAP Cloud ERP Private, accurate system sizing is paramount. While SAP provides a globally consistent, standardized architecture, the responsibility for executing and validating sizing activities rests squarely with the customer and their implementation partners.

Ultimately, accurate sizing isn’t just a technical exercise; it’s a strategic enabler for stability, scalability, and long-term cost efficiency.

This guide demystifies SAP sizing, focusing on the core concepts, benefits, and practical methods within the SAP Cloud ERP Private landscape.

What is SAP Cloud ERP Private?

SAP Cloud ERP Private is a cloud-based offering that marries the control of an on-premise system with the agility and efficiency of the cloud. It guides customers toward a clean core through standardized processes and modern extensibility via SAP Business Technology Platform (SAP BTP), and in-app extensibility tools.

I think the biggest advantage of running SAP on certified cloud infrastructure that SAP Cloud ERP Private oferring adheres to is how it simplifies everything — security, compliance, and support are all built in. It lets IT teams spend less time keeping the lights on and more time driving innovation. The key, though, is being ready to fully embrace the cloud mindset to get the most out of it.

For more information please refer to Understanding the Distinct Scope of SAP Cloud ERP Private.

General SAP Sizing Overview

SAP sizing is the process of precisely determining the required hardware resources such as CPU, memory, storage, and network capacity to effectively support an SAP system based on specific business needs. It’s a blend of science, utilizing tools and calculations, and expert judgment to account for the unique context of each implementation.

Key aspects of sizing include:

Translating Business Requirements: Starting with user counts, transaction volumes, data growth, and performance expectations.
Hardware Determination: Calculating the required compute, memory, and storage.
Iterative Process: Sizing isn't a one-time event. It must be revisited as the business and technology evolve. This is because sizing relies on assumptions and approximations about future usage, and it must balance optimal performance with cost management.
Data Quality is Critical: The accuracy of the sizing results is heavily dependent on the quality of the validated usage data and sizing assumptions provided by customers and partners.

SAP Cloud ERP Private Sizing Strategy

Sizing for SAP Cloud ERP Private is a vital step to ensure your infrastructure efficiently supports your SAP workloads. SAP offers two primary models:

Standard Sizing: A simplified, consumption-based model using predefined T-shirt size service bundles (e.g., XXS to 4XL), which provides a baseline scope with a minimal sizing effort.
Tailored Sizing: A more granular, customized approach for complex landscapes, offering greater flexibility based on detailed requirements.

Key Sizing Steps

A structured approach to sizing includes:

Define the Scope: Identify the SAP applications (e.g., SAP S/4HANA, SAP BW/4HANA) and specific modules, determine transaction workloads, and define usage (e.g., Production, QA).
Collect Baseline Data: Use tools like the SAP Quick Sizer for new systems or EarlyWatch Reports and historical data (ST03N / ST06) for existing ones. For migrations, the SAP Readiness Check is essential.
Use SAP Sizing Tools: Leverage tools like Quick Sizer (greenfield) or specific sizing reports like /SDF/HDB_SIZING (brownfield) to get technical resource estimates.
Incorporate Growth & Buffer: Always plan for projected growth (3–5 years) and add a buffer (typically 10–25%) for peak loads and future needs.
Validate with Experts: Review and validate sizing with SAP experts, potentially via a "Size to Scale" engagement through SAP Premium Engagement.

Standard Sizing: The T-Shirt Model

The Standard approach maps your business needs to a predefined, T-shirt-sized model.

Full User Equivalent (FUE)

The starting point for Standard sizing is calculating the Full User Equivalent (FUE). An FUE reflects the average workload of a typical user, with different user types weighted accordingly:

User Type	FUE Weight
Developer Access	0.50
Advanced Use	1
Core Use	5
Self-Service Use	30

The final FUE count determines the required hardware package.

Example Sizing Tiers (SAP S/4HANA Illustration)*

T-Shirt Size	FUE Range	Production DB RAM (Example)
XXS	60 to 135	256 GB
XS	136 to 550	256 GB
S	551 to 1,000	512 GB
L	2,001 to 4,000	2,048 GB

*This for illustration only. Always refer to the SAP Service Description Guide for the latest metrics.

Strategies in Deployment Models

Model	Sizing Method	Primary Tool(s)	Key Action
Greenfield (new implementation)	Use projected user and transaction volumes	SAP Quick Sizer (SAP HANA-based)	The tool outputs can then mapped to FUE and a corresponding T-shirt size.
Brownfield (system conversion)	Analyze historical data and current system usage	/SDF/HDB_SIZING report (SAP Note 1872170)	Perform data archiving and cleanup first, then run the report to estimate SAP HANA memory and map to the closest T-shirt size.

Refer to the Key Resources section for tools and reports that will help you identify the right option for your scope.

Tailored Sizing: Customization for Complexity

The Tailored Option provides granular control and customized hardware specifications. This model combines standard tools with deep expert analysis, allowing more precise control over application server sizing and high-availability (HA)/disaster-recovery (DR) configurations.

Tailored Sizing Approaches

Model	Sizing Method	Primary Tool(s)	Key Action
Greenfield	Based on business assumptions and projected volumes	SAP Quick Sizer (SAP HANA-based)	Generates hardware-independent recommendations (SAPS, memory, disk).
Brownfield	Based on analysis of historical data and system usage	/SDF/HDB_SIZING report, SAP Readiness Check, EWA	Housekeeping is critical. Report output is refined by an SAP expert to account for custom code and specific usage.

In a tailored environment, the strategy shifts to "right-sizing" for current needs. This means leveraging the cloud’s elasticity to scale up or down instead of provisioning for multi-year growth upfront, which is the case for traditional on-premise models.

Refer to the Key Resources section for tools and reports that will help you identify the right option for your scope.

“Size to Scale” and Technical Assessment

The SAP Cloud ERP Private Technical Assessment is a mandatory, comprehensive evaluation designed to analyze and document the technical requirements, architecture, and sizing needs.

SAP Expert Sizing Engagement

For complex, large, or unusual landscapes, engaging an SAP expert is highly recommended. The "Size to Scale" is the expert sizing service from SAP offered via SAP Premium Engagements (MaxAttention or ActiveAttention). It provides a deep-dive, tailored sizing service.

When is "Size to Scale" required?

SAP proactively escalates an implementation for expert review if:

Initial analysis indicates a SAP HANA DB Requirement > 4 TiB.
A large amount of custom code is being migrated.
There are plans to consolidate multiple ERP solutions or significant new functionality (e.g., embedded EWM/TM).

SAP Sizing & Technical Assessment Engagement Flow

The sizing process is a multi-step flow involving different teams:

Initiation & Scoping: Define objectives and scope with Customer, SAP Account Executives, and SAP Cloud Architecture & Advisory (CAA).
Data Collection & Pre-Assessment: Customer and partner run sizing reports (e.g., /SDF/HDB_SIZING, SAP Readiness Check) and collect historical performance data.
Sizing Analysis: The SAP CAA team analyzes data, maps it to infrastructure (T-shirt or tailored specs), and applies the necessary growth buffer.
Technical Assessment Review & Validation: Finalized sizing assumptions are reviewed, aligned on HA/DR/network, documented in the Technical Assessment Report, and signed off by the customer.
Handover to Delivery: The infrastructure is provisioned as per the agreed specifications.

Monitoring and Reporting in Cloud ERP, Private

After provisioning, continuous monitoring is key to validating the sizing and ensuring performance. This is managed through core services provided as part of the SAP Cloud ERP Private offering:

Capacity Management: This ongoing process ensures the environment meets performance and availability requirements by monitoring utilization, forecasting demand, and dynamically adjusting resource allocation.
Problem Management: This function identifies, analyzes, and resolves capacity and performance issues. It links directly back to sizing by investigating if initial assumptions were inaccurate and recommending a necessary resizing or optimization.
Performance Benchmarking (Enhanced Operations Services for Large Enterprises – EOS LE): A jointly defined service that measures selected business transactions over time, helping to identify performance trends and proactively mitigate future issues.

For more information on EOS LE please refer to SAP Cloud ERP, Private Service Description site.

By diligently performing and validating your sizing assumptions, your organization can ensure that your SAP S/4HANA journey in SAP Cloud ERP Private is built on a foundation of optimal performance, scalability, and cost efficiency.

Greenfield vs. Brownfield: Sizing Strategies for SAP S/4HANA Success

When moving to SAP S/4HANA, especially within the SAP Cloud ERP Private environment, the path you choose dictates your sizing strategy. Do you start fresh (greenfield) or convert an existing system (brownfield)?

While both methods rely on core SAP sizing tools, the inputs, assumptions, and required infrastructure for CPU, RAM, and storage diverge significantly. Understanding these differences is crucial for accurate provisioning and avoiding costly over- or under-sizing.

Sizing Approaches: Greenfield vs. Brownfield at a Glance

Aspect	Greenfield Sizing	Brownfield Sizing
Data Volume	New system, usually reduced data footprint (selective migration)	Full data migration — larger existing database size (full history)
Sizing Approach	Based on projected business requirements (users, transactions, volumes)	Based on existing system usage and historical performance metrics
Primary Tools	SAP Quick Sizer, business blueprints	SAP HANA sizing reports (e.g., /SDF/HDB_SIZING)
Custom Code	Limited or redesigned; minimal impact on sizing	Custom code retained; requires analysis (Custom Code Analyzer) as it may increase RAM/CPU requirements
Sizing Buffer	Add buffer for uncertainties in new processes (e.g., 20–30%)	Add buffer for custom code, transition load, and compatibility layers (e.g., 15%)

Greenfield Sizing: Building from the Blueprint

Use Case: A new SAP S/4HANA system deployment, often involving redefined, standardized business processes and a selective data migration.

Key Considerations:

Reliance on SAP Quick Sizer: Since no historical data exists, sizing is purely business-driven. You input future metrics like the number of users by type, sales order volumes, and financial transaction counts. The Quick Sizer outputs estimates for SAP HANA memory, CPU cores, and disk sizes.
Reduced Data Footprint: Greenfield often means selective data migration (e.g., only the last 2–3 years of transactional history). This results in a smaller initial database, lower storage requirements, and reduced initial RAM needs.
Cleaner Architecture: With fewer customizations and a focus on standard SAP S/4HANA processes, sizing for application performance is more predictable.
Add a Growth Buffer: As with any new implementation, add a significant buffer (typically ~20–30%) to account for future data growth, unforeseen business process changes, or new functionality adoption.

Brownfield Sizing: Converting the Past to the Future

Use Case: Converting an existing SAP ECC or SAP S/4HANA system to the private cloud, retaining existing processes and full data history.

Key Considerations:

Historical Data Analysis is Key: Sizing is usage-based. You must analyze the current system's historical performance to get an accurate estimate.

Workload Analysis: Use ST03N (workload analysis) and ST06 (system resources) data, and EarlyWatch Reports to understand CPU and memory utilization patterns.
Data Archiving is Best Practice: To optimize your sizing, archive and clean up unnecessary data before running the sizing reports.

The Crucial Sizing Report: The primary tool is the SAP HANA Sizing Report (/SDF/HDB_SIZING), detailed in SAP Note 1872170. This report runs on your existing system to analyze current database size, compression factors, and transaction volumes, providing a precise estimate of the required SAP HANA memory.
Accounting for Custom Code: Custom programs and reports (often numerous in an SAP ECC system) require assessment. The Custom Code Analyzer helps evaluate their impact, as unoptimized custom code can significantly increase required CPU and RAM.
Include Conversion Load: Be aware that the migration itself requires a temporary sizing uplift for staging, code remediation, and data transformation activities.

Example Sizing Comparison Snapshot

Metric	Greenfield	Brownfield
Initial DB Size	∼500 GB (selected)	1.5 TB (full)
SAP HANA Memory Estimate	∼256 GB	∼768 GB
CPU Cores	∼16–20 cores	∼36–40 cores

Key Recommendations and Next Steps

Sizing is a collective responsibility. While SAP and its certified partners provide the tools and expertise, customers must provide validated data and usage assumptions.

Always Validate:

Consult Experts: Always validate your sizing results—especially for complex brownfield conversions—with SAP CAA or a "Size to Scale" expert engagement through SAP Premium Engagement.
Compare Results: If you are unsure, run both the Quick Sizer (for a clean slate estimate) and the sizing reports (for historical usage) and compare the outcomes.
Documentation is Key: All sizing assumptions, data sources, and final resource estimates must be formally documented in the Technical Assessment Report as part of your SAP Cloud ERP Private onboarding.

Essential Resources:

Tool / Report	Use Case	SAP Note / Link
SAP Quick Sizer	Greenfield sizing (Business-driven)	SAP Sizing Resource
/SDF/HDB_SIZING	Brownfield, SAP ECC HANA Sizing	SAP Note 1872170
SAP Readiness Check	Brownfield Conversion Assessment	SAP Note 2758146
Custom Code Analyzer	Brownfield Code Impact Review	SAP Note 2290622
SAP Note 2296290	SAP BW/4HANA Sizing Report	SAP Note 2296290

By paying close attention to these greenfield and brownfield distinctions, you ensure your SAP S/4HANA landscape in SAP Cloud ERP Private is built on the right foundation for performance and scalability from day one.

Key Resources for SAP Sizing & Technical Readiness

Proper sizing and technical readiness are critical when planning, deploying, or migrating SAP solutions. Whether moving to SAP S/4HANA, SAP BW/4HANA, SAP Datasphere, or deploying on cloud platforms, the right references ensure smooth execution.

SAP Sizing Resources

SAP Sizing toolset
SAP Service Description Guide – scope of SAP services
SAP Note 1872170 – ABAP on SAP HANA sizing (SAP S/4HANA, Suite on SAP HANA)
SAP Note 2296290 – SAP BW/4HANA sizing
SAP Note 3599138 – SAP Datasphere sizing for non-BW systems

SAP Readiness Check

A self-service tool for migration planning and risk identification.

SAP Readiness Check Landing Page (SAP Support Launchpad)
SAP Note 2758146 – SAP S/4HANA Readiness Check
SAP Note 3112362 – Latest information for Readiness Check
SAP Note 2290622 – Custom Code Analysis

Hyperscaler References

Microsoft Azure

M-Series VMs
SAP Note 1928533 – SAP Applications on Microsoft Azure: Supported Products and VM Types

Google Cloud (GCP)

Certified VM Types
SAP Note 2456432 – SAP Applications on Google Cloud: Supported Products and Machine Types

Amazon Web Services (AWS)

EC2 Instance Types
SAP Note 1656099 – SAP Applications on AWS: Supported DB/OS and EC2 Products

Certified SAP HANA Hardware

SAP Certified Hardware Directory

Ultimately, using these official SAP and cloud provider resources helps ensure your landscape is right-sized, supported, and future-ready.

SAP Landscape Strategy in the Era of Managed Cloud and AI

2025-11-04T22:35:15.671000+01:00

In today’s digital-first world, enterprises face intense pressure to operate faster, leaner, and smarter. Emerging technologies like cloud computing, AI, and next-generation ERP systems are transforming how businesses run. Amid this change, SAP landscape consolidation presents a complex challenge, requiring close alignment between business and IT. While it can simplify IT environments, reduce costs, and enable intelligent automation, many organizations struggle to find the right approach. This article aims to demystify the topic, offering executives a clear framework to evaluate options, make informed decisions, and maximize value through an effective instance strategy.

The Case for Landscape Consolidation

Historically, most organizations have accumulated fragmented SAP landscapes through mergers, acquisitions, and regional growth—each business unit running its own version of “the truth.” These siloed environments inflate total cost of ownership, complicate reporting, and slow decision-making. Consolidation directly addresses this by unifying systems into a single, standardized architecture that delivers agility, transparency, and control. From the 1990s to the 2000s, technological limits—particularly hardware capacity—once made global system consolidation impractical. But today, with exponential advancements in computing power, cloud scalability, and tools like SAP’s Unicode-based Business Suite and Country Versions, technology is no longer the barrier. The question is no longer can we consolidate, but why haven’t we yet?

The financial argument is equally compelling. Organizations that have consolidated SAP landscapes typically achieve measurable cost reductions across key operational areas—around 20% in IT operations, 15% in end-user services, 10% in application development, and 8% in maintenance and administration. These savings compound over time, freeing up capital for innovation and strategic growth. More importantly, a unified system landscape enhances global visibility, and accelerates decision-making at scale. For CIOs and CFOs alike, landscape consolidation is not merely an IT optimization—it’s a business transformation lever that drives sustainable efficiency, competitive advantage, and enterprise-wide value creation.

Beyond Systems: Why Process Harmonization Matters

System consolidation alone doesn’t guarantee efficiency. Without harmonized business processes, organizations often find that operational inconsistencies persist even after technical consolidation is achieved. In other words, system consolidation without process harmonization is suboptimal from a total cost of ownership (TCO) perspective.

According to SAP Value Group benchmarks, the typical cost distribution for enterprise systems is approximately 20% hardware, 20% software, 42% development, application support, help desk, and end-user training, 12% system and data management, and 8% other. The largest cost category — development and support — can only be reduced when process variants and customizations are minimized through harmonization and standardization. For this reason, almost all companies that embark on global implementation or consolidation programs also pursue global harmonization of their business processes.

However, while IT organizations often recognize the benefits of harmonization and may attempt to implement global templates “behind the scenes,” true process harmonization cannot be successfully driven by IT alone. It is not a one-time technical exercise, but a continuous business-led transformation that requires executive sponsorship, strong governance, and a clear change management strategy. The business must own and drive harmonization initiatives, defining clear objectives that align with organizational strategy. When processes are harmonized, they enable consistent data, standardized workflows, and measurable outcomes — all of which are essential foundations for scaling intelligent automation and realizing the full efficiency potential of system consolidation.

Ultimately, while IT cost savings from ERP instance consolidation may reach 25%, the true value lies in achieving global visibility, standardized processes, and improved business coordination—benefits attainable only when system consolidation is paired with process harmonization.

How Cloud & AI Have Evolved SAP Landscape Strategy

SAP has long been at the forefront of enterprise transformation. At the core of this evolution is a shift in how enterprises view their landscapes — not just as technical environments but as strategic enablers. The pyramid structure in the diagram below highlights how harmonization and standardization at the strategic level (vision, strategy, and processes) are driving the reduction of system complexity at the operational level (infrastructure and projects). This reflects SAP’s broader goal: simplifying, standardizing, and automating across every layer of the enterprise stack.

The right side of the diagram captures how landscape simplification and consolidation have evolved in a cloud-first era. Hyperscalers have made on-premise (non-SAP managed) operations more flexible and efficient; however, the cost advantages of cloud operations are making regional or local systems increasingly attractive. At the same time, geopolitical disruptions and growing requirements for data localization are prompting enterprises to reconsider their global architectures. As business units evolve, organizations need modular IT landscapes that can adapt quickly to changing market dynamics. Finally, ongoing mergers and acquisitions are further challenging global IT solutions to remain agile and responsive.

While the drivers of change have evolved, the case for landscape consolidation remains strong — especially when considering the transition to SAP S/4HANA as it presents a unique opportunity for enterprises to re-evaluate and modernize their environments. In the new cloud-first era, the key takeaway is that process harmonization alone is not sufficient. True transformation requires a commitment to standardizing on SAP best practices and processes. Only by combining harmonization with standardization can businesses fully realize the benefits of consolidation.

Landscape Options for SAP Process Harmonization

When consolidating SAP systems, organizations can choose among several landscape options that balance process harmonization with flexibility and deployment complexity. The Single Instance Strategy represents the highest degree of process harmonization, enforcing identical procedures and configurations globally within one system. The Virtual Single Instance Strategy, often called the full template approach, also targets global standardization but allows multiple production systems connected to a common template. This option achieves strong alignment across regions but requires significant upfront effort to harmonize processes and design a robust governance framework to maintain consistency.

In contrast, the Template + Multiple Development Systems Strategy (partial template) introduces a global development system for common configurations, while local development systems handle regional adaptations. This approach lowers harmonization effort but increases deployment and maintenance complexity, as changes must be coordinated and synchronized across environments. Finally, the Multiple Development Systems Strategy allows the greatest local flexibility but risks divergence without disciplined governance. Companies without adequate oversight often drift from standardized templates toward independent, inconsistent environments—undermining the benefits of consolidation.

Strong governance and well-defined change management are essential for success, regardless of the chosen model. SAP recommends establishing detailed governance and leveraging tools like SAP Solution Manager Cross-Landscape Distribution (XLD) to manage common configurations and automate object distribution.

Why Template Strategies are so Attractive

Template strategies are appealing because they balance the competing priorities of standardization and flexibility. While a fully harmonized, single global instance delivers high transparency, operational synergies, and seamless information sharing, it can also demand significant coordination and restrict local agility. Conversely, a highly decentralized landscape with multiple independent systems enables rapid local responses, minimizes coordination overhead, and preserves legacy practices—but often sacrifices integration, efficiency, and visibility. In practice, the optimal point rarely lies at either extreme.

A well-governed global template represents the “best of both worlds.” It establishes common core processes and configurations across the enterprise, creating a unified baseline for reporting, governance, and automation, while still allowing local adaptations to meet regional or business-specific needs. This balance optimizes net benefits—achieving substantial harmonization without paralyzing flexibility. Organizations adopting this model can scale globally with consistency and efficiency, yet remain agile enough to evolve with market demands and regulatory changes.

Driving Alignment and Change Across the Enterprise

Consolidation initiatives only succeed when the business—not IT alone—owns the vision. CIOs and CFOs must jointly champion the strategy, aligning executive priorities and translating technical goals into tangible business outcomes. Indecision is worse than a decision; leaders must either commit fully to consolidation or abandon it. A half-hearted approach breeds confusion, wasted effort, and political resistance.

The business must first define why consolidation matters—whether to streamline operations, reduce costs, or enable digital scalability—before any meaningful strategy discussions can occur. The opportunity cost of doing nothing far outweighs the risks of action. Inaction means missed chances for efficiency, growth, and long-term competitiveness. A strategic approach must therefore focus on optimizing performance through technology and process enhancements to achieve sustainable growth and market advantage.

Every consolidation journey ultimately aligns with one of three business scenarios. In the “Winner Takes It All” model, a larger entity absorbs a smaller one, prioritizing cost avoidance, risk reduction, and speed—often driven by politics rather than process optimization. The “Best of Both Worlds” scenario emerges when merging entities are similar in size, each seeking to retain its systems and approaches, leading to cherry-picking, high complexity, and potential deadlock without decisive executive leadership. Lastly, the “Cluster Selection” approach consolidates around relatively autonomous units, balancing flexibility and structure while reducing political tension. Each model carries trade-offs, but success in any of them depends on clear decision-making, consistent leadership, and an unwavering focus on the business rationale behind consolidation.

Decision-Making Framework: From Strategy to Execution

For complex organizations, making the right consolidation decisions can feel daunting. A structured, business-driven framework ensures that each decision is anchored in strategy, not convenience. Consolidation must begin with clarity on why a new landscape is required. The business must first define its objectives—whether to improve visibility, reduce costs, or enable standardized global operations—and communicate the factors influencing consolidation to the IT organization. These include operational pain points, integration challenges, and the cultural readiness for adopting a global business model. Without this alignment and clear ownership, consolidation efforts risk becoming purely technical exercises detached from business value.

Once business intent is clear, IT and business leaders should collaboratively translate it into a practical landscape strategy and design. Together, they develop up to four viable landscape scenarios that reflect different balances of harmonization and flexibility. Each scenario is then assessed through an agreed-upon set of evaluation criteria—such as scalability, governance, deployment complexity, total cost of ownership, and change management impact—with weighted importance assigned to both business and operational priorities. A structured decision process, often supported by workshops or governance boards, leads to a collective vote on the final landscape design and instance strategy. From there, a project roadmap can be established to guide execution. By following this disciplined approach, organizations ensure decisions are data-driven, collaborative, and sustainable—laying the foundation for long-term enterprise value creation and true business-IT alignment.

Turning Consolidation into Competitive Advantage

The rise of SAP S/4HANA Cloud (Private and Public Editions), SAP Business Technology Platform (BTP), and Business Data Cloud (BDC) has transformed how organizations approach landscape consolidation. These platforms provide the flexibility to run modern SAP systems across hybrid and multi-cloud environments, supported by AI-driven insights and automation.

SAP’s Business AI capabilities now automate repetitive tasks, predict trends, and enable intuitive, conversational interactions with business systems. By embedding intelligence directly into processes, organizations gain speed, accuracy, and foresight — shifting their focus from data collection to decision-making.

SAP landscape consolidation is no longer a technical exercise — it’s a strategic imperative for building an intelligent, agile enterprise. By harmonizing systems and processes, embracing cloud-native tools, and integrating AI, businesses position themselves for operational excellence and continuous innovation. In an era where speed and intelligence define market leaders, the organizations that master landscape consolidation today will define the intelligent enterprises of tomorrow.

Consider SAP Customer Advisory

If your organization is planning or evaluating an SAP instance strategy, our team at SAP Customer Advisory can help. We offer tailored guidance to align your architecture vision with business goals, accelerate transformation, and maximize value creation. Connect with me on LinkedIn to explore how we can shape your SAP strategy together.

Solution Order Simulation APIs - OData V4

2025-11-10T11:10:34.647000+01:00

Introduction

Solution Order is a business transaction in SAP Cloud ERP, used to sell solutions which can be a combination of either physical goods, one time services, recurring services, subscriptions, or projects bundled as one integrated customer offering. With the 2508 release of SAP Cloud ERP, the OData V4 APIs for simulation of solution order is available. Simulation APIs can be used to simulate various entities of solution order without creating a solution order. Various determination logic like partner determination, price determination, billing plan etc can be simulated without creating a solution order. This can be used to provide a quote using a quoting engine outside of SAP Cloud ERP. Such external quoting solutions can benefit from the possibility of quoting a real time price calculated in SAP Cloud ERP using the Solution Order simulation APIs. In this blog, you will find more information about the API, the entities available for consumption and the operations on these entities.

Authentication and Access

The communication arrangement with the Business Solution Order Integration scenario(SAP_COM_0706) needs
to be in place to access the API. You will need to create a communication arrangement for the communication scenario
SAP_COM_0706, A communication system with an inbound user. You can as well configure OAUTH 2.0 if
needed.

The API supports Basic Authentication(username/password), OAUTH2.0, and X.509 Certificate Authentication

Metadata

Metadata provides a description of the service, detailing the structure of the data, available entities, their
properties, relationships, and supported operations. It acts as a blueprint that allows both developers and tools
to understand how to interact with the service without needing prior knowledge of its design.
It can be accessed using the below URL
https://<<SERVER>>/sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/api_bussolnordsimulation/0001/$metadata
Below is a screenshot, with a part of the metadata of the Business Solution Order API.

In the above partial view of the metadata, you can see the Entity BusinessSolutionOrderItem, it has 2 key fields - BusinessSolutionOrder and BusinessSolutionOrderItem, a set of properties like Product, Quantity, BusSolnOrdItmCategory, etc. it also specifies the type, max length, precision etc of the properties. There are a set of navigational properties(or associations) for the entity. Associations are other entities related to the current entity.

API Capabilities and Entities

Entity	Supported Operations	Description	Associations
BusinessSolutionOrder	CREATE (Simulate)	Solution Order Header	_Item _Partner
BusinessSolutionOrderItem	CREATE (Simulate) only using deep insert on BusinessSolutionOrder	Solution Order Item	_BusinessSolutionOrder _Partner _PriceElement _BillingRequestItem
BusSolnOrdPartner	CREATE (Simulate) only using deep insert on BusinessSolutionOrder	Header Partner	_BusinessSolutionOrder
BusSolnOrdItmPartner	CREATE (Simulate) only using deep insert on BusinessSolutionOrder	Item Partner	_BusinessSolutionOrder _Item
BusSolnOrdItmPriceElement	CREATE (Simulate) only using deep insert on BusinessSolutionOrder	Item Price Element	_BusinessSolutionOrder _Item
BusSolnOrdItmBillgReqItem	CREATE (Simulate) only using deep insert on BusinessSolutionOrder	Billing Request Line of a Contract Item	_BusinessSolutionOrder _Item

BusinessSolutionOrder – Solution Order Header

Simulate solution order with one item to get header and item entities with simulated net value

You can add any number of items to simulate.

POST <host> /sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/bussolnordersimulation/0001
/BusinessSolutionOrder

X-CSRF-Token: abc
{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Simulation Demo",
  "SoldToParty": "17100001",
  "PayerParty": "17100001",
  "PaymentTerms": "0001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "_Item": [
    {
      "Product": "TG11",
      "Quantity": 1,
      "BusSolnOrdItmQtyUnitISOCode": "PCE"
    }
  ]
}

BusSolnOrdPartner – Solution Order Header Partner

You can pass an empty _Partner:[] entity in the payload to read the header partners that are determined based on the partner determination procedure assigned to the solution order transaction.

POST <host> /sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/bussolnordersimulation/0001
/BusinessSolutionOrder

X-CSRF-Token: abc

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Simulation Demo",
  "SoldToParty": "17100001",
  "PayerParty": "17100001",
  "PaymentTerms": "0001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
 
  //Empty Partner association in payload to return the simulated entity in response
  "_Partner":[],
  
  "_Item": [
    {
      "Product": "TG11",
      "Quantity": 1,
      "BusSolnOrdItmQtyUnitISOCode": "PCE"
    }
  ]
}

BusSolnOrdItmPartner – Solution Order Item Partner

Similar to header partner, You can pass an empty _Partner:[] entity in the payload to read the item partners that are determined based on the partner determination procedure assigned to the item category.

POST <host> /sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/bussolnordersimulation/0001
/BusinessSolutionOrder

X-CSRF-Token: abc

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Simulation Demo",
  "SoldToParty": "17100001",
  "PayerParty": "17100001",
  "PaymentTerms": "0001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "_Item": [
    {
      "Product": "TG11",
      "Quantity": 1,
      "BusSolnOrdItmQtyUnitISOCode": "PCE",
      
      //Empty Partner association in payload to return the simulated entity in response
      "_Partner": []
    }
  ]
}

You can also override a partner determined in simulation by passing the updated partner in the payload. This can be useful to for example simulate changes in shipping cost based on the address of a new partner that is passed which is different from the determined partner.

POST <host> /sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/bussolnordersimulation/0001
/BusinessSolutionOrder

X-CSRF-Token: abc

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Simulation Demo",
  "SoldToParty": "17100001",
  "PayerParty": "17100001",
  "PaymentTerms": "0001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "_Item": [
    {
      "Product": "TG11",
      "Quantity": 1,
      "ShipToParty": "17100002",
      "BusSolnOrdItmQtyUnitISOCode": "PCE",
      
      "_Partner": [
        {
          "CustMgmtPartnerFunction": "00000055",
          "CustMgmtBusinessPartner": "17100002"
        }
      ]
    }
  ]
}

BusSolnOrdItmPriceElement – Item Price Element

Similar to partners, You can pass an empty _PriceElement[] entity in the payload to read the item price elements that are calculated based on the pricing procedure assigned.

How ever you can also pass a new price element in simulation request like a discount to simulate the solution order with the discount condition

POST <host> /sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/bussolnordersimulation/0001
/BusinessSolutionOrder

X-CSRF-Token: abc
{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Simulation Demo",
  "Language": "EN",
  "SoldToParty": "17100001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "_Item": [
    {
      "Product": "TG12",
      "Quantity": 1,
      "BusSolnOrdItmQtyUnitISOCode": "EA",
      
      //Adding a fixed discount
      "_PriceElement": [
        {
          "ConditionType": "DRV1",
          "ConditionRateValue": -10,
          "ConditionCurrency": "USD"
        }
      ]
    }
  ]
}

BusSolnOrdItmBillgReqItem – Item Billing Request Item(Contract Item)

Billing Request Line item is relevant for a service contract item of type SOSC(Service Contract Item) and SOPA(Service Contract Item with Price Adaptation). You can simulate the billing plan by providing the billing date and settlement period in the payload and you will see the Billing Request Items accordingly. For example if you provide a settlement period as monthly for a contract running for 1 year, you will see 12 Billing Request Items in the simulation response.

POST <host> /sap/opu/odata4/sap/api_bussolnordsimulation/srvd_a2x/sap/bussolnordersimulation/0001
/BusinessSolutionOrder

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Simulation of BRLs",
  "SoldToParty": "17100001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "_Item": [
    {
      "BusinessSolutionOrderItem": "10",
      "Product": "SRV_CONTRACT",
      "BusSolnOrdItmCategory": "SOSC",
      "Quantity": 1,
      "QuantityUnit": "AU",
      "BusSolnOrdItmQtyUnitISOCode": "C62",

      // Billing date first of the month
      "SrvcMgmtBillgPlanBillgDateRule": "BILL0002",
      // Settlement period - monthly billing
      "SettlementPeriodRule": "BILL0001",

      "ServiceContrItemStartDateTime": "2025-08-13T00:00:00Z",
      "ServiceContrItemEndDateTime": "2026-08-13T00:00:00Z",
      "_BillingRequestItem": [],
      "_PriceElement": []
    }
  ]
}

Solution Order APIs - OData V4

2025-11-11T15:16:58.766000+01:00

Introduction

Authentication and Access

The communication arrangement with the Business Solution Order Integration scenario(SAP_COM_0706) needs to be in place to access the APIs. You will need to create a communication arrangement for the communication scenario SAP_COM_0706, A Communication System with an inbound user. You can as well configure OAUTH 2.0 if needed.

The API allows Basic Authentication(Username/password), OAUTH2.0, and X.509 Certificate Authentication

Metadata

It can be accessed using the below URL

https://<<SERVER>>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001/$metadata

Below is a screenshot, with a part of the metadata of the Business Solution Order API.

In the above partial view of the metadata, you can see the Entity BusinessSolutionOrder, it has key- BusinessSolutionOrder, and a set of properties like BusinesssSolutionOrder, BusSolnOrdType, BusSolnOrdDescription, etc. it also specifies the type, max length, precision etc of the property. There are a set of navigational properties(or associations) for the entity. Associations are other entities related to the current entity.

API Capabilities and Entities

Entity	Supported Operations	Comments	Associations
BusinessSolutionOrder	CREATE / READ / UPDATE	Solution Order Header	_Items _Partner _Text _UserStatus _ItemRelationship _FUPSalesOrder _FUPServiceOrder _FUPServiceContr _FUPEntProject _FUPSubscrpn _Appointment
BusinessSolutionOrderItem	CREATE / READ / UPDATE / DELETE	Solution Order Item For Create operation, you can only use this entity in association with BusinessSolutionOrder	_Partner _PriceElement _Text _ScheduleLine _UserStatus _Product _ReferenceObject _BillingRequestItem _RateElement _SubscriptionParameter _SubscriptionPriceAgreement _FUPSalesOrderItem _FUPServiceOrderItem _FUPServiceContrItem _FUPEntProjectItem _FUPSubscrpnItem _Appointment _Duration _BusinessSolutionOrder
BusSolnOrdPartner	CREATE / READ / UPDATE / DELETE	Header Partner For Create operation, you can only use this entity in association with BusinessSolutionOrder	_PartnerAddress _BusinessSolutionOrder
BusSolnOrdItmPartner	CREATE / READ / UPDATE / DELETE	Item Partner For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_PartnerAddress _Item _BusinessSolutionOrder
BusSolnOrdPartnerAddress	READ / UPDATE	Header Partner Address	_Partner _BusinessSolutionOrder
BusSolnOrdItmPartnerAddr	READ / UPDATE	Item Partner Address	_Partner _BusinessSolutionOrder
BusSolnOrdItmPriceElement	CREATE / READ / UPDATE / DELETE	Item Price Element For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_Item _BusinessSolutionOrder
BusSolnOrdItmScheduleLine	READ	Schedule Line of Sales Item	_Item _BusinessSolutionOrder
BSOrdItmRateElement	READ	Rate Element of a Subscription Item	_Item _BusinessSolutionOrder
BSOrdItmSubscrpnParameter	CREATE / READ / UPDATE / DELETE	Subscription Parameter of a Subscription Item	_Item _BusinessSolutionOrder
BSOrdItmSubscrpnPriceAgrmt	CREATE / READ / UPDATE / DELETE	Price Agreement of Subscription Item	_Item _BusinessSolutionOrder
BusSolnOrdItmProduct	CREATE / READ / UPDATE / DELETE	Item Product For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_Item _BusinessSolutionOrder
BusSolnOrdItmRefObject	CREATE / READ / UPDATE / DELETE	Item Reference Object For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_Item _BusinessSolutionOrder
BusSolnOrdItemRelationship	CREATE / READ / DELETE	Item Relationship For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_BusinessSolutionOrder
BusSolnOrdUserStatus	CREATE / READ	Header User Status For Create operation, you can only use this entity in association with BusinessSolutionOrder	_BusinessSolutionOrder
BusSolnOrdItmUserStatus	CREATE / READ	Item User Status For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_Item _BusinessSolutionOrder
BusinessSolutionOrderLongText	CREATE / READ / UPDATE / DELETE	Header Text	_BusinessSolutionOrder
BusSolnOrdItmLongTxt	CREATE / READ / UPDATE / DELETE	Item Text For Create operation, you can only use this entity in association with BusinessSolutionOrderItem	_Item _BusinessSolutionOrder
BusSolnOrdItmBillgReqItem	READ	Billing Request Item of a Contract Item	_PriceElement _Item _BusinessSolutionOrder
BSOrdItmBillgReqItmPrcElm	CREATE/READ / UPDATE/DELETE	Price Element of Billing Request Line For Create operation, you can only use this entity in association with BusSolnOrdItmBillgReqItem	_BillingRequestItem _Item _BusinessSolutionOrder
BusSolnOrdAppointment	CREATE / READ / UPDATE	Header Appointments	_BusinessSolutionOrderTP
BusSolnOrdItmAppointment	CREATE / READ / UPDATE	Item Appointments	_Item _BusinessSolutionOrder
BusSolnOrdItmDuration	CREATE / READ / UPDATE	Item Duration	_Item _BusinessSolutionOrderTP
BusSolnOrdFUPSalesOrder	READ	Follow Up Sales Orders	_BusinessSolutionOrder
BusSolnOrdFUPSrvcOrd	READ	Follow Up Service Orders	_BusinessSolutionOrder
BusSolnOrdFUPSrvcContr	READ	Follow Up Service Contracts	_BusinessSolutionOrder
BusSolnOrdFUPSubscrpn	READ	Follow Up Subscriptions	_BusinessSolutionOrder
BusSolnOrdFUPEntProject	READ	Follow Up Projects	_BusinessSolutionOrder
BusSolnOrdItmFUPSalesOrder	READ	Follow Up Sales Order Items	_Item _BusinessSolutionOrder
BusSolnOrdItmFUPSrvcOrd	READ	Follow Up Service Order Items	_Item _BusinessSolutionOrder
BusSolnOrdItmFUPSrvcContr	READ	Follow Up Service Contract Items	_Item _BusinessSolutionOrder
BusSolnOrdItmFUPSubscrpn	READ	Follow Up Subscription Items	_Item _BusinessSolutionOrder
BusSolnOrdItmFUPEntProject	READ	Follow Up Project Items	_Item _BusinessSolutionOrder

BusinessSolutionOrder – Solution Order Header

With the Solution Order Header entity and its associations, you can create a solution order with the header and one or more of its associated entity(and its associated entities).

For Example: You can create a solution order by using the BusinessSolutionOrder along with Items, Partner, Item Partner, PriceElement, ItemRelationship, Text, UserStatus etc.

In the below example you will see creation of a solution order, adding items to the solution orders, creating a header text, and creating an item relationship between two items, all in separate OData calls and also to see how this can be achieved in one deep insert ODATA calls

Create a solution order with just header

POST <host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder

X-CSRF-Token: abc

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Solution Order",
  "Language": "EN",
  "SoldToParty": "17100001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "PurchaseOrderByCustomer": "External Reference"
}

Create an Item for an existing solution order

POST <host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100004251/_Item

X-CSRF-Token: abc

{
  "Product": "TG11",
  "BusinessSolutionOrderItem": "10",
  "Quantity": 1,
  "QuantityUnit": "PC",
  "BusSolnOrdItmQtyUnitISOCode": "PCE"
}

Create another Item for an existing solution order

POST <host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100004251/_Item

X-CSRF-Token: abc

{
  "Product": "SRV_01",
  "BusinessSolutionOrderItem": "20",
  "Quantity": 1,
  "SrvcContrDetnIsSpprsd": true,
  "QuantityUnit": "HR",
  "BusSolnOrdItmQtyUnitISOCode": "HUR"
}

Create a Header Text for an existing solution order

POST <host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100004251/_Text

X-CSRF-Token: abc

{
  "TextObjectType": "0001",
  "Language": "EN",
  "BusinessSolutionOrderLongText": "This is a Header Note"
}

Create an item relationship between item 10 and item 20 of an existing solution order

POST <host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100004251/_ItemRelationship

X-CSRF-Token: abc

{
  "BusinessSolutionOrder":"<<SOLUTION_ORDER_ID>>",
  "SrvcItemRelshpFromItemNumber": "10",
  "SrvcItemRelshpType": "001",
  "SrvcItemRelshpToItemNumber": "20"
}

You can also perform all the above in one deep insert OData request by specifying all the related entities in a single request

Create a solution order with deep insert: 2 items, override header partner, override item partner, add a header note and create an item relationship between item 10 and 20

POST <host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder

X-CSRF-Token: abc

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Solution Order",
  "Language": "EN",
  "SoldToParty": "17100001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "PurchaseOrderByCustomer": "External Reference",

  //Solution Order Item
  "_Item": [
    {
      "Product": "TG11",
      "BusinessSolutionOrderItem": "10",
      "Quantity": 1,
      "QuantityUnit": "PC",
      "BusSolnOrdItmQtyUnitISOCode": "PCE",
      "_Partner": [
        {
          "CustMgmtPartnerFunction": "00000055",
          "CustMgmtBusinessPartner": "17100003"
        }
      ]
    },
    {
      "Product": "SRV_01",
      "BusinessSolutionOrderItem": "20",
      "SrvcContrDetnIsSpprsd": true,
      "Quantity": 1,
      "QuantityUnit": "HR",
      "BusSolnOrdItmQtyUnitISOCode": "HUR"
    }
  ],

  //Partner at Header
  "_Partner": [
    {
      "CustMgmtPartnerFunction": "00000055",
      "CustMgmtBusinessPartner": "17100002"
    }
  ],

  //Notes at Header
  "_Text": [
    {
      "TextObjectType": "0001",
      "Language": "EN",
      "BusinessSolutionOrderLongText": "This is a Header Note"
    }
  ],

  //Relationship between Items
  "_ItemRelationship": [
    {
      "SrvcItemRelshpFromItemNumber": "10",
      "SrvcItemRelshpType": "001",
      "SrvcItemRelshpToItemNumber": "20"
    }
  ]
}

Read all the entities of a solution order

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003509?$expand=*

Read one or more associated entities of a solution order header

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003509?$expand=_Partner,_ItemRelationship

BusinessSolutionOrderItem – Solution Order Item

With the Solution Order Item entity, you can create one ore more of its associated entity. However, to create a solution order item, you will have to use the BusinessSolutionOrder along with _Item association.

For Example: You can create an Item Partner, PriceElement, Text, UserStatus etc for an item using the BusinessSolutionOrderItem along with the respective associations.

In the below examples you will see creation of a discount price condition, Item Text, Item Product, Reference Object, Item Appointment, Item Duration, Price Agreement for an existing solution order item,

Create a discount price element for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/20/_PriceElement

X-CSRF-Token: abc

{
  "ConditionType": "DRV1",
  "ConditionRateValue": -10
}

Create an item text for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/10/_Text

X-CSRF-Token: abc

{
  "TextObjectType": "0001",
  "Language": "EN",
  "BusSolnOrdItmLongText": "This is an Item Note"
}

Create an item product for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/30/_Product

X-CSRF-Token: abc

{
  "ServiceProductListItem": "1",
  "SrvcProductListProduct": "SRV_01"
}

Create item reference object for an existing solution order Service item

For a service item, you can create a reference object by passing either the functional location id or the equipment id.

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/20/_ReferenceObject

X-CSRF-Token: abc

{
  "ServiceReferenceEquipment":"10001405"
}

Create item reference object for an existing solution order Service item

For a contract item, you can create a reference object by passing either the functional location id or the equipment id or the Reference Product.

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/20/_ReferenceObject

X-CSRF-Token: abc

{
  "ServiceReferenceProduct":"10001405"
}

Create an item appointment for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/50/_Appointment

X-CSRF-Token: abc

{
  "SrvcDocAppointmentType":"SUBS_PRIC_DT",
  "SrvcDocApptStartDateTime":"2025-09-28T10:00:00Z",
  "SrvcDocApptEndDateTime":"2025-09-28T10:00:00Z"
}

Appointment entities are used to persist various date fields in solution order.

You define the Appointment type using the configuration activity Define Date Types, Duration Types and Date Rules for Service Transactions in your configuration environment. The system uses the duration, dates types, and date rules that are combined in a specific date profile to display dates in a transaction and to automatically determine them. Make sure to assign the date profile to transaction types.

Create an item duration for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003519/30/_Duration

X-CSRF-Token: abc

{
  "SrvcDocDurationType": "CONTDURA",
  "SrvcDocDurationValue": 18,
  "SrvcDocDurationUnit": "MONTH"
}

Fields on the UI like Fixed Term, Minimum Term, Minimum Term End, Renewal Term, Withdrawal Period, Withdrawal Period End, Term of Notice, Expected Term, Expected Term End, Expected Term Extension (visible under the Subscription Terms section in the UI), and Contact Validity Period (visible in the Dates Section of a contract item)are available in the Item Duration entity. These are persisted against the duration types below. The subscription terms can be updated in the UI as well as API only if the field “Override Default Terms” is selected (field in API - SubscrpnContrTrmsAreSpecified)

You define the Duration type using the configuration activity Define Date Types, Duration Types and Date Rules for Service Transactions in your configuration environment. The system uses the duration, dates types, and date rules that are combined in a specific date profile to display dates in a transaction and to automatically determine them. Make sure to assign the date profile to transaction types.

Create an item price agreement for an existing solution order subscription item

Price agreements are originally persisted in the subscription system, however this can be customised in the S/4HANA system. In such cases, the customised values are additionally persisted in S/4HANA systems.

Under the Price Calculation section you will see the prices that can be customisable. You can customize the price using the POST operation on the BusinessSolutionOrderItem entity using the _SubscriptionPriceAgreement association.

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001 /BusinessSolutionOrderItem/100003519/50/_SubscriptionPriceAgreement

X-CSRF-Token: abc

{
  "SubscriptionRateElement": "ONETIME",
  "SubscrpnBillgPrcElmntSpec": "OneTimePrice",
  "SubscrpnBillgPricingField": "price",
  "SubscrpnBillgPricingScaleType": "A",
  "SubscrpnBillgCndnCalcType": "B",
  "ConditionCurrency": "USD",
  "ConditionRateValue": 190,
  "SbscrBilgCndnScaleLineIsUnlmtd": false
}

Once the price is updated in S/4HANA it is persisted and you will notice under the customization status as Is Customized.

Since there is no persistency in the S/4HANA system until it is customised, the first time the customising of the price can be done using a POST operation of the API, and to update the prices again a PATCH operation can be used.

Multiple Price calculation is not supported. However if you still use the POST again after the initial customising, there will be 2 entries of the price which will be persisted in the table.

In such case the entire Price calculation section will become empty and the solution order item will unusable in the UI along with a simulation error. This cannot be corrected from the UI. To correct this, you will have to delete the record using the DELETE operation on the Item Price Agreement entity (BSOrdItmSubscrpnPriceAgrmt).

BusSolnOrdPartner – Solution Order Header Partner

Solution Order determines header partners based on the partner determination procedure assigned to the transaction type.

To override the determined partners, you can pass the partner information either using the partner functions available as properties in the BusinessSolutionOrder entity like ShipToParty, BillToParty, PayerParty, RespEmployeeBusinessPartnerId and ContactPersonBusinessPartnerId or by passing the respective partners in the _Partner association while creating a solution order using deep insert.

The header partner entity can also be created using the association _Partner of the BusinessSolutionOrder entity but this may result in a too many partner error on the document. So If you use the _Partner association to create a partner at header make sure the entry you are trying to create doesn’t create an additional partner of an existing type.

Create a header partner for an existing solution order

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003561/_Partner

X-CSRF-Token: abc
IF-Match: *

{
  "BusinessSolutionOrder":"100003561",
  "CustMgmtPartnerFunction":"00000003",
  "CustMgmtBusinessPartner":"17100002"
}

If you observe the metadata of the header partner entity, You will notice that both the properties CustMgmtPartnerFunction and CustMgmtBusinessPartner are key properties and hence they cannot be updated via a PATCH call. So to update a header partner, you can use the properties ShipToParty, BillToParty, PayerParty, RespEmployeeBusinessPartnerId and ContactPersonBusinessPartnerId in the BusinessSolutionOrder entity.

You should not try to update the SoldToPrarty property either at the header or the item.

Delete a header partner of an existing solution order

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdPartner/100003561/00000003/17100001

X-CSRF-Token: abc
IF-Match: *

Deleting a header partner might result in an error if the partner function is mandatory.

BusSolnOrdItmPartner – Solution Order Item Partner

Solution Order determines item partners based on the partner determination procedure assigned to the transaction type and the header partner.

To override the determined partners, you can pass the partner information either using the partner functions available as properties in the BusinessSolutionOrderItem entity like ShipToParty, BillToParty, PayerParty, RespEmployeeBusinessPartnerId and ContactPersonBusinessPartnerId or by passing the respective partners in the _Partner association while creating a solution order using deep insert.

The item partner entity can also be created using the association _Partner of the BusinessSolutionOrderItem entity but this may result in a too many partner error on the document. So If you use the _Partner association to create a partner at the item make sure the entry you are trying to create doesn’t create an additional partner of an existing type.

Create an item partner for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100003561/10/_Partner

X-CSRF-Token: abc

{
  "BusinessSolutionOrder":"100003561",
  "BusinessSolutionOrderItem":"10",
  "CustMgmtPartnerFunction":"00000003",
  "CustMgmtBusinessPartner":"17100002"
}

If you observe the metadata of the item partner entity, You will notice that both the properties CustMgmtPartnerFunction and CustMgmtBusinessPartner are key properties and hence they cannot be updated via a PATCH call. So to update an item partner, you can use the properties ShipToParty, BillToParty, PayerParty, RespEmployeeBusinessPartnerId and ContactPersonBusinessPartnerId in the BusinessSolutionOrderItem entity. You should not try to update the SoldToPrarty property either at the header or the item.

Delete an item partner of an existing solution order item

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdPartnerItem/100003561/10/00000003/17100001

X-CSRF-Token: abc
IF-Match: *

Deleting an item partner might result in an error if the partner function is mandatory.

BusSolnOrdPartnerAddress – Address of Header Partner

Address of header partner can be read and updated

Update address of header partner of an existing solution order

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdPartnerAddress/100004251/00000003/17100001

X-CSRF-Token: abc
IF-Match: *

{
  "HouseNumber": "138",
  "StreetName": "ITPL Main Road",
  "CityName": "Banglaore",
  "Country": "IN",
  "Region": "KA",
  "PostalCode": "560066",
  "MobilePhoneCountry": "IN",
  "MobileNumber": "9988776655",
  "PhoneNumberCountry": "US",
  "PhoneNumber": "20204040",
  "PhoneExtensionNumber": "1234",
  "FaxNumberCountry": "IN",
  "FaxAreaCodeSubscriberNumber": "1234567890",
  "FaxExtensionNumber": "5678",
  "EmailAddress": "newmailaddr@mailbox.com"
}

BusSolnOrdItmPartnerAddr - Address of Item Partner

Address of item partner can be read and updated

Update address of item partner of an existing solution order item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmPartnerAddr/100004251/10/00000003/17100001

X-CSRF-Token: abc
IF-Match: *

{
  "HouseNumber": "138",
  "StreetName": "ITPL Main Road",
  "CityName": "Banglaore",
  "Country": "IN",
  "Region": "KA",
  "PostalCode": "560066",
  "MobilePhoneCountry": "IN",
  "MobileNumber": "9988776655",
  "PhoneNumberCountry": "US",
  "PhoneNumber": "20204040",
  "PhoneExtensionNumber": "1234",
  "FaxNumberCountry": "IN",
  "FaxAreaCodeSubscriberNumber": "1234567890",
  "FaxExtensionNumber": "5678",
  "EmailAddress": "newmailaddr@mailbox.com"
}

BusSolnOrdItmPriceElement – Item Price Element

Item price element of a solution order item can be created by passing the price element in the _PriceElement association at the item while creating a solution order using deep insert.

The item price element entity can also be created using the association _ PriceElement of the BusinessSolutionOrderItem entity.

Create an item price element for an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/10/_PriceElement

X-CSRF-Token: abc

{
  "ConditionType": "DRV1",
  "ConditionRateValue": -10
}

If you create a price element with the same condition type as existing, it will override the existing price element and will mark it inactive and make the new one active.

Update item price element of an existing solution order item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmPriceElement/100004251/10/240/1

X-CSRF-Token: abc
IF-Match: *

{
  "BusinessSolutionOrder": "100004251",
  "BusinessSolutionOrderItem": "10",
  "PricingProcedureStep": "240",
  "PricingProcedureCounter": "1",
  "ConditionType": "DRV1",
  "ConditionRateValue": -5
}

The PricingProcedureStep and PricingProcedureCounter needs to be passed in the parameter

Delete an item price element of an existing solution order item

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmPriceElement/100004251/10/240/1

X-CSRF-Token: abc
IF-Match: *

To Deleting an item price element, PricingProcedureStep and PricingProcedureCounter needs to be passed in the parameter.

BusSolnOrdItmScheduleLine – Item Schedule Line(Sales Item)

You can only read a schedule line entity and no other operations are supported on this entity, and this is only relevant for a sales item

Read a schedule line of a sales item of an existing solution order

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmScheduleLine/100004251/10/1

You can also use the $filter parameter to filter by the solution order you will get all the schedule line entities for the solution order

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmScheduleLine?$filter=BusinessSolutionOrder eq '100004251'

BSOrdItmRateElement – Item Rate Element (Subscription Item)

You cannot update a rate element but can read an existing rate element for a solution order subscription item using BSOrdItmRateElement

By passing the solution order number, item and rate element number. You can also read the rate element when you read a solution order item with an expand=_RateElement

BSOrdItmSubscrpnParameter – Item Subscription Parameter(Subscription Item)

You can read a subscription parameter using a GET operation on the BSOrdItmSubscrpnParameter entity by passing the solution order number, item and the subscription parameter sequence number or by reading the solution order item with a $expand = _SubscriptionParameter

Update subscription parameter of an existing solution order item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BSOrdItmSubscrpnParameter/100004251/70/1

X-CSRF-Token: abc

IF-Match: *

{
  "SubscriptionParameter": "ONETIME_CREDIT",
  "SubscrpnParameterIntegerValue": 2
}

You can update a subscription parameter of a subscription item only if the item is not released or completed already

Delete subscription parameter of an existing solution order item

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BSOrdItmSubscrpnParameter/100004251/70/1

X-CSRF-Token: abc
IF-Match: *

You can delete a subscription parameter of a subscription item only if the item is not released or completed already

Create subscription parameter of an existing solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/70/_SubscriptionParameter

X-CSRF-Token: abc
IF-Match: *

{
  "SubscriptionParameter": "ONETIME_CREDIT",
  "SubscrpnParameterIntegerValue": 1
}

You can create a subscription parameter of a subscription item using the POST operation on BusinessSolutionOrderItem using the association _SubscriptionParameter

BSOrdItmSubscrpnPriceAgrmt Item Price Agreement(Subscription Item)

Update subscription price agreement of an existing solution order item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BSOrdItmSubscrpnPriceAgrmt(BusinessSolutionOrder='100004251',BusinessSolutionOrderItem='000070',SubscriptionRateElement='ONETIME_CRDT',SubscriptionRateSubElement='',SubscrpnBillgPrcElmntSpec='OneTimePrice',SubscrpnBillgPricingField='price',SubscrpnBillgPrcAgreementLine='900001')

X-CSRF-Token: abc
IF-Match: *

{
  "SubscrpnBillgPricingScaleType": "A",
  "SubscrpnBillgCndnCalcType": "B",
  "ConditionRateValue": 1001,
  "ConditionCurrency": "USD"
}

Delete subscription price agreement of an existing solution order item

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BSOrdItmSubscrpnPriceAgrmt(BusinessSolutionOrder='100004251',BusinessSolutionOrderItem='000070',SubscriptionRateElement='ONETIME_CRDT',SubscriptionRateSubElement='',SubscrpnBillgPrcElmntSpec='OneTimePrice',SubscrpnBillgPricingField='price',SubscrpnBillgPrcAgreementLine='900001')

X-CSRF-Token: abc
IF-Match: *

You can update or delete a subscription price agreement of a subscription item only if the item is not released or completed already. To be sure you pass the mandatory information correctly, you can do a GET operation on the BSOrdItmSubscrpnPriceAgrmt entity for the subscription item you want to update the price Agreement. It is required to pass the scale type and calculation type in the payload even though you do not intend to modify them

BusSolnOrdItmProduct – Item Product(Contract Item)

Update item product list of an existing solution order contract item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmProduct/100004251/100/1

X-CSRF-Token: abc
IF-Match: *

{
  "SrvcProductListProduct":"SRV_05"
}

Delete subscription price agreement of an existing solution order item

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmProduct/100004251/100/1

X-CSRF-Token: abc
IF-Match: *

You can update or delete an Item Product List of contract item only if the item is not released or completed already.

BusSolnOrdItmRefObject – Item Reference Object(Service or Contract Item)

Update item reference object list of an existing solution order contract item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmProduct/100004251/100/1

X-CSRF-Token: abc
IF-Match: *

{
  "SrvcProductListProduct":"SRV_05"
}

Delete item reference object list of an existing solution order contract item

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmRefObject/100004251/100/1

X-CSRF-Token: abc
IF-Match: *

You can update an Item Reference object of a service item by passing the equipment id or the functional location id in the payload or that of a contract item by passing the reference product id or the equipment id or the functional location id in the payload.

BusSolnOrdItemRelationship – Solution Order Item Relationship

Get all item relationships in a solution order

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItemRelationship?$filter=BusinessSolutionOrder eq '100004251'

Delete an item relationship of type 001 (Depends on) between item 10 and 20

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItemRelationship/100004251/10/001/20

X-CSRF-Token: abc
IF-Match: *

BusSolnOrdUserStatus – Header User Status

Create user status at header for an existing solution order

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/<<SOLO_ID>>/_UserStatus

X-CSRF-Token: abc

{
  "BusinessSolutionOrder": "100004251",
  "UserStatus": "E0002"
}

Create user status at header using deep insert while creating a solution order

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder

X-CSRF-Token: abc

{
  "BusSolnOrdType": "SOLO",
  "BusSolnOrdDescription": "Solution Order with User Status",
  "Language": "EN",
  "SoldToParty": "17100001",
  "SalesOrganization": "1710",
  "DistributionChannel": "10",
  "Division": "00",
  "RespEmployeeBusinessPartnerId": "9980000549",
  "PurchaseOrderByCustomer": "External Reference",
  "_UserStatus": [
    {
      "UserStatus": "E0002"
    }
  ]
}

BusSolnOrdItmUserStatus – Item User Status

Prerequisites: Make sure to assign the status profile to which the user status belongs to the respective item category of the solution order item. To do this, using SSCUI, define status profile for User Status and assign the status profile to item categories

Create item user status at item for an existing solution order

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100004251/10/_UserStatus

X-CSRF-Token: abc

{
  "UserStatus": "E0002"
}

Create item user status using deep insert while creating a solution order item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100004251/_Item

X-CSRF-Token: abc

{
  "Product": "TG11",
  "Quantity": 1,
  "BusSolnOrdItmQtyUnitISOCode": "EA",
  "_UserStatus": [
    {
      "UserStatus": "E0002"
    }
  ]
}

BusinessSolutionOrderLongText – Header Long Text

Get all header text of a solution order

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderLongText?$filter=BusinessSolutionOrder eq '100004251'

Get a specific header text of a solution order

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderLongText/100004251/0001/EN

Update a header text of a solution order

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderLongText/100004251/0001/EN

X-CSRF-Token: abc
IF-Match: *

{
  "BusinessSolutionOrderLongText":"Updated Header Text"
}

Delete a header text of a solution order

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderLongText/100004251/0001/EN

X-CSRF-Token: abc
IF-Match: *

BusSolnOrdItmLongTxt – Item Long Text

Get item text of a solution order item 10

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmLongTxt?$filter=BusinessSolutionOrder eq '100004251'and BusinessSolutionOrderItem eq '10'

Update item text of a solution order item 10

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmLongTxt/100004251/10/001/EN

X-CSRF-Token: abc
IF-Match: *

{
  "BusSolnOrdItmLongText": "Updated Item Text"
}

Delete item text of a solution order item 10

DELETE
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmLongTxt/100004251/10/001/EN

X-CSRF-Token: abc
IF-Match: *

BusSolnOrdItmBillgReqItem – Billing Request Item(of a Contract Item)

Only READ operation is supported on the BusSolnOrdItmBillgReqItem entity. This will be available only for service contract item with item category SOSC (Service Contract Item) and SOPA (Service Contract Price Adaptation)

Get all Billing Request Items of a solution order contract item

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmBillgReqItem?$filter=BusinessSolutionOrder eq '100004251'

Get a specific billing request item of a solution order contract item by id

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmBillgReqItem/100004251/100/800001

BSOrdItmBillgReqItmPrcElm – Price element of Billing Request Item (Contract Item)

You can create a Price Element for a Billing request Item of a Contract item of a solution order using the _PriceElement association of the BusSolnOrdItmBillgReqItem entity.

Create a discount price element for a specific billing item a solution order service contract item

POST
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmBillgReqItem/100004251/100/800001/_PriceElement

X-CSRF-Token: abc

{
  "ConditionType": "DRV1",
  "ConditionRateValue": -10,
  "ConditionCurrency": "USD"
}

Above payload will create a price element (Fixed Discount DRV1) for billing item 800001 of the service contract item

Read all the price element for a billing request item of a solution order contract item

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmBillgReqItem/100004251/100/800001/_PriceElement

Update a price element for a billing request item of a solution order contract item

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BSOrdItmBillgReqItmPrcElm/100004251/100/800001/90/1

X-CSRF-Token: abc
IF-Match: *

{
   "ConditionType": "PSI1",
   "ConditionRateValue": 120
}

BusSolnOrdAppointment – Header Appointment

Appointment entities are used to persist various date fields in solution order.

Update BILL_DATE at solution order header using the Appointment Entity

Billing Date is a single date field and does not have a start and end date, in such case in the payload, the SrvcDocApptStartDateTime needs to be passed.

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdAppointment/100004251/BILL_DATE

X-CSRF-Token: abc
IF-Match: *

{
  "SrvcDocAppointmentType": "BILL_DATE",
  "SrvcDocApptStartDateTime": "2025-10-23T00:00:00Z",
}

Read BILL_DATE at solution order header using the Appointment Entity

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdAppointment/100004251/BILL_DATE

BusSolnOrdItmAppointment – Item Appointment

To update subscription end date of a subscription item, use the ServiceContrItemEndDateTime field at the BusinessSolutionOrderItem entity instead of the CONTEND Appointment type.

Update Requested delivery date of a sales item of a solution order using the Appointment Entity

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmAppointment/100004251/10/REQ_DLV_DATE

X-CSRF-Token: abc
IF-Match: *

{
  "SrvcDocAppointmentType": "REQ_DLV_DATE",
  "SrvcDocApptStartDateTime": "2025-10-28T00:00:00Z"
}

BusSolnOrdItmDuration – Item Duration

Various durations like subscription terms, contract duration, renewal terms, etc are stored as durations in the BusSolnOrdItmDuration entity which has an association with the BusinessSolutionOrderItem entity. The different duration types in solution order are persisted across the duration types specified in the below table.

Update Contract Duration of a contract item of a solution order using the Duration Entity

PATCH
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusSolnOrdItmDuration/100004251/100/CONTDURA

X-CSRF-Token: abc
IF-Match: *

{
  "SrvcDocDurationType": "CONTDURA",
  "SrvcDocDurationValue": 48,
  "SrvcDocDurationUnit": "Month"
}

BusSolnOrdFUPSalesOrder – Follow-up Sales Order

You can only read the follow up sales order and no other operations are supported on this entity. This will list all the follow-up sales order document for the solution order. Once a sales item is released, the follow up document gets created. This corresponds to the “Transaction History” section on the UI

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003541/_FUPSalesOrder

BusSolnOrdFUPSrvcOrd – Follow-up Service Order

You can only read the follow up service order and no other operations are supported on this entity. This will list all the follow-up service order document for the solution order. Once a service item is released, the follow up document gets created. This corresponds to the “Transaction History” section on the UI

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003541/_FUPServiceOrder

BusSolnOrdFUPSrvcContr – Follow-up Service Contract

You can only read the follow up service contract and no other operations are supported on this entity. This will list all the follow-up service contract document for the solution order. Once a service contract item is released, the follow up document gets created. This corresponds to the “Transaction History” section on the UI

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003541/_FUPServiceContr

BusSolnOrdFUPSubscrpn – Follow-up Subscription

You can only read the follow up subscription and no other operations are supported on this entity. This will list all the follow-up subscription document for the solution order. Once a subscription item is released, the follow up document gets created. This corresponds to the “Transaction History” section on the UI

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003541/_FUPSubscrpn

BusSolnOrdFUPEntProject – Follow-up Enterprise Project

Only read operation is supported on this entity. This will list all the follow-up project document for the solution order. Once a project item is released, the follow up document gets created. This corresponds to the “Transaction History” section on the UI

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrder/100003541/_FUPEntProject

BusSolnOrdItmFUPSalesOrder - Follow-up Sales Order Item

Only read operation is supported on this entity. This will list all the follow-up sales order along with its corresponding item numbers. Once a sales item is released, the follow up document gets created.

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/10/_FUPSalesOrderItem

BusSolnOrdItmFUPSrvcOrd – Follow-up Service Order Item

Only read operation is supported on this entity. This will list all the follow-up service order along with its corresponding item numbers. Once a sales item is released, the follow up document gets created.

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/20/_FUPServiceOrderItem

BusSolnOrdItmFUPSrvcContr – Follow-up Service Contract Item

Only read operation is supported on this entity. This will list all the follow-up service contract along with its corresponding item numbers. Once a service contract item is released, the follow up document gets created.

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/30/_FUPServiceContrItem

BusSolnOrdItmFUPSubscrpn – Follow-up Subscription Item

Only read operation is supported on this entity. This will list all the follow-up subscription. Once a subscription item is released, the follow up document gets created.

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/40/_FUPSubscrpnItem

BusSolnOrdItmFUPEntProject - Follow-up Enterprise Project Item

Only read operation is supported on this entity. This will list all the follow-up project document for the solution order. Once a service contract item is released, the follow up document gets created.

GET
<host>/sap/opu/odata4/sap/api_businesssolutionorder/srvd_a2x/sap/businesssolutionorder/0001
/BusinessSolutionOrderItem/100004251/50/_FUPEntProjectItem

Cloud-Native with ABAP Cloud – The Transactional Outbox Pattern

2025-11-12T16:48:29.446000+01:00

Cloud-Native with ABAP Cloud – The Transactional Outbox Pattern

Cheers ABAP folks!

In modern, distributed system landscapes, ensuring data consistency between a database and a message broker is a common challenge – especially when it comes to the integration of S/4HANA Cloud with Side-by-Side extensions built on the SAP Business Technology Platform (e.g. SAP BTP ABAP Environment, aka. Steampunk) or any other microservice-based architecture.

How do you guarantee that a database update (“Order created”) and a corresponding message (like "Request a shipping of the order") are never out of sync? The answer lies in the Transactional Outbox Pattern. This elegant solution ensures that these two critical operations are treated as a single, atomic unit, which is vital for maintaining data integrity and building robust, event-driven architectures atop SAP's core business processes.

The Logical Unit of Work

The Logical Unit of Work (LUW) in ABAP represents a series of database operations that are treated as a single, indivisible transaction. All changes made within an LUW, whether updates, insertions, or deletions, must either be committed to the database successfully or rolled back entirely if an error occurs, ensuring transactional consistency. This "all or nothing" principle is managed by the ABAP transaction service, typically involving database commits to finalize the changes. In standard ABAP programming, a database LUW ends when a program executes a COMMIT WORK or ROLLBACK WORK statement, or when a dialog transaction concludes. However, transactional consistency can only be ensured within the same database system. There are plenty of alternatives, when it comes to cloud-native architecture and micro service design. However, a well-established approach is to apply the paradigm of eventual consistency.

Eventual Consistency

Eventual consistency is a relaxed consistency model in distributed systems where updates are not instantly propagated, meaning different replicas might temporarily show conflicting data. However, given enough time and the assumption that no further updates occur, the system guarantees that all data will reach a consistent state (soon).

The Transactional Outbox Pattern

The transactional outbox pattern directly supports eventual consistency by decoupling the primary data write from the external message emission. It ensures the message has been reliably persisted within the same database transaction as the data change, guaranteeing that the required event will only be sent and consumed by other services, if the main transaction succeeded. Due to the defer of the message emission the micro service is much more robust against spontaneous outages.

Figure 1: Unstable microservice design. Depending on the execution sequence, the transactional data or the status reflected to the remote system might be inconsistent, if the microservice is affected by an outage in between.

Figure 2: More robust microservice design. The message is only emitted, if the transactional data and the outbox, which acts as trigger for the publisher, was successfully committed.

Implementing a Transactional Outbox in ABAP Cloud

In ABAP Cloud there is the background processing framework (bgPF) available, which can seamlessly be integrated in the transactional processing of an ABAP application built with the RESTful Application Programming model (RAP).

The clue: Instead of directly emitting outbound messages in the save sequence of your transaction, a handler can be registered, which is executed asynchronously in the background, once the RAP framework successfully complemented the database commit. This custom handler grants additional flexibility on top of the transactional outbox pattern, allowing the ABAP application to control how a certain message should be handled (emitted to an external system, processed internally, etc.).

Figure 3: Implementation of the "Transactional Outbox Pattern" in ABAP Cloud.

This setup involves only two components, everything else is handled by the RAP runtime out-of-the-box:

The definition of a bgPF handler, which implements the actual message (e.g. external system call) emission. The handler needs to implement the interface IF_BGMC_OP_SINGLE.

class zcl_rap_bgpf_request_shipping definition
  public
  final
  create private.
  public section.

    class-methods create_instance
      importing
        is_order           type zr_order000
      returning
        value(ro_instance) type ref to if_bgmc_op_single.

    interfaces if_bgmc_op_single.

  protected section.
  private section.

    methods constructor
      importing
        is_order type zr_order000.
    data ms_order type zr_order000.

endclass.
class zcl_rap_bgpf_request_shipping implementation.

  method if_bgmc_op_single~execute.
    "implement outbound call or system local processing
    modify entity zr_shippingrequest
      create
        set fields auto fill cid
          with value #(
            ( %data = value #(
              OrderReference = ms_order-uuid
              ShippingStatus = 'Ordered' )
            )
          )
   mapped data(mapped)
   failed data(failed)
   reported data(reported).
  endmethod.

  method create_instance.
    return new zcl_rap_bgpf_request_shipping( is_order ).
  endmethod.

  method constructor.
    ms_order = is_order.
  endmethod.

endclass.

The registration of the handler within the save sequence of the RAP business object.

method save_modified.
  "...
  data(lo_factory) = cl_bgmc_process_factory=>get_default( ).
  data(lo_process) = lo_factory->create( ).
  lo_process->set_name( 'Request shipping' )->set_operation(
    zcl_rap_bgpf_request_shipping=>create_instance(
      is_order = corresponding #( <ls_order> )
    )
  ).
  lo_process->save_for_execution( ).
  "...
endmethod.

By that, the RAP runtime ensures that the persisted order data is always in sync with the status reflected to the dependent application. If the main process is affected by an outage, the transactional data, as well as the registration for the message emission will be rolled-back. By that, the actual message will never be emitted.

Process Monitoring

The background processing framework (bgPF) in ABAP Cloud is technically based on bgRFC processes, which can be monitored via the Fiori app “Monitor bgRFC Queues”. The app displays scheduled, running and aborted processes and provides manual restart capabilities. Important to know: bgPF is one of multiple inbound destinations for bgRFC queues. A queue consists again out of multiple processing units – one of those is our registered handler.

Figure 4: Aborted bgPF process (simulated via assert violations) and its restart capabilities.

Additional Information

Check out some more details on the bgPF in general:
https://community.sap.com/t5/technology-blog-posts-by-sap/introducing-the-background-processing-framework/ba-p/13579056

Official documentation:
https://help.sap.com/docs/abap-cloud/abap-concepts/background-processing-framework

Complete example in GitHub:
https://github.com/SAP-samples/abap-platform-rap-transactional-outbox-with-bgpf

Stay tuned for further cloud native design patterns in ABAP Cloud!

Cheerio ABAP Folks!

Unlocking Scalability: How Apache Kafka Handles Massive Data Streams

2025-11-17T14:47:05.530000+01:00

In today’s data-driven world, applications must process massive volumes of information with low latency and near-perfect reliability. This is exactly where Apache Kafka shines. Often labeled as “just a message queue,” Kafka is far more powerful. Its architecture is intentionally designed for horizontal scalability, enabling companies like LinkedIn, Netflix, Uber, and Airbnb to process trillions of events every single day.

This post breaks down how Kafka scales, focusing on three core mechanisms:

Topic Partitioning
Broker Clusters with Replication
Consumer Groups

Together, these form the foundation of Kafka’s ability to scale seamlessly.

1. The Power of Parallelism: Kafka Topic Partitioning

At the core of Kafka’s scalability is its partitioned log architecture.

A Kafka topic is divided into one or more partitions, and each partition is an ordered, immutable sequence of messages. This simple idea unlocks massive parallelism.

How Partitioning Works

Producers write to partitions based on a key or round-robin.
Consumers read partitions independently.
Kafka guarantees order only within a partition, not across the entire topic.

This means if you need strict ordering for a particular key (like userId), that key should always be routed to the same partition.

Why It Matters

Partitioning allows Kafka to:

scale horizontally across multiple brokers
process data in parallel
distribute workload efficiently across consumers

This is the foundational mechanism behind Kafka’s ability to scale linearly.

Visualizing Partitioning:

In Diagram 1, the user_events topic is split into P0, P1, and P2. A producer sends messages based on keys, and a consumer group reads them in parallel—each consumer handling one or more partitions. This parallelism gives Kafka its first—and most important—dimension of scale.

Diagram 1

2. High Availability & Horizontal Growth: Broker Clusters and Replication

Kafka clusters are made up of brokers, and each topic partition is stored redundantly across them.

Leader–Follower Model

Each partition has one leader replica
Other brokers store follower replicas
Producers and consumers communicate only with the leader

If a leader goes down, Kafka automatically promotes a fully synced follower to leader—usually within milliseconds.

In-Sync Replicas (ISR)

Replicas that are completely caught up with the leader are added to the ISR set.
Failover only happens within this ISR group, minimizing data loss risk.

Why Replication Matters

Prevents data loss
Enables zero-downtime failover
Helps scale reads
Adds durability and resiliency

Diagram 2 shows this setup clearly: multiple brokers, distributed replicas, and seamless failover—resulting in a system that can withstand broker crashes without downtime.

Diagram 2

3. Scaling Consumer Throughput with Consumer Groups

Partitions decide how data is stored.
Consumer groups decide how data is consumed.

A consumer group consists of multiple consumers cooperating to consume data from a topic. Kafka’s enforced rule:

A partition can be consumed by only one consumer within a group.

This sets the upper limit on parallelism.

Parallelism Scenarios

Partitions	Consumers	Result
10	1	All data consumed by 1 consumer (slow)
10	10	Perfect parallelism (fast)
10	11	Extra consumer stays idle

If you need more throughput, you simply increase partitions OR add consumers—depending on which side is the bottleneck.

Diagram 3 visually represents this: more partitions → more potential parallelism → more throughput.

Diagram 3

Real-World Scaling Examples

Over 7 trillion messages/day
Uses Kafka for activity logs, real-time analytics, and fraud detection.

Netflix

Processes billions of events/day for:

device telemetry
QoS monitoring
recommender systems

Uber

Uses Kafka for:

real-time trip events
fare calculations
live map updates

These systems rely heavily on partitioning, replication, and consumer groups, the same principles discussed above.

Conclusion

Kafka’s scalability isn’t an accident—it’s baked into its core architecture. Through partitioning, broker clusters with replication, and consumer groups, Kafka achieves a remarkable blend of high throughput, resilience, and horizontal scalability.

Whether you're building real-time analytics pipelines, event-driven microservices, or large-scale data streaming platforms, understanding these mechanisms helps you design systems that can grow effortlessly—from thousands to trillions of events per day.

References & Further Reading

Apache Kafka Documentation — Architecture & Design
https://kafka.apache.org/documentation/#design
Confluent — Kafka Fundamentals & Internals
https://developer.confluent.io/learn-kafka/
Spring for Apache Kafka
https://spring.io/projects/spring-kafka
Baeldung — Kafka Architecture & Components
https://www.baeldung.com/apache-kafka

Harmonizing UI5 URLs: Convenient URLs for SAPUI5/OpenUI5 CDN

2025-12-01T17:07:45.254000+01:00

IMPORTANT UPDATE 2026/01/08

‼️After receiving severe feedback about Content-Security-Policy (CSP) issues by sending permanent redirects for the runtime resources of OpenUI5 which redirects every resource from https://openui5.hana.ondemand.com to https://sdk.openui5.org we decided to stop the redirection of the runtime resources immediately. ‼️

⚠️We plan to re-enable the runtime redirects for OpenUI5 again - but there will be a proper communication upfront via this blog post and other channels such as the notifications in the demo kit / linkedin / mailing list. ⚠️

ℹ️Independent from that, all demo kit / documentation related resources from OpenUI5 and SAPUI5 will be redirected to the new domains. As this is not affecting applications using OpenUI5 or SAPUI5, this change is transparent for you! But please update your bookmarks. ℹ️

What Do We Do?

To further enhance consistency and ease of access, we are now making the convenient URLs the new default for all Demo Kit resources. The following table shows the previous URLs and their short an convenient URLs:

Previous URLs	Short and Convenient URLs
openui5nightly.hana.ondemand.com	sdk.openui5.org/nightly
openui5.hana.ondemand.com	sdk.openui5.org
sapui5.hana.ondemand.com	ui5.sap.com

This follows our initial announcement “Short and Powerful: Convenient URLs for SAPUI5/OpenUI5 CDN”.

Why We’re Doing This

One URL for OpenUI5 and one for SAPUI5 improves search engine indexing and discoverability which will lead to better search results. It will simplify the access to our documentation and tools for developers and establishes consistent and future-proof domains which are independent from the platform they are served from.

What Will Happen?

To make the transition as easy as possible, we will gradually redirect users to the new URLs. Here’s what you can expect:

Demo Kit Resources (HTML pages) will be automatically redirected to the new URLs starting on:
- OpenUI5: December 8th
- SAPUI5: January 7th
Runtime Resources (everything else) will be redirected to the new URLs starting on:
- OpenUI5: POSTPONED!
- ~~SAPUI5: ~UI5con Germany 2026~~

These steps are designed to give everyone plenty of time to adjust to the new URLs and ensure a seamless experience.

What You Should Do Now

Make use of the short and convenient URLs now by...

...updating your bookmarks to the Demo Kit to use the new domains
...adopting your applications to bootstrap OpenUI5 or SAPUI5 from the new domains
...sharing this update with your teams and communities to help us spreading this information (Hint: still the old netweaver.ondemand.com URLs are in use!!)

Although we redirect the existing URLs they are going to continue to work. Once the old URLs will be sunset, we’ll inform you early enough upfront.

Note: To bootstrap SAPUI5 in non-cloud scenarios please use the Standard Variant for Bootstrapping. See details on the difference in Docu: Bootstrapping from Content Delivery Network and in note 2943781.

Another note on Tracking Prevention when using these URLs: Please mind the respective information in "Browser and Platform Support" for SAPUI5 / OpenUI5 and note 3216225 on how to handle it.

Comment SAP MM peut transformer le processus d’achats dans une entreprise

2025-12-05T10:02:11.080000+01:00

Le module SAP MM (Materials Management) est l’un des piliers des systèmes SAP pour la gestion des achats et des stocks. Une bonne utilisation de SAP MM peut révolutionner le processus d’approvisionnement, en le rendant plus rapide, plus précis et plus efficace.

Automatisation des achats SAP MM permet de générer automatiquement les demandes d’achat, les commandes

fournisseurs et les bons de réception, en réduisant les erreurs humaines et en accélérant le cycle P2P (Procure-to-Pay).

Meilleure gestion des fournisseurs

Le module centralise toutes les informations sur les fournisseurs : données de contact, conditions d’achat, historique de commandes, performances, etc. Cela facilite la sélection des meilleurs fournisseurs et le suivi des KPI.

Optimisation des stocks

SAP MM permet de suivre en temps réel les stocks disponibles, les mouvements de matériel, et les niveaux de réapprovisionnement. Cela réduit les ruptures de stock et les surstocks, améliorant la gestion du capital.

Intégration avec les autres modules SAP

Grâce à l’intégration avec SAP FI (finance) et SAP SD (ventes), SAP MM garantit que toutes les transactions d’achats ont un impact direct sur la comptabilité et la chaîne logistique. Cela offre une visibilité complète et un contrôle précis des coûts.

Analyses et reporting avancés

SAP MM fournit des rapports détaillés et des tableaux de bord pour suivre les performances des achats, analyser les écarts de prix et anticiper les besoins futurs. Les décisions deviennent plus rapides et basées sur des données fiables.

En adoptant SAP MM, une entreprise peut transformer son processus d’approvisionnement :plus de rapidité et d’efficacité,

moins d’erreurs,
meilleure visibilité sur les stocks et les fournisseurs,
décisions basées sur des données précises.

SAP MM n’est pas seulement un outil informatique, c’est un véritable levier stratégique pour la performance des achats.

SAP ERP Cloud SAP S/4HANA Cloud Public Edition Sourcing and Procurement

From On-Premise to Cloud: Making the Right SAP ERP Move

2025-12-10T08:19:08.342000+01:00

A comparative representation of SAP Cloud ERP deployment variants

This article presents an overview of SAP’s ERP solutions, outlining available deployment models and providing a comparative representation of the variants. It is designed to support customers in navigating and evaluating options that align with their organization’s digital transformation goals, operational requirements, and existing technology investments. The attention is given to SAP’s private cloud offerings, highlighting the flexibility, scalability, and relevance for enterprise-grade modernization initiatives.

SAP ERP On-Premise

Historically, SAP operated as a software provider focused on licensing and support, while customers and partners took on the challenge of designing, building and running highly customized implementations. This approach offered maximum flexibility but came at a cost - fragmented landscapes, version sprawl, and operational complexity. Additionally, as SAP simultaneously support more than 20 software versions of ERP and countless release variations - it increased the burden of maintenance, made it harder to adopt new features, and slowed innovation. Today, SAP is shifting toward standardized, cloud-based solutions that streamline operations and accelerate the transformation and adoption of change.

Whether you run your SAP ERP systems in your own data center, with a hosting provider or directly with a Hyperscaler, it is considered an on-premise deployment. Moving from here to an SAP Cloud ERP deployment is equally relevant and the strategic direction of SAP.

SAP Cloud ERP

SAP delivers a diverse portfolio of ERP solutions tailored to meet the needs of organizations across industries and geographies, addressing increasing demands for security, compliance, and operational control. While SAP continues to drive standardization and scalable adoption, it recognizes that transitioning to a unified cloud-based ERP is a phased journey for many enterprises. To support this evolution, SAP offers a range of strategic pathways that enable customers to embrace SAP Cloud at their own pace - preserving existing investments, leveraging the latest innovations, and maintaining a flexible operating model aligned with their business priorities.

SAP Cloud ERP sits at the center of SAP’s strategic architecture, serving as a foundational layer for enabling accelerated adoption of AI-driven services and continuous innovation. Its integration with key architectural components - including SAP Business Technology Platform, SAP Business Data Cloud, line-of-business applications, and AI agents - is essential for designing future-ready business processes and operating models. This architectural alignment ensures cohesive data flow, scalable automation, and a unified platform for digital transformation across the enterprise.

SAP's Strategic Architecture Model

Over the years, SAP has been transitioning to a cloud company. SAP Business ByDesign was launched in 2007, and multiple private cloud offerings were launched starting in 2013. SAP’s cloud services have matured continuously ever since, and SAP Cloud ERP is now at the center of SAP’s strategy. The consumption model is modular and scalable. Businesses can start with essential modules and expand as needed.

SAP Cloud ERP is a modern, cloud-based ERP solution that helps businesses manage core operations using intelligent technologies like AI, machine learning, and automation. It’s designed for speed, scalability, and continuous innovation - all while running under SAP’s strong security framework.

Adoption is now more important than ever. There is little to gain if innovation is held back due to technical difficulties, unsupported software and a lack of strong governance in the daily operation. This is one of the reasons SAP has invested heavily in cloud services and adoption programs. Now offering a modern commercial model with user- and metric-based subscription, which is accelerating the architecture design process with modular building blocks, and adoption programs helping customers to a modern ERP through “RISE with SAP” and “GROW with SAP”, focusing on accelerating the digital transformation of customers.

GROW with SAP

GROW with SAP is a program to rapidly implement SAP Business Suite using a standardised framework, tools, and guidance. It is designed for new SAP ERP customers and enables a greenfield/new implementation of SAP Business Suite in SAP Public Cloud.

RISE with SAP

RISE with SAP is a program that helps on-premise SAP ERP customers tailor their transformation to modernise their business with Business Suite. It is designed for existing SAP ERP customers, focused on modernising their existing SAP ERP systems in SAP Private Cloud.

Both journeys lead to the same destination, full SAP Business Suite capabilities, but are tailored to the customer’s starting point.

Public or Private Cloud

SAP has two cloud ERP solutions to choose from:

SAP Cloud ERP (Public): Ready-to-run cloud ERP managed by SAP
SAP Cloud ERP Private: Tailored-to-fit cloud ERP that adapts to your unique business needs while enabling the migration of your on-premises ERP investment from SAP

The first assessment customers need to make is whether their requirements can be met in SAP Public Cloud or if SAP Private Cloud deployment is needed. There are fundamental differences between the two cloud options, which often make the first choice simple:

Comparison Between SAP Public and Private Cloud

This simple table reveals significant differences. The public cloud doesn’t yet offer the full scope of ERP functionalities, and if that doesn’t cover the customer’s requirements, the private cloud is the only alternative.

The SAP code can’t be modified in public cloud and while the SAP recommendation has always been not to modify the SAP standard code, there are certain situations where it can’t be avoided, or changes have already been made in on-premise systems and must be kept. In this case the only possible destination is private cloud.

(*) Direct modification of SAP-delivered standard code is not permitted as a standard practice. The environment is designed to maintain a "clean core," and customers are expected to use supported extensibility options (such as in-app extensions, BAdIs, or side-by-side development on SAP BTP) rather than altering SAP standard objects. Exceptions to this rule are rare and require formal SAP approval, with the customer assuming full responsibility and risk for any such modifications.

In public cloud, mandatory software releases and updates are pushed out by SAP and the changes must be adopted within a limited time period. In private cloud, the updates are included in the service, but the implementation is a customer choice. SAP will not install software updates without consent from the customer.

Finally, the very nature of a SaaS solution can be restricted by some customers or deployment options might be needed, which are not available in public cloud. Typical examples could be stronger segregation of data, the need for a private code base, increased business continuity concepts and distinct security and compliance requirements.

SAP Cloud ERP Public

SAP Cloud ERP Public is a pure Software-as-a-Service (SaaS) cloud delivery model, and it is the preferred deployment model for all customers opting for a fresh new-implementation (greenfield) of SAP ERP and whenever functional, integration, and localisation requirements can be addressed.

Being a SaaS offering, the deployment options are limited, by design, compared to private cloud, and as the focus of this article is private cloud, this deployment model is not described further.

SAP Cloud ERP Private

SAP Cloud ERP Private is a deployment option of SAP ERP software installed specifically for the customer in a private cloud environment.

SAP Private Cloud is technically SAP-managed services and software licenses running in a single-tenant, virtual private cloud environment on subscription. Customer systems run in a dedicated cloud tenant with dedicated capacity and is completely isolated from other customer accounts. SAP is providing managed infrastructure, technical managed services and operations, security, and lifecycle management. Customers access their systems via secure, private network connections (not public internet), retain control over business processes and configurations.

It offers enhanced control, security, and customization compared to public cloud solutions. Private cloud deployments typically offer more robust security measures and compliance capabilities, making them suitable for industries with stringent data protection requirements.

Private cloud deployments are more appropriate for existing on-premise customers who require more customization, whose functional needs can’t be addressed with the public cloud option, or if the investments made in existing on-premise systems need to be retained.

SAP aims to transition all customers using SAP ERP to SAP S/4HANA by 2027. Before the introduction of RISE with SAP in 2021, SAP did not fully meet the needs of customers seeking cloud-based ERP solutions. The primary option available was SAP S/4HANA Cloud Public Edition, which required a new implementation. This was not a viable option for many existing SAP ERP customers who wanted to retain their investment in their current systems, leverage existing data, and carry forward customizations and modifications.

To address this gap, SAP introduced SAP Cloud ERP Private solutions with the launch of RISE with SAP. These single-tenant solutions offer each customer their own dedicated instance of SAP software, hosted on separate infrastructure within a data center operated by one of the major hyperscalers or SAP itself. Existing SAP ERP customers can choose to either lift-and-shift their SAP ERP systems or transition to SAP Cloud ERP Private using a system conversion, selective data transition, or a new implementation approach. SAP Cloud ERP Private comes in two offerings: Packaged and Tailored.

Packaged Option (Private Cloud Edition, “PCE”)

SAP Cloud ERP Private is a packaged deployment option that is fixed, template-based, and uses SAP Reference Architecture. It focuses on core ERP functionality delivered in modular packages for standardised and rapid consumption. Infrastructure sizes and changes are delivered in T-shirt size models via a catalogue-based list of services that covers the user software license, infrastructure, and technical managed services required to run SAP.
This is the strategic choice for providing innovation and cloud value while customers retain investments by converting existing systems.
Standardisation is strict

Tailored Option (Private Cloud Edition, Tailored Option, “PTO”)

The SAP Cloud ERP Private, tailored deployment option is a flexible, individually configured using SAP Reference Architecture and covers the full ERP scope, covering nearly any SAP on-premise product still in maintenance with SAP technical support.
This is the strategic choice for complex architecture, large data volumes, customer-specific requirements, compliance and flexibility.
Standardisation is strict, while offering more flexibility

Both SAP Cloud ERP Private, Packaged and Tailored options can be deployed in different ways, but not all deployment options are available for both types.

Deployment Options

In SAP Cloud ERP Private, customers select their deployment option and specify the data center to use. Each option has its own distinct delivery model designed to cover different needs. Regardless of which option they choose, customers are responsible for the application layer (such as functional configuration, business process design, company authorization concept), and SAP is responsible for the technical managed service, infrastructure management, governance, security & compliance framework, and software and support.

Regardless of which private cloud deployment option is used, customers are in control of functional changes. Some changes are fully managed by customers, like custom code/extension and integration, business consistency and correctness, and SAP transport management. Other changes are initiated by customers and managed by SAP, like release upgrades and patch updates on SAP applications and the database. While updates to the software are included, SAP will not upgrade these components without customer approval.

The technical layers are managed differently, and the responsibilities vary as illustrated below. SAP has overall ownership, provides a generic architecture framework with common tools and a service delivery model, and remains agnostic about which deployment option to use. The end-user experience is designed to be the same regardless of which option is used.

SAP offers the following delivery options:

Hyperscaler

Deployed on Hyperscaler Infrastructure-as-a-Service (IaaS) under SAP's account
The default deployment model with global coverage, enterprise-grade scalability capabilities and the latest features
Often an advantage for customers who already have an active account with the same hyperscaler. Advantages like improved network latency, re-use of existing connections between customer premises and the hyperscaler, pre-approved by the customer’s security department

SAP Data Center

SAP operated data centres in Germany and options in Europe, APJ and North America
Compared to Hyperscaler, the scalability capability is limited and generally reserved for moderate workloads
This option is typically chosen for customers with strict regulatory, security, or technical requirements that cannot be met by Hyperscalers

Customer Data Center

Allows SAP to deliver and operate its managed cloud services directly within a data centre facility owned or leased by the customer
SAP manages the full stack remotely, while the customer retains control over the physical facility and network perimeter
Designed for organisations with strict data residency, regulatory, or integration requirements, but with certain features that may be limited
The data centre facilities must adhere to SAP’s reference architecture principles and security & compliance framework which must be approved by the hardware partner and SAP

Premium Supplier

A delivery framework where selected strategic partners, Premium Suppliers, are responsible for the technical infrastructure build, operation, and day-to-day services
While the Premium Suppliers manage the technical run and operations, SAP retains overall contractual responsibility, governance, and customer engagement
The infrastructure and some operational services are delivered by the Premium Supplier, either in their own data centres or in Hyperscaler environments managed by them
The model has specific rules for technical validation and operational responsibilities, which differ from the other SAP-delivered deployment options

RACI for SAP Cloud ERP Private Deployment Options

Security, Data Protection and Compliance

The packaged and tailored options both share many characteristics and principles as they both run according to SAP’s global Private Cloud concept, Reference Architecture and Cybersecurity and Compliance Frameworks.

The table below shows some of the security, data protection and compliance options available in Cloud ERP Private for the different deployment options. Some are available in both Cloud ERP Private offerings, while others are available for either the packaged offering (core ERP) or the tailored offering (full ERP). This leads to many combinations of options available to meet the requirements of customers, and each option has conditions that need to be assessed individually in collaboration with SAP.

Security & Compliance Capabilities for SAP Cloud ERP Private Deployment Options

SAP Sovereign Cloud

SAP Sovereign Cloud can be categorized as a Cloud ERP Private deployment option. However, in essence, this is a separate offering with distinct features covering both private and public ERP cloud offerings from SAP. This is the strategic choice for increased country-specific sovereignty requirements. All data is stored and operated to maintain compliance with heightened local data protection regulations.

The sovereignty extends beyond the technical infrastructure and must also be operated by security-cleared personnel from government-accredited, security-cleared facilities, according to country-specific data residency regulations and specific audit and regulatory standards.

SAP Sovereign Cloud is relevant if there is a specific need for increased sovereignty that SAP Cloud ERP and SAP Cloud ERP Private cannot otherwise provide. Like SAP Cloud ERP Private, different deployment options are available to cover different requirements across geographies and industries.

Deployment Options

Like SAP Cloud ERP Private, there are choices between which data centres to use, each option with its own distinct delivery model designed to cover different needs. Equal for all is that customers are responsible for the application layer (like functional configuration, business process design, company authorisation concept) and SAP is responsible for the governance, security & compliance framework and the global standard architecture framework.

There are differences in the remaining layers, however, SAP has overall ownership, provides a generic architecture framework with common tools and service delivery model and remains agnostic. The end-user experience is the same regardless of which option is used.

Deployment Options for SAP Sovereign Cloud

Make the right strategic choice

When evaluating cloud deployment options, the many available options SAP provides are often overlooked, perhaps inadvertently ruled out prematurely or not even known as valid deployment options.

The reality is that through the wide range of deployment options, SAP offers the ability to support most industry requirements and regulatory demands for deployment in the cloud:

Cloud ERP – preferred option when:

New or existing customers planning a new (greenfield) implementation from scratch and whenever functional, integration, and localisation requirements can be addressed
Multi-tenancy is a suitable cloud deployment model for your organisation
Your organisation can adhere to a mandatory software lifecycle management process governed by SAP

Cloud ERP Private – preferred option when:

Existing SAP customers looking for innovation and cloud value while retaining investments by converting existing systems
Standardisation and agility are a priority
Standard migration scenarios of your existing systems into SAP cloud are sufficient
Functional requirements can be addressed
Standard Business Continuity and network capabilities are sufficient

Cloud ERP Private, tailored option – preferred option when:

Full functional SAP ERP scope is required
Flexibility in the configuration of the infrastructure
Complex migration scenarios of your existing systems into SAP Cloud are needed
Enhanced Business Continuity and network capabilities are required
Advanced features and capabilities are required
Very large data volumes

SAP Cloud ERP Private, SAP Data Center - preferred option when:

There is a specific need to have SAP as data center owner or controller
Cloud workloads must run according to country-specific data residency regulations
Small to moderate workload

SAP Cloud ERP Private, Customer Data Center - preferred option when:

There is a specific need to have the customer as data center owner or controller
Cloud workloads must run according to country-specific data residency regulations
Customer can provide data centers that are suitable for running SAP Cloud ERP Private
The customer want to manage the physical data center premises
Typically, most relevant for high workload

Sovereign Cloud – preferred option when:

There is a specific need for increased sovereignty that SAP Cloud ERP cannot otherwise provide
Must be operated by security-cleared personnel
Must run from government-accredited, security-cleared facilities
Must run according to country-specific data residency regulations and specific audit and regulatory standards

On-premise / Native Hyperscaler – legacy option when:

Upgrade to a supported version is impossible
The existing system is planned to be decommissioned within a short time frame
Other reasons preventing customers from moving to the cloud. SAP will support with a detailed assessment of the available pathways

A closer examination reveals a wide range of options and combinations that can only be fully evaluated in collaboration with SAP through the mandatory Technical Assessment process. The table below aims to illustrate the wide range of options available to customers that SAP provides to support customers in transitioning to the optimal cloud deployment model.

Comparison of SAP ERP Offerings

Secure your SAP Cloud ERP deployment through a Technical Assessment

The Technical Assessment is a process designed to ensure that customer requirements are met when transitioning to SAP Cloud ERP Private, and to support a successful move to the cloud. This service is included in every engagement and is delivered by SAP Global Cloud Operations (GCO) - the business unit in SAP that is responsible for design, build and operate of Cloud ERP Private. GCO also oversees the service engineering of the included services (read more about that here), and the customer advisory for evaluating cloud deployment options and ensuring successful onboarding to SAP Cloud ERP Private.

Technical Assessment Scope:

SAP Cloud ERP Private Deployment
Technical Architecture
Network & Connectivity
Security & Compliance
Services & Operations
Cloud Onboarding.

The Technical Assessment is defined and led by the SAP Cloud Architecture & Advisory team within SAP Global Cloud Operations. We guide customers through the necessary steps at a pace aligned with each customer’s readiness and transformation journey. Your designated Cloud Architect & Advisor (CAA) is available to guide you through a deeper assessment of the cloud deployment options outlined in this article.

Choosing the right path to Cloud ERP

2025-12-12T05:22:51.264000+01:00

For many SAP-using organizations, moving to Cloud ERP is not a question of if but how. And businesses are feeling the pressure. End-of-support for ECC is fast approaching and many of SAP’s newest innovations are offered only in the Cloud.

Despite the urgency, more than half of SAP users have yet to begin their migration. One of the biggest hurdles is choosing the right path to Cloud ERP.

At first, this might seem like a simple decision between Public Cloud ERP and Private Cloud ERP. Yet, the choice is far more complex. It requires careful consideration of your business priorities, regulatory requirements, and landscape complexity.

Public vs Private

It’s tempting to view Public Cloud ERP as a one-size-fits-all solution, with limited flexibility. Public Cloud ERP is often described as a standardized, SAP-managed solution with a Clean Core – where most customizations move to external platforms like BTP. Private Cloud ERP is seen as the more flexible alternative, particularly for organizations needing to retain legacy customizations.

While there is some truth to that distinction, it oversimplifies the reality for businesses considering shifting to the Cloud. The real difference is less about whether you can customize, but where and how.

In Public Cloud, extensions and customizations, mostly occur outside the core ERP system. Unlike Public Cloud, Private Cloud permits more change to the core ERP system and offers more options that address end-user requirements such as hosting preferences and underlying technology.

The Many Variations of Private Cloud

For larger enterprises, Private Cloud is the likely choice. Yet, that choice is anything but straightforward. Over time, SAP has expanded beyond a single core offering of Private Cloud ERP (formerly RISE), offering numerous options designed to meet distinct needs, whether infrastructure preferences, regulatory compliance, or phased migration timelines.

Some examples of Private Cloud include:

SAP Cloud ERP Private Edition: Classic RISE with SAP option and the right choice for many enterprises
SAP Cloud ERP Private Edition Tailored: Contracted options are customized per unique customer requirements. May include contracted coverage for many responsibilities considered customer concerns in the base offering.
SAP Cloud ERP Private Sovereign Cloud: Keeps all data and processing within a particular jurisdiction or geography. It’s ideal when technical or regulatory requirements make traditional off-site hosting infeasible.
SAP Cloud ERP Hyperscaler: Runs on the customer’s preferred hyperscaler, often leveraging an existing relationship.
SAP Cloud ERP Hyperscaler Tailored: Modified version of Cloud ERP running on the customer’s existing hyperscaler environment. Offers additional flexibility for deployment architecture and may be more suitable for migrating highly integrated or complex existing on-premises implementations.
SAP ERP Customer Datacenter Edition: Brings Cloud architecture into a company’s datacentre when external hosting isn’t feasible.
SAP Cloud ERP Private Edition Transition Option: A commercial offering enabling enterprises to commit to Cloud ERP while keeping ECC supported past 2027 and through 2033.

The number of Cloud ERP options can be overwhelming. Yet, it also means you can choose an offering closely aligned with your strategic goals.

Key considerations for your Cloud journey

There are more options available than many SAP-using organizations realize. The best outcomes come from asking the right questions and focusing on what matters most to your business.

Customization: Do we have significant existing customizations? How critical are these customizations? Is code going to be retained or modernized? Where does redevelopment or customization take place?
Compliance: What compliance or jurisdictional requirements govern where data can reside?
Cloud partnership: How important is leveraging an existing hyperscaler contract or infrastructure investment?
Timeline: Do we anticipate maintaining ECC beyond standard support timelines, and if so, what transition paths exist?

Look beyond Public and Private and focus on business realities. In this way, you can identify an option that balances flexibility, control, and long-term viability. It means businesses can avoid putting operations and compliance at risk as they migrate to the Cloud.

The Bottom Line

The journey to Cloud ERP is rarely straightforward. No two organizations have the same requirements and goals. What’s clear is that there is no universal answer. Public Cloud offers speed, standardization, lower total cost of ownership, automatic SAP updates, and scalability. Private Cloud provides flexibility, with choices built to address distinct business challenges.

The right choice depends on aligning your migration strategy with business outcomes. Focus on your requirements and chart a course that ensures your ERP landscape remains a foundation for growth, innovation, and resilience today and in the future.

Digital Transformation. View of an Enterprise Architect - Conway's Law

2026-01-13T13:07:27.255000+01:00

#GenerativeArt

Out of the Ivory Tower: Architecture, Organization, and the Reality of SAP Transformations

Many SAP transformations today do not fail because of technology. SAP S/4HANA, cloud architectures, and modern integration platforms are mature and powerful. Yet in practice, end-to-end processes often remain slow and inefficient.

The root cause is frequently not the system itself, but the organization that designs, operates, and evolves it.

When SAP Architecture Meets Organizational Silos

In many enterprises, SAP organizations have historically been structured around technical modules such as SD, MM, or FI.
While these modules are technically connected through document flows, they are often organizationally separated.

This leads to familiar challenges:

· high coordination effort across team boundaries

· fragmented ownership along end-to-end processes

· long lead times despite modern platforms

As a result, architecture becomes a reflection of organizational reality.

Conway’s Law: Relevant in Everyday Practice

This pattern can be explained by Conway’s Law:
Systems inevitably mirror the communication and decision structures of the organizations that design them.

For SAP customers, this means that as long as organizations are aligned around technical components, architectures will follow the same structure—regardless of how advanced the underlying technology is. Agile methods alone do not change this as long as structural dependencies remain.

A Realistic Perspective on Organizational Change

Especially in large, established SAP organizations, one thing is clear:
Breaking down organizational silos is difficult and often not fully achievable.

Governance models, reporting lines, and historically grown responsibilities impose real constraints. A radical organizational redesign is therefore rarely feasible in the short term.

Why Awareness Still Makes a Difference

The key benefit already starts with awareness of the relationship between organization and architecture:

· dependencies become visible earlier

· architectural decisions are assessed more realistically

· interfaces are understood as organizational, not just technical, challenges

Even without major reorganization, this awareness enables targeted improvements—for example, clearer end-to-end ownership for critical initiatives or more deliberate team setups where it matters most.

Conclusion

SAP architecture does not emerge in an ivory tower. It is always shaped by the organizational context in which it is created.
Those who understand and consider Conway’s Law make better architectural decisions—even when organizational silos cannot be fully removed.

Architecture is organizational design.

What Does This Mean for Your SAP Transformation?

Taking a conscious look at organizational structures, responsibilities, and communication paths can significantly improve the effectiveness of architectural decisions. Not every organization needs to be redesigned—but every transformation benefits from thinking about architecture and organization together.

Common thread of this blog series:

Introduction
Tasks of an Enterprise Architect
Success Factors for Digital Transformation Projects
Help of an Enterprise-Architecture-Framework
Steps and Tips
Artificial Intelligence Meets Enterprise Architecture
Conway’s Law

References

Hohmann, M.; Wagner, D.: Architecture Is Organizational Design, iX – Magazine for Professional Information Technology, Issue 1/2026.

Success Pläne - Der neue Support-Ansatz von SAP für die Cloud

2026-02-05T11:26:32.459000+01:00

SAP führt im März 2026 ein neues Support-Modell ein, das die Zusammenarbeit mit Kunden vereinfachen soll. In einer Session im Rahmen der IT Online Konferenz erklärten Dr. Stephanie Lockemann (Head of Premium Engagements and Customer Innovation Services) und Simone Ruprechter (Head of Solution Sales Business Development and Go-to-Market Services) die Neuerungen in einem Interview. Anbei eine Zusammenfassung.

Warum werden die Success Pläne als ein neues Support-Modell benötigt?

Veränderte Marktbedingungen

Die Rahmenbedingungen für Unternehmen haben sich gewandelt. Märkte folgen nicht mehr vertrauten Mustern, sondern verändern sich in kürzeren Zyklen. Wachstumsphasen, Inflation und Rezession wechseln sich schneller ab. Lieferketten geraten ins Stocken, Fachkräfte fehlen, und geopolitische Entwicklungen ändern sich im Tagesrhythmus.

Gleichzeitig entstehen neue Chancen: Daten liefern Erkenntnisse in Echtzeit, künstliche Intelligenz steigert die Produktivität, und neue Geschäftsmodelle werden möglich. Entscheidend ist nicht mehr die Unternehmensgröße, sondern Geschwindigkeit, Transparenz und Anpassungsfähigkeit.

Kundenfeedback als Treiber

Neben den Marktbedingungen war das Kundenfeedback zentral für die Neuausrichtung. Kunden erwarten SAP in einer beratenden Rolle über den gesamten Lebenszyklus ihrer Lösung - nicht nur bei der Implementierung. Sie brauchen vorausschauende Guidance, Unterstützung bei neuen Releases und kontinuierliche Beratung, um den Return on Investment zu maximieren und TCO zu senken.

Die drei Success Pläne von SAP im Überblick

Das neue Modell besteht aus drei aufeinander aufbauenden Success Plänen:

Foundational Success Plan

Der Foundational Success Plan erweitert das bestehende SAP Enterprise Support Angebot und richtet sich an Kunden mit standardnahen Systemen und geringeren Support-Anforderungen. Alle SAP‑Cloud-Kunden erhalten ihn automatisch. Er bietet:

24/7 Support entlang Service Level Agreements
Managed Services für den Cloud-Betrieb
Self-Service-Inhalte für Onboarding und Launch
Begleitung bei der Transformation mit SAP Cloud ALM
Learning Journeys für Schulungen

Advanced Success Plan

Der Advanced Success Plan baut darauf auf und löst SAP Preferred Success sowie SAP Preferred Success expanded edition ab. Er bietet u.a,:

Verbesserte Service Level Agreements
Innovation and Adoption Guidance für neue Releases und Features
KI-basiertes Systemmonitoring mit automatisierten Empfehlungen
Activation and Optimization Services (Microservices mit 8-16 Stunden)
Einen remote Success Expert, der einen Serviceplan erstellt
Kunden können alle Entitlements unbegrenzt nutzen

Max Success Plan

Der Max Success Plan ermöglicht eine strategische Partnerschaft mit SAP. Er kombiniert alle Leistungen aus Foundational und Advanced und ergänzt sie um:

Einen dedizierter Success Plan Manager
Zugriff auf das Premium Engagement Service Portfolio
Services für Business Process Improvement, Complex Transformation und Safeguarding
Maßgeschneiderte, individuelle Services incl. Prototyping
Enhanced Case Management mit dediziertem Ansprechpartner
Vor-Ort-Unterstützung bei Bedarf

Der Max Success Plan integriert das bisherige Premium Engagement Services Angebot.

Was sind Praxisbeispiele der Success Pläne von SAP?

SAP Business AI Nutzung

Bei SAP Business AI sieht es wie folgt aus:

Foundational: Zugriff auf Lösungsdokumentation über help.sap.com, Learning Journeys, Aktivierung von Joule über Self-Services

Advanced: Zusätzliche Leistungen zur Identifikation des Business AI Potenzials, strategische Aktivierung von Anwendungsfällen, fortlaufende Produktberatung, Guidance und Optimierungsempfehlungen

Max: Definition der KI-Strategie, Erstellung einer Daten- und Architektur-Roadmap, Entwicklung von Prototypen für maßgeschneiderte KI-Anwendungsfälle

Business Data Cloud (BDC) - Neues Release

Ein konkretes Szenario bei einem neuen BDC-Release zeigt die Flexibilität durch die Kombination verschiedener Layer:

Foundational: Zugriff auf Lösungsdokumentation über help.sap.com, neue Lerninhalte über Learning Journeys

Advanced bietet:

Release Guidance für Überblick über neue Funktionen
Key Feature Advisory für interessante Features
Best Practice Advisory für Einsatzszenarien
Aktivierung des Features zum Testen
Transformation Advisory für die Implementierungs-Roadmap
Kontinuierliches KPI-Monitoring und Optimierungsvorschläge

Max bietet:

Proof of Concept bei großflächigem Rollout
Begleitung der Implementierung
Safeguarding der Implementierung

Was sind Kernprinzipien der Success Pläne von SAP?

Design Prinzipien sind die Folgenden

Umfassendes, maßgeschneidertes Serviceportfolio für alle Phasen
Einheitliches Front Office und eine Governance
Ein Ansprechpartner über alle Lösungen hinweg
End-to-End Betrachtung der Lösungslandschaft
Individueller Serviceplan je nach Situation

Welche Vorteile bieten SAPs Success Pläne?

Flexibilität: Unlimitierter Abruf von Entitlements ermöglicht schnelles Ausprobieren neuer Features ohne Approval-Prozesse oder separate Angebote
Agilität: Schnellere Innovation durch unkomplizierte Service-Nutzung aus verschiedenen Ebenen
Integrated Delivery: Ein einheitliches Governance‑Modell sorgt für eine optimale Lieferung - unabhängig davon, aus welchem Level oder Portfolioelement die Services kommen
Individualisierung: Lösungsspezifische Wahl des passenden Plans - verschiedene SAP-Systeme können unterschiedliche Success Plans nutzen
Ressourceneffizienz: Einsparung interner Ressourcen und externer Beratung durch SAP-Services

Fragen und Antworten zu SAPs Success Plänen

Für wen ist welcher Plan geeignet?
Die Success Pläne eignen sich für alle Kundengruppen. Durch die drei aufeinander aufbauenden Ebenen findet jeder Kunde das passende Modell - abhängig von Komplexität, Bedarf und strategischer Bedeutung der jeweiligen Lösung.

Wie ist die Verfügbarkeit? Das neue Support-Modell startet am 3. März 2026.

Wie ist der Übergang von bestehenden Verträgen?
Laufende Premium Engagement und SAP Preferred Success Verträge bleiben bestehen und laufen über die gesamte Vertragslaufzeit. Nach Vertragsende erfolgt die Überführung in das neue Modell gemeinsam mit dem Kunden. Ein früherer Wechsel ist nach Absprache mit den bekannten Ansprechpartnern möglich.

Gilt das neue Modell nur für Cloud-Kunden? Ja, die Success Pläne sind für Cloud-Lösungen konzipiert. On-Premise-Kunden können weiterhin Premium Engagement Services in einem revidierten Modell nutzen.

Was passiert mit laufenden SAP Preferred Success oder Premium Engagement Verträgen? Bestehende Verträge laufen über die vereinbarte Vertragslaufzeit. Die Überführung ins neue Modell erfolgt nach Vertragsende oder bei Bedarf früher in Abstimmung mit dem Kunden.

Kann man verschiedene Success Pläne für unterschiedliche Lösungen wählen? Ja, Kunden haben volle Flexibilität. Für jede SAP-Lösung kann der passende Plan gewählt werden. Der Max Success Plan stellt dabei die End-to-End-Beratung über alle Lösungen sicher.

Wann sind Kosten und Preise verfügbar? Aussagen dazu sind ab März 2026 möglich.

Für welche Kundengruppen sind die Success Pläne geeignet? Für alle Kundengruppen. Die drei aufeinander aufbauenden Level bieten für jeden Bedarf das passende Modell.

Wo finden sich weiterführende Informationen? Nach dem Launch im März folgt eine dreiteilige Webcast-Reihe in Deutsch und Englisch mit den Schwerpunkten: Überblick über die Success Pläne/ Deep Dive Advanced Success Plan / Deep Dive Max Success Plan. Die Anmeldung ist bereits hier möglich.

Was sind Tipps für die Praxis? Hierzu wurden folgende Punkte genannt:

Frühzeitig klassifizieren: Bewerten Sie Ihre SAP-Lösungen nach strategischer Bedeutung, Komplexität und Standardnähe, um den passenden Plan zu identifizieren.
Ansprechpartner kontaktieren: Nutzen Sie bestehende SAP-Kontakte für eine individuelle Bewertung und Empfehlung.
Flexibilität nutzen: Denken Sie lösungsspezifisch - nicht jede Lösung benötigt denselben Support-Level.
Entitlements ausschöpfen: Im Advanced und Max Plan sind Services unlimitiert abrufbar. Nutzen Sie diese Flexibilität für schnelle Innovation.
End-to-End betrachten: Lassen Sie sich vom Success Plan Manager oder Expert einen ganzheitlichen Serviceplan erstellen.
Learning Journeys einplanen: Nutzen Sie die integrierten Schulungsangebote für eine erfolgreiche Adoption.
Webcast-Reihe besuchen: Die geplanten Deep Dives bieten detaillierte Einblicke in Advanced und Max Pläne.

Zusammenfassung

SAP reagiert mit den neuen Success Plänen auf veränderte Marktbedingungen und Kundenbedürfnisse. Das dreistufige Modell - Foundational, Advanced und Max - bietet von Self-Service bis zur strategischen Partnerschaft das passende Engagement für jeden Bedarf.

Kernelemente sind Flexibilität, integrierte Delivery mit einer Governance und die Möglichkeit, für unterschiedliche Lösungen verschiedene Pläne zu wählen. Bestehende Verträge bleiben selbstverständlich weiter gültig. Die Success Pläne bündeln SAPs Cloud‑Support‑Kompetenz in einem klar strukturierten Modell, das Stabilität, Innovationstempo und strategische Beratung vereint.

So begleitet SAP Unternehmen durch den gesamten Lebenszyklus ihrer Softwarelösungen. Mehr Infos gibt es hier in den Webinaren.

Accelerate your transformation to the Cloud with SAP Business AI: Live Session March 5, 2026

2026-02-06T20:38:23.731000+01:00

Unlock Faster, Smarter Cloud Migration with SAP Business AI Are you ready to transform your business with AI-driven efficiency? Join our 45-minute live session on March 5, 2026, and explore how SAP’s intelligent toolchain simplifies migration, integrates seamlessly with tools like Signavio and Cloud ALM, and delivers measurable results. Whether you're a project manager, developer, or architect, this session will show you how to accelerate your cloud journey with confidence.

Key Takeaways:

Unified Platform: Replace disjointed tools with an AI-powered solution for seamless workflows.
Live Demos: See how Signavio, LeanIX, and Cloud ALM integrate for measurable results.
Get Started Today: Learn practical steps to begin your transformation with confidence.

Who Should Attend? Project managers, developers, consultants, and architects looking to accelerate cloud adoption with AI.

Register now

Leading AI-Driven Transformation – A New SAP Enterprise Architect Course

2026-02-18T00:05:31.303000+01:00

Our new course, Leading AI-Driven Transformation as an SAP Enterprise Architect, empowers you to master SAP’s latest Business AI strategies and tools. Designed for enterprise architects, this course equips you to drive technology change, shape AI-enabled landscapes, and position SAP solutions confidently to customers.

You will gain practical knowledge on SAP’s Business AI strategy, AI reference architectures, hybrid design patterns, and effective ways to support customers through their AI transformation journey. Don’t miss the chance to upgrade your skills for the future of enterprise IT.

What You’ll Learn

Understand how SAP’s Business AI strategy shapes the enterprise architect’s evolving responsibilities and opportunities.
Use SAP tools to guide AI exploration, architecture design, and early-stage assessments across SAP landscapes.
Recognize common challenges and blockers in AI adoption, and how to overcome them.
Explore hybrid architectures and best practices for integrating AI into existing SAP and third-party environments.
Learn to position AI value to customers and support their end-to-end transformation journey.

Upgrade your skills and lead with confidence—register today for “Leading AI-Driven Transformation as an SAP Enterprise Architect.”

The Path to SAP Cloud ERP Private –Technical Assessment

2026-02-25T07:08:34.797000+01:00

With SAP Cloud ERP Private, SAP removes the complexity of designing, building, and operating SAP software for customers by offering a user- or metric-based subscription that bundles software and tooling licenses, infrastructure, and technical managed services—everything needed to run an SAP solution. Read more about this here: Understanding the Distinct Scope of SAP Cloud ERP Private

To ensure a smooth transition to the cloud, SAP collaborates with each customer and partner on all design, build, and operational topics relevant to SAP Cloud ERP Private, assessing the technical feasibility of each customer’s requirements and handing them over to the business unit within SAP that is responsible for designing, building and operating SAP Cloud ERP Private.

Moving to a cloud subscription service either from an on-premise datacenter or indeed from public cloud IaaS is not a trivial task. It requires due diligence to ensure that all technical and operational requirements are met, and where deviations exist, a solution is achieved to deliver the same business outcome.

To support our customers’ transition to the private cloud, SAP offers a safeguarding process which covers all the technical and operational requirements. This process, which we call Technical Assessment, is delivered by a unit within Global Cloud Operations called Cloud Architecture & Advisory (CAA).

This document explains the role and value of the Technical Assessment process in the journey to SAP Cloud ERP Private. It outlines how SAP works with customers and partners to achieve the following:

Advise on suitable private cloud options and high-level architecture choices
Assess technical requirements and align expectations across stakeholders
Transition the agreed outcomes into a clear and feasible target architecture before delivery

By providing an overview of the assessment domains, decision points, and outcomes, this document aims to give stakeholders a clear understanding of how the Technical Assessment helps ensure a secure, scalable, and successful transition to SAP Cloud ERP Private.

Figure1 : Technical Assessment Flywheel

Advise the customer on the private cloud offerings within the SAP GCO portfolio

A key factor to ensure a successful transition to SAP’s Private Cloud is to understand the private cloud offering and the details of each technical domain such as:

Technical Domain	Expected customer’s stakeholder
SAP Cloud ERP Private Overview	All key stakeholders
Cloud Technical Architecture	Infrastructure, application, basis, and network stakeholders
Network and Integration	Infrastructure, network, and security stakeholders
Cybersecurity and Compliance	Security, network, infrastructure, application, and basis stakeholders
Cloud Managed Services and Operating Model	All key stakeholders
Customer Onboarding	Infrastructure, application, basis, and network stakeholders

Table 1: Technical Domains and expected participants

These domains provide a structured lens to assess customer needs and requirements as well as position the right GCO services. Depending on the complexity of the requirements, some topics will require deep‑dive workshops to reach a shared understanding and robust solution options. This collaborative approach enables tailored architectures and operating models that align to the customer’s objectives and proactively address potential challenges during the move to SAP Cloud ERP Private.

Assess the technical feasibility of the customer’s requirements

Figure2: Technical Assessment aspects

Aligning the customer’s current and target (“to‑be”) state is essential to define a clear path for their cloud journey. This assessment ensures both sides share the same expectations on scope, timelines, and responsibilities.

Throughout this process, SAP validates that the customer’s business and operational requirements can be implemented within SAP’s private cloud delivery standards. It also confirms that the solution follows GCO best practices for business continuity, operations, and cybersecurity.

Some aspects to be covered during the assessment are the following:

Aspect	Topics to be discussed	Decisions to be taken
Deployment option, platform, and region	As described in the blog From On-Premise to Cloud: Making the Right SAP ERP Move, SAP offers several deployment options for SAP Cloud ERP Private, such as hyperscaler, SAP data center, customer data center, and premium suppliers – each available on different platforms and in multiple regions. It is the customer’s responsibility to choose the deployment model and select the platform and target regions, with support from the SAP CAA team to align with requirements, synergies, and the customer’s cloud strategy.	Deployment option (hyperscaler, SAP data center, customer data center, premium supplier) Cloud provider or hyperscaler for the deployment Regions (main and disaster recovery)
Network and communication infrastructure	Each platform provides different private and internet-facing connectivity options. Based on the chosen deployment option, platform, region, and performance needs, the customer must decide how to connect to SAP Cloud ERP Private, including any requirements for network segregation and DNS integration that should be clarified during the Technical Assessment.	Connectivity options for private and public access Bandwidth required DNS integration method (zone transfer, conditional forwarding, etc.) Load balancing requirements
Application platform and integrations	It’s crucial to clarify which bill of materials, applications, and solutions are in scope for the private cloud, how they are offered in the GCO portfolio (for example, high availability, disaster recovery, and SLAs), and how they will integrate with SAP and non‑SAP systems.	Bill of material and solution’s versions Business continuity options and SLAs Technical elements required for integration with SAP and non-SAP systems
Solution sizing	Solution sizing from the customer or partner must be translated into cloud technical sizing (for example, database and storage), since accurate sizing is key for a smooth transition and optimal performance.The blog Sizing Your Success: A Guide to SAP Cloud ERP Private is a recommended reference for this activity.	Target sizing of the different solutions and tiers Expected growth during the contract’s runtime
Security and regulatory requirements	As explained in the blog RISE with SAP: Comparing the Security of SAP S/4HANA Cloud, private edition Vs SAP S/4HANA Cloud, public edition, SAP applies a multilayered security strategy and a zero‑trust approach across its cloud services, with controls such as encryption, access control, auditing, compliance, logging, monitoring, and secure operations governed by SAP standards and policies. This underpins the SAP Cloud ERP Private security and regulatory framework. Each organization also has its own security and regulatory needs, and where specific requirements go beyond the standard framework, SAP reviews them and designs appropriate measures.	Confirm that SAP’s security framework meets the customer’s requirement in terms of cybersecurity and regulation. Identify any special requirement and find a solution for it.
Best practices and operational model	SAP Cloud ERP Private provides several operating models and SLA levels to suit different customer sizes and requirements. This includes defining backup expectations and reviewing roles and responsibilities (for example, via a RACI matrix) to identify and close any gaps. This blog https://www.sap.com/sea/blogs/erp-cloud-without-surprises explains who really does what is SAP Clud ERP Private.	Operational model Availability SLAs for solutions Customer’s specific backup SLA Review of roles and responsibilities RACI matrix to identify potential gaps

Table 2: Technical aspects to be assessed

The outcome of the technical domain sessions and the customer landscape assessment is a clear and accurate “to‑be” picture of the customer environment, including the transformation strategy. This serves as the blueprint to design and build the final landscape in SAP Cloud ERP Private.

Transition the customer’s requirements to GCO for delivery

SAP Cloud ERP Private is a managed private cloud service delivered by Global Cloud Operations (GCO), requiring a structured handover of customer requirements to SAP.

Early transition planning: Although the formal transition begins after the Cloud ERP Private agreement is signed, preparation should start early to avoid deployment delays that could jeopardize the project timeline.

Support process: The Cloud Architect and Advisory (CAA) team guides customers and partners through this process by collecting onboarding information, coordinating milestones, and ensuring smooth delivery to SAP teams.

The following outlines typical onboarding information to be collected:

Type of Input	Input Needed
Operational	Support user (S-user) Type of deployment (greenfield or brownfield) Planned downtime SAP Best Practices activation Financial relevance Customer contact information Regulatory requirements – GxP, HIPPA, data sovereignty Cybersecurity requirements
SAP-specific	System parameters (SIDs, clients, languages, etc.) Target versions
Network and DNS	Connectivity method Connectivity data Private IP addresses ranges DNS information

Table 3: Onboarding information

Outcome of Technical Assessment: baseline and working document

The Technical Assessment process produces the Technical Assessment Report, summarizing all sessions and workshops, the proposed to‑be architecture for SAP Cloud ERP Private, and any assumptions or exceptions from discussions.

This report is shared with the customer for review and sign-off. It serves as the baseline for the commercial contract, delivery onboarding and is a living document throughout the contract lifecycle.

Innovate and grow in SAP Cloud ERP Private

Everything described above represents continuous engagement throughout the entire contract lifecycle, not a one-time effort.

For new customer requirements, the GCO team supports the customer and partner through a renewed technical assessment process. Depending on the requirement, relevant assessment domains and onboarding details will vary, but GCO provides full guidance—advising on goals and value drivers, identifying innovation opportunities, and extending the Cloud ERP Private scope via the change request process.

IaC for SAP BTP: Automating Environment Management with Terraform and CI/CD

2026-02-27T06:03:58.154000+01:00

Introduction

In our previous blogs, we introduced the concept of Infrastructure as Code (IaC) for SAP BTP using Terraform, and how it can help organizations manage their environments in a consistent, repeatable, and automated way.

For Cloud Engineers working outside the SAP ecosystem, this approach is already well established. Running Terraform through CI/CD pipelines, managing remote state, and promoting changes across DEV, QA, and PROD environments is a common DevOps pattern in modern cloud-native architectures.

With SAP BTP, the same principles can now be applied consistently within the SAP landscape. This opens up new possibilities for:

Cloud engineers who are new to SAP and want to apply familiar DevOps and IaC practices.
Experienced SAP administrators who are modernizing their landscape management using Infrastructure as Code and CI/CD automation.

While this article demonstrates the approach using a classic 3-tier landscape (DEV, QA, PROD), the architecture is by no means limited to that scenario. In fact, it becomes even more valuable when applied to medium and large enterprise landscapes, where multiple subaccounts, regions, teams, and services must be provisioned and maintained in a consistent and governed way. Automating these environments through CI/CD significantly reduces operational overhead and improves scalability.

There are multiple options when it comes to integrating Terraform into your automation workflows. For example:

CI/CD platforms to execute: Jenkins, GitLab CI, GitHub Actions, Azure DevOps.
Store state of managed landscape: SAP BTP Object Store, HashiCorp Vault, AWS S3, and more.

In this article, we will focus on a concrete implementation: Jenkins as the CI/CD platform and SAP BTP Object Store as the remote store for the Terraform state file. I'll also demonstrate how to structure the pipeline for a multi-environment landscape (DEV, QA, PROD).

Why This Matters: Key Use Cases

1. Consistent Landscape Provisioning

Organizations often need to provision and update identical landscapes (for example, DEV, QA, and PROD) for multiple development teams or applications. Doing this manually is time-consuming, error-prone, and not scalable.

Certainly, Cloud Engineers and BTP Admins can execute Terraform commands ona local machine or laptop, as we discussed in a previous blog. But of course, in the real world, such operations need to be automated via CI/CD pipelines and embedded in processes.

With CI/CD and Terraform, we can:

Deploy and update environments automatically and consistently.
Manage infrastructure from an external system, not manually.
Enforce corporate policies and naming conventions.
Minimize the workload for Ops teams.
Scale quickly when new teams or projects need their own BTP environments.
Ensure full transparency and auditability through the pipeline.

2. Automated BTP Landscape Management

Beyond provisioning, enterprises need centralized, automated control of SAP BTP environments. This includes:

Provisioning subaccounts, service instances, entitlements, and roles.
Enabling self-service deployments for development teams.
Enforcing governance and segregation of duties across environments.
Reducing time-to-market for new services and solutions.
Integrating seamlessly with existing DevOps processes.

Provisioning of new and updating of existing subaccounts should be a part of the new application deployment, mainly to have a consistent environment across landscape.

Architecture Overview

In our scenario, we would like to automate the provisioning of a 3-tier landscape, with a similar configuration inside, follow the naming convention, and also save the states of our subaccounts in an external S3 bucket. At the moment, via CI/CD pipeline, without governance(I will cover it in the next blog).

The setup described here is based on:

GitHub repository to store our Terraform configuration files.
We will use Terraform providers from SAP to manage SAP BTP resources.
Jenkins CI/CD platform for pipeline orchestration.
SAP BTP Object Store for storing the Terraform state (terraform.tfstate file).
Multiple environments (DEV, QA, PROD) managed via dedicated state files.

A high-level flow looks like this:

Cloud Engineer/Basis Admin commits Terraform configuration to Git.
Jenkins triggers pipeline execution. Basically, it can be triggered by GitHub webhook, or run by schedule, via API from an external system, or manually.
The state file is stored in SAP BTP Object Store.
Depending on the selected parameters (apply, show, destroy), a different subset of operations will be executed.
Changes are applied to the targeted environment (DEV, QA, or PROD), also based on the input parameters for pipeline execution.

Remote State Management

Terraform uses the state file (terraform.tfstate) to track the current infrastructure, and calculate changes in case of update or destroy. For multi-team, multi-environment setups, storing this state remotely is critical.

In our case, I'll use SAP BTP Object Store as the store for state files separated per subaccount:

Each environment (DEV, QA, PROD) has its own path and state file.
Remote state ensures collaboration without conflicts.
Access is controlled through Object Store policies and Jenkins credentials.

This provides consistency, security, and scalability when our Jenkins pipeline interacts with multiple BTP subaccounts.

Multi-Environment Strategy

There are two common approaches to managing multiple environments:

Terraform workspaces
Separate state files per environment (our case).

In our setup, Jenkins pipelines are parameterized by environment.

A pipeline may run for Dev, QA and Prod.
Each environment has its own state stored in Object Store.
Promotion of changes follows the lifecycle DEV → QA → PROD, ensuring controlled rollout.

CI/CD Pipeline with Jenkins

Our pipeline for provisioning and manage BTP landscape in Jenkins includes the following steps:

Terraform Init. Basically, pipeline pulls data from GitHub and initialize terraform config, dowload providers and etc.
- Terraform plan. On this step, Terraform(in a container, I described this part in the previous blog) calculates what should be done based on the tfstate file(in case of update or destroy), or the deployment plan in case of a new deployment.
Terraform apply. Deployment execution based on the calculated plan.
Terraform destroy. Destroy the subaccount in case of decommissioning. Would be more relevant for the temporary subaccount deployed for test purposes
Send Request to SAP CALM(I'll skip this step in this blog.)

An important note.

Terraform init.
- Configure Terraform to use SAP BTP Object Store as the store for tfstate files and provide a naming convention for tfstate files.

Based on the configuration of my pipeline in Jenkinsfile, when we run the Jenkins pipeline manually, we can see the input window where we can choose what and where we want to execute.

Uses Jenkins parameters to choose the environment. In the future, we will automatically pass these parameters via API
Loads credentials securely.
Runs the full Terraform cycle from init to apply/destroy.
Stores the state file with information of provisioned/updated landscape in BTP Object Store bucket.

Below result of execution with the log of what was provisioned.

Conclusion

By combining Terraform, Jenkins, and SAP BTP Object Store, organizations can build a scalable and repeatable automation framework for managing SAP BTP environments.

This approach enables:

Faster and more reliable provisioning of landscapes.
Reduced manual effort and operational risks.
Clear separation of environments with controlled promotion paths.
Integration into broader DevOps and compliance processes.

In the next blog, we will explore how to integrate Terraform-driven automation with SAP Cloud ALM, extending Infrastructure as Code to the operational lifecycle of BTP landscapes.

Let's Talk: Transformation (Webinar Series)

2026-04-03T11:04:03.873000+02:00

We invite you to participate in these engaging roundtable sessions. It’s your chance to:

- Share your organization’s experiences and learn from industry peers.

- Explore best practices in transformation programs.

- Gain actionable insights to propel your organization forward.

Together, let’s drive impactful changes and ensure your journey with cloud solutions is both rewarding and successful.

Let's Talk Transformation - Session Calendar 2026

Virtual roundtable sessions for H1 2026 (HR Connect in-person events excluded). All sessions are live via Teams/Zoom.

Session Title	Date	Time	Region	Registration Link
Sustaining your Cloud Solution	April 9, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Managing Continuous Change	April 15, 2026	7:00 PM UTC / Apr 16 2:00 AM AEST	APJ	Register Here
Modelo de Gobierno / Governance Model	April 21, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
Sustaining your Cloud Solution	April 21, 2026	7:00 PM UTC / Apr 22 2:00 AM AEST	APJ	Register Here
Efficient Data Management	April 22, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Managing Continuous Change	April 23, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Gestion de Partners / Partner Management	April 27, 2026	9:00 AM UTC / 11:00 AM MEX / 4:00 PM CHILE	LATAM	Register Here
Efficient Data Management	April 28, 2026	8:00 PM UTC / Apr 29 3:00 AM AEST	APJ	Register Here
Sostenimiento de la Solucion de Nube / Sustaining your Cloud Solution	April 29, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
Managing Continuous Change	May 6, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
Transforming HR with AI	May 7, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Managing Continuous Change	May 11, 2026	7:00 PM UTC / May 12 2:00 AM AEST	APJ	Register Here
Transformando RH con IA / Transforming HR with AI	May 12, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
How Future to Present Focused HR is Shaping Cultures	May 14, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
How HR is Future to Present is Shaping Mindsets	May 18, 2026	8:00 PM UTC / May 19 3:00 AM AEST	APJ	Register Here
Gestion de Partners / Partner Management	May 19, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
Efficient Data Management	May 20, 2026	8:00 PM UTC / May 21 3:00 AM AEST	APJ	Register Here
Value Management	May 21, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Transforming HR with AI	May 24, 2026	6:00 PM UTC / May 25 1:00 AM AEST	APJ	Register Here
Sustaining your Cloud Solution	May 26, 2026	7:30 PM UTC / May 27 2:30 AM AEST	APJ	Register Here
Modelo de Gobierno / Governance Model	June 2, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
Efficient Data Management	June 2, 2026	8:00 PM UTC / Jun 3 3:00 AM AEST	APJ	Register Here
Sostenimiento de la Solucion de Nube / Sustaining your Cloud Solution	June 9, 2026	8:00 AM UTC / 10:00 AM MEX / 3:00 PM CHILE	LATAM	Register Here
Managing Continuous Change	June 9, 2026	7:00 PM UTC / Jun 10 2:00 AM AEST	APJ	Register Here
Sustaining your Cloud Solution	June 11, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Sustaining your Cloud Solution	June 16, 2026	7:30 PM UTC / Jun 17 2:30 AM AEST	APJ	Register Here
Efficient Data Management	June 18, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Transforming HR with AI	June 23, 2026	6:00 PM UTC / Jun 24 1:00 AM AEST	APJ	Register Here
Managing Continuous Change	June 25, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here
Transforming HR with AI	July 2, 2026	7:00 AM UTC / 9:00 AM CT / 2:00 PM CET	EMEA/NoAm	Register Here

Introducing Architecture Switching in SAP Solution Scout

2026-04-08T18:00:00.021000+02:00

See the Right Solutions with Ease

Cloud Architecture: Dynamically showcase public cloud solutions centred around “SAP S/4HANA Cloud Public Edition,” for unmatched scalability and speed.

Hybrid Architecture: Effortlessly explore a blend of public cloud components with private cloud or on-premises elements via “SAP S/4HANA Cloud Private Edition,” or “SAP S/4HANA.”

Unlock These Benefits

Precision Filtering - See only the most relevant solutions based on your chosen architecture.
Faster Decisions - Save time by focusing on the best-fit options for your specific needs.
Strategic Readiness - Ensure your chosen solutions align with your long-term business goals.

Empower your digital transformation journey with SAP Solution Scout’s enhanced flexibility, making it easier than ever to find the perfect solutions tailored just for you.

Start Navigating Your Ideal Solutions with SAP Solution Scout Today!

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

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

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

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

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

Flowchart giving overview for complete Process

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

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

BACKEND BUILD :

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

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

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

cds add hana,xsuaa --for production

b. Below terminal command will add blueprint for deployment.

cds add mta

c. Below terminal command will install libraries.

npm install

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

3. Click on Finish after selecting all the options.

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

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

user: CRUDApp $ pwd

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

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

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

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

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

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

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

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

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

Now let's continue with further steps from Backend.

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

namespace my.bookshop;

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

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

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

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

FRONT END BUILD:

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

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

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

4. Give Name to App and Module.

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

VALIDATION :

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

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

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

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

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

SECURITY:

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

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

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

4. There are two options for adding Approuters.

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

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

cds add approuter

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

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

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

DEPLOYMENT:

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

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

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

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

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

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

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

cf login

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

cds deploy --to hana --profile hybrid

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

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

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

mbt build

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

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

cf login

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

cf deploy mta_archives/CRUDApp_1.0.0.mtar

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

TESTING

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

cds watch --profile hybrid

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

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

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

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

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

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

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

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

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

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

FINAL APP EXECUTION🔥:

1. Now, lets open the app as below.

2. Lets create some incorrect entries as below.

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

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

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

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

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

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

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

CONCLUSION:

Hence the overall flow looks as below.

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

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

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

SAP Community - Cloud

Linux Shell Script for automating graceful startup and shutdown of SAP S4HANA System

Sizing Your Success: A Guide to SAP Cloud ERP Private

What is SAP Cloud ERP Private?

General SAP Sizing Overview

SAP Cloud ERP Private Sizing Strategy

Standard Sizing: The T-Shirt Model

Tailored Sizing: Customization for Complexity

“Size to Scale” and Technical Assessment

SAP Sizing & Technical Assessment Engagement Flow

Monitoring and Reporting in Cloud ERP, Private

Greenfield vs. Brownfield: Sizing Strategies for SAP S/4HANA Success

Greenfield Sizing: Building from the Blueprint

Brownfield Sizing: Converting the Past to the Future

Key Recommendations and Next Steps

Key Resources for SAP Sizing & Technical Readiness

SAP Landscape Strategy in the Era of Managed Cloud and AI

The Case for Landscape Consolidation

Beyond Systems: Why Process Harmonization Matters

How Cloud & AI Have Evolved SAP Landscape Strategy

Landscape Options for SAP Process Harmonization

Why Template Strategies are so Attractive

Driving Alignment and Change Across the Enterprise

Decision-Making Framework: From Strategy to Execution

Turning Consolidation into Competitive Advantage

Consider SAP Customer Advisory

Solution Order Simulation APIs - OData V4

Table of Contents

Introduction

Authentication and Access

Metadata

API Capabilities and Entities

BusinessSolutionOrder – Solution Order Header

BusSolnOrdPartner – Solution Order Header Partner

BusSolnOrdItmPartner – Solution Order Item Partner

BusSolnOrdItmPriceElement – Item Price Element

BusSolnOrdItmBillgReqItem – Item Billing Request Item(Contract Item)

Solution Order APIs - OData V4

Table of Contents

Introduction

Authentication and Access

Metadata

API Capabilities and Entities

BusinessSolutionOrder – Solution Order Header

BusinessSolutionOrderItem – Solution Order Item

BusSolnOrdPartner – Solution Order Header Partner

BusSolnOrdItmPartner – Solution Order Item Partner

BusSolnOrdPartnerAddress – Address of Header Partner

BusSolnOrdItmPartnerAddr - Address of Item Partner

BusSolnOrdItmPriceElement – Item Price Element

BusSolnOrdItmScheduleLine – Item Schedule Line(Sales Item)

BSOrdItmRateElement – Item Rate Element (Subscription Item)

BSOrdItmSubscrpnParameter – Item Subscription Parameter(Subscription Item)

BSOrdItmSubscrpnPriceAgrmt Item Price Agreement(Subscription Item)

BusSolnOrdItmProduct – Item Product(Contract Item)

BusSolnOrdItmRefObject – Item Reference Object(Service or Contract Item)

BusSolnOrdItemRelationship – Solution Order Item Relationship

BusSolnOrdUserStatus – Header User Status

BusSolnOrdItmUserStatus – Item User Status

BusinessSolutionOrderLongText – Header Long Text

BusSolnOrdItmLongTxt – Item Long Text

BusSolnOrdItmBillgReqItem – Billing Request Item(of a Contract Item)

BSOrdItmBillgReqItmPrcElm – Price element of Billing Request Item (Contract Item)

BusSolnOrdAppointment – Header Appointment

BusSolnOrdItmAppointment – Item Appointment

BusSolnOrdItmDuration – Item Duration

BusSolnOrdFUPSalesOrder – Follow-up Sales Order

BusSolnOrdFUPSrvcOrd – Follow-up Service Order

BusSolnOrdFUPSrvcContr – Follow-up Service Contract

BusSolnOrdFUPSubscrpn – Follow-up Subscription

BusSolnOrdFUPEntProject – Follow-up Enterprise Project

BusSolnOrdItmFUPSalesOrder - Follow-up Sales Order Item

BusSolnOrdItmFUPSrvcOrd – Follow-up Service Order Item

BusSolnOrdItmFUPSrvcContr – Follow-up Service Contract Item

BusSolnOrdItmFUPSubscrpn – Follow-up Subscription Item

BusSolnOrdItmFUPEntProject - Follow-up Enterprise Project Item

Cloud-Native with ABAP Cloud – The Transactional Outbox Pattern

Cloud-Native with ABAP Cloud – The Transactional Outbox Pattern

The Logical Unit of Work

Eventual Consistency