Skip to Content
Technical Articles

Run Modes of SAP BW Streaming Process Chains

Dear SAP BW enthusiasts!

Recently, one of my customers asked me for possible approaches to implement real-time reporting. During preparation my research also covered “Streaming Process Chains” with surprising results. For this reason I thought it would be a good idea to share “one of the best kept secrets of BW functionality” here in the SAP community.

This blog post will focus on the streaming process chain run modes and provides URLs to additional sources in the end. I use the general term “SAP BW” which refers to both SAP BW 7.5 and SAP BW/4HANA (any release).


In general, acquiring data as fast as possible should not be regarded as first choice. Instead, SAP recommends leveraging virtualization and data federation wherever possible. In combination with SAP HANA, BW provides multiple suitable modeling options, mainly based on SAP HANA integration services (SDA, SDI), SAP HANA modeling options (Calculation Views), and Open ODS Views or CompositeProviders as virtual InfoProviders on the BW application side.

Only if these approaches do not meet your business requirements, loading data in “real-time” into SAP BW should be evaluated as a serious alternative. Introduced long ago in 2006 with NetWeaver 7.0, “Real-Time Data Acquisition (RDA)” was the related concept for InfoCubes and DSOs (classic). However, with the introduction of ADSOs, SAP decided to retire RDA and to enhance the existing framework of process chains instead.

Streaming is an operation mode of BW process chains which can be set in the properties of each process chain. When a process chain is running, each step takes a certain amount of time; the interesting question is what actually happens, when the chain is started again -maybe even several times- during this period, and the execution reaches the process which is already active from a previous execution:

  • A classic process chain is scheduled in the background. Then the second execution waits 10 minutes for the previous execution to complete. If the previous run is not completed within this period, the second execution is canceled, the process chain is interrupted and fails with an error.
  • A process chain in streaming mode is executed using a new Queued Task Manager Framework. This enables a flexible number of “worker” jobs that get the next process from a queue. If a second, third, and further execution reaches the current active process, these requests to start this process once more are written to a queue only. No more resources are used, and the system does not wait. As soon as the current process is finished, the worker job receives all of these start requests for a given process and restarts the process just once: It takes the most recent chain execution from the queue and executes it. This means that the second and third chain executions are dropped, and only the most recent chain execution is continued.

In a nutshell, the main value-added the Streaming mode is that it facilitates the frequent data transfer from a source system to SAP BW without scheduling errors and without unreasonable waste of resources. As a result, data can be acquired in SAP BW in almost real-time. It is not 100% real-time, because the realistic latency is measured in minutes in the best case. So do not expect latency times of milliseconds to seconds which are common in SAP SLT replication scenarios for example.

In general, there are different run modes to be distinguished: A Push and two Pull run modes. The main difference between them is whether the consuming system or the source system is triggering the data transfer.

A) The PUSH Run Mode

Main Characteristics:
SAP BW receives a trigger from a so-called ODP Daemon in the source system if a new record is generated there. This event starts the immediate execution of the process chain which transfers the new data to the SAP BW InfoProvider.
This is the preferred mode for ODP sources, because the process chain runs only when new data is available in the source. The process chain is scheduled once in streaming mode, the definition of periodic repetitions is not required.
The daemon has to be scheduled as regular job ODQ_DAEMON_CLIENT_xxx in the SAP source system (tr. ODQMON, GoTo/Real-Time Daemon…). By default scheduling, It checks all 15 sec for updates and sends an event to BW if there are any.


  1. This mode is only available for ODP DataSources of types SAP Extractors, ABAP CDS Views, BW InfoProviders and SLT.
  2. Another precondition is that DataSources are Delta-capable:
    • ODP_SAP or ODP_CDS: The delta-capability is dependent on the implementation.
    • ODP_BW: The delta-capability depends on the source InfoProvider. Supported sources are DSOs (classic), InfoCubes and ADSOs.
    • ODP_SLT: All DataSources are delta-capable in general.
  3. Finally, the DataSources need to support Streaming (“Streaming can be triggered by this DataSoure“):
      • ODP_CDS, ODP_BW, ODP_SLT: All delta-capable DataSources support this property by default.
      • ODP_SAP: This property depends on the individual implementation of the extractor. For example, LO Cockpit DataSources (2LIS_*) are generally not streaming-enabled due to their complexity (e.g. due to the queued delta), but other SAP delivered DataSources might support this feature. However, most of the SAP delivered DataSources are not streaming-enabled in the delivered version. There are some corrections provided (see SAP notes 1692484, 1780297, 1782173), but in most of the cases so-called Realtime-flag has to be set manually in the SAP source system (e.g. by a customer report updating ROOSOURCE-REALTIME to value ‘X’, see also SAP note 905089, which is not released currently and so SAP internal only). However, consider that this makes only sense for DataSources which are able to provide new data in real time, which means a delta is available at every point of time.
        Customer developed DataSources do not have this property initially as well. It must be enabled explicitly in the DataSource definition (Tr. RSO2). The corresponding property is called Real-Time enabled and is available in the customizing settings for the Delta mode.

