Skip to main content

Celonis Product Documentation

Real Time Extension
EMS Deployment Options

Real Time Connection to SAP can be implemented both for Full Cloud and Hybrid (LYDIP) scenarios.

Supported Databases

The following database are currently supported:

  • Oracle

  • DB2

  • MS SQL (2012 and higher)


  • Sybase

RFC Module and Extractor

The real-time extension requires the following minimum versions of the Celonis RFC Module and Extractor:

  • RFC Module: 2.0.0

  • SAP Extractor: 2020-10-19

Please install/upgrade these components before moving forward with the setup.

For clean installation of the RFC Module and Extractor Service follow the steps as described in Celonis RFC Module: Requirements and Installation.

The Real-time extractor setup mainly includes the following 2 actions:

  1. Create the Log tables to store the changes in SAP

  2. Install triggers to monitor the changes in SAP

Step 1 has been simplified by including the Change Logs of the standard templates (O2C, P2P, AR, AP) in the transports of the Celonis RFC Module. This means that the customer who is installing the RFC Extractor the first time can easily activate the Change Log tables for the respective process with minimal effort, as described below.

The standard SAP landscape is comprised of 3 systems - DEV, QA, and PROD. The Log tables can usually be created only in the DEV system because the QA and PROD systems are locked for these kinds of changes. After the tables are added in DEV, they should be transported to QA and then to PRD via transport. However, the triggers are not transportable, and should be installed in QA (for testing) and then subsequently in PRD (for productive use). The diagram below describes a typical setup process.


To add a Change Log table:

  1. Log in into SAP and navigate to Transaction Code /CELONIS/CLMAN_UI

  2. Click the button “Add Change Log Tables”

  3. In the pop up select the process you want to activate. The respective tables will be populated on the screen.

  4. Click "Check Tables" to dry run the creation process. If everything is green, click "Save", and the Change Log tables will be added


After the tables are created, you will need to transport them to the next system as described in the next section.

Default tables for the main 4 processes

You can find the recommended tables for the main 4 processes on the following page, or in this google sheet: Tables for Real Time Extraction Mode

Required SAP rights to add log tables and triggers

The SAP User should have a minimum of the following rights to be able to create the tables and add triggers. However, usually, this action is performed by SAP BASIS who has full admin rights.

  • Object: S_TCODE


  • Object: S_RFC



    3. ACTVT: 16

  • Object: S_TABU_NAM

    1. ACTVT: 03

    2. TABLE: * or the specific tables

  • Object: S_DEVELOP

    1. ACTVT: *


    3. OBJNAME: *


To streamline the transfer of CL tables from DEV to either QAS or PRD, the T code /CELONIS/CLMAN_UI allows the user to generate a transport that carries forward the setup configurations to the next system in the landscape.

Before creating the transport in DEV, the SAP BASIS admin should change the Transport Layer of the package ZCELONISCL. Make sure to select a Layer that contains a Consolidation Route connecting DEV to QAS. This will ensure that the log tables can be assigned to a transportable request, and therefore, be pushed forward from DEV to QAS. To change the layer:

  1. Call SE80 to open the Object Navigator

  2. In the object list selection, choose Package.

  3. Enter ZCELONISCL and choose Display.

  4. Double-click the name of the package.

  5. Switch to edit mode

  6. Select a Transport Layer that contains a Consolidation Route connecting DEV to QAS



After saving the Transport Layer change, you may be prompted to transport that modification too. However, this change is not needed in QA/PRD so you don't need to transport it.

After performing the steps above, you are ready to create a transport request for the Change Log tables. To do that:

  1. Call the transaction code /CELONIS/CLMAN_UI

  2. Click the Transport button

  3. Select a Request where to place the transport, or create a new one

    1. If creating a new Request, define a description and click save.

  4. The all Change Log tables and the configuration table will be added to the transport request, which you can release to the next system.

A trigger should be installed to track the changes in the source tables, and capture them in the respective Change Logs. To do that:

  1. Log in into SAP and navigate to Transaction Code /CELONIS/CLMAN_UI

  2. Find the table(s) in the grid (check this section for the steps on how to add a table)

  3. Click on Install Trigger

  4. After the trigger is installed successfully, its name will be displayed in the column “Trigger Name”

