End-to-end integration between SAP Datasphere, BTP, and SAC for planning automation: A Task Chain in SAP Datasphere calls a REST API on SAP BTP, which then triggers a MultiAction in SAP Analytics Cloud (SAC). The MultiAction executes planning logic, and the result loops back into a Task Chain—creating a fully integrated and automated planning cycle across systems.

This Is the Way: Rethinking Analytics Orchestration with REST in SAP Datasphere 

von Christian Schilcher-Williin BWBLOG, Datasphere/DWC, Planung, SACan Veröffentlicht am

This Is the Way: Rethinking Analytics Orchestration with REST in SAP Datasphere (DSP)

Introduction 

SAP Datasphere Task Chains have recently been enhanced with a new capability: the ability to add a REST API Step, as documented by SAP. This addition significantly expands the integration potential of Task Chains, allowing them to trigger or interact with external systems via REST APIs—something previously not possible within the task chain framework itself. 

While SAP Datasphere already offers a Command Line Interface (CLI) for interacting with its environment, I believe that technical automation—especially triggering Task Chains—should be handled via REST endpoints wherever possible. (Yes, I am aware this is already on the roadmap.) 

If you have followed the evolution of SAP Analytics Cloud, you have likely noticed how its REST API capabilities have grown considerably. This trend strongly suggests a broader strategic shift within SAP toward more API-driven architectures. 

Beyond the technical implications, this new feature offers a glimpse into how future data and analytics architectures might be designed. The ability to call external REST APIs directly from within a Task Chain is a small yet significant change—it paves the way for loosely coupled, event-driven, and more modular system landscapes. 

In this blog post, I will explore the broader implications of this feature—looking at both architectural perspectives and practical use cases—to illustrate how this seemingly simple addition might shape our thinking on modern data platform design going forward. The different implications and perspectives I will try to sketch out in this blog post. 

Integration Perspective 

With this new capability, you can invoke a REST service directly within a process step. What could such a REST service do? Here are a few examples: 

  1. Microservices and Third-Party Data Sources: Trigger a microservice that extracts data from a third-party system and writes it into SAP Datasphere using the OPEN SQL schema.
  2. Advanced Analytics on External Buckets: Initiate a predictive analytics process after data has been pushed to an external storage location (e.g., a Google Cloud Storage bucket), leveraging external computation power or models.
  3. Endless Possibilities: From orchestrating workflows to enriching data pipelines with external intelligence.

This simple yet powerful feature drastically lowers the barrier for integrating external systems. Especially in modern, heterogeneous IT landscapes, the ability to seamlessly interact with REST services is crucial. As solutions increasingly span multiple platforms and technologies, having native support for REST APIs within Task Chains enables more modular, scalable, and interoperable architectures. 

Task Chain integration with REST API and SAP Datasphere: This diagram illustrates a simple data flow where a Task Chain triggers a REST API call, which then extracts data and writes it directly into SAP Datasphere. It represents an automated data ingestion pipeline using external APIs.

SAC Seamless Planning Perspective 

At present, Seamless Planning in SAP provides only a foundational set of features. However, even with these basic capabilities, it is now possible to trigger a Multi Action in SAP Analytics Cloud (SAC)—with some lightweight technical implementation, such as a microservice on SAP BTP to handle user propagation. 

What Does This Enable? 

It opens the door to scheduling planning-related actions that can be executed automatically—daily, during off-peak hours, or at custom intervals—all orchestrated directly from SAP Datasphere. This marks a significant step toward greater automation and operational efficiency in planning processes. 

Looking ahead, the possibility of triggering a Task Chain from within a Multi Action (either via SAP’s upcoming official Task Chain Trigger feature or through a custom-built solution) would close the loop, enabling bi-directional process orchestration between SAC and Datasphere. 

A Vision of Integration – Imagine this scenario: 

  • Master data is loaded from an S/4HANA system into Datasphere (where the Master data may be managed in the future) and updated in the planning model. 
  • Once this loading process is completed, a Data Action is automatically triggered to generate the necessary planning combinations. 
  • Each step is orchestrated across systems—seamlessly integrating Datasphere and SAC. 