B) The Intelligent PULL Run Mode

Main Characteristics:
SAP BW checks very frequently (each 60 seconds) if a new record is generated in the source. If this check is successful, the process chain is started immediately to transfer the new data to the target InfoProvider. The process chain is scheduled once in streaming mode, the definition of periodic repetitions is not required.
This is the preferred mode for HANA sources, because the process chain runs only when new data is available in the source system.


  1. This mode is available for HANA DataSources only.
  2. The DataSources need to be Delta-capable.
  3. If the source system type is HANA_LOCAL or HANA_MDC (BW/4HANA) / HANA with connection type “Local SAP HANA Database Schema” (BW 7.5), check additional requirements in SAP note 2372534.
  4. If the source system type is HANA_SDA (BW/4HANA) / HANA with connection type “SAP HANA Smart Data Access” (BW 7.5), it is important which type of remote connection is in use:
    • SAP HANA Smart Data Access (SDA) does not support this run mode in general.
    • SAP HANA Smart Data Integration (SDI): The intelligent PULL mode is available only for adapters which support “Real-time Change Data Capture” as documented in the PAM functional overview of SAP HANA SDI 2.0 (pages 20-22). Currently those are: ASEAdapter, ASEECCAdapter, DB2ECCAdapter, DB2ECCLogReaderAdapter, MssqlECCAdapter, MssqlLogReaderAdapter, OracleECCAdapter, OracleLogReaderAdapter, PostgresSQLLogReaderAdapter, HanaAdapter, TeradataAdapter, AbapAdapter, CloudDataIntegrationAdapter and TwitterAdapter.

In a nutshell, the SDI adapter replicates each change to a generated BW table (/BIC/CMT*) in real-time. You can identify this table in the BW DataSource definition, there is a button called SAP HANA objects. This is the location the streaming process chain checks for new data regularly.

Note: For BW DataSources related to source system HANA_* the Streaming property is always off (“Streaming cannot be triggered by this DataSource“). Do not be confused – I was confused myself quite a long time…it seems like this property only refers to the PUSH mode and thus to ODP sources.

C) The Scheduled PULL Run Mode
Main Characteristics:
SAP BW executes a process chain which leverages the streaming framework, no matter if there are new data in the source or not.  The Streaming process chain is scheduled as a periodic job and it can be executed very frequently if required (up to each minute). If there are updates available, they will be loaded immediately to SAP BW. On the other hand, if there is no new data, then an empty request is created in the target InfoProvider.
This is the preferred mode, if the source is receiving streaming data, e.g. a record each second. In this case the PUSH or intelligent PULL would not be able to process the new data in the same speed toward SAP BW. So this simple frequent scheduling could be most efficient approach.



  1. This mode is available for ODP DataSources which are not streaming-enabled.
  2. This mode is also available for HANA DataSources which rely on SAP HANA SDA, or they are based on SAP HANA SDI connections which do not support “Real-time Change Data Capture” (all adapters which are not listed above).
  3. Another precondition is that the DataSource is Delta-capable.

