In SAP, PAL stands for Predictive Analysis Library.

It’s a collection of built-in, pre-delivered machine learning and statistical algorithms that run directly inside SAP HANA (in-memory database). Instead of exporting data to an external ML tool (like Python, R, etc.), PAL allows you to do predictive analytics inside HANA itself, close to the data.

Key Capabilities

• In-Database Predictive Processing: PAL enables running ML/statistical algorithms within the HANA database itself, eliminating the need to export data to external tools. This delivers high performance and reduces data latency.
• Rich Algorithm Portfolio: PAL provides a wide spectrum of built-in algorithms: classification (decision trees, logistic regression, Naïve Bayes), regression (linear, polynomial), clustering (k-means, DBSCAN), time-series forecasting (ARIMA, exponential smoothing), association rules, anomaly detection, and more.
• SQL/Script-Based Invocation: All PAL algorithms are exposed as SQL Script procedures. Developers can embed calls directly in SQL or stored procedures, enabling seamless integration with existing database logic without switching environments.

SAP HANA’s SQL Script is an extension of SQL. It includes enhanced control-flow capabilities and lets developers define complex application logic inside database procedures. However, it is difficult to describe predictive analysis logic with procedures.

Why PAL was introduced

For example, an application may need to perform a cluster analysis in a huge customer table with 1T records. It is impossible to implement the analysis in a procedure using the simple classic K-means algorithms, or with more complicated algorithms in the data-mining area. Transferring large tables to the application server to perform the K-means calculation is also costly.

Prerequisites

• ADT (ABAP Development Toolkit)
  
• ABAP GUI Logon with system access

Segmentation Analysis

• Open ABAP Perspective:

Window → Perspective → Open Perspective → ABAP

• Create an ABAP Project:

Use the left panel → Create ABAP Project → connect to your SAP system

• Define AMDP Procedures:

Create AMDP procedures to define input/output structures for the PAL algorithm

Create an ABAP Report:

1. Fetch the required data
2. Set algorithm parameters
3. Call the AMDP procedure to run the PAL algorithm
4. Display or store the results

Predefined PAL Algorithms Available in SAP HANA

The Predictive Analysis Library (PAL) defines functions that can be called from within SQL Script procedures to perform analytic algorithms. This release of PAL includes classic and universal predictive analysis algorithms in ten data-mining categories:
Clustering

• Classification
• Regression
• Association
• Time Series
• Preprocessing
• Statistics
• Social Network Analysis
• Recommender System
• Miscellaneous

Checking PAL Installation

To confirm that the PAL procedures were installed successfully, you can check the following three public views:

• sys.afl.areas
• sys.afl_packages
• sys.afl_functions

These views are granted to the PUBLIC role and can be accessed by anyone.
To check the views, run the following SQL statements:

SELECT * FROM "SYS"."AFL_AREAS" WHERE AREA_NAME = 'AFLPAL';
SELECT * FROM "SYS"."AFL_PACKAGES" WHERE AREA_NAME = 'AFLPAL';
SELECT * FROM "SYS"."AFL_FUNCTIONS" WHERE AREA_NAME = 'AFLPAL';

Example for Classification Algorithm

AMDP class: It acts as a bridge between ABAP and SAP HANA PAL. It allows us to define the input and output structures and call the PAL algorithms directly from ABAP, enabling in-database predictive analytics without moving data outside HANA.

