SAP Community - NW ABAP Remote Function Call (RFC)

WebSocket RFC – RFC For the Internet

2021-07-19T13:16:50+02:00

Introduction, Overview, and Availability

By using WebSocket as an alternative transport layer for Remote Function Call (RFC), WebSocket RFC, the new web-enabled flavor of RFC, combines the benefits of a standardized transport layer with the well-known advantages of RFC and the benefits of RFC's fast serialization. WebSocket RFC is easy to administrate and is secure by default.

Profit from a New Standardized Transport Layer for RFC

You no longer need a VPN tunnel for RFC connections across network borders, avoid the time-consuming process of setting up a VPN tunnel and the costs entailed by this in terms of time and money required for the respective certificates.

Hybrid scenarios are possible without an intermediate SAP Cloud Connector (in this weblog further on, for reasons of simplicity named "Cloud Connector" ).

You can use standard HTTPS ports (443) - the normal HTTP port (80) should not be used because TLS is mandatory for WebSocket RFC as described below -, standard HTTP network infrastructure and tools since WebSocket uses an upgraded HTTPS connection.

In a nutshell, you avoid the disadvantages of the proprietary CPIC protocol so far underlying all RFC communication, and, instead, benefit from a standardized, web-enabled transport layer.

Well-known Strengths of RFC

High performance,

Tight coupling by usage of a continuously open connection,

RFC’s close integration into the ABAP programming model, which is the reason why

Exposing a function module for calls from another system or calling a remote-enabled function module (RFM) in another system requires hardly any special knowledge about RFC connectivity on the part of the ABAP developer – no matter if you use RFC over CPIC or over WebSocket.

Advantages due to Automatic Use of Fast Serialization

Faster by factors than classic serialization and basXML.

Transmission speed is equally high for all data and parameter types so that

No expert knowledge is required for developing, configuring, and extending high-performing fast RFC scenarios via WebSocket RFC. With fast serialization it is easy to achieve high RFC performance.