After these steps are completed successfully, the Delta Extractions for the specified tables will be executed in real time mode. The date and time of latest successful execution will be displayed in the column “Last Extracted Date”.



Triggers cannot be transported. They should be installed in QA (for testing) and then subsequently in PRD (for productive use).

In the CL Management UI you can set up a recurring background job in SAP which will run on a daily basis and clean up the records from the Log tables.

To set up the job click the button "Clean Up Settings". A dialogue will pop up where you should define:

  • Number of days to keep records. All records older than the specified date will be removed from the log tables.

  • Where to run the background job. If the "Run Anywhere" option is selected, SAP system will decide on which server to execute the job. Otherwise, the job will be run on the same server where the settings have been defined.



The clean up background job is an important element to control the size of the Log tables. It prevents the tables from growing in case they are not being extracted.

Removing Triggers and Tables

Both the Triggers and Log tables can be removed via the transaction code /CELONIS/CLMAN_UI. Unlike adding a table, you DON'T need to create a transport from DEV. You can remove the log table and the trigger directly in production without opening the client for changes.

However, make sure that the same tables are removed in DEV and QA as well, to ensure that all systems in the landscape have a similar setup.

Temporary Suspension of the Triggers

There may be situations where it is necessary to temporarily suspend the triggers, for example during massive data migration. This can be done by deleting the trigger and then re-installing it later for the respective tables.

Checking the Table Type Before Activating Logs for it

SAP tables from which the data is extracted by Celonis usually fall into one of these classes:

  • Transparent Table

  • Cluster or Pool Table

Transparent tables physically exist at the database level, and there is a 1-to-1 mapping between the logical table in SAP and its physical equivalent in SAP. Most of the tables fit into this category, i.e. EKKO, EKPO, BKPF, VBAP, etc...

Pool and Cluster tables, on the contrary, exist only in the SAP logical layer and do not have a physical counterpart in the database. This makes it impossible to install triggers for them because there is simply no equivalent base table in the database. The most popular Cluster tables are BSEG and CDPOS.

If you want to activate real-time mode for a table that is not present in the standard script, you should first check whether it is transparent or not. Table classes are stored in the SAP table DD02L. This table should be extracted and then the following query run, to check the class of the tables for which triggers are desired. Replace XXXX with the desired table name.

select * from "DD02L"

where "DD02L" . "TABNAME" in ( 'XXXX' )

Replacing BSEG with Secondary Index Tables

BSEG is not a Transparent table and therefore we cannot install triggers on it and extract it in real-time mode. Meanwhile, given its size and importance, we cannot simply exclude it from the real-time extraction, so it is strongly recommended to replace BSEG with alternative Transparent tables. You can find detailed documentation on how to do it here.

Are the triggers created in SAP or at the database level? The trigger creation command is executed from an SAP GUI (transaction code /CELONIS/CLMAN_UI), however, the trigger is created only at the database level executing native SQL command. In other words, the trigger does not exist in the SAP Data Dictionary. Therefore it cannot be transported and should manually be created in each environment. Is there a performance impact on the SAP system?

Triggers generate a logging entry for each transaction in SAP, so there is some impact. However, the impact is very small and does not slow down operations.

Triggers are a native database technology and therefore they are very effective. They are not a technology created by Celonis, and we just instruct the trigger when and how to react.

What should we do in case of data migrations, when there are billions of records entered in the database?

Before starting the data migration you can delete the triggers, and then re-install them once the migration is over.

When does the trigger fire, i.e. create a log record?

Triggers operate at the database level, and whenever the database record is inserted/updated/deleted the trigger works. The trigger responds to all field updates, and it does not distinguish between the standard SAP and custom (Z) fields. For any update, a log record will be generated.

We have thousands of transactions on a daily basis. I imagine that the Log tables will grow very fast. Are they cleaned up regularly?

When setting up the triggers you should also create the Clean Up job, which is basically an SAP Recurring Background Job that runs on a daily basis and removes the extracted records that are older than X days, where X is defined by you. This makes sure that the tables are regularly purged and consume minimal space.

We already have SLT running? Will the real-time extractor interfere with it?

The real-time extractor uses its own triggers which will not interfere with those of SLT. Both can be run in parallel.