Note: The fact that the preconditions the PUSH mode (A) or the Intelligent PULL mode (B) are not met, does not mean, that you cannot run process chains in streaming mode. You can still leverage the queued task manager framework to run them with high frequency for Delta-capable DataSources. In this case, the process chain needs to be scheduled as a periodic job to pull data from the source in up to 1 minute frequency, instead of the process chain being triggered only when new source data is available.



The Streaming property is a really cool enhancement of the process chain concept in SAP BW. It provides a flexible toolset, if you really have to load data as fast as possible into a BW InfoProvider. The preferred run modes are the PUSH mode and the Intelligent PULL mode, as they only trigger the DTP execution if new source data is generated.

I recommend following SAP Education offerings if you are eager to learn more about this topic and much much more. We have prepared a sophisticated scenario based on SDI HanaAdapter where you can explore streaming process chains hands-on. Both trainings are currently upgraded to SAP BW/4HANA 2.0 SP07 with more details about streaming process chains. Availability of this latest version expected by mid-2021.

  1. BW462 – SAP BW/4HANA: Delta from BW classic
  2. BW450 – SAP BW/4HANA Data Acquisition



There are some interesting blog posts in this community which provide use cases for the run modes introduced above:

  1. Streaming Process Chains – Scheduled PULL via ODP_SAP and PUSH via ODP_SLT
  2. Streaming Process Chains – PUSH via ODP_CDS
  3. Streaming Process Chains – PUSH via ODP_SLT (1)
    Streaming Process Chains – PUSH via ODP_SLT (2)

For additional details refer to the SAP help portal or following SAP notes:

  • SAP BW/4HANA help about Process Chains for Streaming
  • SAP note 2844555: Corrections for Streaming Process Chains (BW Note Analyzer)
  • SAP note 2372534: Streaming data from local SAP HANA schema to SAP BW
  • SAP note 2447916: How to transfer RDA to Streaming Process Chains
  • SAP note 2865995: How to check if an ODP DataSource supports PUSH Streaming or not
Thanks to Waldemar, Dirk, Nicola, Thomas, Deniz, Tobias, Jens, Alex, Andreas, Luiz, Paul and others who provided valuable input for this blog post!
You must be Logged on to comment or reply to a post.
  • Hi Frank, thanks for this interesting blog. The pull mode was new to me and can be of interest for many scenarios. A problem I found when testing streaming process chain was to skip a record in case a record produces an error. SDI based remote subscriptions offer such a functionality. My test was to send two number from the source and then do a division as a logic in the transformation between DS and target. When I sent a 0 for the divisor I got as expected a div by 0 shortdump. But couldn't figure out how to skip this record in the the processing so that the stream returned to be operative again. Any hints on that? Take care Philipp

    • Hi Philipp,
      was machst Du nur für Sachen... 🙂
      Well, I don´t know the exact answer how to skip a record with errors and fix the stream. But in general I think, there should not be any logic in the TRFN from DataSource to the ADSO for exactly the case you describe: To avoid any errors or delays on the BW target side. Here the focus is on the near-real-time transfer of data and any logic will put a danger there. At least the monitoring effort would increase.

      Viele Grüsse, Frank

  • Good one Frank! This blog covers a lot of unexplored areas of process chain streaming feature that BW techies were looking out for 🙂


  • Frank, once again an excellent blog from you covering a topic that is often asked about, but few are able to explain in detail. Thanks for sharing the findings of your research.

  • Excellent blog Frank! So valuable - especially as more customers asking for "real-time" or "near real-time" options when looking at data loads into BW. Thanks for sharing 🙂

  • Before this post, I thought the "push" mode is for ODP-SLT only, and the "pull" mode is for ODP-SAPI. Apparently, SLT always supports push, but ODP only sometimes does. Now it's clear that even if a data source doesn't support streaming (RSOOSOURCE-REALTIME flag is not set) and it says so, we shouldn't give up, because BW will use its own streaming, which is the "pull" mode. One way or another. Makes sense now.