SAP Automation Across all SAP Technical Interfaces and Beyond

SAP offers, besides UIs, as well technical interfaces which we can use for automation purposes. This is a consideration parallel to the UIs here.
Here is a tiny overview of the technical interfaces of SAP:

RFC (Remote Function Call)
Technical communication between SAP systems and between SAP systems and non-SAP systems. RFC means a function call which is executed in a remote system. It exists different variants of RFCs:

  1. Synchronous RFC (sRFC): Calls a module and waits for results.
  2. Asynchronous RFC (aRFC): To parallelize tasks, only for ABAP reports. Calls a module and don’t waits for results.
  3. Transactional RFC (tRFC): To parallelize tasks, caller gets a transaction ID (TID) to monitor execution. Calls a module and don’t waits for results.
  4. Queued RFC (qRFC): Serialized tRFC with in- and outbound queues.
  5. Background RFC (bgRFC): Successor of tRFC and qRFC

All types of RFC are transferred their data by CPI-C or TCP/IP.

BAPI (Business Application Programming Interface)
Standardized programming interface of implemented RFC-enabled Function Modules (RFM). BAPIs must be defined in the Business Object Repository (BOR, TAC SWO1) to see it in the TAC BAPI. BAPIs have the following requirements:

  1. Stable interface
  2. No presentation layer
  3. No exceptions
  4. Database updating via update function module

IDoc (Intermediate Document) via ALE (Application Link Enabling)
Transfering of message information between SAP systems. ALE provides the services and tools to send the messages. IDoc defines a structure of a document in segments with the format of data fields and their size, in which the data will be contains. The ALE forwards the IDoc to the target system and in a normal case the RFM is called.

SOAP (Simple Object Access Protocol)
SOAP is an HTTP protocol for exchanging XML messages.

REST (Representational State Transfer) with OData (Open Data Protocol)
REST services provides a uniform interface using standard HTTP operations, such as GET, POST, PUT, DELETE, PATCH and exchange information e.g. in JSON or XML formats. OData is a protocol to use RESTful APIs and to realize CRUD (Create, Read, Update and Delete) operations easily.

The question is now, how can we handle the different types of SAP technical interfaces with UiPath Studio?
First of all, UiPath Studio can handle all this interfaces.

  1. RFC: Here it is necessary to leave the non-code area and to use Invoke Code activity. To handle RFMs we use SAP dotNET Connector, which I described here. A conceivable scenario would be the development of a module by an RPA developer. This can then be easily used in the context of workflows.
  2. BAPI: UiPath offers its own great activity for this.
  3. IDoc and ALE: Here you can use the same as RFC.
  4. SOAP: UiPath offers its own SOAP activity for this
  5. REST and OData: UiPath offers its own HTTP activity for this

As you can see, UiPath Studio can handle all technical interfaces of an SAP system.
So far I have used RFC, BAPI and REST with OData and everything worked perfectly.


Hello Stefan,

What is the difference in terme of implementation effort between classic SAP automation and Using SAP BAPI, can we quantify the charge in terme of developpement for both methodologie for one process ?

Will be discussed here Developpement Charge when using SAP Gui activities Vs SAP BAPI activities

no need to duplicate the post :slight_smile:

1 Like