Fast serialization’s S/4 HANA mode mitigates problems in the RFC transmission caused by incompatible changes of DDIC types with every S/4HANA release.
(Find more on RFC's fast serialization in my weblog How to Profit from FAST RFC Serialization)

Secure by Default

All WebSocket-RFC-connections are TLS-encrypted: WebSocket RFC always uses HTTPS.

UCON protection for WebSocket RFC is mandatory and by default active on-premise and in the cloud: You can have different allowlists for the RFMs you expose via CPIC and via WebSocket RFC, which means that you can expose one subset of your system's remote enabled function modules (RFMs) for external access by RFC over CPIC and another subset for external access via WebSocket RFC.

Supported Authentication Methods

Basic authentication - user/password

x.509 - mutual TLS authentication

Trusted-trusting (only on-premise)

Full Support of Queued RFC

WebSocket RFC works fine with t/q/bgRFC.

Availability of WebSocket RFC

Delivered as part of SAP S/4HANA 1909 with its underlying ABAP Platform and

Also available in S/4HANA Cloud and SAP BTP ABAP environment: In SAP BTP ABAP environment, you can create RFMs that can be called from outside (inbound scenario) and you can call RFMs in other systems (outbound scenario). In S/4HANA Cloud inbound and outbound WebSocket RFC scenarios are also possible, if the respective RFMs are part of a Communication Scenario delivered by SAP. As for further details of WebSocket RFC scenarios in the cloud, have a look at the boxed paragraph below "Integration via WebSocket RFC in the cloud".

Support by RFC-based connectors: So far supported on the client side as of SAP Java Connector 3.1 and on the server side as of SAP Java Connector 3.1.3 and as of NetWeaver RFC SDK 7.50 on client and server side. The implementation of WebSocket RFC is also planned for .NET Connector on client- and server side. So far there is no support for WebSocket RFC in the Cloud Connector.

Scenarios in Which You Profit Most from WebSocket RFC

You want to call RFMs across the borders of your company network, e.g. between on-premise systems in different data centers or between your system and the one of your supplier without the tedious process of setting up a VPN tunnel, or you want to expose one group of RFMs to calls from outside of your company network (via WebSocket RFC) and a different group of RFMs to calls from within this network (for which, in general, CPIC-based RFC is used).

As for hybrid connectivity scenarios between an ABAP-based cloud solution and your on-premise system, you can call RFMs in an
- ABAP-based Cloud solution from an on-premise system via WebSocket RFC without an intermediate Cloud Connector.
- On-premise system from an ABAP-based cloud solution without Cloud Connector, but this is only possible, if the respective on-premise system is exposed to the internet. If your on-premise system cannot be reached from the internet, you need Cloud Connector to call RFMs in this system from the cloud. Since the CPIC-based RFC is tunneled via TLS between Cloud Connector and the respective ABAP system in the cloud, CPIC-based RFC suffices for hybrid RFC-scenarios with Cloud Connector. For this reason, Cloud Connector does not support WebSocket RFC in any direction.

Cloud-cloud scenarios: In the cloud, WebSocket RFC enables you to expose RFMs to other SAP cloud products via WebSocket RFC.

Compatibility of WebSocket RFC and Its Limits

Compatibility: WebSocket RFC is mainly compatible with CPIC RFC - with the exception of these minor restrictions: WebSocket RFC does not support

RFC callback/the usage of “DESTINATION BACK”,

Communication with RFMs that open SAP GUI-based UI/Web GUI (and

Forward debugging.

Configuration and Test Costs for a WebSocket RFC Scenario

Creating or maintaining a destination for a WebSocket-RFC-connection is little work in itself – both on-premise and in the cloud – for a new scenario, but requires some more effort - mainly in terms of testing -, if you want to use WebSocket RFC in an existing RFC scenario: You need a suitable destination, have to make sure that the RFMs belonging to the respective scenario are on the relevant allowlist of UCON for WebSocket RFC (also cf. section “How to Set up and Maintain UCON Allowlists for WebSocket RFC in More Detail” below) and have to preclude that the RFMs called in your scenario call “DESTINATION 'BACK'” or open an SAP GUI-based UI.

Creation and Configuration of a WebSocket RFC Connection

This is how you get a suitable destination to make an RFC connection over CPIC into a WebSocket RFC scenario or to create a new WebSocket RFC scenario:

On-premise: An administrator creates and configures a destination for WebSocket RFC – as usual – in transaction SM59. You just need the new type "W". Using a destination of this type in the “CALL FUNCTION” statement you get a WebSocket RFC connection.

In the cloud instead of using transaction SM59, creation and maintenance of destinations is done
- In the Communication System in S/4HANA Cloud.
- In SAP BTP ABAP environment: In the Communication System or in the SAP BTP Destination Service

In SAP BTP ABAP environment, just choose proxy-type “Internet", in S/4 HANA Cloud “Cloud Connector off”.

Get the Relevant RFM(s) on the UCON Allowlist for WebSocket RFC

The effort to set up the mandatory allowlists for a WebSocket RFC scenario depends on whether the respective RFMs are in the cloud or on-premise and – in on-premise systems – whether it is a new or an existing scenario:

Exposing an RFM to be called via WebSocket RFC in the cloud requires no additional test effort because all RFMs in the respective Communication Scenario are automatically added to the respective allowlist (cf. below: “Integration via WebSocket RFC in the Cloud”.)

In on-premise systems due to mandatory and active-by-default UCON protection for RFMs exposed via WebSocket RFC:
- New RFC Scenarios require little effort in this regard because, in these scenarios, it should be known which RFMs need to be exposed.
- Switching existing RFC scenarios to WebSocket, in general, requires extensive testing because, usually, it will take some time to find out which RFMs need to be exposed in a particular scenario and therefore to be added to the respective UCON allowlist.

Ensure the Relevant RFMs do Not Use Features Incompatible with WebSocket RFC

Again, less effort is needed, if you want to use WebSocket RFC in a new RFC scenario: In this case, you know the RFMs called by the scenario and it should not be too much work to preclude that the respective RFMs make callbacks or open an SAP-GUI or WEB-GUI-based UI.

As for existing RFC scenarios between different on-premise systems, more testing may be needed before you know which RFMs are called via the respective WebSocket destination and whether these RFMs make callbacks or open an SAP-GUI or WEB-GUI-based UI. Using WebSocket RFC in cases in which hybrid RFC scenarios (between Cloud and on-premise) via Cloud Connector have been used so far, should require less testing because these incompatible features are also not supported by Cloud Connector.

In general, it is a good idea to test things thoroughly if you use WebSocket RFC for an already existing RFC scenario.

Note: Keep in mind that as with all connectivity features, WebSocket RFC can only be used, if it is supported on the client and server side of a connection.

No Code Changes Required for Calls via WebSocket RFC

The code to create an RFC-call is the same no matter whether WebSocket or CPIC is the underlying transport layer. Just use the good old “CALL FUNCTION” statement also for WebSocket RFC: In all supported RFC scenarios – that is all scenarios except for those using RFC callback or opening an SAP-GUI or WEB-GUI-based UI – you can use WebSocket RFC instead of RFC over CPIC. No need not change the “CALL FUNCTION” statement in any way: All you need is a destination of type “W”. And, of course, you should make sure that the RFMs called via WebSocket RFC do not use "DESTINATION BACK" or open an SAP-GUI or WEB-GUI-based UI.

No Particular Connectivity Knowledge Required by Developers for WebSocket-RFC-Calls

While usage of other HTTP-based connectivity technologies may require a developer to have some complex knowledge of the respective technology, developers using WebSocket RFC get along with the limited knowledge required to set up an RFC call. WebSocket RFC does not require the creation of a particular proxy or a detailed understanding of how things are serialized. The complete WebSocket handling is transparent in a lower layer and developers and administrators need not care about it.

Integration via WebSocket RFC in the cloud

As for all connections with other systems in ABAP-based clouds,

(1) Inbound WebSocket RFC scenarios need:

A dedicated Communication scenario that defines all RFMs to be called on the server side (inbound scenario) and

The Instantiation of this Communication Scenario in form of a Communication Arrangement with a Communication System and a Communication User (cf. related documentation and tutorial for SAP BTP ABAP environment).

(2) Outbound WebSocket RFC scenarios offer two options. You can

Instantiate the respective Communication Scenario (as described above under item 1) or

Make do without a Communication Scenario and simply use a reference to the respective destination in the SAP BTP Destination Service in your ABAP Code. (cf. related documentation)

All this, by and large, is the same for all types of communication in the cloud between different systems: WebSocket RFC scenarios do not differ in any principal way from scenarios based on RFC via CPIC or HTTP in the cloud. But there is a basic difference as to

Whether a business or technical scenario is delivered by SAP, in which case SAP develops the respective Communication Scenario and you as customer only configure/instantiate it,

Whether something is developed by the customer, in which case the customer first needs to create the relevant Communication Scenario (if one is needed) before configuring it.

Important Note: Before enabling a WebSocket RFC scenario, make sure that all RFMs to be called over WebSocket do not open any SAP-GUI or WEB-GUI-based UIs or make callbacks. Often, this will require extensive testing.

The Different Layers of WebSocket RFC and CPIC RFC

Basically, WebSocket RFC differs from CPIC RFC by having a different transport layer and mandatory fast serialization, while you call an RFM via WebSocket RFC just the way you are used to as an ABAP developer:

WebSocket RFC in More Detail

High Performance and Compression

WebSocket-RFC’s permanent use of fast serialization achieves a much higher data compression than classic serialization and basXML, which is partially due to it using different compressions for LAN and WAN scenarios:

In WAN, a high compression rate is most important to reach a high performance and to minimize network bandwidth costs. This is why, in WAN scenarios, fast serialization uses a compression algorithm with a high compression rate and, to some degree, ignores the time needed for the data compression.

In LAN, fast serialization uses a compression with a good balance between payload reduction and the time needed to process the compression algorithm – because in LAN compression speed and compression rate are equally important.

WebSocket RFC automatically selects the best compression for your RFC scenario because it measures the latency of the respective connection during the TLS handshake and, based on this measurement, decides, if LAN or WAN compression is better. Still, you can override this automatic selection and chose to always use the high WAN compression, if – for example – you primarily want to save bandwidth because you are in a cloud scenario and may have to pay for bandwidth.

Note: Automatic selection of the best compression is only available for connections between two ABAP servers and not supported by the RFC-based connectors.

Note: By default, the line between LAN and WAN is 110 ms, but you can adapt this to your specific needs.

Latest Supported Version of WebSocket RFC Used Automatically

The WebSocket handshake exchanges protocol information so that always the highest version of WebSocket RFC is used that is supported both by client and server. There is no need to select and maintain this version manually in transaction SM59.

Extensibility of RFC Parameters and Incompatibilities Due to Field-Extensions in S/4

Due to WebSocket RFC's use of fast serialization, incompatibilities between structures on the client side and structures on the server side are detected. If possible without data loss, the data is automatically transferred to the server-side structures, otherwise - if data loss within a particular component cannot be avoided due to incompatibility between parameter-types on client- and server-side - an error message is thrown: This mitigates many of the problems caused by incompatible changes of DDIC types with every new S/4 release. Fast serialization allows for field extensions or the introduction of new fields at all positions in structures used in interfaces of existing function modules, which has the consequence that fields that do not exist on both sides are omitted in the data transmission, and no error message is thrown in this case.

Web Socket RFC's Flavor of Fast Serialization Supports Transparence and Maximal Parameter Extensibility

Just as ABAP Objects – compared to procedural ABAP – offers more and less at the same time, namely more powerful object-oriented features and a stricter syntax check, which forbids many old statements, WebSocket RFC’s mandatory use of fast serialization’s future-proof interface contract for new scenarios is more powerful in terms of parameter extensibility and, also at the same time, forbids non-transparent parameter mapping mechanisms used in exceptional situations - most times in scenarios connecting newer with very old releases - by the other RFC serializations. WebSocket RFC’s flavor of fast serialization

Offers you maximal extensibility of structures and tables, namely at all positions, not only at the end, and

Strictly forbids extreme differences in technical properties of the same RFC parameter between client- and server side, which often are tolerated by classic serialization or basXML and handled by unexpected exceptional mapping mechanisms. While fast serialization for CPIC-based RFC also has these modes that, to a large degree, emulate these exceptional mapping mechanisms of the other RFC serializations, WebSocket RFC does not offer fast serialization's emulation/compatibility modes for basXML and classic serialization. Instead WebSocket RFC's mandatory usage of fast serialization's future-proof interface contract for new scenarios enforces a transparent and consistent behavior as to which differences in the same RFC parameter between client- and server side are tolerated, and which differences lead to an error. (Find out more on fast serializations different flavors or modes in my weblog How to Profit from FAST RFC Serialization in the section on configuration.)

Support for Multiplexing and Load Balancing

Multiplexing for WebSocket RFC means that a physical WebSocket connection/tunnel is only created once between two points and can be re-used for other RFC connections via WebSocket between these two points. Given this re-use of a WebSocket tunnel, the fact that WebSocket protocol and TLS need several handshakes to setup a connection only has a small impact on the performance of WebSocket RFC. There is also support for load balancing by Web Socket RFC.

Still, multiplexing and load balancing have some restrictions and presuppositions as explained in the table below:

	ABAP System – ABAP System	ABAP-based Connector/NW RFClib – ABAP System
Load Balancing	Only with SAP Web Dispatcher.	Standard HTTP(S) load balancer will also do.
Multiplexing	Only with Web Dispatcher and if HTTP/2 is supported by all infrastructure in between client and server.	Not possible due to missing HTTP/2 support by connectors, but this is remedied by connectors' pooling of unused RFC connections (both for RFC over CPIC and WebSocket) that enables re-use of RFC connections.

How to Set up and Maintain UCON Allowlists for WebSocket RFC in More Detail

As you already know, in the cloud, all RFMs to be exposed by WebSocket RFC (inbound scenario) need to be listed in a Communication Scenario. Then all these RFMs are automatically added to the UCON allowlist for WebSocket RFC once the respective Communication Scenario is activated. (The same is true for RFMs to be called via CPIC RFC: The respective UCON allowlist is automatically maintained based on the RFMs listed in the relevant Communication Scenarios.)

On-premise, for the usage of WebSocket RFC, there is a new UCON scenario that is mandatory and active by default. Now you have UCON RFC basic (for calls via CPIC) and UCON for WebSocket RFC with different allowlists for RFMs to be exposed via CPIC and via WebSocket. In on-premise systems, you must fill the respective allowlists manually, while – as you know by now - in the Cloud, all called RFMs for incoming calls (inbound scenarios) are defined in the Communication Scenario, and then automatically added to the respective UCON allowlist.

Exposing RFMs to calls via CPIC from within your company’s network is less risky than exposing RFM to calls over WebSocket from the internet. Therefore, you should keep the numbers of RFMs exposed to calls via WebSocket RFC as small as possible, and this is why UCON for WebSocket RFC has a dedicated allowlist of its own that you should maintain carefully: It would be very insecure, if you exposed all RFMs you need to access in your CPIC-based RFC scenarios also for external calls over WebSocket – as it would be the case if you had a shared allowlist for RFC over CPIC and WebSocket RFC. For security reasons, you should have an allowlist of its own for WebSocket-RFC-scenarios, if your ABAP onPremise system is exposed to the internet

It is, however, possible to select an option in UCON for WebSocket RFC that automatically exposes the same RFMs via WebSocket RFC and via RFC over CPIC. This option is mainly meant for those customers who can or want to invest as little time as possible in the UCON protection of their server-side WebSocket RFC communication and, still, want to profit from UCON protection of WebSocket RFC. But of course, having distinct allowlists for WebSocket RFC and CPIC RFC respectively, is more secure.

Important Note: No matter whether you chose to have the same or different allowlists for RFMs to be called over WebSocket and over CPIC, - as already stated above - you should only enable WebSocket RFC for a particular destination based on an intentional decision and after extensive testing:

Before you have to make sure that no SAP-/WEBGUIs and no callbacks are used in the RFMs called via the respective destination: Since these features are not supported in WebSocket RFC, calling RFMs that open SAP-/WEBGUI-based UIs or use callbacks over WebSocket will cause a dump, which should be prevented by testing.

Administration of UCON for WebSocket requires little effort because - in contrast to UCON RFC basis for CPIC-based RFC - there is no dedicated logging and there are no phases in UCON for WebSocket RFC. You simply do not need this: Due to the extensive testing that is required for WebSocket RFC scenarios, you know exactly which RFMs to expose. Still, if you chose to have the same allowlist for both RFC flavors, accordingly, the UCON phase tool of the UCON RFC basic scenario shows all RFC calls in the same way no matter if they are WebSocket- or CPIC-based.

Summary

Gone are the days, when you had to choose between RFC and a connectivity technology with a standardized web-enabled transport layer. With WebSocket RFC you have it all: The advantages of a standardized transport layer and the well-known advantages of RFC. Calling RFMs via WebSocket RFC you can use standard internet infrastructure and no longer need VPN tunnels for calls across the borders of your business network. Still you get RFC’s high performance, a continuously open connection and RFC’s close integration into the ABAP programming model plus all the improvements that come with RFC’s fast serialization - such as its equally high transmission speed for all data and parameter types as well as for all permitted parameter extensions and fast serialization’s S/4HANA mode that mitigates problems in the RFC transmission caused by incompatible changes of DDIC types with every S/4HANA release.

The RFC statement you need for calls via Web Socket RFC is the same as it ever was. But at any rate, you should take into account that WebSocket RFC does not support SAP-/WEBGUI-based UIs or RFC callbacks.

WebSocket RFC is secure by default because of mandatory TLS-encryption and mandatory and active-by-default UCON protection on-premise and in the cloud. The test effort needed to setup the respective allowlist with all relevant RFMs varies depending on whether the RFMs to be exposed are known or not: No additional effort to fill the UCON list is required in the cloud and for new on-premise scenarios. Using WebSocket RFC for existing on-premise scenarios may need extensive testing to find out the respective RFMs you need to expose.

All in all, with WebSocket RFC you get a lot of advantages with comparatively little effort.

ASYNC/Parallel ABAP in a OO way

2021-08-26T17:29:46+02:00

Edit:

After some feedback and some time to work on this I've improved the examples and introduced the Thread Pool Executor concept.

Motivation

Every now and then we find a need for doing some work in parallel. Recently I’ve worked on a process that was taking far too long to be of any use. It was taking large amounts of data in and creating an even larger amount of records given complex rules, validations and enrichment.

Refreshing some ABAP parallelism techniques, my options were basically to split the input data and then running FMs in background, starting a new task or writing a report and scheduling a job with parallelism being ranges of a selection criteria.

All valid options, I suppose, but I got used to work purely in OO and hammering FMs here and there to have my parallelism had a particular bad smell. It would prevent me to assert some critical behavior via unit tests, for starters, and it would also add this new responsibility, running in parallel, to weird places with code that looked boring and repetitive (take data from classes, run fm, take data back…).

So I decided to find an OO approach to parallelism in ABAP, and took Java Thread as inspiration. I was particularly drawn to Java Thread given its simple Runnable interface, which allows developers to quickly wrap what needs to be done in parallel in a single method. I could use it to simply call the existing methods I already had. Below is an example on how it would look like in Java.

  public class MyRunnable implements Runnable {



    public void run(){

       myOtherClassMethodThatDoesStuff( )

    }

  }



Runnable runnable = new MyRunnable(); // or an anonymous class, or lambda...

Thread thread = new Thread(runnable);

thread.start();

zthread

There are probably hundreds of similar implementations to this out there. Hope this one can be useful for some of you. My concept is exactly the same as in Java, having the Runnable interface and the Thread as the starting point. As I’m used to (and like) the callback idea behind Javascript, I’ve thrown it into to mix. It made some of the code I needed easier to write and test. It looks something like this:

Created with PlantUML(http://plantuml.com)

There is a thread factory interface and some default implementations too, which I've discarded from the diagram, to help unit test classes using Threads.

Usage

You can check git for the most up to date documentation. I´m putting some examples here to show how to use it in general.

The examples below are building up from previous examples. So zc_my_runnable is not always declared and its implementation is the one from its last time defined.

Raw way

Simply implement your runnable interface, give it to a Thread and start it. The drawback of this is that is up to the caller to manage how many Threads can run in parallel, and implement logic wait for Threads to finish so others can start and so forth.

If your program will have 2 or 3 threads that is ok and this way suits you. But if you are splitting large data into smaller parts, if it ends up 100 smaller parts this will consume all of your system resources.

Always prefer using a Pool Executor like in the next section below.

"example have merged definition and implementation

class zcl_my_runnable definition.

    public section.

        interfaces zif_runnable.           



    method constructor.

      "store data to process async/paralel.

    endmethod.

     

    method zif_runnable~run.

      "process data

    endmethod.



endclass.



data(runnable1) = new zcl_my_runable( datasplit1 ).

data(runnable2) = new zcl_my_runable( datasplit2 ).



new zcl_thread( runnable1 )->start( ).

new zcl_thread( runnable2 )->start( ).



zcl_thread=>join_all( ). "awaits all threads to finish

Thread pool executor

The thread pool executor is an executor service that allows to limit the number of threads that can run in parallel based on its pool size, allowing to work to be forked indefinitely without consuming all system resources. Java has several executor services implementations, I’m delivering a basic one that can be extended as seem fit.

The runnable interface implementation is the same as the previous example.

"only 10 will be allowed in parallel in the pool

data(executor) = zcl_executors=>new_fixed_thread_pool( 10 ). 



data(runnable1) = new zcl_my_runnable( datasplit1 ).

data(runnable2) = new zcl_my_runnable( datasplit2 ).



"submits individual runnables

executor->submit( runnable1 ).

executor->submit( runnable2 ).



"Asks for a 100 runnables to run but, 

"due to the pool size only 10 will

"be allowed to be active at a time

executor->invoke_all( a100Runnables ). 



"blocks executor from queing new runnables

executor->shutdown( ).



"awaits threads to finish and queue to be empty

executor->await_termination( ).

Retrieving results

You can get the result of your threads in multiple ways, but all require that your result be class implementing the zif_runnable_result interface.

Ideally, you want your results to be separate objects, as it should be significantly smaller than your runnable in terms of data size and this plays a role in resource consumption and the serialization process behind threads.

In the example below, however, we are implementing it in the runnable itself.

class zcl_my_runnable definition.

    public section.

        interfaces zif_runnable,zif_runnable_result.       

        data: my_result type i.    

        methods:

            construtor

                 importing

                    numbers type any table.           

            get_sum returning value(rv_result) type i.



    method zif_runnable~run.

        my_result = reduce #( init result  = 0

          for number in numbers

          next result = result + number ). 

       ro_result = me. "important!

    endmethod.

     

    method get_sum.

      rv_result = my_result.

    endmethod.



endclass.

From Threads

If you are creating your threads manually, the result will come from the Thread get_result( ) method. If this method is called before finished, zcx_still_running is raised. You can check the thread was successful with get_error( ).

data(runnable1) = new zcl_my_runnable( value #( ( 10 ) ( 10 ) ( 10 ) ). "30

data(runnable12) = new zcl_my_runnable( value #( ( 20 ) ( 20 ) ( 20 ) ). "60



data(thread) = new zcl_thread( runnable1 ). 

data(thread2) = new zcl_thread( runnable2 ).



thread->start( ).

thread2->start( ).



zcl_thread=>join_all( ).



data(result) = cast zcl_my_runnable( thread->get_result( ) )->get_sum( ).

data(result2) = cast zcl_my_runnable( thread2->get_result( ) )->get_sum( ).



data(total) = result + result2.

write: total. "90

From Executors

Executors don’t return the Threads created, but rather a Future representing that Thread result. When asking the Future for its result, it will wait for the termination of its Thread if it is still running. Therefore the following code is synchronous but runs in parallel (different session). If an error happens during the runnable execution, the Future will raise zcx_thread_execution with the error as its previous exception.

executor->submit( runnable1 )->get( ).

For actual async and parallel code to execute, wait for the executor to terminate.

"for submits

data(future) = executor->submit( runnable1 ).

data(future2) = executor->submit( runnable2 ).

executor->shutdown( ).

executor->await_termination( ).



data(result) = cast zcl_my_runnable( future->get( ) )->get_sum( ). "30 from last example

data(result2) = cast zcl_my_runnable( future2->get( ) )->get_sum( ). "60 from last example



write: result + result2. "90



"same for invoke_all

data(futures) = executor->invoke_all( value#( ( runnable1 ) ( runnable2 ) ).

executor->shutdown( ).

executor->await_termination( ).



loop at futures into data(future).

  total = total + cast zcl_my_runnable( future->get( ) )->get_sum( ).

endloop.



write: total. "90

Callbacks

Callbacks are my preferable way to manage async/parallel work. It is a simple concept to understand and it allows decoupling the code responsible for defining work from the code responsible for processing results.

Simply implement the zif_thread_callback interface and give it to Threads or Executors and use its on_result to collect, merge or aknowledge results as you please.

The callback object must have a valid reference throughout the lifecycle of the Threads.

class zcl_sum_callback definition.

  

    public section.

        interfaces zif_thread_callback.

        methods:

           get_total returning value(rv_result) type i.

    private section.

       data: my_total type i.

   

 

    method zif_thread_callback~on_result.

        "be safe

        check io_result is instance of zcl_my_runnable. 

        data(result) = cast zcl_my_runnable( io_result ).

        my_total = my_total + result->get_sum( ). 

    endmethod.



   method zif_thread_callback~on_error.

        "this method is triggered in case any error happen during runnable execution.

        "you can raise your own exceptions there as well

        "taskname is available in both on_callback and on_error.

        "taskname is an optional value of thread constructor

        raise exception type zcx_my_calculation_error

            exporting

                previous = io_error

                taskname = iv_taskname.

         

  endmethod.



  method get_total.

    rv_result = my_total.

  endmethod.



endclass.



data(callback) = new zcl_sum_callback( ).



"giving it to threads

new zcl_thread( 

  io_runnable = runnable1

  io_callback = callback )->start( ). "sum to 30





"giving it to executor

data(executor) = zcl_executors=>new_fixed_thread_pool(

  iv_threads = 10

  io_callback = callback ).



executor->submit( runnable2 ). "sum to 60

executor->await_termination( ).



data(result) = callback->get_total( ).



write: result. "90

Some thoughts

Feel free to check the code behind it. What is happening is the serialization of the runnable so it can be sent to a function module as a string. This FM is called using options starting new task and on end of task. In the FM, the runnable is deserialized and its run method is called. Whatever result or error that happen are serialized by the FM and deserialized back by the Thread class. If a callback routine is defined, it is called with the result or error. This means a couple of things.

Avoid complex runnables, all serialization constrains of the id transformation are applicable. If you have complex runnables, relying on other objects, prefer instantiating those objects inside the run method.

Parallel work runs on dialog workers. As far as I can tell, the only restrictions are memory allocation and time execution (5 min being default). Make sure you split into chuncks that fit dialog workers restrictions.

Each Thread runs on a different session, on top of serialized/deserialized objects, so…Don’t fall into the trap of expecting a singleton to be shared between threads.

If you have a server with 2 processors, it doesn’t matter if you have 20 threads as they will just round robin your CPU time. Most production servers have a good enough number of threads available, but it is not always the case for development servers. Make sure you account for this when developing, testing, deploying.

Threads can´t be stopped. Unfortunately I did not found a way to get the PID of a thread based on this task name.

If a callback routine is defined, it must still be a valid reference at the end of the Thread.

SAP does have something in newer versions, check the comments about cl_abap_parallel. I think overall we still need some other tools to allow an raw OO implementation to the philosopher’s dinner problem.

But, as I say this I also realize we are moving away from heavy process and relying on more stream like flows with small API endpoints. In any case, this is still a tool that can be used when needed.

Cheers and enjoy!

Git repository here.

Configure SAP Event Mesh for SAP S/4HANA On-Premise

2022-01-19T16:46:31+01:00

Introduction

This blog post will guide you through steps to use SAP Event Mesh in SAP BTP, Cloud Foundry environment and to establish connection between SAP Event Mesh and SAP S/4HANA (on premise) for asynchronous data transfer.

Blog will cover introduction, architecture, enabling SAP Event Mesh and configuration of Message Queues on SAP BTP. We will learn to establish connection between SAP Event Mesh service and SAP S/4 HANA (on premise) system. Then will have a short demo of data transfer between these systems.

SAP Event Mesh

SAP Event Mesh (Earlier known as SAP Enterprise Messaging) is a fully managed cloud service to offer messaging in SAP Business Technology Platform (SAP BTP). This service allows real-time and asynchronous communication between applications through events to develop responsive applications. So these applications can work independently and connect seamlessly through decoupled communication.

Note: SAP Event Mesh is available in SAP BTP, Cloud Foundry environment.

Architecture

Steps

Enablement of SAP Event Mesh service on SAP Business Technical Platform

Configuration of Message Queue in SAP Event Mesh cockpit

Test SAP Event Mesh service using Postman Application

Setup Connection between SAP Event Mesh service and SAP S/4 HANA (on premise) system through RFC Destination and OAuth Client Profile

Demo of data access in SAP S/4HANA (on premise) system

Enablement of SAP Event Mesh Service on SAP Business Technical Platform:-

Open SAP Business Technical Platform and register yourself, if you have already registered then logon with your user credential.
For SAP Event Mesh service, user can use trial account also by clicking on Go To Your Trial Account.A new trial global account will be created with sub-account trial. Click on sub-account. User can see sub-account specifications(Id, Tenant Id, SubDomain etc.), Cloud Foundry environment, Entitlements (Subscribed services) etc.

Click on Create Space button. Provide Space name as 'emtrial' and press Create. User can see newly created Space 'emtrial' under trial sub-account.Click on created Space. It will navigate to that space. You can see ‘Service’ tab in left side of page. This tab is having 2 sections – Service Marketplace (SAP provided services for which user has taken subscription), Instances (Instances created by user).

Click on Service Marketplace tab. Search for Event Mesh service. User can see Documentation and available service plan for Event Mesh through clicking on tile.Click on Create button to create a new instance of Event Mesh service. Provide details as below and click on Create button in popup.

Basic Info:-
Service - Event Mesh
Plan.- dev (for trial)
Instance Name - eminstance
Parameters:- {"emname": "emdemo", "options":{"management": true, "messagingrest": true}}

User can see newly created instance under Services->Instances in left side of page.Click on Create Service Key to generate service key for Event Mesh instance. Provide Service Key Name as 'emservicekey' and click on Create button.New Service Key will be created which will be bound to service instance. Service key will be used to access SAP Event Mesh Service by external systems.Click on View button. A popup will appear and user can see Credentials to access SAP Event Mesh service. Note down clientid, clientsecret, tokenendpoint and uri which will be required later on. You can download credentials in text format as well.Click on View Dashboard button for instance eminstance.

Configuration of Message Queue in SAP Event Mesh Cockpit:-

On click of View Dashboard button, SAP Event Mesh - Messaging Administration Cockpit is opened in new tab. Under Overview tab, 3 properties are defined.

Connections:- Number of active connections which are accessing Event Mesh instance asynchronously.
Queues:- Number of Message Queues
Number of Messages:- Number of Messages in queueClick on Queues tab in left side of page. Click on Create button. A popup will appear which will ask for Queue Name. Provide queue name as 'demoqueue' and click on Create button.

Test SAP Event Mesh Service using Postman Application:-

Open Postman application. Create new collection as SAP Event Mesh which will contain HTTP requests related to Event Mesh. There are 4 different types of request.

Token:- POST request which will return access token for message queue. (Success Response Status Code - 200)
Send Message:- POST request which will push message in queue. (Success Response Status Code - 204)
Receive Message:- POST request which will fetch message from queue. (Success Response Status Code - 200)
Acknowledge Message:- POST request which will send acknowledgement to queue that message is consumed successfully from 3rd party system. So queue will delete that message. (Success Response Status Code - 200)

Token:- Create HTTP request as per below parameters. On click of Send button, it will return access_token and token_type in body section.

HTTP Method:- POST
URL:- <tokenendpoint>
Params:- grant_type - client_credentials, response_type - token
Authorization:- Basic Authorization, Username - <clientid>, Password - <clientsecret>
Headers:- Content-Type - application/x-www-form-urlencodedSend Message:- Create HTTP request as per below parameters. On click of Send button, It will show status code 204 as we are not getting any response back.

HTTP Method:- POST
URL:- <uri from httprest protocol section>/messagingrest/v1/queues/<queue name>/messages
Params:- x-qos - 1, authorization - Bearer <access_token fetched from Token call>
Authorization:- No Authorization
Body:- Data in JSON, Text or in other format which need to sendGo back to Overview section of SAP Event Mesh - Messaging Administration Cockpit. User can see 1 Connection and 1 Message via Send Message call (by Postman as shown above). Now click on Queues section which shows that there is 1 message in demoqueue.

Receive Message:- Create HTTP request as per below parameters. On click of Send button, It will show status code 200 and user can see response data under body section.

HTTP Method:- POST
URL:- <uri from httprest protocol section>/messagingrest/v1/queues/<queue name>/messages/consumption
Params:- x-qos - 1, authorization - Bearer <access_token fetched from Token call>
Authorization:- No AuthorizationAcknowledge Message:- Create HTTP request as per below parameters. On click of Send button, it will show status code 200 and user can see response data under body section.

HTTP Method:- POST
URL:- <uri from httprest protocol section>/messagingrest/v1/queues/<queue name>/messages/<message id>/acknowledgement
Params:- x-qos - 1, authorization - Bearer <access_token fetched from Token call>
Authorization:- No AuthorizationNote:- User can copy message id from response of receive message call (Under Header section).Go to Queues section of SAP Event Mesh - Messaging Administration Cockpit. User can see queue name demoqueue along with 0 number of messages. Message is removed from queue.

Setup Connection between SAP Event Mesh Service and SAP S/4 HANA (on premise) system through RFC Destination and OAuth Client Profile:-

Open SAP On-Premise system with SAP Logon. Open SPRO configuration and press SAP Reference IMG. Here we need to perform below operations.

RFC Destination Setup
OAuth Client Profile Creation
OAuth Client Profile Setup

RFC Destination Setup:- Click on SAP Netweaver->Enterprise Event Enablement->Administration->Channel Connection Settings->Manage RFC Destination entry.User can open RFC Destination configuration screen using T-Code SM59 also.We will create a connection to external server. Click on Create icon. Provide destination name as 'EVENT_MESH_DEMO' and select connection type as 'HTTP Connections to External Server' from drop down.Enter an appropriate description for RFC destination. Provide Host name and Port name under Technical Settings tab. Leave other fields as it is.
Copy URI from HTTPREST protocol section(without 'https://' ) in Service Key on BTP for Host Name. Click on Logon & Security tab. Under Security Options, Make SSL as Active and select ANONYM SSL Client (Anonymous) as SSL Certificate. Don't make any changes for others. No need to make changes for Special Options tab as well.Save this RFC Destination and Click on Connection Test. You can see Status HTTP Response as 200 and Status Text as OK under Test Result. Go to other tabs like Response Header Fields , Response Body, Response Text and see the result.OAuth Client Profile Creation:- Open object navigator using T-Code SE80. Select Local Objects. Right click on Local Object. Under Create icon, User can see various type of development objects. Select on option More which will show option to create OAuth 2.0 Client Profile.Enter Client Profile name as 'EVENT_MESH_DEMO_PROFILE' and select Type as 'HANA_CLOUD_PLATFORM' from drop down. Click on OK icon. Once new Client Profile is created, Save it.OAuth Client Profile Setup:- Click on SAP Netweaver->Enterprise Event Enablement->Administration->Channel Connection Settings->Manage OAuth Client Setup entry. (or use T-Code OA2C_CONFIG)A browser window will open with all the existing OAuth Client Profiles for On-Premise System. Click on Create button in header toolbar.In Popup, Select newly created OAuth 2.0 Client Profile from drop down. Keep Configuration Name same as Profile name. Enter OAuth 2.0 Client ID which was copied from Event Mesh service key in SAP Business Technology Platform.Details of Client Profile will be displayed. In Administration tab, Provide Client Secret, Authorization Endpoint and Token Endpoint which are copied from SAP Event Mesh service key. Other fields are auto populated. Do not make any changes for Scopes and Enhancement Settings tabs. Press Save. User can see updated configurations for Client Profile.

Demo of data access in On-Premise system:-

We will try to access data of message queue through SAP ABAP executable program. Open T-Code SE38. Enter executable report name as 'ZRP_READ_EVENT_MESH_DATA' and click on Create button. In popup, Provide meaningful description for report. Click on Save. An empty report will be created.First, Create EVENT_MESH_DEMO destination object and then create EVENT_MESH_DEMO_PROFILE OAuth 2.0 Client Profile object by accessing static methods of class CL_HTTP_CLIENT. Required code is highlighted in below screenshot.Now set token to authorize access of messages from queueSet x-qos parameter in request header, URI to get message from queue and request method as POST. Now trigger call and receive response from request. This is similar what we have done through Postman application.Get data from response. This data will be in same format(JSON, Text etc.) as of the message we have pushed in queue. Once data is retrieved, we can deserialize into deep structure. Then write your logic to parse deep structure data into desired structure as per requirement.Once data is successfully retrieved, We will send acknowledgement to queue along with message id which was read earlier. Queue will delete that message.For testing, We will push one more message to demoqueue as shown in below screenshot. User can see newly added message in SAP Event Mesh Cockpit.Execute ZRP_READ_EVENT_MESH_DATA report in debugging mode. We can see message data in ls_payload variable in JSON format as highlighted. In lr_data variable, JSON data is parsed in deep structure via deserializing.By expanding deep structure, we can verify data in debugging mode.

Once data is read, Acknowledgement is sent to queue and queue will delete that message. We can see 0 messages in SAP Event MeshYou can see ABAP report code here.

Conclusion

We have explained enablement, creation and configuration of SAP Event Mesh service. Along with this, we have learned how to establish connection between SAP Event Mesh service and SAP S/4HANA (on premises) system through demo.

To get more information on SAP Event Mesh, follow the topic page of SAP Event Mesh.

Import Event Push of Configuration Text Tables to External Database

2022-02-09T22:39:46+01:00

Introduction

I was recently posed with a problem that needed a new solution for our planned S4 migration in a few weeks. How to get the configuration domain text data to an external database to retain some existing reporting capabilities? I'm betting that a lot of folks work in heterogenous landscapes and sometimes it requires getting creative with how to tackle a problem. I have seen a couple of approaches in the past and have to admit that I'm not a fan of either, but I'll let you decide for yourself which one is least preferred. First example - two synchronous ABAP Proxies of megalith proportions statically defined to return data on several dozen configuration domains based on daily or weekly frequency. The second - several recurring job instances throughout the day (four or five maybe) that extract the data whenever change pointers are detected on dependent business objects, and saved as files on the application server, which requires some other process to fetch the data and load it. Is a many times daily, daily, or weekly cadence appropriate given the relatively infrequency that configuration tables are updated in a productive environment?

Proposal

What if there were an event that could push the data for a pit stop into Integration Suite for some transformation before reaching its final destination in the external database? I spent a few hours pondering the question and came up with the following: Implement BADI CTS_IMPORT_FEEDBACK along with BRF+ to evaluate customizing requests and push table names to Integration Suite. Start with an iterating splitter, and sprinkle a little graphical mapping, content enricher via OData, and XSL transform and arrive at XML that can be processed by the JDBC adapter to initiate stored procedures for UPSERT. What follows is the culmination of a day and a half of build, learning, and experimentation with a couple of gotchas along the way.

ABAP

The original intent was to execute the entirety of ABAP within this BADI method, but after I had completed the full service layer in Integration Suite and worked backward into this method, I discovered that it executes in client 000, and received a ST22 dump when the BRF+ application could not execute. The BRF+ code was pushed into the RFC function module. Consequently, after working in SAP software for 14 years and having never logged in to client 000, I have for the first time (SM59 destination), and doubtful I ever would again. You may also wonder why I wouldn't simply read keys and use a combination of RTTS and web services to push the data to Integration Suite. Beyond avoiding the megalith mentioned above, dealing with situations where some columns are ignored for certain tables, and determining appropriate structure, it certainly wouldn't be blog worthy and you wouldn't be reading this! After following the remaining steps I think it will be clear why I decided to go with the chosen route.

METHOD if_ex_cts_import_feedback~feedback_after_import.



  DATA: corr   TYPE trwbo_request,

        tables TYPE tt_tabnames.



* Read object keys for import

  CLEAR: tables.

  LOOP AT requests INTO DATA(request).

    CLEAR corr.

    CALL FUNCTION 'TR_READ_REQUEST'

      EXPORTING

        iv_read_objs_keys = 'X'

        iv_trkorr         = request-trkorr

      CHANGING

        cs_request        = corr

      EXCEPTIONS

        error_occured     = 1

        no_authorization  = 2

        OTHERS            = 3.



    IF sy-subrc = 0.

*     Record any tables for evaluation in BRF+

      LOOP AT corr-keys INTO DATA(key)

              WHERE object = 'TABU'.

        APPEND key-objname TO tables.

      ENDLOOP.

    ELSE.

*     Should never happen based on data requested in FM

    ENDIF.

  ENDLOOP.



* Sort and remove duplicates and pass to RFC for

* communication

  SORT tables.

  DELETE ADJACENT DUPLICATES FROM tables.

  CALL FUNCTION 'ZCA_WS_CONFIG_UPDATE_DISPATCH'

       DESTINATION 'CFGUPDDISP'

    EXPORTING

      table = tables.



ENDMETHOD.

Originally, this RFC was only intended to be a shell for my enterprise service consumer proxy generation (we do not have an ESR), but after experiencing the client 000 problem it became a suitable surrogate to execute the BRF+ application in the appropriate client, as well as the ABAP proxy.

 FUNCTION zca_ws_config_update_dispatch.

*"----------------------------------------------------------------------

*"*"Local Interface:

*"  IMPORTING

*"     VALUE(TABLE) TYPE  TT_TABNAMES

*"----------------------------------------------------------------------



  DATA:timestamp    TYPE timestamp,

       t_name_value TYPE abap_parmbind_tab,

       name_value   TYPE abap_parmbind,

       r_data       TYPE REF TO data,

       input        TYPE zzca_ws_config_update_dispatch,

       proxy        TYPE REF TO zco_zws_config_update_dispatch.



  CONSTANTS: function_id TYPE if_fdt_types=>id VALUE '005056977E091EECA1F05A7D5FE1B25F'.



* Set timestamp for processing and move input data into reference

  GET TIME STAMP FIELD timestamp.

  name_value-name = 'TT_TABNAMES'.

  GET REFERENCE OF table INTO r_data.

  cl_fdt_function_process=>move_data_to_data_object( EXPORTING ir_data             = r_data

                                                               iv_function_id      = function_id

                                                               iv_data_object      = '005056977E091EECA1F05DC93384D25F' "TT_TABNAMES

                                                               iv_timestamp        = timestamp

                                                               iv_trace_generation = abap_false

                                                               iv_has_ddic_binding = abap_true

                                                     IMPORTING er_data             = name_value-value ).

  INSERT name_value INTO TABLE t_name_value.

  CLEAR name_value.



  TRY.

*   Execute BRF+ function

    cl_fdt_function_process=>process( EXPORTING iv_function_id = function_id

                                                iv_timestamp   = timestamp

                                      IMPORTING ea_result      = input-table-item

                                      CHANGING  ct_name_value  = t_name_value ).



*   Only execute proxy if any tables of interest are found

    IF input-table-item[] IS NOT INITIAL.

      CREATE OBJECT proxy.

      CALL METHOD proxy->zca_ws_config_update_dispatch

        EXPORTING

          input  = input.



      COMMIT WORK.

    ENDIF.



    CATCH cx_fdt.

*     Do what on error?

    CATCH cx_ai_system_fault.

*     Do what on error?

  ENDTRY.



ENDFUNCTION.

BRF+

I find BRF+ to be an often underutilized gem in the system. If I have a simple question for the system to answer, pass the necessary input and let it determine the outcome. The true beauty is that I can add or remove a table for this scenario without writing a single line of ABAP!!

Integration Flow

The first two steps of the flow are setup steps to determine the backend OData host and split the incoming message by each table. The last three steps will be presented in more detail below.

Full E2E Integration Process

Graphical Mapping

This mapping serves the purpose of mapping a backend table name into four corresponding bits of data... stored procedure, OData service name, resource, and query using a combination of the fixValues function and a couple of simple Groovy scripts. Folks could be wondering why not use value mapping, but I feel like that is a lot of overkill to maintain several input fields instead of simple 1:1 mappings with fixValues. Also, note the use of the query parameter is used because for one table we don't want the full field list. If we use $select query options for one table in the OData adapter we must maintain it for all (Tried the empty string and it did not work). This leaves me with a choice dilemma:

Option 1 - Add a query parameter, which is more stuff to maintain in the graphical mapping

Option 2 - Do not add query parameter and handle stripping of extra fields in XSL transform

Since I'd rather not select fields and transport extra data over the network that is of no consequence, I went with the first option.

Graphical mapping for OData/Stored procedure determination

The setHeader function should be self explanatory, but the joinContexts function is to establish a queue like some of the older PI/PO functions. I could not find an equivalent in Integration Suite, so I constructed my own (Feel free to share if there is some out of the box option that I could not find).

// Insert message headers

def void setHeader(String[] keys, String[] values, Output output, MappingContext context){

  def i = 0;

  while(i < keys.size()) {

    context.setHeader(keys[i], values[i]);

    i++;

  }

}



// Create context queue to match keys with values

def void joinContexts(String[] input1, String[] input2, String[] input3, Output output, MappingContext context){

  output.addValue(input1[0]);

  output.addValue(input2[0]);

  output.addValue(input3[0]);

}

Content Enricher via OData

The first image includes basic host and service metadata that is handled in the first step, and the graphical mapping step. I was unsure if externalized parameters and headers would be concatenated like two headers, so I went with this option. If externalized parameters do work in this way, then I could eliminate the first step in the flow. The second image shows the processing tab with the other metadata required for the OData service call. You may be wondering at this point... what about V2 vs. V4? For the 10 tables I need to push, I was able to identify 2 services that are both V2. If I have to cross that bridge in the future, I can manage with the addition of a version metadata field in the graphical mapping and an appropriate routing step.

OData Connection Information

OData Processing Information

The following XML is the result after the content enricher via OData using the combine algorithm. The nice feature/outcome being that I did not have to statically define any table structures or field types anywhere in the solution.

<?xml version='1.0' encoding='UTF-8'?>

<multimap:Messages xmlns:multimap="http://sap.com/xi/XI/SplitAndMerge">

  <multimap:Message1>

    <Root>

      <StoredProcedure>sp_TVV1T</StoredProcedure>

    </Root>

  </multimap:Message1>

  <multimap:Message2>

    <AdditionalCustomerGroup1> 

      <AdditionalCustomerGroup1> 

        <AdditionalCustomerGroup1_ID>T01</AdditionalCustomerGroup1_ID>

        <AdditionalCustomerGroup1Text>Tier 1</AdditionalCustomerGroup1Text> 

      </AdditionalCustomerGroup1> 

      <AdditionalCustomerGroup1> 

        <AdditionalCustomerGroup1_ID>T02</AdditionalCustomerGroup1_ID>

        <AdditionalCustomerGroup1Text>Tier 2</AdditionalCustomerGroup1Text> 

      </AdditionalCustomerGroup1> 

      <AdditionalCustomerGroup1> 

        <AdditionalCustomerGroup1_ID>T03</AdditionalCustomerGroup1_ID> 

        <AdditionalCustomerGroup1Text>Tier 3</AdditionalCustomerGroup1Text> 

      </AdditionalCustomerGroup1> 

      <AdditionalCustomerGroup1> 

        <AdditionalCustomerGroup1_ID>T04</AdditionalCustomerGroup1_ID> 

        <AdditionalCustomerGroup1Text>Tier 4</AdditionalCustomerGroup1Text> 

      </AdditionalCustomerGroup1> 

      <AdditionalCustomerGroup1> 

        <AdditionalCustomerGroup1_ID>T05</AdditionalCustomerGroup1_ID>

        <AdditionalCustomerGroup1Text>Tier 5</AdditionalCustomerGroup1Text>

      </AdditionalCustomerGroup1> 

      <AdditionalCustomerGroup1>

        <AdditionalCustomerGroup1_ID/>

        <AdditionalCustomerGroup1Text/> 

      </AdditionalCustomerGroup1> 

    </AdditionalCustomerGroup1>

  </multimap:Message2>

</multimap:Messages>

XSL Transform

For the sake of brevity, I have included a truncated XSL transform that only includes 3 tables despite my requirement being 10 tables. If you happen to be a savvy XSL veteran, and find my work to be rudimentary, keep in mind that this is my first XSL transform after spending 30 minutes reading and learning on W3Schools. I did implement the XSL transform in such a way that empty string key records would be removed from the stream.

<?xml version="1.0" encoding="UTF-8"?>



<xsl:stylesheet version="1.0"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:multimap="http://sap.com/xi/XI/SplitAndMerge">



<xsl:template match="/">

  <root>

    <StatementName>

      <storedProcedureName action="EXECUTE">

        <table><xsl:value-of select="multimap:Messages/multimap:Message1/Root/StoredProcedure"/></table>

        <ProcedureParameter type="CLOB">

          <xsl:text disable-output-escaping="yes">&lt;![CDATA[</xsl:text>



          <!-- TVM4T Procedure -->

          <xsl:for-each select="multimap:Messages/multimap:Message2/AdditionalMaterialGroup4">

            <List>

              <xsl:for-each select="AdditionalMaterialGroup4[AdditionalMaterialGroup4_ID!='']">

                <Item>

                  <MaterialGroup4><xsl:value-of select="AdditionalMaterialGroup4_ID"/></MaterialGroup4>

                  <MaterialGroup4Text><xsl:value-of select="AdditionalMaterialGroup4Text"/></MaterialGroup4Text>

                </Item>

              </xsl:for-each>

            </List>

          </xsl:for-each>

          

          <!-- TVM5T Procedure -->

          <xsl:for-each select="multimap:Messages/multimap:Message2/AdditionalMaterialGroup5">

            <List>

              <xsl:for-each select="AdditionalMaterialGroup5[AdditionalMaterialGroup5_ID!='']">

                <Item>

                  <MaterialGroup5><xsl:value-of select="AdditionalMaterialGroup5_ID"/></MaterialGroup5>

                  <MaterialGroup5Text><xsl:value-of select="AdditionalMaterialGroup5Text"/></MaterialGroup5Text>

                </Item>

              </xsl:for-each>

            </List>

          </xsl:for-each>



          <!-- TVV1T Procedure -->

          <xsl:for-each select="multimap:Messages/multimap:Message2/AdditionalCustomerGroup1">

            <List>

              <xsl:for-each select="AdditionalCustomerGroup1[AdditionalCustomerGroup1_ID!='']">

                <Item>

                  <CustomerGroup1><xsl:value-of select="AdditionalCustomerGroup1_ID"/></CustomerGroup1>

                  <CustomerGroup1Text><xsl:value-of select="AdditionalCustomerGroup1Text"/></CustomerGroup1Text>

                </Item>

              </xsl:for-each>

            </List>

          </xsl:for-each>



          <xsl:text disable-output-escaping="yes">]]&gt;</xsl:text>

        </ProcedureParameter>

      </storedProcedureName>

    </StatementName>

  </root>

</xsl:template>



</xsl:stylesheet>

The resulting XML is JDBC adapter ready

<root xmlns:multimap="http://sap.com/xi/XI/SplitAndMerge">

  <StatementName>

    <storedProcedureName action="EXECUTE">

      <table>sp_TVV1T</table>

      <ProcedureParameter type="CLOB">

        <![CDATA[

        <List>

          <Item><CustomerGroup1>T01</CustomerGroup1><CustomerGroup1Text>Tier 1</CustomerGroup1Text></Item>

          <Item><CustomerGroup1>T02</CustomerGroup1><CustomerGroup1Text>Tier 2</CustomerGroup1Text></Item>

          <Item><CustomerGroup1>T03</CustomerGroup1><CustomerGroup1Text>Tier 3</CustomerGroup1Text></Item>

          <Item><CustomerGroup1>T04</CustomerGroup1><CustomerGroup1Text>Tier 4</CustomerGroup1Text></Item>

          <Item><CustomerGroup1>T05</CustomerGroup1><CustomerGroup1Text>Tier 5</CustomerGroup1Text></Item>

        </List>

        ]]>

      </ProcedureParameter>

    </storedProcedureName>

  </StatementName>

</root>

JDBC

Disclaimer: This part has not actually been tested, but instead the above XML was dumped to an FTP site for extraction during unit testing.

Once the DB admins are able to create the necessary stored procedures I will include an editorial update. In the past, I have used the JDBC adapter in PI/PO where we can do bulk inserts, but I did stumble upon some blog/answer posts, and an OSS note indicating that bulk inserts are not supported in Integration Suite unless using a splitter in batch mode. I referred to the following blog on the topic of using stored procedures, which I had used in the past in PI/PO - Stored procedure as XML Type I opted not to split an already split message, along with the fact that this approach fares far better from a performance perspective.

Conclusion

After reaching a point where I can successfully unit test the full solution outside of of the JDBC handling, I'm pleased with the outcome. For future's sake, if I need to add a new table in the future the process is quite simple:

Add table to BRF+ expression

Identify/build an OData service - Note: if you have spent inordinate amounts of time working backward from tables to a usable OData service, then you are not alone, and I would rather reuse than build. I don't need draft capabilities for this type of thing and I'm still presented with choosing from multiple options... whatever happened to software reusability, but that's a topic for another day

Add four bits of metadata (maybe five if versioning enters the picture) for OData and a stored procedure into the graphical mapping step

Add a new block to the XSL transform

Get a DB Admin to create the required stored procedure

Hope folks can get something useful out of this... enjoy!

SAPJSF user gets frequently locked

2022-02-10T11:15:36+01:00

In this blog we are going to discuss how to resolve the SAPJSF user getting locked issue due to incorrect logon attempts.

Before diving into this, i want to give a little bit of background to issue. I was facing this issue since May 2021. After checking and applying various SNOTE, the issue was not resolved. I am using Dual Stack ( ABAP + JAVA ) running on NetWeaver 7.4. I raised SAP OSS but the support was unable to resolve this issue and finally suggested the upgrade to NetWeaver 7.5. I was able to resolve this without the upgrade.

Cause :

This issue occurs when SAPJSF password has been updated ( by a user or by system upgrade/implementation/change etc. ) .

In a dual stack system, this leads to failed attempts by SAPJSF user as the same SAPJSF password has not been updated at following places :

ABAP SAP GUI

OS application server ( Configtool )

SAP NetWeaver portal ( JCO and RFC destinations )

Resolution :

To resolve this issue we have to update the same SAPJSF password at all the three locations mentioned above.

Go to SU01 – Change and Update the SAPJSF password and save the changes.

Login to your J2EE engine operating system. Open the Config Tool. Choose Global server configuration > services > com.sap.security.core.ume.service. Change the password on ume.r3.connection.master.passwd.

The config tool located under /usr/sap/<SAP SID>/<Instance Dir.>/j2ee/configtool/configtool.bat or .sh *

3. Login to NetWeaver portal : Configuration > connectivity > destination. find : RFC destination UME Backend connection > logo data > edit > update SAPJSF password. (check first if user is SAPJSF).Then Go to SU01 > Unlock the SAPJSF user manually. Restart the Java instance from SAP MMC at OS level.

Login to NetWeaver portal :Configuration > connectivity > JCO connector. You will find the list of running TCP/IP connection. Check logon data of each connection and if the USER is SAPJSF and then update the password. Then Go to SU01 > Unlock the SAPJSF user manually. Restart the Java instance from SAP MMC at OS level.

After following the above steps, I have resolved this issue.

Conclusion :

In a dual stack system , Communication user SPAJSF is used for establishing the connection between ABAP and JAVA. In a single stack JAVA only system, this user is used for internal communication.

The same password should be maintained at the destination and user sheet, otherwise this will lead to SAPJSF user getting locked frequently.

I hope this blog is helpful to you. Please feel free to drop any questions and clarification if any.

Interfacing web apps with SAP

2022-04-05T19:46:09+02:00

Businesses are unique, and so are their challenges. Evora designs, builds, and implements custom-tailored solutions based on modern technologies and best practices. As a long-time SAP partner, we have extensive experience in developing custom apps and connecting them to SAP backend systems. I spoke to my colleague fredericpollmann about his project experience so I could share the learnings with the SAP community.

Leveraging SAP Gateway

SAP Gateway is part of SAP NetWeaver, which allows to connect devices, applications, and platforms to SAP systems. For the integration, the Open Data Protocol (OData) is used, so any programming language or model can be used to connect SAP systems with non-SAP applications.

Using a familiar RFC interface, developers can easily create OData. As a JSON dialect, it offers easy integration with all kinds of frontend technologies and frameworks that are prepared to consume data out of REST services, even if you do not want to use or implement the entire OData functionality. While the main job of the gateway is to pass data on, it can also be used to fetch, refine, and transform it based on your requirements along the way.

Leveraging SAP Gateway

Our Technology Stack for hybrid web apps

In one customer case for a field service app at a technology company, we built a hybrid web app using Angular, Bootstrap, and Apache Cordova. The core of this application runs on iPads and Windows 10 convertible devices and is accessible as a web page - all built from the same code base.

Flexible Architecture

The application logic is built with Angular and is heavily dependent on rxjs and the reactive programming paradigm. This allows us to easily update the application whenever data changes.

Beautiful User Interfaces

Using Bootstrap as the UI framework allows us to quickly achieve results and build applications that the user intuitively understands. Applying a theme allows us to easily match the app to the customers corporate design colors and style guide.

One Code Base

Everything is bundled together in a Cordova app which gives us cross-platform capabilities. And thanks to using a mono-repository approach, the source code for the core libraries and different app shells lives in the same code repository and ensures that we don’t have problems with broken dependencies.

Automatic Synchronization

By integrating the Apple push notifications service into the RFCs, we can trigger a sync between mobile clients and backend whenever required without manual refresh.

What technology you use? What piece of knowledge regarding web app development you would like to share? Looking forward to the discussion, please provide feedback in the comments section here.

Disclaimer: all information and images are created by Evora IT Solutions.Note that this post first appeared at https://www.evorait.com/2022/02/11/interfacing-web-apps-with-sap.

Shipment Data Transfer from ECC to TM Without Middleware

2022-06-10T22:17:27+02:00

There are multiple ways to send data from one SAP system to another for several scenarios. IDocs and webservices can fulfil most of your integration requirements. However, there maybe times when your project requires you to achieve something that is not standard SAP behaviour. And when SAP does not provide such functionalities, you must figure out a workaround.

One of those scenarios is Shipment Transfer from ECC system to TM system without a middleware.
SAP does not allow point-to-point connection for data transfer from Shipment in ECC to Freight Order in TM system. It mandates the use of PI system as a middleware. This means that once you have triggered Shipment creation from a Freight Order in TM, you do not have the confirmation from ERP system if PI system is not involved. Furthermore, any change of Shipment Status is also not sent back to TM system. Hence, the Freight Order Status remains unchanged.

In this blogpost, I have shared the solution to send shipment data from ECC system to TM system. The data includes both confirmation details as well as status change details. We will be building an RFC that will be called by the ECC system and will update the corresponding Freight Order in TM system. If required, similar solution can be used for numerous Freight Order fields with the right bit of BOPF coding.

Attached below are the screenshots of the Freight Order fields I will update based on Shipment Data
in ECC.

Prerequisite:

• Basic understanding of BO structure
• Knowledge of BOPF coding
• Understanding of BO node actions

The fields to be updated are:

1. Carrier
2. Transmission-to-ERP status
3. Last ERP Confirmation On/At
4. Lifecyle Status
5. Execution Status
6. Logistical Execution Status

And this is the mapping between the ECC shipment fields and the corresponding status in FO in TM. When the Shipment Status fields are checked (‘X’), the corresponding status code should be updated in FO in TM system.

Shipment Status Field (X)	Execution Status (SAP TM)	Lifecycle Status (SAP TM)	Logistical Execution Status (TM system)
VTTK-STLBG	Loading In Process (09)	In Process (02)
VTTK-STLAD	Ready for Transportation Execution (07)	In Process (02)	Loaded (18)
VTTK-STTBG	In Execution (03)	In Process (02)
VTTK-STTEN	Executed (04)	In Process (02)
VTTK-STABF	Executed (04)	Completed (05)

Step 1: Build RFC Function Module in TM system

First, we will build the RFC (Remote Function Call) which will be called from ECC. The RFC will be developed in TM system and will be called when the Shipment is created, updated, or deleted. Identify the nodes in which the above fields are present.

Of the above TM fields, all, except the Logistical Execution Status field, are present in the Root Node. Therefore, the actions to update the fields will be present under the Root Node. The Actions are:

ASSIGN_TSP (To Update carrier)

SET_EXM_STATUS_EXECUTED (Set Execution status to Executed)

SET_LC_COMPLETE (Set lifecycle status to Processed)

SET_LC_IN_PROCESS (Set lifecycle status in Process)

SET_EXM_STATUS_READY_FOR_EXEC (Set Execution Status to Ready for Execution)

SET_EXM_STATUS_IN_LOADING (Set Execution Status to in Loading)

SET_EXM_STATUS_IN_EXECUTION (Set Execution Status to In Execution)

The Logistical Execution Status field is present under STOP Node and the action to change its status to ‘Loaded’ is SET_HANDLING_EXECUTION.

The fields Transmission-to-ERP status and Last ERP Confirmation On/At are updated by MODIFY method of Interface /BOBF/IF_TRA_SERVICE_MANAGER.

The above Actions are executed using the method DO_ACTION of interface /BOBF/IF_TRA_SERVICE_MANAGER.

Let us come to RFC now and see the logic that has been implemented.

In our system, we have kept the Freight Order and Shipment number range same. Therefore, the freight order number (TOR) is same as the shipment number.

Get the TOR ID in a variable. Pass it through a Conversion routine before assigning it to the internal table of type /SCMTMS/T_LOC_ALT_ID.

We will use the TOR ID as an Alternate Key to retrieve the Root details.

We also need to instantiate the Service Manager and Transaction Manager.

Now we retrieve the TOR GUID from the Freight Order Number and use it to fetch Root Details.

Now we pass the Transmission status and ERP Confirmation Date/Time and create the parameters for MODIFY Method.

Pass the parameters to MODIFY method and SAVE the changes by calling the Transaction Manager.

Now we update the Carrier in the TOR structure. The challenge here is to populate the Action Parameters Declare an object of type /SCMTMS/S_TOR_ROOT_A_ASGN_TSP which is the importing parameter of the Action ASSIGN_TSP. Populate the parameter as shown below and pass it to the DO_ACTION method.

Now we update the Status of the Freight Order (TOR). Check if the Actions mentioned above has any importing parameter. If there is, declare a DATA Object by referencing the Importing Parameter. Pass it to the DO_ACTION Method to update the carrier. Remember to call the Transaction manager to save the changes.

Except Logistical Execution Status which comes under the STOP Node, update the other status like the above steps.

Update the Logistical Execution Status, get the current stop details using the GET_CURRENT_STOP method of Class /SCMTMS/CL_TOR_HELPER_STOP.

Declare the Action Parameter by referencing the Importing Parameter of the Action ASSIGN_TSP. Pass the required values to the object. Then call the DO_ACTION Method.

Step 2: Call the RFC from TM System

Once the RFC has been created in TM system, the next course of action is to call the RFC from the ECC system. There are two ways to call this RFC.

One way is to create a custom ABAP program in ECC that will call the RFC. The ABAP program will then be assigned to an Output Type that will get triggered for create/update/delete of shipment.

Another way is to identify a BADI that will get triggered after saving of shipment and then call the RFC from the BADI.

We will proceed with the second option here. You can choose whichever option is suitable for you. The BADI interface is IF_EX_BADI_LE_SHIPMENT. There are three methods in it – AT_SAVE, IN_UPDATE, BEFORE_UPDATE.

We will add our logic to the IN_UPDATE Method. Implement the BADI and create an implementing class and add the below logic.

Setup RFC destination in ECC and TM system.

Fetch the RFC destination and save it in a variable of type RFCDEST.

Check the Importing Parameters of the Method. There are three separate internal tables for each of Shipment Related Tables. Each of the Internal Tables end with suffix like INS or UPD or DEL to distinguish between the different shipment processes like Create, Update and Delete.

Read the Internal tables to get the Details required to update the Freight Order. Call the RFC and pass the values to the Function.

There are many VTTK fields corresponding to the status as well as carrier in Freight Order in TM system. Identify the fields and pass them to the RFC.

This is the entire process to send data from ECC to TM system without any middleware. However, if you are using PI system as your middleware, you do not have to put in this much effort and the data flow is seamless.These Service Providers can get things done easily.1. TransportationOrderSCMExecutionConfirmation_In 2.TransportationOrderSCMExecutionStatusNotification_In

Conclusion

Using RFC is a simple and straightforward way to send data from one SAP system to another. It bypasses the use of middleware and can be highly effective. Check out the solution given above and let me know what you think of it.

Duplicate workitems in My Inbox fiori app

2022-06-28T08:13:23+02:00

Hi,

When you implement My Inbox fiori app you can face one issue in which user is receiving duplicate work items in his My inbox fiori app.

If you check total workflow tasks in inbox from SBWP . Workflow is showing total 7 items.

Total 7 workitems

If you login to My inbox fiori app it is showing 14.

Total workitems

In this blog we will discuss the reason behind it and how to resolve it.

Reason:

The main reason behind it is that Odata service Taskprocessing has been assigned 2 different system aliases.

Like follows:

System Alias

Solution:

Simple solution to resolve this issue is that delete one unnecessary System Alias. This will resolve the issue.

System Alias

When you run the My Inbox Fiori app. it will show the correct number of workitems instead of showing duplicate workitems.

Workitems

For more detail please visit https://community.sap.com/topics/abap

https://blogs.sap.com/

S/4 HANA Topic.

Creation of bgRFC and calling in a program

2023-03-15T19:38:50+01:00

Description:

What is bgRFC.

bgRFC configuration.

bgRFC programming.

bgRFC Monitoring.

1. What is bgRFC?

The bgRFC allows application to record data that is received later by a called

application. When the data is received, we must ensure that the data was transferred to

the receiver either once only in any order(transactional) or once only in the order of

creation(queued).

2. bgRFC Configuration?

Creation of supervisor Destination.

This is a mandatory step because the bgRFC can only function if a supervisor

destination has been define for bgRFC processing. For creation of supervisor

destination the t-code is SBGRFCCONF.

bgRFC_Configuration_1

bgRFC_Configuration_2

Prerequisite:

Need to verify the supervisor destination as an RFC destination using the transaction

SM59. This destination must be defined as either an ABAP connection or a logical

connection.

bgRFC_Configuration_3

A user, password, and client must be entered for both connection types. Please refer

the attached screenshot.

bgRFC_Configuration_4

ABAP Connection :

No load balancing can be defined.

No system number can be entered.

No server can be entered.

bgRFC_Configuration_5

Creation of destination:

We have to create inbound/outbound destination name based on the requirement.

Creation of Inbound Destination:

On the define inbound Dest. Tab page in the transaction SBGRFCCONF, we can

maintain a separate inbound destination for each application. This is also mandatory

step to create any inbound bgRFC.

Logon/Server group can be defined using transaction RZ12.

All the settings and activities related to the transaction SBGRFCCONF is BASIS related

activity so before creating/configuring any bgRFC please consult with BASIS team.

bgRFC_Configuration_6

bgRFC_Configuration_7

bgRFC_Configuration_8

Creation of outbound destination:

We can create outbound destination using transaction SM59. Creation of outbound

destination in SM59 is normal like any of the destination creation. Please refer the

below screenshot for reference.

bgRFC_Configuration_9

We have to created outbound destination under ABAP Connections. For this destination

we have to maintain the necessary target destination IP, system no etc. Please refer all

the below screenshots for detailed setting in each tab.

bgRFC_Configuration_10

bgRFC_Configuration_11

bgRFC_Configuration_12

After creation of the outbound destination in SM59 we have to maintain this destination

in SBGRFCCONF transaction. We have to maintain the destination in Scheduler

Destination tab of transaction SBGRFCCONF. Please refer the below screenshot.

bgRFC_Configuration_13

3. bgRFC Programming

After the entire configuration now let’s talk about the programming.

Creation of unit:

We have to create one bgRFC unit by taking the reference from the configured

inbound/outbound destination name. Destination objects can be requested using the

class methods from the class CL_BGRFC_DESTINATION_OUTBIUND for the

outbound and the class CL_BGRFC_DESTINATION_INBOUND for the inbound. We

have to use method create of the above mentioned class to create a destination object.

Please see the below example of how to create an inbound destination object.

Pass any of the configured inbound destination name in the below mentioned variable.

Call the below mentioned method to create reference of inbound destination.

bgRFC_Programming_1

If the inbound/outbound destine is invalid the program is going to dump.

Please refer the blow screen shot for your reference.

bgRFC_Programming_2

For handling the runtime error we need to use exception class

CX_BGRFC_INVALID_DESTINATION. Please refer the below screenshot for your

reference.

bgRFC_Programming_3

After creation of the destination object it is time to create a bgRFC unit. bgRFC unite

can be two types like tRFC and qRFC. We have to use method CREATE_TRFC_UNIT

to create a tRFC unit and method CREATE_QRFC_UNIT to create a qRFC unit. Please

refer the below screenshot.

bgRFC_Programming_4

To create a qRFC unit we just have to call CREATE_QRFC_UNIT method instead of

CREATE_TRFC_UNIT method.

Calling a function module:

After creation of the unit we have to call any function module in background. The new

syntax for calling a function module for background processing is as follows.

CALL FUNTION ‘function_name’

IN BACKGROUND UNIT unit

EXPORTING…

Inside the calling function module we have to write our required logic which we want to

process in background (e.g Update a table). Please refer below screenshot for calling of

a function module.

bgRFC_Programming_5

In the above example the function module is called in background using the created

unit. In the exporting parameter we can define whatever we want to send in the function

module. If we want to send some table also we can define it in the calling module and

we can send it.

bgRFC_Programming_6

The above screenshot shows complete program to call bgRFC.

RFC Function module:

RFC_Fun_1

The function module must be RFC enabled function module.

RFC_Fun_2

Here one thing need to remembered, calling the function module will happen once

program does the COMMIT WORK. If we want to create bgRFC from our custom

program like report in that case we have to do external COMMIT WORK but if we are

trying to create bgRFC from any BADI/USER EXIT/Enhancement Spot in that case we

do not need to apply external COMMIT WORK. Once standard SAP do the COMMIT

WORK bgRFC unit will be Created.

4. bgRFC Monitoring:

bgRFC monitor typically required to check if any unit is failed or there are any issue in

any particular unit.

We have to use transaction SBGRFCMON to monitor bgrfc unit. In the selection screen

we have option to monitor Inbound/Outbound unit along with tRFC unit or qRFC unit.

Also there are several options in the selection screen. Please refer the below screen shot.

bgRFC_Mon_1

After execution the transaction we will be able to monitor all the erroneous units in the

system. We have to remember if any unit is created successfully and if there are no

data issue or any connection issue in that case it will be executed and we will not able

to see it in this transaction. Only erroneous and warning units will be displayed here.

Please refer the below screenshot.

bgRFC_Mon_2

Conclusion:

Background Remote Funtion Call (bgRFC) is a technology in SAP that allow for

asynchronous (qRFC) and synchronously (tRFC) communication between different

systems. It is used to enable background processing of distributed system in a secure

and reliable manner.

With bgRFC, developers can create and schedule processes to run in the background

of SAP system, which helps reduce the workload on the front-end and improve system

performance. The technology ensure that all data is transmitted securely and can

handle large volumes of data efficiently.

I would like to hear your thoughts and feedback on this post and promoting relevant

community resources in the SAP community.

Related links

Other Blogs for related bgRFC:

https://support.sap.com/en/alm/sap-focused-run/expert-portal/integration-cloud-monitoring/bgrfc.html#:~:text=bgRFC%20is%20a%20superordinate%20term,classic%20tRFC%20and%20qRFC%20versions.

https://support.sap.com/en/alm/solution-manager/expert-portal/monitoring-of-integration-scenarios/bgrfc-channel.html

More Blogs:

https://community.sap.com/topics/abap-connectivity

https://answers.sap.com/tags/266264953119842772207986043063520

https://blogs.sap.com/tags/266264953119842772207986043063520/

Thank you for reading my content on SCN blog! If you enjoyed what you read and

would like to see more, I encourage you to follow my profile.

SAP Build Apps and BAPIs: RFC meets Web

2023-04-02T12:17:56+02:00

"RFC meets Web"

Enable all your RFC functions for web consumption without development?

Today, I'm excited to share a new thing: A proxy on SAP BTP that translates from REST to SAP RFC calls, making it possible to use BAPIs and RFC-enabled function modules on older SAP ECC or S/4HANA systems.

This solution is particularly useful for SAP ERP users who are looking to integrate with systems that lack the new OData APIs that are only available on newer S/4HANA systems. With the REST-to-RFC proxy, RFC meets web, creating a seamless integration experience that unlocks the full potential of your SAP ecosystem.

Benefits:

Protect your past investment: Use your function modules for the web

RFC modules turned into synchronous REST APIs

No further development work

Secured communication through SAP BTP destinations

Image 1: Outline of solution - it works with any RFC function module (Y/Z-RFC modules included)

In this blog post, we'll take a closer look at how this proxy works, the benefits it provides, and the impact it can have on your SAP integration projects. So, let's dive in and discover the possibilities of web meets RFC!

Solution approach

SAP BTP offers the destination service to define ways to connect to systems. Keeping destinations separate from applications makes them reusable and easy to maintain. They come in several flavors like:

HTTP - for anything like REST, OData-REST, HTML and the like.

LDAP - Lightweight Directory Access Protocol to lookup information in a network. Often used for organizational data of entities and persons.

MAIL - to send emails to an SMTP server

RFC - Remote Function Call, this is what we look at for the cloud connector-facing side.

From here we define the first destination to the cloud connector (CC) as RFC. You need to white-list the function modules you plan to use in your cloud connector instance.

Image 2: Example of an RFC destination. The ashost is as defined in your CC.

I use this destination in the Java HTTPServlet. On the consumption side you'll need another destination that you can use for e.g. SAP Build Apps and which is provided by the HTTPServlet. If you secure it with OAuth2 the config could look like that.

Image 3: REST destination for consumption of BAPIs or RFC functions in general.

Since I use xsuaa for authentication and authorization I've defined 2 scopes to allow for display and change authorization.

Image 4: POST and GET related scopes to be assigned to relevant users for consumption.

The difference between the two is that the POST will trigger a BAPI.commit and therefore posts data in your S/4HANA or ECC system while the GET doesn't. Of course it depends on how you've designed your ABAP code - standard BAPIs will adhere to this approach.

SAP Build Apps demo: Change material master

Enough talk! Let's see a demo built with SAP Build Apps. It uses 3 BAPIs:

BAPI_MATERIAL_GETLIST - To search for materials and get them in a list

BAPI_MATERIAL_GETALL - To retrieve the details of a selected material

BAPI_MATERIAL_SAVEDATA - To change some fields in the material master

There is no development done on both backend and frontend.

1. Mobile application

2. SAP Build and S/4HANA Backend

Solution Architecture

Below are the schematics for using the REST to RFC proxy running on BTP Cloud Foundry.

Image 2: Solution architecture for REST-RFC proxy on SAP BTP Cloud Foundry

I'll explain the technical details in a second blog if you are interested to create such a proxy on BTP for yourself.

Conclusion

And there it is: A proxy that opens all your RFC developments to the web in a secured manner. Hope it is useful!

Check my second blog for the technical details on how you can design the proxy on SAP BTP.

RFC meets the Web: Part II - Building the proxy

2023-04-04T03:19:14+02:00

RFC meets Web - Part II: How to build the proxy

Welcome back to the second blog post where we look into building the REST2RFC proxy! It's a SAP Cloud SDK Java application running on SAP BTP Cloud Foundry runtime.

Introduction and BTP services used

When I started with the project (which was inspired by customers telling me "we don't have APIs, we are still on S/4HANA 1909") I explored the options to build a proxy to translate between the RFC and the REST world. A few things became clear:

That proxy must be agnostic - no function module specific logic should be in it, so it can be universal.

REST is channeled through SAP Cloud Connector and with that we have a granular way to white-list what should be exposed from the on-premise system.

SAP BTP offers the RFC-flavor for defining a destination. Great!

Using BTP RFC destinations only works through Java and the API For SAP BTP (Java Web Tomcat 9) which is not in the SAP Cloud SDK for Java (not to be confused with the JCo you can download as a separate package) and likely coming from Neo but working perfectly fine with CF and latest Cloud SDK, too.

All existing tutorials were outdated that explained the RFC integration so I hope this blog helps you.

As for the BTP project building the application needs these services:

Authorization and Trust Management Service (xsuaa): Securing the application from the web entry point with OAuth2 and roles to be assigned to a user which define the scope during authentication as part of the JWT.

Connectivity Service: To connect between cloud and on-premise through the Cloud Connector (CC).

Destination Service: To retrieve the destinations in the Java app for RFC and offer the REST service to the caller.

Application Logging Service: To allow for a really nice monitoring of the proxy. Not mandatory but I highly recommend it for debugging and day-to-day monitoring.

Proxy project details

Development IDE

I used Eclipse in connection with the SAP Cloud SDK for Java. You want to install Maven with

$ choco install maven

on a Windows device. To create a fresh project I ran

mvn archetype:generate "-DarchetypeGroupId=com.sap.cloud.sdk.archetypes" "-DarchetypeArtifactId=scp-cf-tomee" "-DarchetypeVersion=RELEASE"

since I built on TomcatEE and not Springboot. This create the framework you should open in Eclipse once done.

I deleted those elements which I didn't need (like junit and integration tests 😂) so the build process just considered my code. You also need to define a manifest file and the obligatory xs-security.json.

---

applications:



- name: jco-rfc-rest-server

  memory: 1500M

  timeout: 300

  random-route: true

  path: application/target/jco-rfc-rest-server-application.war

  buildpacks:

    - sap_java_buildpack

  env:

    USE_JCO: "true"

    TARGET_RUNTIME: tomee7

    SET_LOGGING_LEVEL: '{ROOT: INFO, com.sap.cloud.sdk: INFO}'

    JBP_CONFIG_SAPJVM_MEMORY_SIZES: 'metaspace:128m..'

    xsuaa_connectivity_instance_name: "jco-rfc-rest-server-xsuaa"

    connectivity_instance_name: "jco_connectivity"

    destination_instance_name: "jco_destination"

    ENABLE_SECURITY_JAVA_API_V2: "true"

    

  services:

    - jco-rfc-rest-server-xsuaa

    - jco_connectivity

    - jco_destination

    - jco-app-logging

above is my manifest.yml.

{

  "xsappname": "jco-rfc-rest-server",

  "tenant-mode": "dedicated",

  "scopes": [

    {

      "name": "$XSAPPNAME.Display",

      "description": "GET requests on BAPI"

    },

    {

      "name": "$XSAPPNAME.Modify",

      "description": "POST requests on BAPI"

    }

  ],

  "role-templates": [

    {

      "name": "JCo-REST-RFC-Server-Viewer",

      "description": "Required to run GET requests for RFC BAPI calls.",

      "scope-references"     : [

        "$XSAPPNAME.Display"

      ]

    },

    {

      "name": "JCo-REST-RFC-Server-Administrator",

      "description": "Required to run POST requests for RFC BAPI calls.",

      "scope-references"     : [

        "$XSAPPNAME.Modify"

      ]

    }

  ]

}

Above is my xs-security.json. Based on that you can create 2 role collections in BTP later to allow for a display and and admin role for the proxy calls.

Java specifics: Authority checks

The Java class for the proxy is based on the HttpServlet class. Below I'd like to share the pattern for authority checks.

@WebServlet("/rfc/*")

@ServletSecurity(@HttpConstraint(rolesAllowed = { "Display", "Modify" }))

public class Rest2RfcProxy extends HttpServlet {



        // .... some code



	@Override

	@RolesAllowed({"Modify"})

	protected void doPost(HttpServletRequest request, HttpServletResponse response)

			throws ServletException, IOException {	

               // ...

        }



	@Override

	@RolesAllowed({"Display", "Modify"})

	protected void doGet(HttpServletRequest request, HttpServletResponse response)

			throws ServletException, IOException {

               // ...

        }



        // .... some more code



}

So that's how the security scopes defined in xs-security.json are checked in the Java code. You must enable that in the web.xml file of the webapp like so:

    <login-config>

        <auth-method>XSUAA</auth-method>

    </login-config>



	<security-constraint>

        <web-resource-collection>

            <web-resource-name>Baseline Security</web-resource-name>

            <url-pattern>/*</url-pattern>

        </web-resource-collection>

        <auth-constraint>

            <role-name>*</role-name>

        </auth-constraint>

    </security-constraint>



    <security-role>

        <role-name>Display</role-name>

    </security-role>

     <security-role>

        <role-name>Modify</role-name>

    </security-role>

Only then it will work with the data injected by the JWT.

Info: Per default BTP destination service will work with X-CSRF token. I turned it off for testing - this is also defined in web.xml!

Java specifics: JCo REST/RFC

The communication through JCo via RFC follows this sequence:

Get the RFC destination with details that we specified in the SAP BTP (see the first blog).

Define the function to be called in Java.

Define the import/ export and table parameter list from the function module. These variables hold the according structures.

Load the metadata of the 3 objects from the SAP ECC or S/4HANA data dictionary.

Set the import or tables parameters as needed.

Execute the function module call.

If it's a POST, also execute a call to BAPI BAPI_TRANSACTION_COMMIT. If you call a Z-function module it depends how your organized your LUW whether this has any impact at all. Certainly it won't hurt but the commit might have been done before that in your ABAP code.

Feed back the data to the caller

Example for the IMPORTS:

if (jImports != null) {

	logger.info("Filling BAPI import: " + jImports.toString());

	bapiImports.getMetaData();

	bapiImports.fromJSON(jImports.toString());

}

This uses the .fromJSON method to fill the structure. On the way back to the caller you can then use the .toJSON method to obtain the JSON data for REST.

Application logging

I recommend to consider using the application logging service on BTP, particularly for this middleware application to facilitate error analysis. It builds on the common org.slf4j framework. You activate it with

private static final Logger logger = LoggerFactory.getLogger(<your class name>.class);

declared on class level to have it available in every method and exception. In the manifest.yml you can then set the logging level:

SET_LOGGING_LEVEL: '{ROOT: INFO, com.sap.cloud.sdk: INFO}'

here it means everything is logged. You can reduce it to WARN or ERROR.

Image 1: Application Logging service on BTP

The dashboard offers detailed filtering and statistics which are very handy.

Image 2: Application logging dashboard overview

Troubleshooting

I faced a few issues when developing and building it because the tutorials were outdated or didn't support the use case. Maybe this can help you.

java.lang.UnsupportedClassVersionError

"java.lang.UnsupportedClassVersionError: com/sap/demo/jco/ConnectivityRFCExample has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 52.0 (unable to load class [com.sap.demo.jco.ConnectivityRFCExample])

This means the bytecode of the WAR file isn't matching the BTP Java Buildpack. First you want to check the buildpack on BTP:

$ cf buildpacks

E.g. 52.0 = Java 8, 61.0 = Java 17. I had to set my Eclipse JDK to create code for 52.0 by setting it to Java 8 from Java 17. Also this help is useful (standard is Java 8, if using SAP Machine it's Java 11).

POST, PUT, PATCH. DELETE will require X-CSRF-Token

If you don't want that, turn it off, out-comment the section for the filter RestCsrfPreventionFilter in web.xml. This can help during testing. For production, better put it back in.

After setting up a fresh project with Maven Eclipse looks "funny"

You got to switch the facet in the project properties to Java.

Maven repository not found

Add it to the Java Build Path in the project's properties.

Image 3: Project properties, Java build path

"Where is the source code?"

Please check my LinkedIn post in that matter.

Conclusion

Building a proxy to translate between the RFC and REST world requires an agnostic proxy. It is a universal solution without function module specific logic, and the REST service is channeled through the SAP Cloud Connector. Using the RFC-flavor for defining a destination on the SAP BTP platform with Java Web Tomcat 9 API allowed for easy integration. By following this blog, building an efficient proxy is now possible, and it will be useful for businesses using older SAP S/4HANA or ECC systems.

Let me know your feedback - I'm eager to learn how you are using the approach for your web use cases!

Parallel Processing On OABAP - Using Classes and Methods

2023-04-27T18:03:43+02:00

Parallel processing is implemented in ABAP reports and programs, not in the background processing system itself. That means that jobs are only processed in parallel if the report that runs in a job step is programmed for parallel processing. Such reports can also process in parallel if they are started interactively.

Parallel processing in OAbap is using class and methods in report level program.

Parallel Processing is implemented with a special variant of Asynchronous RFC. It’s important that you use only the correct variant for you own parallel processing applications. The “CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP” keywords.

when a huge number of records needs to be processed and it takes a lot of time to produce the output, this parallel processing technique can be applied to achieve run time improvement. So, this Parallel processing is an asynchronous call to the Function Module in parallel sessions/ different session/ multiple sessions.

T-Codes:

RZ12 - To Check the Server Group.

SM66 - To Check all the Work Processers.

SM51 - To Check the Application Server.

SM21 - System log in case of any failures.

""""" parallel processing """"""""

REPORT ZPARALLEL_PROCESSING_OABAP.

DATA:chk1,
chk2,
ret11 TYPE TABLE Of bapisdstat,
ret22 TYPE TABLE OF bapisdstat,
ret TYPE bapisdstat.

CLASS lcl_demo DEFINITION.

PUBLIC SECTION.

CLASS-METHODS:

CALL IMPORTING sdoc1 TYPE bapivbeln-vbeln
sdoc2 TYPE bapivbeln-vbeln,
handle1 IMPORTING p_task TYPE clike, "must have a importing para-of type clike
handle2 IMPORTING p_task TYPE clike. "must have a importing para-of type clike

ENDCLASS. "LCL_DEMO DEFINITION

*———————————————————————-*

*       CLASS LCL_DEMO IMPLEMENTATION

*———————————————————————-*

CLASS lcl_demo IMPLEMENTATION.

METHOD call.

CALL FUNCTION'BAPI_SALESORDER_GETSTATUS'
STARTING NEW TASK'FUNC1'
DESTINATION'NONE'
CALLING handle1 ON END OF TASK
EXPORTING
salesdocument = sdoc1.

CALL FUNCTION 'BAPI_SALESORDER_GETSTATUS'
STARTING NEW TASK 'FUNC2'
DESTINATION 'NONE'
CALLING handle2 ON END OF TASK
EXPORTING
salesdocument = sdoc2.

WAIT UNTIL chk1 = abap_true AND chk2 = abap_true.

WRITE:/'SUCCESS'.

ENDMETHOD.           "call method

METHOD handle1.

DATA: ret1 TYPE TABLE OF bapisdstat.
RECEIVE RESULTS FROM FUNCTION 'BAPI_SALESORDER_GETSTATUS'
TABLES
statusinfo    = ret1.
ret11 = ret1.
chk1 = abap_true.

ENDMETHOD.                "HANDLE1

METHOD handle2.
DATA: ret2 TYPE TABLE OF bapisdstat.
RECEIVE RESULTS FROM FUNCTION 'BAPI_SALESORDER_GETSTATUS'
TABLES
statusinfo  = ret2.
ret22 = ret2.
chk1 = abap_true.

ENDMETHOD.            "HANDLE2

ENDCLASS.          "LCL_DEMO  IMPLEMENTATION

START-OF-SELECTION.

PARAMETERS: p_sdoc1 TYPE bapivbeln-vbeln,
p_sdoc2 TYPE bapivbeln-vbeln.

CALL METHOD lcl_demo=>call
EXPORTING
sdoc1 = p_sdoc1
sdoc2 = p_sdoc2.

LOOP AT ret11 INTO ret.

write: / ret-doc_number , ret-material, ret-creation_date.

ENDLOOP.

CLEAR ret.

LOOP AT ret22 INTO ret.
write:/ ret-doc_number,ret-material, ret-creation_date.

ENDLOOP.

PROGRAM:

Image 1

Defining a Class : When you define a class, you define a blueprint for a data type. This doesn't actually define any data, but it does define what the class name means, what an object of the class will consist of, and what operations can be performed on such an object.

That is, it defines the abstract characteristics of an object, such as attributes, fields, and properties.

Implementation : Implementation of a class contains the implementation of all its methods. In ABAP Objects, the structure of a class contains components such as attributes, methods, events, types, and constants.

Image 2

ABAP keyword CALL FUNCTION <function> STARTING NEW TASK <taskname> with the DESTINATION IN GROUP argument.

Use this keyword to have the SAP system execute the function module call in parallel. Typically, you'll place this keyword in a loop in which you divide up the data that is to be processed into work packets. You can pass the data that is to be processed in the form of an internal table (EXPORT, TABLE arguments). The keyword implements parallel processing by dispatching asynchronous RFC calls to the servers that are available in the RFC server group specified for the processing.

Waiting for job completion: As Line No 37 : indicates wait until with abap boolean .

As part of your task management, your job must wait until all of the parallel processing tasks have been completed.

To do this, the program uses the WAIT UNTIL keyword to wait until the number of completed parallel processing tasks is equal to the number of tasks that were created.

Image 3

Methods : The definition of a method is declared in the class declaration and implemented in the implementation part of a class.

The METHOD and ENDMETHOD statements are used to define the implementation part of a method.

ABAP keyword RECEIVE: Required if you wish to receive the results of the processing of an asynchronous RFC.

RECEIVE retrieves IMPORT and TABLE parameters as well as messages and return codes.

Image 4

Image 4 : as its business implemented , declaring the parameter .CALL the method with respective parameter

Use LOOP and ENDLOOP executes the statement block between LOOP and ENDLOOP once for each read row. The output response result determines how and to where the row contents are read. The table key with which the loop is executed can be determined in cond.

OUTPUT:

Parallel processing is a method in computing of running two or more processors (CPUs) to handle separate parts of an overall task. Breaking up different parts of a task among multiple processors will help reduce the amount of time to run a program using class and methods, which helps in performance.

Time consumption in OAbap is less compared to normal Abap reports.

I hope Abapers will understand Parallel Processing with Classes and Methods.

Please provide your feedback and your thoughts into comment section below.

Do you have any Q&A please reach to https://answers.sap.com/index.html and post your

questions.

follow the ABAP Development environment Topic page https://community.sap.com/topics/abap

and for reading further blog post visit https://blogs.sap.com

Regards,

Shruthi S.

Principal propagation in a multi-cloud solution between Microsoft Azure and SAP, Part VII: Invoke RFCs and BAPIs with Kerberos delegation from Microsoft Power Platform

2023-06-19T13:52:16+02:00

This blog post is the seventh part of a tutorial series. For a better understanding of the concepts and technologies, it is highly recommended that you read part IV first, and then come back here again. Part IV introduces the Microsoft Power Platform with some of its key components that you will use in this part of the tutorial series as well, such as the On-Premises Data Gateway (OPDG), Power Automate, and Connectors.

Since there is no "one-size-fits-all" approach for integration scenarios between Microsoft's and SAP's platforms using principal propagation, this series starts with part I explaining the technology standards for principal propagation in the context of calling a simple Web Service on SAP Business Technology Platform (BTP) on behalf of the authenticated user (or principal) from Azure Active Directory (Azure AD). Parts II, III, IV and V extend this scenario step by step by adding on-premise connectivity, Microsoft Teams integration, and API management to it. I do recommend reading these parts as well to get an understanding of the different scenarios and recommended options to implement them. Part VI looks at the reverse direction for propagating the principal from SAP Cloud Identity Services to Azure in the context of calling the Microsoft Graph API from an BTP application.

This part takes in in-depth look at principal propagation for an application built with the Microsoft Power Platform making a Remote Function Call (RFC) to an SAP system on-premise using a Business Application Programming Interface (BAPI) to search a product catalogue. Check out episode 142 of the SAP on Azure video podcast series for a live demo of this scenario.

All variants for principal propagation in this blog series used HTTP secured by Transport Layer Security (TLS) as the application layer protocol for calling a Web service on BTP (see part I), an OData service on SAP NetWeaver Gateway (see parts II, III, IV and V), or the Graph API (see part VI) to call Microsoft 365 services. The OAuth 2.0 Authorization Framework is the de-facto security standard for restricting access to the data exposed by these RESTful services. To enable principal propagation, additional standards such as the Security Assertion Markup Language (SAML) 2.0 and OpenID Connect (OIDC) 1.0 are required for a secure and interoperable transfer of the security context and identity information of the authenticated user (or principal) across system- and network boundaries. Please refer to the other parts of this blog series for a detailled explanation how OAuth, SAML and OpenID can be combined for secure principal propagation.

For RFCs and BAPIs, none of the beforementioned protocols can be used to secure the communication and propagate the principal between an external client and the SAP Application Server (AS) ABAP. For these services, Secure Network Communications (SNC) can be applied to secure RFCs. SNC uses the standardized Generic Security Service Application Program Interface (GSS-API) for integrating with a cryptographic library for encrypting the data traffic on the network level and supporting single sign-on (SSO) to an SAP system using X.509 client certificates or the Kerberos protocol as specified in RFC 4120.

Principal Propagation with Kerberos Delegation

The Kerberos protocol, named after the three-headed guard dog of Hades from the Greek mythology, requires a trusted authority, the Key Distribution Center (KDC), to facilitate SSO between the client and a "kerberized" service or resource on a server. The protocol not only defines these three entities, but also three phases of their message exchange as illustrated in figure 1:

Figure 1: The Kerberos protocol

Authentication Service (AS) exchange: The client requests a ticket-granting ticket (TGT) with an authentication service request (AS_REQ) message (1) from the Authentication Service (AS) of the KDC. The user authenticates at the AS by encrypting this message with her secret key K_Cthat is created by hashing the user's password stored in the KDC's account directory. Upon successfull decryption, the KDC constructs the TGT for the user and returns it to the client with a AS_REP (2) message. The TGT is encrypted with the KDC's secret key K_K and is a special type of Kerberos ticket that can only be used by the client to obtain other tickets from the KDC.

Ticket-Granting Service (TGS) exchange: To establish an authenticated communication session with the service, the client uses the TGT (instead of the long-term secret key K_C from the user's hashed password) and requests a service ticket (ST) from the KDC's Ticket Granting Service (TGS) with a ticket-granting service request (TGS_REQ) message (3). The service for which the ST is requested for is identified by its Service Principal Name (SPN). SPNs uniquely identify an instance of a service and are registered on a user or computer account in the KDCs account directory by setting the servicePrincipalName attribute of the object. The KDC returns the ST for the service encrypted with the service key K_S to the client with a ticket-granting service response (TGS_REP) message (4).

Client/Server Authentication (AP) exchange: The client sends the ST to the service with an application server request (AP_REQ) message requesting access to the service (5). The server can validate the ticket by decrypting it with its service key K_S where it finds the user's unique name (cname). Optionally, the client might request that the server verify its own identity by sending back a application server response (AP_REP) message (6).

For propagating the authenticated user from the service to another service, the Kerberos protocol provides the Service for User (S4U) extensions. These extensions allow a service to obtain a Kerberos service ticket for a different service on-behalf-of a user that has not authenticated to the KDC. S4U includes the S4U2self and S4U2proxy extensions:

The Service-for-User-to-Self (S4U2self) extension is intended to be used by a service to obtain a ticket for itself on-behalf-of a user who has authenticated in some other way than by using Kerberos to the service. With S4U2self, the service gets a ticket just as if the user had used Kerberos.

The Service-for-User-to-Proxy (S4U2proxy) extension allows a service to
call another service, acting on-behalf-of the user. The first service uses a Kerberos service ticket as if the user had obtained the service ticket for it and sends the ticket to a second service directly. Configuration at the KDC's TGS can be used to limit the scope of the S4U2proxy extension, also known as constrained delegation. The second service is typically a proxy performing some work for the first service, and the proxy requires to do that work under the authorization context of the user.

Figure 2 shows the two S4U Kerberos extensions (steps 10 to 13) in the context of the complete end-to-end message flow for the scenario in this blog post:

Figure 2: System landscape and message flow

Jack Davis as the application test user in this tutorial logs on to the domain-joined Windows workstation on the corporate network. This results in a Kerberos TGT issued by the local Active Directory Domain Service (AD DS) acting as the KDC (see figure 1, steps 1 & 2). The same applies to services in the corporate domain, such as the OPDG, that also obtains a TGT from AD DS.

The user launches the "SAP Product Search" Power Platform app in a web browser. The app consists of two components (see figure 3): A canvas app providing the user interface to search for the price of a product in the Enterprise Procurement Model (EPM) demo application of the SAP system in the corporate network. The business logic to connect to SAP, transforming the BAPI response data, and error handling, is implemented in a Power Automate flow. The flow uses the SAP ERP Connector's prebuilt Call SAP function (V2) action to invoke the BAPI_EPM_PRODUCT_GET_DETAIL Business Application Programming Interface (BAPI) of the EPM demo application.Figure 3: Application components

For authentication to Power Platform, the app requires an OpenID Connect (ID) token for authentication and an OAuth access token for authorization, and redirects the user to the app's Azure AD tenant authorization endpoint to trigger authentication with the OAuth 2.0 authorization code flow. For a complete SSO experience, the setup in this scenario synchronizes the user accounts from the corporate Active Directory Domain Services (AD DS) to the Azure AD tenant with Azure AD Connect and Password Hash Synchronization (PHS) enabled. With PHS, hashes of the user passwords in AD DS are synchronized by Azure AD Connect to Azure AD so that the users can login with the same password on-premises and in the cloud. This feature can be combined with Seamless SSO in Azure AD Connect to automatically sign-in users when they are on their corporate devices connected to the corporate network. The following steps 4 to 6 explain this process in more detail.

Azure AD challenges the browser to provide a Kerberos ticket for the user by sending an HTTP 401 Unauthorized response.

The browser requests the Kerberos ticket from AD DS for the computer account representing Azure AD in AD DS.

The browser forwards the encrypted Kerberos ticket to Azure AD which can decrypt it using the shared key for the account.

Upon successful SSO to the cloud, the Azure AD tenant generates an OAuth 2.0 authorization code for the user and sends it to the SAP Product Search app by redirecting the user's web browser.

The app redeems the authorization code for an OAuth access token and OpenID Connect (ID) token by sending the authorization code to the Azure AD tenant's token endpoint.

When the user enters a product ID and clicks the search button, the app triggers the flow which in turn uses the SAP ERP connector to call the SAP system's BAPI via the OPDG on the corporate network. The flow passes the product ID to the BAPI's input parameters and sends the user's ID token in the call to the SAP ERP Connector. The ID token must successfully pass the validations of its claims, such as the intended recipient (audience), the trusted issuer who constructed the token (Azure AD tenant), and the validity of the expiration of the token, before the User Principal Name (UPN) is extracted from it and send to the OPDG.

OPDG uses the Kerberos S4U2self extension to retrieve a forwardable service ticket for itself on behalf of the Azure AD-authenticated user. To do so, OPDG has to run under a service user account (e.g. CORP\GatewaySvc) within the AD domain, uniquely identified by its SPN (e.g. gateway/WIN-OPDG). OPDG needs to map the UPN from the Azure AD-authenticated user to a different UPN of the user in the on-premise AD, using an unused Active Directory attribute such as msDS-cloudExtensionAttribute1 in this scenario. This lab setup requires user mapping because the user's UPN suffix in Azure AD (e.g. jdavis@bestruncorp.onmicrosoft.com) is different from her suffix in the corporate AD (e.g. jdavis@corp.bestrun.com). As specified by the S4U2self extension, OPDG creates the PA_FOR_USER data structure with the mapped user name and sends it with a TGS_REQ message to AD DS.

AD DS uses OPDG's identity from its TGT sent with the TGS_REQ message to create the OPDG service ticket and returns the service ticket for the user in the TGS_REP message.

The SAP system is configured for SNC and Kerberos-based SSO (e.g. for SAP GUI), which requires registration of an SPN for the SAP system's service account in AD DS following the format "SAP/<SID>", e.g. SAP/A4H. OPDG is now attempting to obtain a service ticket for the SAP system on-behalf-of the user with the S4U2proxy Kerberos extension. OPDG sends the TGS_REQ message with the user's service ticket for OPDG obtained in the previous step as an additional-ticket in the request.

AD DS makes sure the forwardable flag is set in the OPDG's service ticket found in the additional-ticket and uses its local policy to determine if OPDG is allowed to obtain a service ticket on behalf of a user to the SAP system. If these conditions are met, the TGS crafts the TGS_REP message to return the user's service ticket to the SAP. This response contains the cname field identifying the user's UPN in AD DS that was taken from the additional-ticket.

OPDG utilizes the locally installed SAP Connector for Microsoft .NET 3.1 (NCo 3.1) and SAP Cryptographic Library to make a secure, SNC-protected synchronous RFC call to the BAPI, authenticated with the Kerberos ticket from the previous step for the SAP system obtained on-behalf-of the Azure AD-authenticated user from AD DS. The SAP system can single sign-on the user with the Kerberos ticket by mapping its cname to the user's SNC name (e.g. p:CN=JDAVIS@CORP.BESTRUN.COM).

If all authorization checks for the propagated user are successfull (such as the permission to call the BAPI), the response from the BAPI is sent back by the SAP ERP Connector to the flow, checked for any errors, and parsed for the price of the product which is returned to the app.

Prerequisites and lab setup

The following list of prerequisites must be met to successfully complete the exercises of part VII:

A Power Platform environment. You can reuse the environment from part IV, or (if you started your journey here) can get a new one with a free Power Apps trial account or Microsoft 365 Developer license and by following these instructions.

Administrative access to an Active Directory domain and on-premises systems for simulating the corporate network in your lab environment. You can create the required systems in your lab environment as Hyper-V VMs and configure them according to the table below:

System	Operating system & software
Active Directory Domain Controller (AD DC)	Windows Server 2019 Active Directory Domain Services (AD DS role). Installing the AD DS role and promoting a Windows Server to a domain controller is documented here. The domain name used in this tutorial is corp.bestrun.com (NetBIOS: CORP), but you can also choose any other name. Azure AD Connect, version 2.1.20.0, following these installation instructions.
On-Premises Data Gateway (OPDG) Server	Windows Server 2019, domain-joined On-Premises Data Gateway, minimum version 3000.178.9 (June 2023) or newer. Installation instructions and how to register the OPDG in your Power Platform environment can be found here. SAP Connector for Microsoft .NET 3.1 (NCo 3.1). Select NCo 3.1 compiled with .NET Framework 4.6.2 - SAP Connector for Microsoft .NET 3.1.<n>.<n> for Windows 64 bit (x64) for download. SAP Cryptographic Library (`sapcrypto.dll`) 64 bit, version 8.5.25 (or newer). Download the latest version of the SAP Cryptographic Library from the SAP Support Portal's Software Download (S-User required). Search for "`CommonCryptoLib"` in the Support Packages and Patches area. Optional tools for troubleshooting: Wireshark
Workstation	Windows 10 Pro, domain-joined SAP GUI 7.70 SAP Secure Login Client 3.0
SAP System	SAP Application Server ABAP Note: The SAP system is not required to be domain-joined and not to have line-of-sight to the AD DC. Therefore you can run it also in the cloud. If you don't have a system available for testing, the SAP Cloud Appliance Library (CAL) provides a simple way to deploy a test and development system for evaluation purposes on Azure. Use the SAP ABAP Platform 1909, Developer Edition appliance template which fulfills all requirements for this tutorial by installing an SAP Application Server ABAP 7.54 SP2.

Table 1: Lab setup

Administrative access to an Azure AD tenant (which is included in the Microsoft 365 Developer license). The domain name of the tenant used in this tutorial is bestruncorp.onmicrosoft.com, but you can also choose any other name.

Checkout branch part7 of the blog series GitHub repository with a Git client of your choice and the following commands:

git clone https://github.com/raepple/azure-scp-principal-propagation.git

cd azure-scp-principal-propagation

git checkout part7

The following exercises require switching between different roles. The table below lists those user roles and corresponding accounts used in the configuration steps of the scenario:

Role	User accounts
Administrator	SAP login: SAPADMIN AD login: CORP\Administrator Azure AD login: admin@bestruncorp.onmicrosoft.com SAP operating system login: <SID>adm
Developer	SAP login: DEVUSER AD login: CORP\devuser Azure AD / Power Platform login: devuser@bestruncorp.onmicrosoft.com
Application test user	SAP login: JDAVIS AD login: CORP\jdavis Azure AD login: jdavis@bestruncorp.onmicrosoft.com

You will start the exercises to setup the end-to-end scenario illustrated in figure 2 by configuring the service account and SPN in the corporate Active Directory for the SAP system and setup the SAP system for SNC to test single sign-on with the SAP GUI. You can skip the following section if your SAP system is already configured for Kerberos-based SSO.

Configure SAP for Kerberos-based SSO with Active Directory

Step	Description	Screenshot
1	As a domain administrator, launch the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in on the Domain Controller host. Right-click on Users in your domain to open the context menu and select New → User to create the new service account for the SAP system.
2	Enter Kerberos<SID> as the First name, Full name and User login name. Replace <SID> with the ID of your SAP system (e.g. "A4H"). Click Next.
3	Enter the password for the new service user account. Select User cannot change password and Password never expires. Click Next.
4	Click Finish.
5	Start the ADSI Editor (adsiedit.msc) to maintain the Service Principal Name (SPN) of the new service account. Select CN=Users from your domain's default naming context, and right-click on the CN=Kerberos<SID> user object. From the context menu, select Properties. Alternatively to steps 5 to 8, you can also use the command line as an Administrator and enter the following command: `setspn –A SAP/<SID> <domain>\Kerberos<SID>` Replace <domain> with the NetBIOS name of your domain (e.g. "CORP"), and <SID> with the ID of your SAP system (e.g. "A4H").
6	Select servicePrincipalName from the list. Click Edit.
7	Enter the Service Principal Name (SPN) for the SAP service account in the format "SAP/<SID>". Replace <SID> with the ID of your SAP system (e.g. "A4H"). Click Add.
8	Click OK.
9	Go back to the Active Directory Users and Computers MMC snap-in and select the new SAP service account Kerberos<SID> from the Users list. Right-click on it and select Properties from the context menu.
10	Switch to the Account tab. Under Account options, activate the checkbox for This account supports Kerberos AES 256 bit encryption. Click OK.
11	Login to the domain on the workstation host with your application test user (e.g. CORP\jdavis).
12	Start SAP GUI and login as the SAP administrator. Run transaction SNCWIZARD to start the SNC Configuration wizard.
13	If you see the error message "DEFAULT profile in the DB and in the file system are different" then run transaction RZ10 first, and select Utilities → Import Profiles → Of active servers, and return to the SNCWIZARD. On the Start page of the SNC Configuration wizard, click Continue.
14	Accept the default value for system's SNC Identity and click Continue.
15	Click Continue.
16	Click Close.
17	Log off from the SAP system to restart the application server.
18	As SAP system user <SID>adm, use the commands `sapcontrol -nr <instance_number> -function Stop` and `sapcontrol -nr <instance_number> -function Start` to restart the application server. Replace <instance_number> with the number of your application service instance, e.g. "00".
19	After the restart of the application server, log on to SAP GUI and run transaction SNCWIZARD again.
20	On the Start screen, click Continue.
21	Click Continue.
22	In the SPNEGO Configuration, click Display/Change to switch into edit mode.
23	Click Add to configure a new Kerberos User Principal.
24	Enter the following values: User Principal Name: Kerberos<SID>@<full-qualified name of your Active Directory Domain in uppercase letters, e.g. "CORP.BESTRUN.COM"> Password: <The password you specified in step 3> Confirm Password: <The password you specified in step 3>
25	Click Exit. Click Save to store the updated SPNEGO Configuration.
26	Click Skip on the X.509 Credentials wizard step.
27	Click Complete to finalize the wizard.
28	Open the SAP Secure Login Client and right-click on the Kerberos Token from the Profiles list. Select Copy SNC name to clipboard from the context menu.
29	Go back to SAP GUI and run transaction SU01 to maintain the application user's SNC mapping. Enter the application test user's ID (e.g. JDAVIS) in the User field and click Change.
30	Switch to the tab SNC. Maintain the user's SNC name by pasting the value you copied in step 28 from the clipboard (e.g. p:CN=JDAVIS@CORP.BESTRUN.COM). Click Save.
31	Repeat the last two steps for maintaining the SNC mapping for the developer's user account. Enter the developer user's ID (e.g. DEVUSER) in the User field and click Change.
32	Switch to the tab SNC. Maintain the developer user's SNC name (e.g. p:CN=DEVUSER@CORP.BESTRUN.COM). Click Save.
33	Log off as the administrator from SAP GUI.
34	Right-click on the SAP system connection and select Properties... from the menu.
35	Switch to the Network tab. Activate the checkbox Activate Secure Network Communication. In the SNC Name field, enter the SAP system's SNC Identity from step 12. Click Finish.
36	Right-click on the system's connection and select SNC Logon with Single Sign-On to test the new SNC setup.
37	You should be single signed-on as user JDAVIS to the SAP system. Click Log off (or select System → Log off from the menu) to log out as user JDAVIS.

Configure OPDG for Kerberos Constrained Delegation

By default, OPDG runs as the machine-local service account NT Service\PBIEgwService. To use Kerberos Constrained Delegation with the protocol's S4U extensions, OPDG has to run under a service account in the domain.

Step	Description	Screenshot
38	On the Domain Controller host, go back to the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in. Right-click on Users in your domain and select New → User from the context menu. Enter "GatewaySvc" as the First name, Full name and User login name. Click Next.
39	Enter the password for the OPDG domain service account. Select User cannot change password and Password never expires. Click Next.
40	Click Finish.
41	As the domain administrator, run the following command to create an SPN for the new service account which is required to configure the Kerberos delegation in the next step: `setspn –S gateway/<OPDG hostname> <domain>\GatewaySvc` Replace <OPDG hostname> with the hostname of your OPDG system. You can find out the name by entering the command `hostname`.
42	Right-click on the new service account and select Properties from the context menu.
43	Switch to the Delegation tab. Select Trust this user for delegation to specified services only and Use any authentication protocol. Click Add.
44	Click Users or Computers.
45	Enter "Kerberos<SID>" in the object names field. Replace <SID> with your SAP system's ID, e.g. "A4H". Click Check Names to resolve it to the full existent name. Click OK.
46	The list of allowed services now contains the value from the SPN (Service Type / Computer) of the SAP system. The new OPDG service account can request a service ticket only for the SAP system on-behalf-of the propagated user with the Kerberos S4U2proxy protocol extension. Click Select All.
47	Click OK.
48	Click OK.
49	The OPDG service account must be granted to local policies on the OPDG host. Perform this configuration with the Local Group Policy Editor by running gpedit.msc from an Administrator command prompt.
50	Go to Local Computer Policy → Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment. Grant the OPDG domain service account (e.g. "CORP\GatewaySvc") the local policy Act as part of the operating system by double-clicking on it. Click Add User or Group.
51	Enter the name of your OPDG's domain service account (e.g. "GatewaySvc") and click Check Names to resolve it to the full existent name. Click OK. The service account's domain name (e.g. "CORP\GatewaySvc") is now added to the policy's user list. Click OK to apply the new configuration.
52	Repeat the same step for the Impersonate a client after authentication policy by double-clicking on it. Click Add User or Group and resolve the OPDG's service account to the full existent name with Check Names. Click OK.
53	The service account's name (e.g. "CORP\GatewaySvc") is now added to the policy's user list. Click OK. Close the Local Group Policy Editor.
54	Start the OPDG app from the desktop link on the gateway host, or by running `C:\Program Files\On-premises data gateway\EnterpriseGatewayConfigurator.exe`. Click Sign in to login as the Power Platform System administrator user who registered the OPDG in the environment.
55	Select Service Settings from the configurator's menu. Click Change account.
56	Click Apply and Restart.
57	Enter your OPDG's service account name (e.g. "CORP\GatewaySvc") and password from step 34. Click Configure.
58	Provide your Power Platform System administrator sign-in account, by clicking on Sign in.
59	Choose Migrate, restore or takeover an existing gateway to restore your gateway registration.
60	Select your gateway cluster and instance from the drop-down boxes and provide the recovery key you've chosen during the initial registration. Click Configure.
61	After the restoration is complete, your OPDG service instance uses the domain service account (e.g. "CORP\GatewaySvc").
62	Add the OPDG service account to the Windows Authorization and Access Group. This is requried because the user accounts that the gateway will impersonate are in Azure AD and thus not in the same domain as the OPDG service account. On the Domain Controller host, go back to the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in. Select the Builtin folder for your domain and double-click on the Windows Authorization and Access Group security group.
63	Switch to the Members tab of the security group. Click Add.
64	Enter the name of your OPDG's domain service account (e.g. "GatewaySvc") and click Check Names to resolve it to the full existent SPN. Click OK.
65	The OPDG service account is now added to the policy's user list. Click OK to apply the new configuration.

Install and configure the SAP Cryptographic Library

For SNC communication between the OPDG and the SAP system, the SAP Cryptographic Library must be installed on the gateway host along with SAP NCo 3.1.

Step	Description	Screenshot
66	Download the latest version of the SAP Cryptographic Library from the SAP Support Portal's Software Download (S-User required), and copy the library file (`sapcrypto.dll`) to the OPDG's installation directory on the gateway host (`C:\Program Files\On-premises data gateway`). Right-click on the `sapcrypto.dll` file and select Properties from the context menu.
67	Switch to the Details tab to check the version of the library. It should be 8.5.25 or newer. Click OK.
68	Create a new text file `sapcrypto.ini` in the same directory (`C:\Program Files\On-premises data gateway`) with the following content: `ccl/snc/enable_kerberos_in_client_role = 1` Save the file.
69	Grant read and execute permissions to both the `sapcrypto.ini` and `sapcrypto.dll` files to the gateway service user account and the AD user(s) that the service user impersonates. Right-click on the files and select Properties from the context menu. Switch to the Security tab. Check that the groups Domain Users and Authenticated Users are in the list. Click OK.
70	Create a `CCL_PROFILE` system environment variable and set its value to the path of the`sapcrypto.ini`configuration file. On the gateway host, launch the Control Panel and navigate to System and Security → System. Click Advanced system settings.
71	Click Environment Variables.
72	Under System variables, click New.
73	Enter `CCL_PROFILE` as the variable name. For the variable value, enter the full path to your `sapcrypto.ini` file, e.g. `C:\Program Files\On-premises data gateway\sapcrypto.ini` Click OK.
74	Click OK.

Configure User Mappings in Active Directory

To enable Kerberos-based principal propagation for a user in this scenario, a mapping from the user's full username (User Principal Name, UPN) in Azure AD to the user's local name in AD is required. For this purpose we will use the unused attributemsDS-cloudExtensionAttribute1 of the local AD user to store the Azure AD UPN. Any other unused Active Directory attribute can be used as well.

For the application test user Jack Davis in this scenario, you will set the msDS-cloudExtensionAttribute1 attribute of the local AD domain user account jdavis@corp.bestrun.com to the user's Azure AD UPN jdavis@bestruncorp.onmicrosoft.com for linking his two accounts. The same applies to the application development user devuser, who requires a mapping from devuser@corp.bestrun.com to devuser@bestruncorp.onmicrosoft.com.

Step	Description	Screenshot
75	On the gateway host, open the file `Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config` in the OPDG installation folder (`C:\Program Files\On-premises data gateway`) in an editor.
76	Search for the setting `ADUserNameReplacementProperty` and set its value to `SAMAccountName`.
77	Search for the setting `ADUserNameLookupProperty` and set it to the value `msDS-cloudExtensionAttribute1`. Save the changes in the file.
78	Click Restart now from the OPDG's configurator Service Settings tab to apply the changes.
79	On the Domain Controller host, click Start, and select Windows Administrative Tools → ADSI Edit from the menu. In the ADSI Editor, navigate in the left-side object tree to CN=Users under the domain's Default naming context. Right-click on the test user's object (e.g. CN=Jack Davis) and select Properties from the context menu.
80	Select the attribute `msDS-cloudExtensionAttribute1` from the list and click Edit.
81	Enter the test user's Azure AD UPN (e.g. jdavis@<domainname>.onmicrosoft.com) in the Value field. Replace <domainname> with your Azure AD tenant's domain name, e.g. bestruncorp. Click OK.
82	Repeat steps 79 to 81 for the developer user object (e.g. CN=Developer User) and map it to the user's Azure AD UPN (e.g. devuser@<domainname>.onmicrosoft.com).via the `msDS-cloudExtensionAttribute1` attribute. Click OK and close the ADSI Editor.

Configure SAP User Authorizations

Next, the SAP system is configured for the application test user and power platform developer who need a different set of authorizations. The developer needs a set of authorizations used by the SAP ERP Connector for looking up the RFCs offered by the system during development of the Power Automate flow and at runtime. In addition, the application test user role requires the authorization to call the BAPI_EPM_PRODUCT_GET_DETAILS BAPI to search the product catalog with the Power App.

Step	Description	Screenshot
83	Go back to SAP GUI and log in as the administrator user. Start transaction PFCG to define a new role for the application users in this scenario.
84	Enter `PRODUCT_SEARCH_BAPI` in the Role field. Click Single Role.
85	Click Save.
86	Switch to the Authorization tab. Click the pencil button to edit the new role's authorization data.
87	Click Do not select templates.
88	Click Manually.
89	Enter `S_RFC` for the Authorization Object in the first row. Click OK.
90	Click the pencil button to edit the authorization checks for field RFC_NAME.
91	Enter the following values in the Value Intrvl table's 'From' column: `BAPI_EPM_PRODUCT_GET_DETAILS` `RFCPING` `RFC_FUNCTION_SEARCH` `RFC_METADATA_GET` Click Save.
92	Click the pencil button to edit the authorization checks for field Activity (ACTVT).
93	Select Execute from the list. Click Save.
94	Click the pencil button to edit the authorization checks for field RFC_TYPE.
95	Select FUNC (Function Module) from the list. Click Save.
96	Click Save to save the application user role.
97	Click Generate.
98	Click Exit.
99	Switch to the User tab. Enter your application test user's ID (e.g. JDAVIS) in the first row of the User Assignment table. Click Save.
100	Click User Comparison.
101	Click Full Comparison, then Close the dialog window.
102	Click Exit.
103	Next, create the role for the application developer. Enter `PRODUCT_SEARCH_DEVELOPER` in the Role field. Click Single Role.
104	Repeat steps 85 to 90 for the new role. Enter the following values in the Value Intrvl table's 'From' column: `DD_LANGU_TO_ISOLA` `RFCPING` `RFC_FUNCTION_SEARCH` `RFC_METADATA_GET` Click Save. Continue by repeating steps 92 to 98 for the application developer role.
105	Switch to the User tab. Enter your application test user's ID (e.g. DEVUSER) in the first row of the User Assignment table. Click Save.
106	Click User Comparison.
107	Click Full Comparison, then Close the dialog window.
108	Click Exit.

Setup the Power Platform canvas app and flow

All on-premise components (SAP system, OPDG, and AD) are now configured properly for Kerberos-based principal propagation of the Azure AD-authenticated user in the Power Platform canvas app which triggers the Power Automate flow to call the SAP system.

In this step, you will import the application components as a solution in your Power Platform environment and configure them according to your test lab setup. If you want to deploy to a new environment for this scenario, go to Power Platform admin center and create it.

Step	Description	Screenshot
109	Login to Power Apps Studio at https://make powerapps.com with your Power Platform developer user. From the top menu, select the environment to deploy the scenario components.
110	Click Import solution from the top menu bar.
111	Click Browse and select the file `SAPProductSearchSolution.zip` from the Git repository's `/ProductSearchApp` folder. Click Next.
112	Click Next.
113	Open the drop-down box and select New connection.
114	In the SAP ERP Connection dialog, select Azure AD integrated as the Authentication Type. In the Choose a gateway drop-down box, select your OPDG instance for this scenario. Click Create.
115	The new connection requires authentication to your Azure AD tenant. Click Fix connection.
116	Sign-in to your Azure AD tenant with your development user's account that you configured the SNC mapping in step 32 and AD mapping in step 82, and assigned the `PRODUCT_SEARCH_DEVELOPER` role in step 105.
117	Upon successful sign-in, switch back to the previous browser tab.
118	Click Refresh.
119	The new connection is now selected by the import solution wizard. Click Import.
120	Wait for the completion of the import as indicated by the green banner. Then select the imported SAP Product Search Solution from the list.
121	From the solution components, select the SAPERPSettings environment variable. This variable is used by the SAP ERP connector action in the Power Automate flow to configure the SAP system connection parameters. It is in JSON format.
122	Click New value to overwrite the default value.
123	Enter the SAPERPSettings environment variable's new value according to your lab setup and the example below. You can use the default value as a template in a text editor. `{ "AppServerHost": "<SAP system IP address or hostname, e.g. 23.123.153.183>", "Client": "<your client ID, e.g. 001>", "SystemNumber": "<your system numner, e.g. 00", "LogonType": "ApplicationServer", "SncLibraryPath": "C:\\Program Files\\ On-premises data gateway\\sapcrypto.dll", "SncPartnerName": "<SAP system's SNC name, e.g. 'p:CN=A4H'>", "SncQOP": "Default", "SncSso": "On", "SystemID": "<SAP system's ID, e.g. A4H>", "UseSnc": "true" }` Click Save.
124	Select the SAP Product Search canvas app from the solution.
125	The Power Apps Studio opens the SAP Product Search canvas app in edit mode. Click Allow.
126	Select Power Automate from the left-side navigation menu to list the flows used by the canvas app. From the list, select the ellipsis ('…') next to the GetProductDetailsFromSAP flow. Click Refresh.
127	Click Publish.
128	Click Publish this version.
129	You need to provide your application test user(s) access to the app. Click Share.
130	Enter your application test user's name (e.g. "Jack Davis") in the search field. Click on the user account. Note: Instead of configuring single users, you can also type "Everyone" in the search filed and share the app with "Everyone in <tenant org>".
131	Deactivate the checkbox Send an email invitation to the user. Click Share.
132	Close the Share dialog box.
133	Click the Copy link to clipboard icon next to the app's Web link.
134	Since the SAP Product Search app uses the SAP ERP Connector which is Premium tier connector, the application test user requires a Power App license to use this app. In a new browser tab, open the Microsoft 365 admin center at https://admin.microsoft.com/ and login as your Power Platform administrator. Select Billing → Licenses from the left-side navigation menu. Click Microsoft Power App Plan 2 Trial.
135	Click Assign licenses. In the search box, enter your application test user's name and select the user's account from the list. Click Assign. You can now log out from the Microsoft 365 admin center.
136	Similar to the canvas app, it is also required to set the user's permission to access the OPDG instance. Go to the Power Platform admin center at https://admin.powerplatform.microsoft.com and login as your Power Platform admin user. Select Data (Preview) from the left-side navigation menu and switch to the On-premises data gateway tab. For the OPDG instance in your scenario, select the ellipsis ('…'). From the context menu, select Manage users.
137	In the search field, start entering your application test user's name. Select the user's account from the list to add it.
138	Click Share.

Testing the scenario

All required components are configured for testing the scenario in the following steps.

Step	Description	Screenshot
139	Login to the domain on the workstation host with your application test user (e.g. CORP\jdavis).
140	Open a web browser and paste the URL copied in step 133 into the address field.
141	Since you have synchronized your AD users with Azure AD Connect, you are single signed-on with the application test user to your Azure AD tenant and the app is loaded.
142	The SAP ERP connector requires a connection on-behalf-of the authenticated user. Click Allow to give consent to the requested permission to use this connection.
143	Enter a product ID form the catalog in the entry field, e.g. AR-FB-1000. Click Search.
144	The app triggers the flow which calls the SAP system on-behalf-of the Azure AD-authenticated user. The SAP ERP connector obtains a Kerberos ticket from Active Directory for the user found in the `msDS-cloudExtensionAttribute1` attribute. Upon receiving the Kerberos ticket with the BAPI call, the SAP system is able to map the AD user via the SNC mapping to a local user in the system, for whom it checks the proper authorizations to invoke the BAPI. Finally, the response with the product details is returned to the Power Automate flow, which parses the response and sends the price information back to the canvas app.

Congratulations! You've successfully completed the scenario. The following sections provide additional information about optional settings to improve the end user's experience, configure for load balancing, and some troubleshooting tips.

Bypass the user consent

In step 142, the user has been asked to confirm the requested permissions of the SAP ERP Connector. In most enterprise scenarios, this user consent is usually not required, and can be bypassed with the following Powershell commands for Power apps administration:

Step	Description	Screenshot
145	Start a Windows Powershell as an administrator. Import the necessary modules using the following commands: `Install-Module -Name Microsoft.PowerApps.Administration.PowerShell` `Install-Module -Name Microsoft.PowerApps.PowerShell -AllowClobber` Confirm the questions with "Y".
146	Provide your Power Platform administrator credentials using the following command: `Add-PowerAppsAccount`
147	The command opens the prompt to collect your Power Platform administrator credentials.
148	Run the Power Apps cmdlet `Get-AdminPowerAppEnvironment` and copy the value for your scenario's EnvironmentName to a temporary textfile.
149	Run the Power Apps cmdlet `Get-AdminPowerApp -EnvironmentName <value from step 148>` with the value obtained in the previous step. Copy the value for your app's AppName to the temporary textfile.
150	With the two values for EnvironmentName and AppName run the command: `Set-AdminPowerAppApisToBypassConsent -EnvironmentName <value from step 148> -AppName <value from step 149>` This command changes the `bypassConsent` flag of the SAP Product Search app to true.

Configure Load Balancing via SAP Message Server

In step 123, the connection parameters are configured for a specific application server instance. While this setup is appropriate for development and testing purposes, it may not be the preferred choice in a production environment. There the SAP landscape usually runs an SAP Message Server which load-balances the RFC calls to multiple application servers.

If you want to setup the scenario for load balancing via SAP Message Server, change the SAPERPSettings environment variable according to the following template:

{

    "MessageServerHost": "<SAP Message Server address or hostname, e.g. 23.123.153.183>",

    "Client": "<your client ID, e.g. 001>",

    "LogonType": "Group",

    "MessageServerService": "<The service name or port number that the Message Server is listening under for load balancing requests, e.g. 3601>",

    "SncLibraryPath": "C:\\Program Files\\On-premises data gateway\\sapcrypto.dll",

    "SncPartnerName": "<SAP system's SNC name, e.g. 'p:CN=A4H'>",

    "SncQOP": "Default",

    "SncSso": "On",

    "SystemID": "<SAP system's ID, e.g. A4H>",

    "UseSnc": "true"

}

Here is an example of a valid connection string using SAP Message Server. You can use transaction SMMS (Message Service Monitor) to find the correct value for parameter MessageServerService:

{

    "MessageServerHost": "20.123.153.183",

    "Client": "001",

    "LogonType": "Group",

    "MessageServerService": "3601",

    "SncLibraryPath": "C:\\Program Files\\On-premises data gateway\\sapcrypto.dll",

    "SncPartnerName": "p:CN=A4H",

    "SncQOP": "Default",

    "SncSso": "On",

    "SystemID": "A4H",

    "UseSnc": "true"

}

Troubleshooting

In complex integration scenarios across various system-, network- and technology-boundaries, troubleshooting usually starts with gathering information about what the issue is and where it occurs. Therefore the techniques in this last section start with troubleshooting the scenario from the user's perspective and then explain how to obtain detailed error traces from the system components along the end-to-end communication path.

Debugging with the Power Platform tools

To starting debugging the application scenario, login to https://make powerautomate.com with your Power Platform developer user. Select My flows from the left-side navigation menu and click on the Run button of the GetProductDetailsFromSAP flow. You can enter a product ID to search for in the entry field and click Run flow to start a new instance of the flow (figure 4):

Figure 4: Manually triggering the flow in the scenario

In the confirmation dialog box (figure 5), click the Flow Runs Page link. This page shows the run history of the GetProductDetailsFromSAP flow. Click on the fist item in the list to see the results from the last run. As shown in the following screenshot, the 3rd step Call SAP function (V2) - BAPI EPM PRODUCT GET DETAIL failed with a BadGateway error. By clicking on Show raw outputs you can view more details about the underlying issue. The user who started the instance (in this case the Power Platform developer user) obviously didn't have the required permissions in the SAP system to call the BAPI according to the exception message:

Figure 5: Monitor flow run

Lower-level issues such as Kerberos- or user-mapping-related problems are usually reported back to the flow as an InternalServerError by the SAP ERP Connector. In this case you should take a closer look at the available error traces in the different log files.

SNC and Kerberos troubleshooting

A good starting point for troubleshooting SNC and Kerberos is the Guided Answers wizard for SNC Kerberos Configuration for SAP GUI troubleshooting. In addition, the following (non-complete) list of SAP Notes also provides resolutions for common SNC-related problems:

1635019: No user exists with SNC name - canonical name not resolved

1696905: SNC name configuration to support Kerberos and Certificates

1848999: Central Note for CommonCryptoLib 8 (SAPCRYPTOLIB)

1878155: SNC Error Code A2210231: Kerberos ticket not yet valid

2265085: Unable to load GSS-API DLL sapcrypto.dll

2384027: Error A2210233:Kerberos ticket contains wrong service name target

2446327: SNC Error Code A221021D Server refuses offered key exchange algorithm

2497505: SNC Error Code A2200210 Peer certificate verification failed - Kerberos configuration

Turning on SNC traces for SAP NCo and the SAP system can further help with the root cause analysis:

On the SAP system, login as the operating system administrator, and change to the directory where the SAP Cryptographic Library is loaded from, e.g /usr/sap/<SID>/<INST>/exe, and create a new text file named sectrace.ini with the following content:
```
LEVEL=4

DIRECTORY=<new-or-empty-subfolder>
```
DIRECTORY must be set to a valid folder name for the respective platform. It must be the subfolder of an existing one, and should be placed in a local drive. If DIRECTORY doesn't exist it will be created. As an example, DIRECTORY can be set on a Linux system to /usr/sap/<SID>/<INST>/sectrace.
The following screenshot shows the traces generated in file sec-disp+work-<nnnnnn>.trc by the SAP GUI login of the application test user in step 37:

To enable SNC tracing on the OPDG, open the sapcrypto.ini (see step 68) and add the following two lines to it:
```
ccl/trace/level=4

ccl/trace/directory=C:\snctrc
```
Generated trace files can be found in the directory specified by the ccl/trace/directory profile parameter.

As the size of the generated trace files may grow quickly and tracing also reduces the performance of the systems, it is recommended to remove sectrace.ini and/or the configuration profile parameters from sapcrypto.ini once the troubleshooting activities are completed.

An in-depth analysis of the Kerberos message exchange between OPDG and SAP is possible with Wireshark, a tool for capturing and analyzing network traffic. Install the tool on the OPDG host and follow the steps below to capture the Kerberos taffic of steps 10 to 14 from figure 2:

Launch Wireshark. Select the network interface(s), e.g. Ethernet, to capture traffic for, and click on Start capturing packets.
Run the application scenario (steps 139 to 144)
Enter "kerberos" in the display filter field and press Enter. In the captured messages filtered for the Kerberos protocol, look for any error messages. The screenshot shows the `TGS_REQ` message (figure 2, step 12) with the user's service ticket for OPDG obtained in the previous step as an `additional-ticket` in the request.

Collecting the logs from OPDG

Launch the OPDG app (see step 54) and sign-in as the Power Platform administrator. Select Diagnostics and click Export logs as shown in figure 6:

Figure 6: Exporting OPDG logs

Unzip the file that is saved to the ODGLogs folder on your Windows desktop. Look for the most recent GatewayErrors* file in the archive. The following screenshot shows the log file with an error message that the SAP Cryptographic Library could not be found in the OPDG installation directory:

Figure 7: OPDG log excerpt

Other common issues

Finally, table 2 contains a non-complete list of common error message in the scenario and suggests possible ways to resolve them.

If you see this ...	... try this:
When signing on to the Power app, the error message PowerPINotAuthorizedException is shown:	Go to Power Platform admin center at https://admin.powerplatform.microsoft.com and login as your Power Platform admin user. Select Data (Preview) from the left-side navigation menu and switch to the On-premises data gateway tab. For the OPDG instance in your scenario, select the ellipsis ('…'). From the context menu, select Manage users. Check if the user you signed-on to the app is in the list of users assigned to the Connection Creator role of the gateway and that the SAP ERP Connection type is activated.
When executing the search, a No RFC authorization error message is shown:	An error in the app indicating an RFC authorization issue can be fixed by checking the correct role design (steps 83ff) and the assignment to the user (step 99). To troubleshoot authorization problems of the propagated principal in the backend start a system trace as the SAP admin with transaction ST01 as shown in the screenshot below. Select Authorization checks from the Trace Components and click Trace on. Re-run the scenario and click Trace off, then Anaysis. On the next screen, enter "" for the user name and click Start Reporting (F8)*: The orange-colored lines in the report show failed authorization checks due to missing permissions of the user in the system.
GatewayTimeout caused by SAP system connection timeout with the message "partner '<IP address of SAP system>:48<instance number>' not reached"	Make sure that port 48<instance number> (e.g. 4800) on the SAP system can be reached from the OPDG. In case you deployed a CAL instance on Azure, check the Network security group (NSG) settings on the subnet and network interface level for corresponding rules to allow network traffic over this port as shown in the following screenshot:

Table 2: Common error message and their possible resolution

From zero to hero security coverage with Microsoft Sentinel for your critical SAP security signals – Part 4

2023-07-06T10:42:19+02:00

👉🏿back to blog series or to GitHub repos with ready-to-run playbooks.

Dear community,

There are various problematic attack vectors for SAP backends, but only a few are as severe as losing access to the SAP audit log from your security tooling. In part 3 we discussed malicious deactivation of the SAP audit log. Now, what if the SAP RFC user to collect the audit log info gets locked, deleted, or disabled in any other way too?

At that point you are fully blind and might not even get the audit-log deactivation message anymore if the attacker is fast.

Today you will see an automated response flow to deal with that situation. But wait!

How about regular SAP or Sentinel Collector VM maintenance? How do we distinguish between normal operations and actual attacks?

Stay tuned – Azure Center for SAP solutions (ACSS) comes to the rescue🐕‍🦺⛑️ to wade through the false positives and emphasize the impactful true positives.

Fig.1 Overview remediation workflow for the Sentinel Collector attack scenario powered by ACSS

Cyber-attacks require the quickest possible reaction

The provided playbook posts an adaptive card to Microsoft Teams with a color-coded message scoring the likelihood of an attack based on the signals coming from the Sentinel Collector for SAP, and the SAP system state. The Azure Center for SAP Solutions provides a set of managed APIs to query such info in a scalable and secure way.

The playbook is wired to listen to the pre-built Sentinel alert “SAP - Data collection health check”. But you may customize yourself to whatever scenario you need.

In the scenario depicted in fig.1 the Sentinel Collector for SAP is healthy while SAP is running fine too.

That causes the playbook to raise the attack likelihood based on the alert “RFC LOGON FAILURE” to medium. After all there is still a little chance that someone unintentionally performed a breaking user setup change. Up to you to configure this as “high” or “OMG run for your lives” based on how likely you think that is in your landscape.

See here how to register your SAP system with ACSS and be ready for upcoming out of the box integrations.

In case the Collector or SAP would have been down, the likelihood of attack gets set to low with the suggestion to double check and investigate further through Sentinel, since this likely a planned maintenance or an outage.

See here how to communicate SAP maintenance via Microsoft Teams in an interactive way. Integration with the SharePoint list using the SID known to Sentinel enables you to enhance the presented flow further.

What else would you like to see here? Reach out or let me know in the comments.

Fig.2 Screenshot of adaptive card with Sentinel’s SAP incident in Microsoft Teams

As per the inferred info from the various sources, the playbook suggests a couple of options to remediate the situation. This is customizable according to your needs.

Let the community know what additional remediation paths you would like to see here. Happy to dive deeper.

The simplest option addresses the possible process glitch on the Collector VM. Hit the corresponding button (see lower section on above screenshot) to trigger an automatic restart of the VM.

Fig.3 Screenshot of Sentinel Collector VM restart logic

This suggested remediations (see fig.2) are a natural fit for the upcoming Microsoft Security Copilot. Will get into details once it gets more widely available.

The true power lies in the correlation of multiple signals in addition to the ACSS metadata leading to the event of the SAP Collector being "blinded"

Fig.4 Screenshot from Sentinel security video series about multi-staged attacks to SAP

In the above scenario you can see a sequence of alerts painting the larger picture of the attack from RDP activity to login attempts in various places leading to a successful data download from SAP sending the file to an unknown IP address. In addition to that Microsoft Defender already compiled which attacker group was responsible based on the attack footprint, techniques and tools used.

See the full video here.

Additional automation scenarios

Another popular RFC attack vector (Capture-Replay vulnerability in NetWeaver AS for ABAP; SAP security Note 3089413) can be addressed like this. How about blocking the user corresponding to that new SAP system connection? Have a look at part 1 of the series.

Last weeks publication in the German SAP security tech press re-inforces the need to deal with RFC vulnerabilites. Would you like to get the recommended security setting change for the function module "RFC_TRUSTED_SYSTEM_SECURITY" to be performed automatically from such a workflow? Or would you consider that too high a risk because it could be used to attack from a different angle?

Part 4 concludes the first wave of my blog series.

Looking to you now to request additional scenarios and share your own as Pull Requests on GitHub.

Final words

That’s a wrap 🌯today you saw another SAP security automation scenario in action. We deployed a playbook that scores potential attacks to the audit log ingestion pipeline of Microsoft Sentinel. The required signals to determine the severity of the alert are fed by Azure Center for SAP solutions to get reliable information about the operational state of SAP.

In case all involved systems are up and running while only audit log ingestion is impacted, there is a considerable chance for an ongoing attack. The playbook offers pre-configured actions to act immediately directly from Microsoft Teams.

That brings down the time to action while avoiding to “shoot” from the hip with security incidents when SAP is just down for maintenance. Whooza, whoooza Sentinel. Nothing to worry about 🧘🏻 ☮

This integration pattern overall is applicable to any SAP API. Got another SAP threat at your hands that needs automatic remediation? Let me know in the comments or reach out directly.

Cheers
Martin

Call Node.js or Python Functions from ABAP

2023-08-25T16:45:09+02:00

Node.js rich ecosystem offers plenty of functions and utilities. Using node-rfc server bindings, these assets can be consumed from ABAP, just like standard ABAP functions. SAP Open Source node-rfc connector and SAP NW RFC SDK Library make it possible.

For more info check the node-rfc server documentation and server examples. Example given here is for Node.js platform and it works the same way with Python, using PyRFC.

Background RFC protocol is currently supported for Python and work in progress for Node.js.

Node.js server source code: server-test-blog.mjs

ABAP client source code: zserver_stfc_struct.abap

How it works?

ABAP program can call an ABAP function in Node.js system, over SAP RFC protocol, just like when that function would be in ABAP system. The node-rfc server will route the ABAP RFC call to JavaScript function, registered for serving that ABAP function calls. ABAP function call parameters are automatically transformed to JavaScript and registered JavaScriot function is invoked. After JavaScript function is completed, result is automatically transformed to ABAP format and send back to ABAP client. All standard ABAP RFC call parameters can be used, like ABAP variable (JavaScript variable), ABAP structure (JavaScript "plain" object) or ABAP table (JavaScript array of "plain" objects).

Rather then manually defining ABAP interface the node-rfc server function, the node-rfc can re-use the signature of already existing ABAP function, or empty ABAP function can be created, just to define ABAP function interface for node-rfc server function..

Let try it in real systems, a notebook with Node.js supported LTS release and any new or old ABAP system.

ABAP function module signature for Node.js function

Let use the interface of ABAP function STFC_STRUCTURE, to call JavaScript function which we will create. The STFC_STRUCTURE expects one input structure, IMPORTSTRUCT and returns one variable, the RESPTEXT string and one structure, ECHOSTRUCT. There is also a table parameter RFCTABLE:

FUNCTION STFC_STRUCTURE.

*"----------------------------------------------------------------------

*"*"Lokale Schnittstelle:

*"       IMPORTING

*"             VALUE(IMPORTSTRUCT) LIKE  RFCTEST STRUCTURE  RFCTEST

*"       EXPORTING

*"             VALUE(ECHOSTRUCT) LIKE  RFCTEST STRUCTURE  RFCTEST

*"             VALUE(RESPTEXT) LIKE  SY-LISEL

*"       TABLES

*"              RFCTABLE STRUCTURE  RFCTEST

*"----------------------------------------------------------------------

Here is our Node.js function, to be called from ABAP using these parameters:

function my_stfc_structure(request_context, abap_input) {

  // inspect request context

  const attributes = request_context["connection_attributes"];

  console.log(

    "[js] my_stfc_structure context:",

    attributes["sysId"], attributes["client"], attributes["user"], attributes["progName"]);

  console.log("[js] my_stfc_structure input:", abap_input.IMPORTSTRUCT);

  

  // prepare response for ABAP client

  const echostruct = abap_input.IMPORTSTRUCT;

  echostruct.RFCINT1 = 2 * echostruct.RFCINT1;

  echostruct.RFCINT2 = 3 * echostruct.RFCINT2;

  echostruct.RFCINT4 = 4 * echostruct.RFCINT4;

  const abap_output = {

    ECHOSTRUCT: echostruct,

    RESPTEXT: `~~~ Node server here ~~~`,

  };

  console.log("[js] my_stfc_structure response:", abap_output);

  

  // return response data

  return abap_output;

}

Here is Node.js function call from ABAP client, from ABAP test report:

call function 'STFC_STRUCTURE' destination 'NWRFC_SERVER_OS'

  exporting

    importstruct          = ls_struct

  importing

    echostruct            = ls_struct

    resptext              = lv_resp

  tables

    rfctable              = lt_table

  exceptions

    communication_failure = 1 message lv_error_message

    system_failure        = 2 message lv_error_message.

To make this ABAP function call into Node.js work just like standard ABAP function call, following steps shall be done, covered in follow-up sections in detail

ABAP system: Configure RFC destination for node-rfc server

Node.js system: Configure node-rfc server connections to ABAP system

Node.js system: Create Node.js function to be called from ABAP and launch the server

ABAP system: Call Node.js function

Configure RFC destination for node-rfc server

Using transaction SM59 create RFC destination of type TCP/IP connection ("T"), like for example

RFC destination configuration - technical settings

If bgRFC protocol shall be supported by node-rfc server, configure the basXML serializer option here:

RFC destinatin configuration - bgRFC support

Configure node-rfc server connections for ABAP system

node-rfc server requires two RFC destinations for ABAP system, configured in sapnwrfc.ini file in Node.js system.

The first destination, "MME", is RFC client destination, the node-rfc can use to call ABAP functions. This client connection is used by node-rfc server to obtain ABAP STFC_STRUCTURE function definition, so that node-rfc server can automatically transform ABAP STFC_STRUCTURE call data to JavaScript and vice versa.

The second destination, "MME_GATEWAY", is RFC server destination, open after server is launched and used for listening on ABAP client requests.

sapnwrfc.ini

DEST=MME

USER=demo

PASSWD=welcome

ASHOST=system51

SYSNR=00

CLIENT=620

LANG=EN

TRACE=0



DEST=MME_GATEWAY

GWSERV=sapgw00

GWHOST=coevi51

PROGRAM_ID=RFCSERVER

REG_COUNT=1

Start node-rfc server

After SAP NW RFC SDK binaries are downloaded and installed on your Node.js system, you can create empty folder and install node-rfc

mkdir server

cd server

npm init -y

npm install node-rfc

Now the first server test can be done, to verify ABAP system connections. Create sapnwrfc.ini file in project root directory and create test script, like:

import {RfcLoggingLevel, Server} from "node-rfc";



// Create server instance, initially inactive

const server = new Server({

  serverConnection: { dest: "MME_GATEWAY" },

  clientConnection: { dest: "MME" },

  // Server options are optional

  serverOptions: {

    logLevel: RfcLoggingLevel.error,

    // authHandler: authHandler,

  },

});



(async () => {

  try {

    // Start the server

    await server.start();

    console.log(

      `[js] Server alive: ${server.alive} client handle: ${server.client_connection}`,

      `server handle: ${server.server_connection}`

    );

  } catch (ex) {

    // Catch errors, if any

    console.error(ex);

  }

})();



// Close the server after 10 seconds

let seconds = 10;



const tick = setInterval(() => {

  console.log("tick", --seconds);

  if (seconds <= 0) {

    server.stop(() => {

      clearInterval(tick);

      console.log("bye!");

    });

  }

}, 1000);

Now open again the NWRFC_SERVER_OS RFC destination using SM59 transaction and find "Connection Test" button

RFC destination - connection test

Start your test script in Node.js system and after server alive message press the "Connection Test" button. When RFC connection with ABAP system is working, the output looks like this:

RFC destination connection test output

Now when RFC connectivity is working let create Node.js function and call it from ABAP.

Create Node.js function to be called from ABAP and launch the server

Let add "my_stfc_structure" JavaScript server function, to receive ABAP calls of STFC_STRUCTURE function in Node.js system. Two additions are required in our test script, the server function implementation and registration.

Server function requires nothing special for node-rfc server, it shall implement only "plain" logic to calculate the response for ABAP client. Also promise can be returned.

The first parameter is request_context, just in case the function implementation shall consider it. The second parameter is JavaScript object with ABAP parameters, as defined by ABAP STFC_STRUCTURE function signature.

// Server function

function my_stfc_structure(request_context, abap_input) {

  const connection_attributes = request_context["connection_attributes"];

  console.log(

    "[js] my_stfc_structure context:",

    connection_attributes["sysId"],

    connection_attributes["client"],

    connection_attributes["user"],

    connection_attributes["progName"]

  );

  console.log("[js] my_stfc_structure input:", abap_input.IMPORTSTRUCT);

  const echostruct = abap_input.IMPORTSTRUCT;

  echostruct.RFCINT1 = 2 * echostruct.RFCINT1;

  echostruct.RFCINT2 = 3 * echostruct.RFCINT2;

  echostruct.RFCINT4 = 4 * echostruct.RFCINT4;

  const abap_output = {

    ECHOSTRUCT: echostruct,

    RESPTEXT: `~~~ Node server here ~~~`,

  };



  console.log("[js] my_stfc_structure response:", abap_output);

  return abap_output;

}

The server function is registered using node-rfc server "addFuncion" method, telling the server to route ABAP STFC_STRUCTURE function calls to JavaScript function "my_stfc_structure":

 server.addFunction("STFC_STRUCTURE", my_stfc_structure);

ABAP data transformations to/from JavaScript are done by node-rfc server automatically.

Our test script is now ready and the node-rfc server can be started, to serve ABAP client calls:

import { RfcLoggingLevel, Server } from "node-rfc";



// Create server instance, initially inactive

const server = new Server({

  serverConnection: { dest: "MME_GATEWAY" },

  clientConnection: { dest: "MME" },

  // Server options are optional

  serverOptions: {

    logLevel: RfcLoggingLevel.error,

    // authHandler: authHandler,

  },

});



// Server function

function my_stfc_structure(request_context, abap_input) {

  const connection_attributes = request_context["connection_attributes"];

  console.log(

    "[js] my_stfc_structure context:",

    connection_attributes["sysId"],

    connection_attributes["client"],

    connection_attributes["user"],

    connection_attributes["progName"]

  );

  console.log("[js] my_stfc_structure input:", abap_input.IMPORTSTRUCT);

  const echostruct = abap_input.IMPORTSTRUCT;

  echostruct.RFCINT1 = 2 * echostruct.RFCINT1;

  echostruct.RFCINT2 = 3 * echostruct.RFCINT2;

  echostruct.RFCINT4 = 4 * echostruct.RFCINT4;

  const abap_output = {

    ECHOSTRUCT: echostruct,

    RESPTEXT: `~~~ Node server here ~~~`,

  };



  console.log("[js] my_stfc_structure response:", abap_output);

  return abap_output;

}



(async () => {

  try {

    // Register server function

    server.addFunction("STFC_STRUCTURE", my_stfc_structure);

    console.log(

      `[js] Node.js function '${my_stfc_structure.name}'`,

      "registered as ABAP 'STFC_STRUCTURE' function"

    );

    // Start the server

    await server.start();

    console.log(

      `[js] Server alive: ${server.alive} client handle: ${server.client_connection}`,

      `server handle: ${server.server_connection}`

    );

  } catch (ex) {

    // Catch errors, if any

    console.error(ex);

  }

})();



// Close the server after 10 seconds

let seconds = 10;



const tick = setInterval(() => {

  console.log("tick", --seconds);

  if (seconds <= 0) {

    server.stop(() => {

      clearInterval(tick);

      console.log("bye!");

    });

  }

}, 1000);

When test script is started in Node.js system and ABAP test report calls STFC_STRUCTURE function in Node.js system, the test script output looks like:

ts-node ci/test/server-test.ts                                                                          (py3.11.4)  ✘ 1 main ◼

[js] Node.js function 'my_stfc_structure' registered as ABAP 'STFC_STRUCTURE' function

[js] Server alive: false client handle: 5554800128 server handle: 0

tick 9

tick 8

[js] my_stfc_structure context: MME 620 D037732 ZSERVER_STFC_STRUCT

[js] my_stfc_structure input: {

  RFCFLOAT: 0,

  RFCCHAR1: '',

  RFCINT2: 2,

  RFCINT1: 1,

  RFCCHAR4: '',

  RFCINT4: 4,

  RFCHEX3: <Buffer 00 00 00>,

  RFCCHAR2: '',

  RFCTIME: '000000',

  RFCDATE: '00000000',

  RFCDATA1: '',

  RFCDATA2: ''

}

[js] my_stfc_structure response: {

  ECHOSTRUCT: {

    RFCFLOAT: 0,

    RFCCHAR1: '',

    RFCINT2: 6,

    RFCINT1: 2,

    RFCCHAR4: '',

    RFCINT4: 16,

    RFCHEX3: <Buffer 00 00 00>,

    RFCCHAR2: '',

    RFCTIME: '000000',

    RFCDATE: '00000000',

    RFCDATA1: '',

    RFCDATA2: ''

  },

  RESPTEXT: '~~~ Node server here ~~~'

}

tick 7

tick 6

tick 5

^C

Calling Node.js function from ABAP

Here is ABAP test report for calling Node.js function, used in this example

*&---------------------------------------------------------------------*

*& Report ZSERVER_STFC_STRUCT

*&---------------------------------------------------------------------*

*&

*&---------------------------------------------------------------------*

report zserver_stfc_struct.



data lv_echo like sy-lisel.

data lv_resp like sy-lisel.



data ls_struct like  rfctest.

data lt_table like table of rfctest.



data lv_error_message type char512.



ls_struct-rfcint1 = 1.

ls_struct-rfcint2 = 2.

ls_struct-rfcint4 = 4.



insert ls_struct into table lt_table.

call function 'STFC_STRUCTURE' destination 'NWRFC_SERVER_OS'

  exporting

    importstruct          = ls_struct

  importing

    echostruct            = ls_struct

    resptext              = lv_resp

  tables

    rfctable              = lt_table

  exceptions

    communication_failure = 1 message lv_error_message

    system_failure        = 2 message lv_error_message.



if sy-subrc eq 0.

  write: / 'rfcint1:', ls_struct-rfcint1.

  write: / 'rfcint2:', ls_struct-rfcint2.

  write: / 'rfcint4:', ls_struct-rfcint4.

  write: / 'resptext:', lv_resp.

else.

  write:   'subrc  :', sy-subrc.

  write: / 'msgid  :', sy-msgid, sy-msgty, sy-msgno.

  write: / 'msgv1-4:', sy-msgv1, sy-msgv2, sy-msgv3, sy-msgv4.

  write: / 'message:', lv_error_message.

  exit.

endif.

When node-rfc server is running and this ABAP report started, the output looks like:

Node.js server call output

Error Handling

In case of error, the server function shall raise exception message and error message will be returned to ABAP, with RFC_EXTERNAL_FAILURE error code.

  throw new Error("my_stfc_function error");



  console.log("[js] my_stfc_structure response:", abap_output);

  return abap_output;

}

ABAP report output

ABAP test report - error

Logging

When activated, the log is saved in local file: _noderfc.log and above mentioned error looks like:

Error log

Enjoy calling Node.js function from ABAP 🙂

ABAP RFC connectivity from BTP Node.JS buildpack and Kyma

2023-10-26T16:14:54+02:00

ABAP RFC connectivity from BTP to ABAP systems is supported by SAP Cloud Connector, for Java runtime only. This blog describes the RFC connectivity configuration for BTP Node.JS runtime, so that Node.JS BTP applications can consume ABAP RFCs, as described in Deployment options section of Powerful web applications with old and new ABAP systems and related blogs.

Our "hello world" example is BTP Node.JS buildpack, with Express server, SAP/node-rfc and SAP NW RFC SDK.

The example source code: SAP-samples/node-rfc-samples//integration/noderfc_btp can be deployed on BTP or tested locally inside SAP/fundamental-tools/docker/btp_cflinuxfs4.Dockerfile docker container.

ABAP RFC connectivity from Node.JS on Kyma works practically out of the box, using SAP/node-rfc and SAP NW RFC SDK inside docker container. Try SAP/fundamental-tools/docker/cflinuxfs4.Dockerfile for example.

SAP NW RFC SDK on BTP

ABAP RFC connectivity from Node.JS is provided by SAP/node-rfc open source, which provides interface to SAP proprietary SAP NW RFC SDK

SAP NW RFC SDK

SAP NW RFC SDK is not included in SAP/node-rfc because of licensing and SAP Support Portal is the only allowed public distribution channel for SAP NW RFC SDK.

Shared SO libraries are required in runtime and must be registered at operating system level, using LD_LIBRARY_PATH env variable on Linux systems for example. Include files and shared libraries are both required for SAP/node-rfc build and re-build. The node-rfc rebuild can be triggered during BTP deployment, just like for other native Node.JS modules.

Express and SAP/node-rfc are standard NPM packages and BTP deployment is straightforward.

Preparation

We use this btp_cflinuxfs4 docker container and standard buildpack structure, with application in app folder. To make SAP NW RFC SDK available for SAP/node-rfc in cloud application, it shall be copied to app root folder for example:

Buildpack

During deployment, native NPM modules like node-rfc may be or must be rebuilt. The re-build process requires SAP NW RFC SDK includes and binaries and SAPNWRFC_HOME_CLOUD environment vaiable shell therefore point to SAP NW RFC SDK root folder, just like SAPNWRFC_HOME in on-premise case.

For run-time enablement, the LD_LIBRARY_PATH env variable shall point to RFC SDK "lib" folder, like in manifest.yaml:

---

applications:

  - name: rfcapp

    stack: cflinuxfs4

    env:

      SAPNWRFC_HOME_CLOUD: /tmp/app/nwrfcsdk

      LD_LIBRARY_PATH: /home/vcap/app/nwrfcsdk/lib

That's all, we are ready for testing.

Local test

$ cd buildpack/app

$ export SAPNWRFC_HOME=`pwd`/nwrfcsdk

$ export LD_LIBRARY_PATH=$SAPNWRFC_HOME/lib

$ npm install

$ node .



node .

HOME

/home/www-admin



SAPNWRFC_HOME

/home/www-admin/src/sap/node-rfc-samples/integration/noderfc_with_nwrfcsdk/buildpack/app/nwrfcsdk



SAPNWRFC_HOME files:

["include","lib","package.json"]



LD_LIBRARY_PATH





node-rfc

{

    "platform": {

        "name": "linux",

        "arch": "x64",

        "release": "6.4.16-linuxkit"

    },

    "env": {

        "SAPNWRFC_HOME": "/home/www-admin/src/sap/node-rfc-samples/integration/noderfc_with_nwrfcsdk/buildpack/app/nwrfcsdk",

        "RFC_INI": ""

    },

    "versions": {

        "node": "18.18.2",

        "acorn": "8.10.0",

        "ada": "2.6.0",

        "ares": "1.19.1",

        "brotli": "1.0.9",

        "cldr": "43.1",

        "icu": "73.2",

        "llhttp": "6.0.11",

        "modules": "108",

        "napi": "9",

        "nghttp2": "1.57.0",

        "nghttp3": "0.7.0",

        "ngtcp2": "0.8.1",

        "openssl": "3.0.10+quic",

        "simdutf": "3.2.14",

        "tz": "2023c",

        "undici": "5.26.3",

        "unicode": "15.0",

        "uv": "1.44.2",

        "uvwasi": "0.0.18",

        "v8": "10.2.154.26-node.26",

        "zlib": "1.2.13.1-motley"

    },

    "noderfc": {

        "version": "3.3.0",

        "nwrfcsdk": {

            "major": 7500,

            "minor": 0,

            "patchLevel": 12

        }

    }

}

BTP Deployment

When all works fine, let deploy

$ cd buildpack

$ cf push

Pushing app rfcapp to ...

Uploading files...

Instances starting....

Instances starting...



name:              rfcapp

requested state:   started

routes:            rfcapp.cfapps.eu10.hana.ondemand.com

last uploaded:     Thu 26 Oct 15:46:54 CEST 2023

stack:             cflinuxfs4

buildpacks:        

        name                                                       version   detect output   buildpack name

        https://github.com/cloudfoundry/nodejs-buildpack#v1.8.18   1.8.18    nodejs          nodejs



type:            web

sidecars:        

instances:       1/1

memory usage:    128M

start command:   npm run start:btp

     state     since                  cpu    memory          disk           logging            details

#0   running   2023-10-26T13:47:09Z   0.0%   54.9M of 128M   231.8M of 1G   0/s of unlimited

The app test route https://rfcapp.cfapps.eu10.hana.ondemand.com/ shows the same result as on premise test:

HOME /home/vcap/app SAPNWRFC_HOME /home/vcap/app/node_modules/nwrfcsdk

SAPNWRFC_HOME files: ["include","lib","package.json"]

LD_LIBRARY_PATH /home/vcap/app/node_modules/nwrfcsdk/lib

node-rfc { "platform": { "name": "linux", "arch": "x64", "release": "6.2.0-33-generic" }, "env": { "SAPNWRFC_HOME": "/home/vcap/app/node_modules/nwrfcsdk", "RFC_INI": "" }, "versions": { "node": "18.18.2", "acorn": "8.10.0", "ada": "2.6.0", "ares": "1.19.1", "brotli": "1.0.9", "cldr": "43.1", "icu": "73.2", "llhttp": "6.0.11", "modules": "108", "napi": "9", "nghttp2": "1.57.0", "nghttp3": "0.7.0", "ngtcp2": "0.8.1", "openssl": "3.0.10+quic", "simdutf": "3.2.14", "tz": "2023c", "undici": "5.26.3", "unicode": "15.0", "uv": "1.44.2", "uvwasi": "0.0.18", "v8": "10.2.154.26-node.26", "zlib": "1.2.13.1-motley" }, "noderfc": { "version": "3.3.0", "nwrfcsdk": { "major": 7500, "minor": 0, "patchLevel": 12 } } }

Connectivity

With RFC connectivity enabled in Node.JS on BTP, WS-RFC connection parameters and SAP Business Connector or Cloud Connector can be used for RFC connections to ABAP systems.

Securing external RFC connections, including certificate-based authentication

2023-12-07T09:18:50+01:00

In today's world of cyber-attacks and data leaks, security and encryption should be an absolute priority for any IT organisation. However, experience shows that this is not always the case. Mechanisms that bring security are still often seen as making work difficult and challenging to implement. The fact that a program was configured years before and there was never a problem is used as an excuse not to make changes. This is a very incorrect approach that can have serious consequences.

In this post, I will cover a topic perhaps quite niche for the SAP Basis administrator - securing connections from external non-SAP programs. An aspect that is often overlooked due to a gap in accountability. On the one hand, this is sometimes seen as outside the Basis scope. On the other hand, programs are sometimes configured by third party vendors not necessarily interested in the security of our system. I will try to show what we, as Basis administrators, can do to make the connection more secure.

Scope of consideration

In this post I will try to consider what mechanisms we can use to make an external connection secure. Of course, SNC/SSL-based encryption will be the focus as usual, but I will not limit myself to this technical aspect alone. As usual, I will also touch on topics that are on the borderline of responsibilities or even outside the typical scope of Basis, but important for understanding how the various mechanisms work.

I will discuss the topics of encryption, authentication using an SSL certificate, level of trust in a foreign CA, permissions, limiting network traffic. I will base my analysis on example programs from the SAP NetWeaver RFC SDK. I originally wanted to write my own simple program, but as Basis administrators we usually secure existing software and connections, so this is a more representative example.

Environment preparation

SAP server side

My test environment is ABAP Platform Trial 1909, based on S/4HANA 1909. The system is not the youngest, nor is it the oldest, but in the field of RFC connection security, not that much has changed over the years. So most of the insights will be valid for both older and younger systems.

The system has already been prepped for SNC and certificate-based authentication. I described this in my previous post "SAP-GUI Single Sign-On based on SSL certificates and SNC", so I won't repeat that part.

Client side

For the purpose of presenting the client program, I prepared a completely fresh Debian Linux system version 12. The rfcuser user was also created, in the context of which we will run the program that connects to the SAP server. Of course, you can use another Linux distribution as well, or even Windows, and the results will be similar.

SAP NetWeaver RFC SDK

SAP Note 2573790 describes where to get the library and briefly describes the installation process. I assume you can download it yourself from the Software Download Center, and I will describe the simplest installation method in a moment. I get two files, which I decompress in the rfcuser home directory.

rfcuser@sandboxn100:~$ unzip nwrfc750P_12-70002752.zip



Archive: nwrfc750P_12-70002752.zip



creating: nwrfcsdk/



creating: nwrfcsdk/bin/



inflating: nwrfcsdk/bin/rfcexec



inflating: nwrfcsdk/bin/startrfc

[...]

inflating: nwrfcsdk/lib/libsapnwrfc.so



inflating: nwrfcsdk/lib/libsapucum.so



inflating: SIGNATURE.SMF



rfcuser@sandboxn100:~$ unzip nwrfc750P12HF_2-70002752.zip



Archive: nwrfc750P12HF_2-70002752.zip



inflating: libsapnwrfc.so



rfcuser@sandboxn100:~$ mv libsapnwrfc.so nwrfcsdk/lib/

All files are located in nwrfcsdk folder. Next step is adding the folder to LD_LIBRARY_PATH environment variable. I can do this for current session, but to make this permanent, I add this to .profile file located in the user's home directory.

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/nwrfcsdk/lib

SAP user

I plan to establish a connection from an external program to my SAP system to perform some operations. It is easy to guess that I will need a user on the SAP system side to do this. So I'm creating an RFC user that the external program will use for operations on the system. I give it the top-secret password secure123, just for the purpose of this presentation, to keep things simple.

In addition to filling in basic user data, I set up the type to system or communication. In this case, it doesn't matter much. I leave the rest of the data default, including the lack of authorizations, because I'll come back to that in the next step.

The first, unsecured connection

Together with the SDK library, we get two sample programs - rfcexec and startrfc. Rfcexec connects to the SAP gateway and waits for incoming commands from the SAP system. I leave it for another occasion for now and will focus on startrfc.

The program connects to SAP and execute one of two function modules, related to EDI or display system information. In fact, I will focus on the last function today. The -i switch is responsible for calling it.

Let's call the program:

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -u rfcuser -p secure123 -c 001 -i

Error: No RFC authorization for function module RFCPING.

Sandbox is my SAP server hostname 00 is SAP instance number. 001 is a productive client.

Error is expected. In general connection is successful, because program reached checking authorization phase.

The principle of least privilege

Indisputably, the principle of least privilege is one of the most important elements of security and an absolute must when it comes to external connections. Keep in mind that a system is only as secure as its weakest component. Even if you secure your SAP system perfectly, an intrusion into a server independent of you that has rights to connect to SAP with a high level of privilege could result in data leakage or even damage to the system. So you should keep the level of RFC user privileges at the minimum level needed to operate. In fact, this should obviously apply to all users. However, for technical users, this rule is more often ignored for some reason. Do we trust programs more than people?

That's why I didn't give the RFCUSER any authorization at the beginning, and now I will build it from scratch. I check what the SU53 transaction reports for this user by selecting Authorization Values / Other User from the menu.

Apparently, the system first checked whether the user had access to the RFCPING function module. Since access was not explicitly granted, so the permissions for the entire SYST function group were also checked. Since I am very strict about permissions, I will build a role with minimal privileges in the PFCG tranaction.

I added this role to RFCUSER and repeated the connection test.

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -u rfcuser -p secure123 -c 001 -i

SAP System ID: A4H

SAP System Number: 00

Partner Host: vhcala4hci

Own Host: sandboxn100

Partner System Release: 754

Partner Kernel Release: 777

Own Release: 753

Partner Codepage: 4103

Own Codepage: 4103

User: RFCUSER

Client: 001

Language: E

This time the connection is fully successful and I get system information. Authorization is sufficient.

Certification authority

At this point it is worth saying a few words about how my system is configured. This is, in fact, already described in my previous post, but it doesn't do any harm to remind you of the basic information. The main certificate authority (OU=Security) signed the certificates of intermediate authorities - for servers (OU=Servers) and for users (OU=Users). The SAP server certificate was issued by the first one.

It's clear that the simplest solution would be to issue a certificate by an existing certification authority, but that would simplify our considerations a bit too much. Instead, I will assume that the certificate was issued by a completely independent group of certification authorities. So I will add three new to the existing ones, marked in blue in the diagram.

I won't focus on details, because you can go through this proces in my previous post, but let's go to the process of CAs creation and issuing RFCUSER's certificate. In practice, SAP administrators are usually not responsible for this part, so if you are not interested in issuing certificates, you can skip without hesitation to the next chapter.

Root CA key creation:

openssl genrsa -out AnotherRootCA/anotherca.key.pem 4096

Certificate generation:

openssl req -x509 -sha256 -new -nodes -key AnotherRootCA/anotherca.key.pem -days 3650 -out AnotherRootCA/anotherca.cert.pem

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:PL

State or Province Name (full name) [Some-State]:kuj-pom

Locality Name (eg, city) []:

Organization Name (eg, company) [Internet Widgits Pty Ltd]:AnotherCompany

Organizational Unit Name (eg, section) []:Trustworthy

Common Name (e.g. server FQDN or YOUR name) []:Another Root CA

Email Address []:

Intermediate CA key:

openssl genrsa -out intermediateAppsCA/interApps.key.pem 4096

Certificate signing request:

openssl req -key intermediateAppsCA/interApps.key.pem -new -sha256 -out intermediateAppsCA/interApps.csr.pem

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:PL

State or Province Name (full name) [Some-State]:kuj-pom

Locality Name (eg, city) []:

Organization Name (eg, company) [Internet Widgits Pty Ltd]:AnotherCompany

Organizational Unit Name (eg, section) []:Apps

Common Name (e.g. server FQDN or YOUR name) []:Intermediate Apps CA

Email Address []:



Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:*******

An optional company name []:

Certificate signature by the new root CA:

openssl x509 -req -in intermediateAppsCA/interApps.csr.pem -days 3650 -CA AnotherRootCA/anotherca.cert.pem -CAkey AnotherRootCA/anotherca.key.pem -CAcreateserial -out intermediateAppsCA/interApps.cert.pem

Certificate request self-signature ok

subject=C = PL, ST = kuj-pom, O = AnotherCompany, OU = Apps, CN = Intermediate Apps CA

RFCUSER key creation:

openssl genrsa -out intermediateAppsCA/rfcuser.key.pem 4096

Certificate signing request:

openssl req -key intermediateAppsCA/rfcuser.key.pem -new -sha256 -out intermediateAppsCA/rfcuser.csr.pem

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:PL

State or Province Name (full name) [Some-State]:kuj-pom

Locality Name (eg, city) []:

Organization Name (eg, company) [Internet Widgits Pty Ltd]:AnotherCompany

Organizational Unit Name (eg, section) []:

Common Name (e.g. server FQDN or YOUR name) []:RFCUSER

Email Address []:



Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:********

An optional company name []:

Client.cnf for client certificates:

nsCertType = client

extendedKeyUsage = clientAuth

Certificate signing:

openssl x509 -req -days 365 -in intermediateAppsCA/rfcuser.csr.pem -sha256 -CA intermediateAppsCA/interApps.cert.pem -CAkey intermediateAppsCA/interApps.key.pem -CAcreateserial -out intermediateAppsCA/rfcuser.crt.pem -extfile intermediateAppsCA/client.cnf

Certificate request self-signature ok

subject=C = PL, ST = kuj-pom, O = AnotherCompany, CN = RFCUSER

Export certificate to PKCS12 format:

openssl pkcs12 -export -inkey intermediateAppsCA/rfcuser.key.pem -in intermediateAppsCA/rfcuser.crt.pem -certfile AnotherRootCA/anotherca.cert.pem -certfile intermediateAppsCA/interApps.cert.pem -out rfcuser.p12

Enter Export Password:

Verifying - Enter Export Password:

exportpassword123

As a result I got several keys and certificates, including the most important rfcuser.p12 file, which contains user's private key and certificate with the trust chain. The file is protected with exportpassword123 password. In real life scenarion this file you'll receive from your certification team.

Enforcing RFC encryption on system level

Ok, I know that forcing encrypted connections is not necessary for my connection to be encrypted. However, I will do it to show if the encryption works or not. Nevertheless, if you are ready to disable unsafe connections, I highly recommend making it permanent. In my case, the snc/only_encrypted_rfc parameter is sufficient, but you might consider setting a few others as well, such as snc/accept_insecure_cpic, snc/accept_insecure_gui, snc/accept_insecure_rfc, snc/only_encrypted_gui.

I can set the parameter to 1, which enforces encryprion for non-ABAP RFC connections. Higher levels enforces encryption for ABAP and intenal connections.

snc/only_encrypted_rfc = 1

Now the call should be rejected by the system.

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -u rfcuser -p secure123 -c 001 -t 3 -i

Error: Unencrypted communication is rejected by this system

It is no longer possible to establish an unencrypted connection.

SAP Cryptographic Library installation

To enable RFC connection encryption, it is necessary to install a cryptographic library. On SAP systems it is included along with the kernel, while here it must be installed separately. I go to the SAP Marketplace to see what the latest version is and download it. In addition, I need to get the SAPCAR program to decompress the archive. So in the end I choose 2 files and save them in a new cryptolib folder.

SAPCRYPTOLIBP_8553-20011697.SAR

SAPCAR_1200-70007716.EXE

It's time to unpack the library:

rfcuser@sandboxn100:~/cryptolib$ ./SAPCAR_1200-70007716.EXE -xf SAPCRYPTOLIBP_8553-20011697.SAR

SAPCAR: processing archive SAPCRYPTOLIBP_8553-20011697.SAR (version 2.01)

SAPCAR: 6 file(s) extracted

SAPCAR and the archive can be removed after extraction. Let's also start sapgenpse component to check if everything is fine.

rfcuser@sandboxn100:~/cryptolib$ ./sapgenpse | tail -10

Versions: SAPGENPSE 8.5.53 (Sep 22 2023)

CommonCryptoLib 8.5.53 (Sep 22 2023) [AES-NI,CLMUL,SSE3,SSSE3]

Build change list: 248172



USER="rfcuser"



Environment variable $SECUDIR is not defined!

Fallback selection of SECUDIR through HOME:

"/home/rfcuser/sec"

It would be good to set SECUDIR variable explicitly and add cryptolib folder to LD_LIBRARY_PATH variable. Let's edit .profile of the user.

rfcuser@sandboxn100:~$ cat .profile

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/nwrfcsdk/lib:~/secudir

export SECUDIR=/home/rfcuser/sec

Client PSE preparation

In the previous sections, I generated an SSL certificate for the RFCUSER. It was saved in the file rfcuser.p12. Even if you don't generate the certificates yourself, you will probably get a ready one from the certification authority in this format. In the SAP world we rather operate on PSE repositories, so with the help of sapgenpse I will convert PKCS#12 to PSE. I will perform all operations in the rfcuser user sec folder.

I prepared files, including certification authorities' certificates:

rfcuser@sandboxn100:~/sec$ ls -l

total 24

-rw-r--r-- 1 rfcuser rfcuser 2033 Nov 30 18:28 anotherca.cert.pem

-rw-r--r-- 1 rfcuser rfcuser 1911 Nov 30 18:29 interApps.cert.pem

-rw------- 1 rfcuser rfcuser 5875 Nov 30 18:28 rfcuser.p12

Let's import the p12 file into new repository and protect it with MyVerySecretPIN_1 secret PIN.

rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse import_p12 -x MyVerySecretPIN_1 -p SAPSNCS.pse -r anotherca.cert.pem -r interApps.cert.pem rfcuser.p12

Please enter PKCS#12 encryption password: *****************

Found key 'INDEX=0,SIG=YES,ENC=YES,MD5-FINGERPRINT=60A1 B7F2 4F30 C198 9457 D2C3 5FA4 7F8E,KEYID=57F11B35BBC963B83B3B65F2666726003D11A46F'

PSE "/home/rfcuser/sec/SAPSNCS.pse" was written

The PIN we can encrypt in cred_v2 file, which is kind of passwords repository. Later this can be used by tools to access the PSE file. I also update file permissions to more strict.

rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse seclogin -x MyVerySecretPIN_1 -p SAPSNCS.pse

running seclogin with USER="rfcuser"

Added SSO-credentials for PSE "/home/rfcuser/sec/SAPSNCS.pse"

rfcuser@sandboxn100:~/sec$ chmod go-rwx cred_v2

Finally I have below files with PSE and cred_v2.

rfcuser@sandboxn100:~/sec$ ls -l

total 28

-rw-r--r-- 1 rfcuser rfcuser 2033 Nov 30 18:28 anotherca.cert.pem

-rw------- 1 rfcuser rfcuser 114 Nov 30 18:37 cred_v2

-rw-r--r-- 1 rfcuser rfcuser 1911 Nov 30 18:29 interApps.cert.pem

-rw------- 1 rfcuser rfcuser 5875 Nov 30 18:28 rfcuser.p12

-rw------- 1 rfcuser rfcuser 5111 Nov 30 18:36 SAPSNCS.pse

Let's check what was saved in the PSE. I can see main certificate, signing CA and validity dates.

rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse get_my_name -p SAPSNCS.pse

SSO for USER "rfcuser"

with PSE file "/home/rfcuser/sec/SAPSNCS.pse"



Subject : CN=RFCUSER, O=AnotherCompany, SP=kuj-pom, C=PL

Issuer : CN=Intermediate Apps CA, OU=Apps, O=AnotherCompany, SP=kuj-pom, C=PL

Serialno : 72:7B:01:77:64:B6:60:0B:31:D7:6C:60:66:0A:B2:7E:AB:FD:77:B1

KeyInfo : RSA, 4096-bit

Validity - NotBefore: Thu Nov 30 17:54:25 2023 (231130165425Z)

NotAfter : Fri Nov 29 17:54:25 2024 (241129165425Z)

KeyUsage : none

ExtKeyUsage : ClientAuthentication

SubjectAltName : none

I can also confirm, that the trust list of the PSE is empty.

rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -p SAPSNCS.pse -l

maintain_pk for PSE "/home/rfcuser/sec/SAPSNCS.pse"

PKList is empty.



Empty trusted list.

SAP user update

The next step is to prepare the RFCUSER user for SSO authentication. To do this, I update the SNC name field in the SNC tab in the SU01 transaction. At the same time, I can disable the option of logging in with a password.

sapnwrfc.ini

The sapnwrfc.ini file allows to configure connection parameters for RFC calls made with the SDK library. You can define parameters there, such as the details of the system you are connecting to, the method of authentication, or encryption. Of course, you can specify a username and password there, but I will be configuring a certificate-based SSO. So I create the sapnwrfc.ini file in the same directory as the startrfc program:

rfcuser@sandboxn100:~/nwrfcsdk/bin$ cat sapnwrfc.ini

DEST=a4htest

SNC_LIB=/home/rfcuser/cryptolib/libsapcrypto.so

SNC_MYNAME=p:CN=RFCUSER, O=AnotherCompany, SP=kuj-pom, C=PL

SNC_PARTNERNAME=p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL

SNC_QOP=9

For readability, the file contains a minimum set of parameters. DEST defines the name of the connection, which must be referred to by the program making the connection. SNC_LIB defines which cryptographic library to use. SNC_MYNAME specifies the SNC name of the client. SNC_PARTNERNAME gives the SNC name of the SAP server to which we are connecting. SNC_QOP defines the scope of the SNC, where 9 defines the maximum available security level.

I can return to startrfc program and update required parameters. The most important one is -D, which defines connection name, consistent with sapnwrfc.ini definition.

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i

You might notice that the parameters responsible for the username, password and client number have been removed. They are not required if the SNC string is unique, that is, only one user on one client in a given system has this specific SNC name assigned to it.

The connection name is essential when you are securing a application that you are not the author of. The most important thing is to find in the documentation or configuration options how to determine this parameter or how to define it. Once you know this you will most likely be able to enable secure connection and encryption, even if the documentation from the vendor does not mention anything about such feature.

Trust relationship

Ok, let's start the program to see what else is missing:

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i

[Thr 139683030722496] Thu Nov 30 18:50:59:304 2023

[Thr 139683030722496] *** ERROR => SncPEstablishContext() failed for target='p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL' [/bas/753_R 3638]

Error:

LOCATION CPIC (TCP/IP) with Unicode

ERROR GSS-API(maj): Miscellaneous failure

GSS-API(min): A2210223:Server does not trust my certificate

path

target="p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany,

C=PL"

TIME Thu Nov 30 18:50:59 2023

RELEASE 753

COMPONENT SNC (Secure Network Communication)

VERSION 6

RC -4

MODULE /bas/753_REL/src/krn/snc/sncxxall.c

LINE 3604

DETAIL SncPEstablishContext

SYSTEM CALL gss_i

The error message is clear - SAP server does not trust my certificate chain. What does it mean?

The situation is as follows - the client approaches the server with a certificate, which perhaps even matches the SNC name of some user in the system. But after all, such certificate can be issued by anyone and any subject can be defined. Therefore, it is very important that the certificate is known and accepted by the server. This can be a trust relationship defined directly - by adding this particular certificate to the list. However, it can also be defined at a higher level - by trusting the certification authority.

It is the administrator's decision, or more often security policies, at which level we establish the trust relationship. It is very convenient to add a specific CA to the trusted list and this is often the right way to go. However, be aware that this also has consequences. The organisation that issues the certificates receives the authority to authenticate users on our system.

When we are unable to trust the certificate authority, we are required to add the leaf certificate to the list. This usually brings with it quite an inconvenience - the need to renew each certificate as it approaches its expiration date. This requires coordination with the client and, with a larger number of certificates, can be very inconvenient, especially as end certificates usually have an expiry date of one year.

As I have full control over my certificate authorities, so I add Another Root CA to my trusted list in transaction STRUST.

Let's retry the connection.

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i

[Thr 139834091542464] Thu Nov 30 18:58:31:277 2023

[Thr 139834091542464] *** ERROR => SncPEstablishContext() failed for target='p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany, C=PL' [/bas/753_R 3638]

Error:

LOCATION CPIC (TCP/IP) with Unicode

ERROR GSS-API(maj): Miscellaneous failure

GSS-API(min): A2200223:Peer certificate path not trusted

target="p:CN=sandbox.mydomain.internal, OU=IT, O=MyCompany,

C=PL"

TIME Thu Nov 30 18:58:31 2023

RELEASE 753

COMPONENT SNC (Secure Network Communication)

VERSION 6

RC -4

MODULE /bas/753_REL/src/krn/snc/sncxxall.c

LINE 3604

DETAIL SncPEstablishContext

SYSTEM CALL gss_init_sec_context

There is still an error, but different one. This is also related to trust, but in opposite direction. Now client doesn't trust server. I need to add SAP system certificate or better it's CA to the client's trusted list. Let's go to SECUDIR and add it to PSE.

rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -a ca.cert.pem

Please enter PSE PIN/Passphrase: *****************

maintain_pk for PSE "/home/rfcuser/sec/SAPSNCS.pse"

----------------------------------------------------------------------------

Subject : OU=Security, O=MyCompany, SP=kuj-pom, C=PL



PKList updated (1 entries total, 1 newly added)



rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -a interServers.cert.pem

Please enter PSE PIN/Passphrase: *****************

maintain_pk for PSE "/home/rfcuser/sec/SAPSNCS.pse"

----------------------------------------------------------------------------

Subject : OU=Servers, O=MyCompany, SP=kuj-pom, C=PL



PKList updated (2 entries total, 1 newly added)

I have to know PSE password to modify it.

You can always your trusted list with below command:

rfcuser@sandboxn100:~/sec$ ../cryptolib/sapgenpse maintain_pk -l

Now I can test the connection once more.

rfcuser@sandboxn100:~/nwrfcsdk/bin$ ./startrfc -h sandbox -s 00 -D a4htest -i

SAP System ID: A4H

SAP System Number: 00

Partner Host: vhcala4hci

Own Host: sandboxn100

Partner System Release: 754

Partner Kernel Release: 777

Own Release: 753

Partner Codepage: 4103

Own Codepage: 4103

User: RFCUSER

Client: 001

Language: E

Success. Connection is possible with SSL based authentication. Encryption is obviously enabled.

Firewall

When we consider how to secure RFC connections, it is impossible to ignore the question of the firewall. It is obvious that also at the network level, we should only allow traffic from addresses that are allowed to communicate with our server. One question to ask is which ports are needed. There are two ports that are used by the Gateway, which is responsible for RFC communication - 33<NN>/tcp and 48<NN>/tcp. NN is instance number, in my case 00. 3300/tcp is used for unencrypted communication, while 4800/tcp is the secure gateway, where communication is encrypted. In my case, after configuring a secure connection, only 4800/tcp is needed.

However, there is one more port to be considered. It is opened by the message server, which is part of the ASCS instance, that in my case is number 01. So I would also consider opening port 3601/tcp on the firewall to allow load balancing using login groups.

UCON

The final option I wanted to recommend to make RFC connections more secure is Unified Connectivity (UCON). This is a mechanism that provides the ability to define a list of allowed remote function modules. This is related to the idea of reducing the attack surface. It is clear that systems only use a very small proportion of functional modules. As the software may contain security vulnerabilities and somewhere in the system someone may have set too broad permissions, it is worth implementing protection at a higher level. UCON introduces an extra layer of protection - even before the user's permissions are checked, it is verified whether the call is on the allowed list. However, UCON is a rather broad topic for a separate article.

Conclusion

RFC connections from external non-ABAP programmes can be secured on very many levels. Security should be a priority these days and unencrypted connections forbidden by any security policy. Although we often have less control over external programs, as you can see, quite a lot can be done in this area too.

Handling RFC in SAP Build - Process Automation

2023-12-28T12:34:38+01:00

Introduction

Hello,

I will be showing you How to handle RFC in SAP Build - Process Automation .

Scenario

We will be using a RFC to get data that we need in our automation.

Prerequisites:

Basic Knowledge about RFC

Basic knowledge about SAP Build

Basic knowledge about SAP Process Automation.

Step-by-Step Procedure:

Creating the RFC .

Creating the Process Automation project.

Consuming RFC in our project

STEP 1 : Creating RFC

Firstly we need to create our RFC according to our needs. Go to ' SE37 ' transaction and create your RFC. Do not forget to select Remote-Enabled Module processing type.

Image 1 - RFC Attributes

In my case, what I needed was the mail addresses of customer numbers I already had. So created my RFC to get mail addresses using company codes and customer numbers. You should set your parameters according to your needs.
You can see my parameters below.

Image 2 - Import Parameters

Image 3 - Tables Parameters

Image 4 - T_CUSTOMER Components

In my coding part I am finding mail addresses using the customer numbers and company code provided in T_CUSTOMER and filling ' MAIL ' component according to ' IV_ CHECK ' import parameter.

STEP 2 : Creating Process Automation Project

Now we are going to create our project.

Go to SAP Build cockpit and click create.

Image 5 - SAP Build Create Project

After that click ' Build an Automated Process ' and ' Task Automation ' . Give your project a name and configure your agent and we are all set.

STEP 3 : Consuming RFC in Project

Firstly we need to add BAPI SDK to our project. To do that go to settings and then Dependencies section. After that click Add Dependency and search for BAPI SDK.

Image 6 - Add Dependency

Now we need to create our Data Types based on our RFC parameters. The important part here is that Data Types must be created as structures, for my case I will be creating two Data Types , one for Import Parameters of my RFC and one for Tables Parameters.

Go to your Project Content and click Create then click Data Type. After that give it a proper name and lets set the Data Type.

Image 7 - Creating Data Types

Create your Data Types based on your RFC parameters. Here are my Data Types

Image 8 - Data Types

Now we can call our RFC from our project. Lets start building our project. You can see the general overview of project, I will be explaining each step.

Image 9 - Overview of Project

Firstly we need to establish our connection to SAP server where RFC exist. For that we are using Set SAP Connection (Basic) activity and filling it as needed.

Image 10 - Set SAP Connection (Basic)

To be sure whether we were able to connect to SAP system or not we are using Is SAP Connection Alive activity.

Image 11 - Is SAP Connection Alive

For next step we are creating our variable using the Data Types that we created.

Image 12 - Creating the RFC Import Variable

Image 13 - Creating the RFC Tables Variable

Now that we created our variables , we are going to fill these variables. Firstly we are checking if the SAP Connection is alive or not after that we are filling our variables as we need.

Image 14 - Filling Variables

Now we can execute our RFC and get the desired data. To call our RFC we are using Execute BAPI activity. And to reach our desired data we are using output parameter of Execute BAPI in a Custom Script activity as you can see below.

Image 15 - Execute RFC

Image 16 - Desired Data From RFC

Here is our mail addresses corresponding to customer numbers and company codes.

Conclusion

If you read the blog well congratulations ! You learned How to create a new project in SAP Build, How to create custom Data Types in a SAP Process Automation, How to consume a RFC in SAP Process Automation and much more.

If this blog is a help to you please like and share 🙂

Also Please do not hesitate to ask any further questions and feel free to share your feedback on the content.

Thank you!

- Metehan Dülger

Created a program to fetch customer details from AS400 system to SAP S4HANA via RFC FM

2024-02-28T13:31:37.538000+01:00

Creating a program to fetch customer details from an AS400 system to SAP S/4HANA via RFC (Remote Function Call) involves several steps. Below is a simplified example to illustrate the process. Note that you need the appropriate authorization and system connectivity settings for RFC communication.

Using Transaction SM59:

Log in to SAP GUI:
- Log in to the SAP GUI using the appropriate credentials.
Open Transaction SM59:
- Enter transaction code SM59 in the command field and press Enter.
Choose RFC Connection:
- In the SM59 screen, navigate to the "RFC Connections" folder in the left-hand tree structure.
Create RFC Destination:
- Right-click on the "RFC Connections" folder, choose "Create," and select the appropriate connection type (for example, "TCP/IP Connections" for remote systems).
Enter Connection Details:
- Fill in the required details for the RFC destination, including the connection type, the target system's IP address or hostname, and the system number.
Configure Logon & Security:
- Configure the logon and security settings. This might include specifying the user credentials that will be used for communication.
Additional Parameters:
- Depending on your scenario, you may need to configure additional parameters, such as language, code page, or other connection-specific settings.
Test Connection:
- Before saving the RFC destination, you can use the "Connection Test" button to check if the connection to the target system is successful.
Save the RFC Destination:
- Once the connection test is successful, save the RFC destination.
Activate and register the RFC Destination:
- After saving the destination, you may need to activate and register it. The activation ensures that the settings take effect.
Use the RFC Destination in ABAP Programs:
- You can use the created RFC destination in ABAP programs by calling the remote function modules defined in the target system.
  Create RFC-Enabled Function Module in SAP S/4HANA:
  - Create an RFC-enabled function module in SAP S/4HANA that will call the RFC function module in the AS400 system. This function module should take any necessary parameters, call the RFC function module in the AS400 system, and return the customer details.

FUNCTION zhr_fm_knb1_fico.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(IM_KUNNR) TYPE  ZHR_TTY_KNB1 OPTIONAL
*"  EXPORTING
*"     VALUE(GT_KNB2) TYPE  ZHR_TT_KNB1
*"     VALUE(EP_MSG) TYPE  STRING
*"  TABLES
*"      GT_KNB1 STRUCTURE  KNB1
*"----------------------------------------------------------------------

  IF  im_kunnr  IS NOT INITIAL.

    SELECT  FROM knb1 FIELDS kunnr,
                            bukrs,
                            erdat,
                            ernam
                             WHERE kunnr in _KUNNR INTO CORRESPONDING FIELDS OF TABLE  _knb2 .

    IF  gt_knb1 IS INITIAL.
      ep_msg = 'No record found'.

    ENDIF.



  ENDIF.


ENDFUNCTION.

Creating a report program in SAP S/4HANA using the ABAP Editor (SE38) involves defining a report using the Report statement, fetching data from the database, and displaying the results. Below is a simple example of a report program that retrieves and displays data from knb1 table.

*&---------------------------------------------------------------------*
*& Report ZHR_RP_FM
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT ZHR_RP_FM.

DATA: lv_kunnr TYPE kunnr.
*
SELECT-OPTIONS: s_kunnr FOR lv_kunnr.

  DATA: lt_range type RANGE OF kunnr.
     lt_range = VALUE #( sign = 'I' option = 'BT'
                       ( low = s_kunnr-low )
                       ( high = s_kunnr-high )
                     ).

DATA: lt_knb1 TYPE TABLE OF knb1,
      gt_knb1 TYPE TABLE of knb1,
*      gs_knb1 TYPE knb1,
      lv_msg TYPE string.


START-OF-SELECTION.

*
CALL FUNCTION 'ZHR_FM_KNB1_FICO' DESTINATION 'zhr_a4hana_to_s4hana'
  EXPORTING
    im_kunnr       = lt_range
 IMPORTING
   GT_KNB2        =  gt_knb1               "gs_knb1
   EP_MSG         = lv_msg
  tables
    gt_knb1        = lt_knb1
          .
IF sy-subrc <> 0.
* Implement suitable error handling here
ENDIF.


IF  gt_knb1[] is NOT INITIAL.
  cl_demo_output=>display( gt_knb1 ).          

ENDIF.

output:

give the input and click on execute button.

provide your user-id for s4hana along with password and click on enter.

it will display the desired output.

Create trusted RFC with specific technical user

2024-05-08T17:46:41.940000+02:00

As the SAP Basis administrator, we know that we can establish the trusted RFC between ABAP systems in which we can connect to the target system with our current user without providing the credentials like in screenshot below.

But what if we want to use a specific technical user and still want to benefit from trusted RFC? Actually, we can do it with the same method and I will show you how in this blog post.

First of all, since we need to create the trusted RFC, we need to establish the trusted relationship between systems through transaction code SMT1. In the scope of this blog, I’ll assume that we need to define the trust between system AA and BB.

1. Go to SMT1 Tcode on AA, and click the “Create” button to start the process.

2. Click “Continue”.

3. On the next screen, we need to provide the information about the target server and login information. It'll create a new RFC on the target server called "TRUSTING@<SID>xxxxxxxx".

4. On the following screens, just click on “Continue” and “Finish” on the final screen.

5. Now, it’s finished on the first system AA and you need to do the same steps on the second system BB.

Next, we need to make sure that the technical user on the source system has enough authorizations to allow the trusted call from the source system.

For that purpose, the user role needs to have the authorization object S_RFCACL. Below is the description of its field.

ACTVT: always 16. It’s the only value we can specify.
RFC_CLIENT: In this field, we can specify which client we allow to make the trusted connection. For example: the AA system has 3 clients 001, 002, and 003, but if we want to grant the trusted connection from client 002 only, then we need to specify here the value 002. The connection from clients 001 and 003 will be rejected.
RFC_EQUSER: This is the important field for making trusted RFCs with another user. In this case, we want to connect with a specific technical user, therefore we set it to value “N”.
RFC_INFO: the installation number of the calling system. We can set it to ‘*’, then the role can be used by multiple source systems, or you can specify here the list of installation numbers that allow you to create a trusted connection.
RFC_SYSID: SID of the calling system.
RFC_TCODE: Calling transaction code.
RFC_USER: ID of the calling user.
After finishing the role creation, please make sure that the role will be assigned to the technical user on the called system.
We have come to the final step. For details on creating the RFC in SM59, please refer to the SAP help documentation. In this blog, I’ll focus only on trusted RFC settings.
After specifying the target hostname and SID, go to the Logon & Security tab and set the Trust Relationship to “Yes”.
Now, instead of setting the checkbox at “Current User”, we will leave it blank and give the information about the technical user from the called system. Of course, the password is no longer necessary because we’re creating a trusted connection.

Save the connection and execute “Authorization Check”.

At this point, if you log in to the called system and go to TCode SM59. Then you will see the connection from the calling system but from that technical user, not ours.

I hope that blog will find you well. If you have any questions or concerns so far, feel free to contact me.