CLASS cl_demo DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.
    INTERFACES : if_amdp_marker_hdb.

    TYPES : BEGIN OF ty_input,
              From_node TYPE c LENGTH 30,
              To_node   TYPE c LENGTH 30,
            END OF ty_input,

            tt_input TYPE STANDARD TABLE OF ty_input WITH EMPTY KEY,

            BEGIN OF ty_param,
              name       TYPE c LENGTH 60,
              intargs    TYPE i,
              doubleargs TYPE f,
              stringargs TYPE c LENGTH 100,
            END OF ty_param,

            tt_param TYPE STANDARD TABLE OF ty_param WITH EMPTY KEY,

            BEGIN OF ty_result,
              node TYPE c LENGTH 30,
              rank TYPE f,
            END OF ty_result,

            tt_result TYPE STANDARD TABLE OF ty_result WITH EMPTY KEY,

            BEGIN OF ty_user_count,
              role_name  TYPE string,
              user_count TYPE i,
            END OF ty_user_count,

            tt_user_count TYPE STANDARD TABLE OF ty_user_count WITH EMPTY KEY,

            BEGIN OF ty_scaling_input,
              data_id    TYPE i,
              count TYPE i,
              rank TYPE f,
            END OF ty_scaling_input,

            tt_scaling_input TYPE STANDARD TABLE OF ty_scaling_input WITH EMPTY KEY,

            BEGIN OF ty_scaling_param,
              name       TYPE c LENGTH 30,
              intargs    TYPE i,
              doubleargs TYPE f,
              stringargs TYPE c LENGTH 30,
            END OF ty_scaling_param,

            tt_scaling_param TYPE STANDARD TABLE OF ty_scaling_param WITH EMPTY KEY,

            BEGIN OF ty_res,
              data_id    TYPE i,
              count TYPE i,
              rank TYPE f,
            END OF ty_res,

            tt_res TYPE STANDARD TABLE OF ty_res WITH EMPTY KEY,

            BEGIN OF ty_model,
              id            TYPE i,
              model_content TYPE c LENGTH 5000,
            END OF ty_model,

            tt_model TYPE STANDARD TABLE OF ty_model WITH EMPTY KEY,

            BEGIN OF ty_statistics,
              stat_name  TYPE c LENGTH 256,
              stat_value TYPE c LENGTH 1000,
            END OF ty_statistics,

            tt_statistics TYPE STANDARD TABLE OF ty_statistics WITH EMPTY KEY,

            BEGIN OF ty_placeholder,
              param_name   TYPE c LENGTH 256,
              int_value    TYPE i,
              double_value TYPE f,
              string_value TYPE c LENGTH 1000,
            END OF ty_placeholder,

            tt_placeholder TYPE STANDARD TABLE OF ty_placeholder WITH EMPTY KEY.



    METHODS : run_pagerank
      IMPORTING
        VALUE(it_data)   TYPE tt_input
        VALUE(it_param)  TYPE tt_param OPTIONAL
      EXPORTING
        VALUE(it_result) TYPE tt_result,

      run_scaling
        IMPORTING
                  VALUE(it_input)       TYPE tt_scaling_input
                  VALUE(it_param)       TYPE tt_scaling_param OPTIONAL
        EXPORTING
                  VALUE(it_res)         TYPE tt_res
                  VALUE(it_model)       TYPE tt_model
                  VALUE(it_statistics)  TYPE tt_statistics
                  VALUE(it_placeholder) TYPE tt_placeholder
        RAISING   cx_amdp_error.

ENDCLASS.

CLASS cl_demo IMPLEMENTATION.

  METHOD run_pagerank BY DATABASE
   PROCEDURE FOR HDB
   LANGUAGE SQLSCRIPT OPTIONS READ-ONLY.

    CALL _SYS_AFL.PAL_PAGERANK(:it_data, :it_param, :it_result);

  ENDMETHOD.


  METHOD run_scaling BY DATABASE
     PROCEDURE FOR HDB
     LANGUAGE SQLSCRIPT OPTIONS READ-ONLY.

    CALL _SYS_AFL.PAL_SCALE(:it_input, :it_param, :it_res, :it_model, :it_statistics, :it_placeholder );

  ENDMETHOD.
ENDCLASS.

To execute PAL algorithms in SAP HANA, we create an ABAP report program. This program calls the methods defined in the AMDP class, fetches the required data, sets the necessary algorithm parameters, runs the predictive procedures, and captures the results for analysis or further processing.

REPORT zpal_demo.