This evolving capability points to a promising future, where SAP’s tools are moving toward more open, event-driven, and tightly connected architectures. It is a strong signal of the direction SAP is heading—toward building truly integrated, cross-platform planning and data ecosystems. 

End-to-end integration between SAP Datasphere, BTP, and SAC for planning automation: A Task Chain in SAP Datasphere calls a REST API on SAP BTP, which then triggers a MultiAction in SAP Analytics Cloud (SAC). The MultiAction executes planning logic, and the result loops back into a Task Chain—creating a fully integrated and automated planning cycle across systems.


Process Orchestration

As outlined in the sections above, these new capabilities significantly enhance our ability to orchestrate analytics processes—in ways that were not possible just a few weeks ago. The integration of REST API steps and the evolving connectivity between SAP Datasphere and SAC unlocks a new level of flexibility. 

What makes this particularly compelling is the ease with which we can now develop lightweight microservices on SAP BTP to support and extend these interactions. Whether it is handling authentication, user propagation, or orchestrating complex logic between systems, BTP provides a robust platform for embedding custom logic into an increasingly modular and responsive analytics architecture.  

The On-Premises Thoughts 

I have already referred several times to the concept of a “small microservice on SAP BTP.” This idea becomes especially relevant when you consider that SAP Datasphere is still often used alongside SAP BW, where orchestration tasks are traditionally handled via Process Chains and ABAP reports. 

In many discussions—whether with internal teams or external consultants—there remains a strong inclination to implement logic directly within the ABAP stack of on-premise systems. This is understandable. It is what I would call the “home-field advantage”: familiarity, confidence, and reliability in an environment they know well. They’re certain it will work—but the question we must ask is: Will this remain a sustainable approach over the next 5 to 10 years? 

The reality is that, SAP’s Business Data Cloud is on the rise, and the centrality of BW in analytics architectures is gradually diminishing. So why not embrace a more future proof approach? 

By building a lightweight REST service on SAP BTP, we gain a flexible, scalable solution that can be triggered both by SAP BW and SAP Datasphere. This doesn’t just modernize our architecture—it lays the groundwork for future-proof integration patterns, better modularity, and easier maintenance in a cloud-centric world. 

A broader architectural perspective 

Another powerful dimension of this development is the ability to interact with a broader range of services available on SAP BTP, such as SAP Event Mesh. For example, you could emit an event to a queue and have that event trigger specific reactions among subscribed services. This pattern—similar to what has long been possible in SAP Data Intelligence using simple Pub/Sub mechanisms—enables a much cleaner, event-driven architecture that is better aligned with modern cloud-native design principles. 

But this blog is not just about the “small” new feature of the REST API step. It is about what this feature represents: a clear signal of how the SAP Analytics ecosystem is rapidly evolving toward the Business Data Cloud—with SAP Datasphere, SAP Analytics Cloud, and SAP Databricks at its core (leaving SAP BW Private Cloud Edition aside for now). 

This shift demands a mindset change for analytics consultants. To remain relevant and deliver robust solutions, we must go beyond our comfort zones and understand how SAP BTP enriches this ecosystem. That includes learning how to build with CAP or UI5, orchestrate processes using SAP Build, and embrace loosely coupled, service-based thinking. 

It’s no longer just about reporting and data modeling—it’s about understanding how to leverage the entire BTP toolset to design smarter, more flexible processes that are fit for the future. 

Conclusion 

The REST API step in SAP Datasphere Task Chains is much more than a technical enhancement—it is a strategic inflection point. It pushes SAP architecture toward: 

  • Greater openness and interoperability 
  • Microservice- and event-driven thinking 
  • Tighter orchestration between SAC, Datasphere, and BTP 
  • A cleaner transition from legacy on-prem ABAP logic 

The future is modular, cloud-native, and integrated—and this is your chance to start designing for it. 

Author: Christian Schilcher-Willi

Christian has been working as a Business Intelligence Consultant at ZPARTNER since 2020. He is specialized in advanced SAP BW/4HANA, HANA native modeling and SAP Datasphere solutions. Christian has a strong technical background in ABAP programming, AMDP transformations, Python-based data processing. He has worked in projects in various industries and developed solutions for complex data extraction, integration and modeling.