DATA: lt_input               TYPE cl_demo=>tt_input,
      ls_input               LIKE LINE OF lt_input,
      lr_table               TYPE REF TO cl_salv_table,
      lt_param               TYPE cl_demo=>tt_param,
      ls_param               LIKE LINE OF lt_param,
      lt_result              TYPE cl_demo=>tt_result,           
      lt_scale_input         TYPE cl_demo=>tt_scaling_input,
      lt_scale_param         TYPE cl_demo=>tt_scaling_param,
      lt_scale_result        TYPE cl_demo=>tt_res,
      lt_scale_stcs          TYPE cl_demo=>tt_statistics,
      lt_scale_model         TYPE cl_demo=>tt_model,
      lt_scale_placeholder   TYPE cl_demo=>tt_placeholder,
      lr_pagerank            TYPE REF TO cl_demo,
      lr_scaling             TYPE REF TO cl_demo.

   START-OF-SELECTION.

  SELECT FROM (Data source)
        FIELDS * INTO TABLE (lt_final).

  "Run pagerank clustering
  CREATE OBJECT lr_pagerank.
  TRY.
      CALL METHOD lr_pagerank->run_pagerank
        EXPORTING
          it_data   = CONV #( lt_final )
          it_param  = lt_param
        IMPORTING
          it_result = lt_result.
    CATCH cx_amdp_version_mismatch INTO DATA(ls_error).
      CALL METHOD ls_error->get_text
        RECEIVING
          result = DATA(ls_txt).

  ENDTRY.

    "Parameters
  APPEND VALUE #( name = 'SCALING_METHOD' intargs = 0 doubleargs = 0 stringargs = '' ) TO lt_scale_param.
  APPEND VALUE #( name = 'Z-SCORE_METHOD' intargs = 0 doubleargs = 0 stringargs = '' ) TO lt_scale_param.
  APPEND VALUE #( name = 'NEW_MAX'        intargs = 0 doubleargs = '1.0' stringargs = '' ) TO lt_scale_param.
  APPEND VALUE #( name = 'NEW_MIN'        intargs = 0 doubleargs = '0.0' stringargs = '' ) TO lt_scale_param.
  APPEND VALUE #( name = 'DIVISION_BY_ZERO_HANDLER' intargs = 0 doubleargs = 0 stringargs = '' ) TO lt_scale_param.

  CREATE OBJECT lr_scaling.
  TRY.
      CALL METHOD lr_scaling->run_scaling
        EXPORTING
          it_input       = lt_scaling_input
          it_param       = lt_scale_param
        IMPORTING
          it_res         = lt_scale_result
          it_model       = lt_scale_model
          it_statistics  = lt_scale_stcs
          it_placeholder = lt_scale_placeholder.

    CATCH cx_amdp_error INTO DATA(ls_scale_error).
      CALL METHOD ls_scale_error->get_text
        RECEIVING
          result = DATA(ls_scale_txt).
      CALL METHOD ls_scale_error->get_longtext
        RECEIVING
          result = DATA(ls_long_txt).

  ENDTRY.

Note: While creating the parameter table, make sure to refer carefully to the official PAL documentation for the specific algorithm you are using. The structure and fields of the parameter table may differ based on the algorithm requirements, so modify it accordingly before execution.

The official PAL documentation will be attached at the end of this article for reference.

Example for including ISLM into Embeddings

*ISLM Connectivity
   DATA(lo_vector_api) =  cl_aic_islm_embed_api_factory=>get( )->create_instance( 'EMBEDDING' ).

Common error we face while working with PAL procedures:
Could not execute ‘CALL SYS.AFLLANG_WRAPPER_PROCEDURE_CREATE (‘area_name’, ‘function_name’, ‘schema_name’, …’ SAP DBTech JDBC: [259]: invalid table name: Could not find table/view SIGNATURE_TABLE in schema PA0001: line 2 col 34 (at pos 107).

How to Resolve this problem?.

The above-mentioned error usually occurs when the mandatory fields in the parameter table are missing or incorrectly defined.

Each PAL algorithm has its own official SAP documentation that specifies the required parameter fields and their data types. It’s important to refer to the respective document while creating the parameter table to avoid such errors.

Conclusion

SAP HANA PAL enables performing machine learning directly inside the HANA database, ensuring faster processing and real-time insights. With algorithms like clustering, classification, and regression, it helps build intelligent, data-driven applications seamlessly integrated within the SAP environment.

The post Quick Start with SAP HANA PAL: Basic Example Implementation appeared first on ERP Q&A.

Key topics include:

• Export from HANA On-Prem DB and Import to HANA Datalake Filesystem in CSV and PARQUET Formats using HANA Cloud.
  
• Export from HANA On-Prem DB and import to the HANA Datalake Filesystem in CSV and PARQUET formats using HANA Datalake Relational Engine.

Export from HANA On-Prem DB and import to the HANA Datalake Filesystem in CSV and PARQUET formats using HANA Datalake Relational Engine

1. Creation of HANA On-Prem Remote Server in HANA Datalake Relational Engine

Step 1: Open SQL Console

From the Database Explorer of SAP HANA Datalake Relational Engine, open the SQL Console.

Step 2: Create HANA On-Prem Remote Server

Execute the following SQL query to create the remote server for the HANA On-Prem system

CREATE SERVER REMOTE_SERVER CLASS 'HANAODBC' USING
'Driver=libodbcHDB.so;
ConnectTimeout=0;
CommunicationTimeout=15000;
RECONNECT=0;
ServerNode= hanahdb.onprem.sap.server:30241;
ENCRYPT=TRUE;
sslValidateCertificate=False;
UID=USERNAME;
PWD=PaSsWoRd;
UseCloudConnector=ON;
LocationID=SCC-LOC-01';

Please note the following

• REMOTE_SERVER: This is an example name. Replace it with the actual source name
  
• hanahdb.onprem.sap.server and 30241: These are the example server name and port. Replace them with the required HANA On-Prem server details
  
• USERNAME and PaSsWoRd: Replace these with valid credentials
  
• SCC-LOC-01: Replace it with the valid Cloud Connector Location name

Step 3: Verify the Remote Server Connection

Run the following SQL query to check if the newly created remote source is functioning correctly

CALL sp_remote_tables('REMOTE_SERVER');

If the output lists all the tables of the HANA On-Prem database, the remote server has been created successfully

Step 4: Check the Remote Server Details

To view the details of the newly created remote server, execute the following query:

SELECT * FROM SYSSERVER;

2. Create a Virtual Table in HANA Datalake Relational Engine for HANA On-Prem Table

Create a Existing (Virtual) Table

To create a existing table (virtual table) that points to a table in the HANA On-Prem database, execute the following SQL query

CREATE EXISTING TABLE VT_TESTMYTABLE AT 'REMOTE_SERVER..SCHEMA_NAME.TABLE_NAME';

Please note the following

• VT_TESTMYTABLE: This is an example virtual table name. Replace it with the required name
  
• REMOTE_SERVER: Replace this with the name of the newly created remote server
  
• SCHEMA_NAME: Replace it with the schema name of the table in the HANA On-Prem database
  
• TABLE_NAME: Replace this with the actual table name in the HANA On-Prem database

3. Export / Import Operations from HANA Datalake Relational Engine to HANA Datalake Filesystem

Export Virtual Table Data

• Once the virtual table is created in HANA Datalake Relational Engine, you can use SQL commands or tools to export its data

Export from HANA On-Prem and Import to HANA Datalake Filesystem in CSV and PARQUET Formats using HANA Cloud

1. Creation of HANA On-Prem Remote Source in HANA Cloud

Step 1: Login to the HANA Cloud Database

• Open Database Explorer of your SAP HANA Cloud Database
  
• Login to your HANA Cloud Database Instance and expand the Catalog to locate Remote Sources

Step 2: Add a Remote Source

• Right-click on Remote Sources and select Add Remote Source
  
• Provide the necessary details
  
  • Source Name: REMOTE_SOURCE_NAME (This is an example, replace it with the appropriate name).
    
  • Adapter Name: HANA (ODBC).
    
  • Source Location: indexserver.

Step 3: Adapter Properties Configuration

• Default driver libodbcHDB.so will be selected automatically
  
• Provide:
  
  • Server: hanahdb.onprem.sap.server (example, replace with your required server).
    
  • Port: 30241 (example, replace with the correct port number).

Step 4: Extra Adapter Properties

• Enter the configuration: useHaasSocksProxy=true;sccLocationId=SCC-LOC-01;encrypt=yes;sslValidateCertificate=False

Note: SCC-LOC-01 is an example Cloud Connector name. Replace it with the correct one

Step 5: Credentials Setup

• Select Technical User as the credentials mode
  
• Provide valid Username and Password

Step 6: Save the Remote Source

• After entering all the details, click Save
  
• Alternatively, you can use the SQL query below to create the remote source:

CREATE REMOTE SOURCE REMOTE_SOURCE_NAME
ADAPTER "hanaodbc"
CONFIGURATION 'ServerNode=hanahdb.onprem.sap.server:30241;useHaasSocksProxy=true;sccLocationId=SCC-LOC-01;encrypt=yes;sslValidateCertificate=False;'
WITH CREDENTIAL TYPE 'PASSWORD'
USING 'user=Username;password=Password';

Step 7: Verify the Remote Source

• Run the following SQL command to check if the newly created remote source is working

CALL PUBLIC.CHECK_REMOTE_SOURCE('REMOTE_SOURCE_NAME');

• If the command executes successfully without errors, the remote source is functional.

Step 8: View the Remote Source

• Expand the Catalog of the HANA Cloud Database Instance
  
• Right-click on Remote Sources and select Show Remote Sources to confirm your connection

2. Create a Virtual Table in HANA Cloud for HANA On-Prem Table

Step 9: Open Remote Source

• Right-click on the newly created Remote Source (REMOTE_SOURCE_NAME) and select Open

Step 10: Search for On-Prem Table (Remote Objects)

• Use the Schema and Object filters to search for the required On-Prem table
  
• Click Search to display the list of available remote objects (tables)

Step 11: Create Virtual Object

• Select the desired table from the list
  
• Click on Create Virtual Object(s)

Step 12: Define Virtual Table Details

• Provide a name for the virtual table
  
• Select the target schema in your HANA Cloud Database
  
• Click Create to finish the process

The newly created virtual table in HANA Cloud can now be used for operations, including exporting data to the HANA Datalake Filesystem.

3. Export / Import Operations from HANA Cloud to HANA Datalake Filesystem

Export Virtual Table Data

• Once the virtual table is created in HANA Datalake Relational Engine, you can use SQL commands or tools to export its data

The post Read \ Write Data between HANA Datalake and HANA On-Prem DB appeared first on ERP Q&A.

SAP S/4HANA is the latest version of SAP. The full form of SAP S/4HANA is SAP Business Suite 4th generation ERP High Performance Analytic Appliance.

There are 3 layers that are present in SAP namely:-

1. Presentation layer
2. Application Layer
3. Database Layer

In the 1990’s a new architecture was introduced, and it was R/3. In R/3 architecture we can observe the three layers namely presentation layer, application layer and database layer.

The speed of R/3 architecture is fast when compared with R/2 architecture. The algorithms in R/2 architecture were in the database layer whereas the algorithms in R/3 architecture are in the application layer. The database layer can be anyone like oracle, Microsoft etc…

1. Presentation Layer

The presentation layer is a screen where user can interact with the system. For example we can take Monitor of a computer or laptop screen. So for SAP it is GUI –> Graphical User Interface. Here user will interact with SAP data base with the help of SAP GUI which is a software that will be installed on laptops.

2. Application Layer

This is the main advantage of SAP R/3 architecture. Here it acts as like middle wear between presentation layer and database layer. Here it will process the user input , applies business rules and execute the programs in this layer.
Here in this layer it will collects all the details or actions that are being carried out by the user and interacts with the database system and represents them on the output screen.

Dispatcher: Dispatcher will collects the request and will decide which type of request it is whether it is dialog, update, background, spool , enqueue. After getting to know about the spool request type it will also check for the work processor which is idle.
Work Processor:- After getting the request into work processor it will co-ordinate with the database management and will perform the operation or action on the database and will also gets a acknowledgement .

3. Database layer

After getting the request or command form the database management the database layer will process it and will update the request.

The below diagram is the in-depth process of how the database layer will function.

DATABASE LAYER FUNCTION FLOW:

• The request from the work processor will first enter into the session manager and the session manager will makes user to automatic behaviour and transaction isolation level.
  
• Once the request got established the request moves to the planning engine which analyses SQL.
  
• And here SQL engine will runs the machine.
  
• The transaction manager assigns a transaction ID and ensures that every operation follows the principle, transactions to the SQL engine and data engine.
  
• The data engine takes over the user request and performs it on the database.
  
• Index Server → Executes SQL/MDX queries, does actual processing.
  
• Name Server → Knows where the data lives.
  
• Pre-processor → Text & search.
  
• XS Engine → Application services.
  
• Persistence Layer → Save points + logs.

In 2015 the SAP S/4HANA has been introduced and here the database is HANA, and this is SAP’S own database. The Hana database can also be called as in-memory database.

S/4HANA is also called 4th generation SAP.

Versions of SAP S/4HANA are released in the following years: –

SAP S/4Hana works with Fiori NetWeaver GUI.

Advantages of sap s/4hana:

• The performance and speed have been improved due to databases.
  
• Embedded analytics have been embedded in sap s/4hana
  
• In ECC we can only perform operations, and some extract basic reports can be extracted in ECC, but not more complex reports can be extracted, when it comes to s/4Hana we can easily extract the complex reports easily.

OLTP – Online Transaction processing (ECC)

OLAP – Online Analytical Processing (BI/BW)

OLTP + OLAP + Planning – SAP S/4HANA

Planning ->

• MRP line
  
• PD MRP
  
• ATP (advanced available to promise)
  
• PDS (production planning and detailed scheduling)

SAP HANA: This Hana is a database which is also called an in-memory database, and this provides or is capable of analytics, data models and library for code writing.

The HANA database can be accessed through HANA STUDIO.

SAP HANA: This Hana is a database which is also called an in-memory database, and this provides or is capable of analytics, data models and library for code writing.

The HANA database can be accessed through HANA STUDIO.

SAP BW powered by HANA (BW for HANA):

SIDE CAR: For suppose you have an ECC system which is working on any database and now you want to connect it with the HANA database then there will be a middle wear SLT which is a software brings the data from table to HANA database.

• HANA live is a tool which can be used to view the analytics of data.
  
• Lumera system is a toll which is being used to represent or visualize the analytical data.

Benefits of a side car:

• Main cars are not being distributed.
  
• It can be implemented in 1.5 to 2 months.

Drawback:

• Data footprint increases: the data is being replicated from the production system to the side car so more space will be occupied.
  
• The landscape is very complex.

SAP BW POWERED BY HANA: It was introduced in 2012 and here the analytical can be obtained. The complex reports can be fetched within seconds only.

SAP BUSINESS SUIT POWERED BY SAP HANA: It was introduced in 2013 in this enhancement pack (EHP 7 or and here the system is ECC, and the database is HANA.)

OLAP + OLTP.

SAP SIMPLE FINANCE POWERED BY SAP HANA: ECC with HANA Database but the difference between this and SOH is only the fico module as they have simplified the data module for FICO and introduced Fiori apps separately for fico and ACDOCA table which is single source of truth table.

Apart from fico modules the other modules will work as they were functioning in the same manner as ECC on any other database.

S/4HANA: This was introduced in 2015 they have simplified the data model for all the modules. They have introduced MATDOC, ACDOCA table and innovations + Fiori apps for all the modules

APP_L -> Technical application for ECC.

S/4 core -> Technical application for HANA.

The post SAP S/4HANA Architecture Functional Flow appeared first on ERP Q&A.

In today’s fast-paced business world, the ability to seamlessly communicate and exchange data between different systems is crucial. SAP Advanced Event Mesh (AEM) offers a robust solution for real-time event-driven communication across various SAP systems and external services. In this blog post, we’ll explore how to integrate S/4HANA with Kafka using SAP AEM for data streaming and event-driven architecture.

Step-by-Step Guide

Let’s break down the connection process between S/4 HANA and Kafka using SAP AEM into 6 sections, each explaining a key part of the connection setup to help you easily understand and implement the process.

1. Login and Setup SAP AEM Service

• First, log in to your BTP subaccount and create a subscription for AEM ensuring your user has the required roles. Once subscribed, log in to your SAP AEM tenant and navigate to Cluster Manager to create an Event Broker service. This service enables applications to publish or consume events. Below is the start page of SAP AEM after logging in.

• Create an Event Broker Service by clicking on ‘Create Service’.

• Provide a meaningful name for the service e.g. – ‘AEM_SERVICE_DEV’, select the service type, and choose the region. Click on “Create Service”.

• After the service is activated, you’ll see the page.

• Navigate to “Manage” and then “Authentication”. Enable Client Certificate Authentication.

2. Establishing Trust between S/4 HANA and AEM

• To implement client certificate-based authentication, you need to establish trust between S/4 HANA and the AEM service broker. In your S/4 HANA system, execute the STRUST transaction to open the Trust Manager. Export the certificates from SSL client (Standard) and upload them into AEM in the next step.

• Go to “Manage” and then “Certificate Authorities”. Upload the exported certificates by clicking on “Add Client Certificate Authority”.

• Once done, all the certificates will be displayed as shown below.

• Now, import the certificate chain of the SAP AEM service broker host and BTP-IS Subaccount host in the SSL client (Standard) in the STRUST transaction code.

3. Broker Manager Configuration in AEM

• Click on “Open Broker Manager” and log in using the “Management Editor Username” and “Management Editor Password”. You can find these access details under the “Status” section of the broker service.

• Once logged into Broker Manager, create a Queue which will serve as a storage mechanism for messages received by SAP AEM. When S/4HANA will generate any events or messages, they will be placed in the queue before being processed and forwarded to Kafka.

• Provide a meaningful name for the Queue e.g. – ‘AEM_DEV’.
  
• Assign a Subscription to the Queue. By creating a subscription, we ensure that our SAP AEM instance is subscribed to the relevant topics or events generated by S/4 HANA.

• Go to “Access Control” and create a Client Username with the hostname from the leaf certificate maintained in SSL Client (Standard) in the STRUST.

4. Configure AEM to Kafka connection through Kafka Sender Bridge

• The Kafka Sender Bridge is required to facilitate communication between AEM and the target Kafka cluster by converting AEM messages into Kafka events and propagating them to the remote Kafka cluster.
  
• To establish client certificate authentication between AEM and the Kafka cluster, you’ll need .jks files of the Keystore and Truststore from your target Kafka broker.
  
• Open the command prompt and use the command ‘keytool’ to convert the .jks files into .p12 files. Here’s how:

keytool -importkeystore -srckeystore C:\OpenSSL\<keystorefilename>.jks -destkeystore C:\OpenSSL\keystore.p12 -srcstoretype jks -deststoretype pkcs12

keytool -importkeystore -srckeystore C:\OpenSSL\<truststorefilename>.jks -destkeystore C:\OpenSSL\truststore.p12 -srcstoretype jks -deststoretype pkcs12

• Once converted, copy these .p12 files to the OpenSSL -> Bin folder.
  
• Now, navigate to the ‘OpenSSL’ directory and convert these .p12 files to .pem files using the commands below:

openssl pkcs12 -in keystore.p12 -out keystore.pem

openssl pkcs12 -in truststore.p12 -out truststore.pem

• You’ll need to set a passphrase during this process. Note: Remember this passphrase, as you’ll need it for client certificate authentication.
  
• From the ‘truststore.pem’ file, copy the content of root and the leaf certificates and save it as .cer files. Add those in our service broker under “Manage” -> “Certificate Authorities” -> “Domain Certificate Authorities”.

• Now, navigate inside Broker Manager to “Kafka Bridges” and create a “Kafka Sender”.

• Add the Kafka Broker Host and Port details in the ‘Bootstrap Address List’ and copy the contents of the ‘keystore.pem’ file and paste them under Client Certificate Authentication – > Content as shown below. Additionally, include the passphrase that we entered while converting the .p12 file to .pem in the ‘Password’.

• Once the Kafka Sender is created, go inside, and click on “Queue Binding”.

• Select our queue – ‘AEM_DEV’ created in section 3.

• Go inside the Queue Binding created in earlier step and add the topic name of the target Kafka cluster in the “Remote Topic”.

• Confirm whether the Kafka connection is up and running.

5. Configure S/4 HANA to SAP AEM connection

• Now to establish a connection from S/4 HANA to AEM go to transaction code SM59, create a type-G RFC destination and enter the host and port of the SAP AEM service broker.

• In transaction code /IWXBE/CONFIG, create Channel configuration in the S/4 HANA system by clicking on ‘via Service Key -> Advanced’ and assign the RFC destination created in the earlier step. In the ‘Service Key’ section enter the JSON content of the service key created using ‘aem-validation-service-plan’ instance in BTP cockpit.

• Save the above changes and activate the channel.
• Create an outbound binding and assign any standard topic. For example, select “Business Partner”. So whenever a Business Partner is newly created or modified, a standard event will be raised through this outbound channel.

6. Testing the end-to-end connection

• To test the end-to-end connection, go to transaction code BP and create a Business Partner. Click on save.

• Once saved, an event should be raised. You can check this by going to transaction code /IWXBE/EEE_SUPPORT and then to /IWXBE/R_EVENT_MONITOR.

• Select your AEM channel.
• You will find a list of all events that were raised and sent to AEM.

• Now, go to AEM. In the Kafka sender, you can see the message count in the sent section has increased. This means that the message was successfully received by AEM and then pushed to the Kafka cluster. Additionally, verify the message at the Kafka end.

• You can also navigate to the ‘Try-Me’ section where you can set up the sender and receiver connection. Subsequently, you can subscribe to our topic at the receiver end and observe the incoming message from S/4 HANA as shown below.

Conclusion

Through this blog, we’ve demonstrated the process of sending an event from SAP S/4HANA to Kafka via SAP AEM. Now, enterprises can leverage the power of event-driven architectures to drive innovation and efficiency in their operations.

The post Integrating SAP S/4HANA with Kafka via SAP Advanced Event Mesh: Part1 – Outbound connection appeared first on ERP Q&A.