WebSocket RFC to Cloud Using SAP Business Connector

[Ulrich_Schmidt]

1 Introduction

The following tutorial describes an easy way of setting up RFC connectivity between an on-premise ABAP system (for example SAP ECC, SAP Web AS or an older SAP S/4HANA (on premise) prior to version 1909) and a cloud-based ABAP system (like SAP S/4HANA Cloud or Steampunk). A condensed form of this blog is also available as a tutorial:

WebSocket RFC to Cloud Using SAP Business Connector

If you are already familiar with the involved technologies and components and only want a few quick How-To steps for setting up this scenario, you may want to switch to the above tutorial. However, if you want more detailed instructions and background information, read on.

Note that in many situations it may not be necessary to perform all the steps described in the following. E.g., most of the steps described in chapter 3 are necessary only if you do your own ABAP development on the SAP S/4HANA Cloud system. If you just want to call a couple of existing BAPIs, most of these steps should already have been taken care of, and then you mainly need to perform the setup of the Business Connector (chapter 4), skipping the setup of the SAP S/4HANA Cloud system (chapter 3).

 

WebSocket RFC is a variant of the well-known RFC protocol that can easily be tunneled via HTTP proxies and over the internet. It is therefore much better suited for connecting on-premise systems with cloud-based systems than the classic RFC protocol. For more details about WebSocket RFC see the following blog:

WebSocket RFC – RFC For the Internet

Technically the connection works as follows:

• The on-premise ABAP system makes an RFC request against an RFC destination of type T.


• At this RFC destination, an SAP Business Connector (SAP BC) is registered. It receives the request, transforms it into a WebSocket/https-based request and forwards that to the cloud-based ABAP system – if necessary, via an HTTP Proxy in your firewall.


• The cloud-based ABAP system processes the request and returns the response back to the SAP BC.


• The SAP BC transforms the response back to classic RFC protocol and returns it to the originating on-premise system.

So basically, the SAP BC acts as a "transformer" between the classic CPIC-based RFC protocol and the WebSocket-based RFC protocol that can be tunneled through firewalls into the Cloud without problems.

Note that if the on-premise ABAP System is an SAP S/4HANA version 1909 or newer, this setup can be simplified considerably: in this case, the underlying ABAP platform is already able to perform WebSocket RFC calls without any additional component, and the setup can look like this:

In this case, you only need the steps described in chapter 3, if not yet done, and an RFC destination of type W in the source system. The "Communication User" from section 3.1 is then used directly in the type W destination instead of in the SAP BC.

 

2 Setting up the Source System

In the source system (SAP ABAP system in the on-premise network), you only need to setup an RFC destination of type T and allow the Business Connector host to register at this destination. The source system will later send all RFC calls and IDocs, which are intended for the SAP S/4HANA Cloud system, to this RFC destination.

2.1 Set up an RFC Destination of Type T

This can be done in transaction SM59. Please fill the destination parameters as follows:

• Destination: a name that describes the final target system. For example, if the target is an SAP S/4HANA Cloud system named “ABC” with client 100, you could name the destination "ABC_100_VIA_BC".


• Connection Type: T


• Description: any further details you want to document for this destination


• Activation Type: Registered server program


• Program ID: can be any arbitrary string that uniquely identifies your Business Connector. However, if the ID resembles the final target system, like the destination name above, it will make the routing settings in the SAP BC much easier/clearer, especially if you have multiple source and/or target systems that will all be routed through the same SAP BC. So if you name the Program ID also something like ABC_100_VIA_BC, it will always be immediately visible, which calls are intended for which target system.


• Gateway Host: hostname of one of the application servers of the on-premise system, which still has some free capacity. For example, the message server.


• Gateway Service: this should be sapgwXX, where XX is the instance number of the on-premise system.

After you have filled out the fields in the tab "Technical Settings" as above, switch to the "Unicode" tab and make sure that here "Unicode" is selected. (In older releases, the default when creating a new destination is still "Non-Unicode").

Finally, save the destination. This destination can later be used in all places where you want to send an RFC call or an IDoc to the Cloud system, e.g., in CALL FUNCTION statements in ABAP reports or in ALE/EDI Port definitions for IDoc routing (transaction WE21).

Note that RFC destinations of type T are available in any SAP system, so basically this way any system of type SAP R/3, SAP Web AS, ECC or SAP S/4HANA (on premise) will be able to communicate with the Cloud.

2.2 Allow SAP BC to Register at the RFC Destination

This step can in most cases be skipped. E.g., if there is already a line like
TP=* HOST=*
in the reginfo settings, you can skip this step. Only if the security settings of your CPIC/RFC gateway are very strict, you need to explicitly allow registrations from the hostname, where SAP Business Connector will be running, at this RFC destination. This is performed in transaction "SMGW --> Goto --> Expert Functions --> External Security --> Maintain ACL Files".

Select the tab “Reginfo File”, add a new line of type “Standard” and fill in the values as follows:

Afterwards choose "Goto --> Reread (Global)" from the dropdown menu.

If the above menu entry "Maintain ACL files" does not exist in your system, the release of this system is too old. In that case you need to edit the reginfo file on filesystem level with a text editor and afterwards reload it from SMGW.

The format of the reginfo file is described in detail in SAP Library - BC SAP Gateway

 

3 Setting up the Target System

If the Business Connector is to execute function modules in the Cloud system, four prerequisites need to be fulfilled:

• We need to know hostname and port, where we can connect to.


• We need user credentials for logging in.


• The system needs to define a list of the function modules we want to call.


• Ensure that the SAP S/4HANA system allows our user to execute these function modules.

As hostname, you have to use the api-host of your SAP S/4HANA Cloud system, which is something like
mysystem-api.s4hana.ondemand.com
The port number is usually 443. Keep these values in mind, as you will need them later when setting up the Business Connector.

The remaining steps, if not already set up by the SAP S/4HANA administrator, are described in the following.

3.1 Create a Communication User for the SAP BC

For logging in to the Cloud system, the SAP BC needs a user identity. User authentication can be performed either via user and password, or via client certificate.

Login to the SAP S/4HANA Cloud system as administrator, scroll down to "Communication Management" and select "Maintain Communication Users".

Click on "New", enter a username, description and a compliant password and then finish the setup of the user via "Create".

If you want to use certificate-based logon, you can upload here the client certificate, that you will later use in the SAP BC. Note that in this case an additional step is needed: the Cloud system needs to trust the CA root certificate that issued the SAP BC’s client certificate. This is achieved by uploading the CA root certificate to the SAP S/4HANA Cloud system as described here: Maintain Certificate Trust List

3.2 Create a Communication System

For associating the user, you just created, with inbound calls from the Business Connector, you need to create a so-called "Communication System" for the Business Connector.

Login to the SAP S/4HANA Cloud system as administrator, scroll down to "Communication Management" and select "Communication Systems".

On the next screen, click on "New", fill the fields "System ID" and "System Name" for example with BUSCON_INBOUND and choose "Create". Select the checkbox "Inbound Only". Finally, scroll down to "Inbound User" and add the user created in the previous step.

Note that when sending IDocs to the SAP S/4HANA Cloud system, the two fields "Logical System" and "Business System" also need to be filled. This depends on the ALE settings and the values used in the IDoc Control Record.

3.3 Create a Communication Scenario

This step is necessary only if you want to call your own custom function modules. If you are using only SAP standard BAPIs, for which a Communication Scenario already exists, you can skip this step. You just need to find the name of the pre-defined SAP_COM_*** scenario containing the required BAPIs/function modules and then proceed with section 3.4. (For example, the scenario SAP_COM_0126 contains the BAPIs for company code management. Check the documentation of the BAPIs you intend to call, for similar SAP_COM scenarios.)

An ABAP Cloud system by default does not allow the execution of remote enabled function modules by external RFC clients. In order for the Business Connector to be able to execute the desired function modules, you need to create an Allow-List containing these function modules. Communication Scenarios are created via ABAP Development Tools (ADT).

Start ADT, click on "Create ABAP Cloud Project", login to your SAP S/4HANA Cloud system with a development user and create a project, e.g., called Z_INBOUND_CALLS (or use an existing one, if you have already done other development in the SAP S/4HANA system). In the project create an ABAP Package (named Z_INBOUND_SCENARIO in this example), selecting a transport request or creating a new one. Finally select the package and then from the context menu choose "New --> Other Repository Object". On the next screen, filter for "Comm", select "Communication Scenario" and click "Next".

Give it a name that matches your scenario, e.g., Z_NUMERICS, add a description, select your transport request again and finally click "Finish".

In the "Overview" tab you can leave all fields at their default. Open the "Inbound" tab and add the function modules you want to call from on-premise. In the "Add New Inbound Service" wizard, click the "Browse" button and then type the beginning of the function module name in the filter field to locate your FMs quickly.

For this tutorial, I created a demo function module Z_ADD_INTS, which simply adds two input parameters of type INT4 and returns the sum. Make sure that the function modules you created, are RFC-enabled. This is done on the "Properties" tab of the FM by selecting "Processing Type = RFC" in the specific properties.

In the end, the finished Communication Scenario will look like this:

Save everything and then click on the "Publish Locally" button to activate the changes on the SAP S/4HANA Cloud server.

3.4 Create a Communication Arrangement

Finally, you need to tell the SAP S/4HANA system that the user created in 3.1 shall have permission to execute the function modules listed in the scenario from 3.3. This is done via a so-called "Communication Arrangement".

From ADT, switch back to the Fiori launchpad used before. Click on "Communication Arrangements" and create a new one. Select the Communication Scenario and the Communication System created earlier and save.

Note: if in the following setup of the SAP Business Connector, you want the SAP BC to lookup the metadata information from the S/4HANA Cloud system instead of from the on-premise system, you need to create a second Communication Arrangement: this time select Communication Scenario SAP_COM_0636 and your Communication System. This will allow the user maintained in your Communication System to execute a number of function modules for reading the DDIC descriptions of the involved function modules, structures and tables.

 

4 Setting up the SAP Business Connector

An instance of the SAP Business Connector takes over the tasks of establishing a secure TLS connection to the Cloud system and of converting the classic RFC data to WebSocket based RFC data and vice versa. If you already have an SAP Business Connector installation in your landscape, e.g., because you use it for automatic tax reports (German "Elster" scenario, British "eFiling" scenario, etc.) or for communication with internal third-party systems or external trading partners, you can reuse this installation for the current Cloud scenario. Maybe increase the sizing parameters a bit to allow for the additional load.

If you do not yet have a Business Connector installation, or you want to set up a dedicated instance for this scenario because of expected high volume, this can easily be done:

• The installer can be downloaded free of charge from the SAP BC homepage:
  SAP Business Connector Download
  (A one-time registration of the SAP customer ID is required.)


• An installation guide and other documentation can be downloaded from here:
  SAP Business Connector in Detail


• Installation and some basic setup like sizing can be done even by someone without prior SAP BC knowhow in less than an hour.


• In case of problems, SAP support tickets can be opened under component BC-MID-BUS.

Currently, SAP BC supports Windows, a number of Linux distributions and AIX. SAP BC is a very lightweight component. If not too much traffic is expected, a good place to install it, would be one of the application servers of the on-premise SAP system. For very high load scenarios, however, a separate server would be recommended.

Note: Some of the features used in this scenario have been added to the SAP Business Connector 4.8.1 only in one of the later "Service Releases" or "CoreFixes". Therefore, before you proceed, it is recommended to update your SAP BC installation with the latest Service Release and CoreFix for 4.8.1 available on the SAP BC download page linked above.

Assuming the BC is installed and started according to the installation guide, three configuration steps need to be performed on the BC:

4.1 Define Connection Parameters for the Cloud System

For opening TLS connections to the target system (e.g., the SAP S/4HANA system or Steampunk system in the Cloud), the SAP BC needs certain hostname, user, certificate and proxy parameters.

First, define an “alias” for the Cloud system under "Adapters --> SAP". Click the "Add SAP Server" link and provide a name for this SAP system entry. In general, any name can be used here, but it is good practice to use the system ID and the client of the target system. Then the routing settings later on will be much clearer. For example, if the system ID of the SAP S/4HANA system is "ABC" and you will be connecting to client "100", you could name this alias "ABC100". (However, please note that for SAP S/4HANA Cloud systems currently the client is always "100" and for Steampunk systems it is automatically derived from the virtual host, so you may as well just use a logical name like “ABC_PROD” and leave the Client field empty.) As "Connection Type" choose "WebSocket Connection" and specify the remaining parameters as follows:

The values for host and port you will get from the administrator of your SAP S/4HANA Cloud or Steampunk system. They are the same as displayed in the "API-URL" of your Communication Arrangements.

The logon can be performed in two different ways: user/password based, or certificate based.

If you are using user/password-based logon, you will also have to activate the checkbox for "Alias User", as most Cloud based systems have disabled normal user login for security reasons. (Only a selected number of users, who have an alias user, are allowed to logon via RFC. This eliminates system access via some critical super-users like DDIC.)

If you want to log on by certificate, you can use either the Business Connector’s default certificate (more on that below) or a dedicated certificate used only for this particular Cloud system. This is useful, if you want to connect to several Cloud systems that require different certificates. So, depending on whether you have one certificate for the SAP BC that is accepted by all your SAP S/4HANA systems, or different certificates for different SAP S/4HANA systems, chose "Default Certificate" or "Custom Certificate" in the field "Logon Type" above.

The default certificate can be defined on the screen "Security --> Certificates --> Default Server Certificate". This certificate needs to be provided in form of three (or more) DER encoded files for the BC’s certificate, the CA certificate(s) that signed that certificate and for the private key. If certificates are managed centrally in your company, just let them issue such a certificate for the SAP BC and import it here. Otherwise, you can use the SAP BC Certificate Toolkit to generate a certificate with a few mouse clicks. This toolkit can be installed on any frontend PC and does not need to be installed on the server, where the SAP BC will be running. Just download the installer for the "SAP BC Developer" from the above download page.

Tip: The certificate toolkit can also be used for converting certificate files from other formats to DER encoded format, if you happen to get your files in a different format like Base64-encoded.

Once you have the required files, the BC’s certificate screen should be customized as follows:

The directory for "Trusted Certificates" can either be left unspecified – in that case the BC trusts all partner systems – or be set to a directory that contains the CA root certificates which signed the server certificates of the partner systems to which the BC will connect. Note that you need to reload the CA list, whenever you copy a new CA root certificate to that directory or remove one from it.

If you chose "Logon Type = Custom Certificate", you can enter the same kind of files (client certificate, signing certificate(s) and private key) directly on the connection parameters screen for the ABC100 system. Certificates of partner systems are still validated against the "Trusted Certificates" as defined on the "Security --> Certificates" screen.

Tip: An easy way to download the SAP S/4HANA system’s certificate is by using the browser’s "show certificate functionality" while you are logged in to the SAP S/4HANA Cloud system. Most browsers provide information on the security status of the SSL/TLS connection, usually displayed as a small "lock" icon. Click on this icon, save the CA root certificate to disc and then copy it to the BC’s trusted certificates directory and reload the CA list once.

 

Finally, if your corporate firewall requires an HTTP Proxy for outbound connections, you need to make this proxy known to the SAP BC. For this, go to the screen "Settings --> Proxy Servers --> Secure Proxy (HTTPS)" and enter the host, port and, if necessary, user information of your proxy server.

Note that here only basic proxy authentication can be configured. If your proxy requires NTML authentication, you need to install the SAP BC on Windows and then set up NTLM authentication as described in the SAPBCAdministrationGuide, section “Responding to NT Challenge/Response Authentication” in chapter 9.

This completes the setup of the outbound connectivity.

If you want to test the connection to the Cloud system, please keep in mind that by default the SAP BC uses the function module RFC_SYSTEM_INFO for testing a connection. An SAP S/4HANA Cloud system is usually set up with a very restricted UCON allow-list, and RFC_SYSTEM_INFO is usually not part of that list. So, the connection test from SAP BC side will fail with an error like "UCON RFC Rejected". This behavior also depends on the setting of profile parameter auth/rfc_authority_check.

In order to avoid this set of problems, you can go to "Adapters --> SAP --> Settings --> Change Settings" and change the value of the "Use System Info" field to "CPIC only" or "Never". This tells the BC to use the function module RFCPING when testing a WebSocket connection (or all connections).

Now you can go to the SAP Server alias defined in the earlier steps and click on the "Test Connection" button to check, whether the setup so far has been successful.

If you have also set up a Communication Arrangement for Scenario SAP_COM_0636 in section 3.4 above, you can now test your function modules from the SAP BC UI:

Go to "Adapters --> SAP --> Lookup", select the ABC100 system defined in this step, enter function module name Z_ADD_INTS, click "Lookup" and then "Test Function".

In the following screen, you can enter import parameters for Z_ADD_INTS and then execute it in the target system.

4.2 Define Connection Parameters for the On-Premise System

Now we have to set up the receiving end of the connection. The SAP BC will register itself at the RFC destination, we have created in chapter 2 "Setting up the Source System", and will listen for incoming RFC requests from the on-premise system.

First go back to "Adapters --> SAP" and create a second SAP Server alias. Assuming the on-premise backend system is called XYZ and we will be receiving RFC requests or IDocs from client 800, this alias could be named "XYZ800". As connection type choose "CPIC Connection" this time, and then fill the "Application Server" and "System Number" fields. Note that the remaining fields, in particular the user/login information, can be left empty, as the SAP BC will not need to logon to this system. We will only receive calls from this system.

After saving this entry, go back to the SAP Servers list and click on the zero in the "Listeners" column of XYZ800 an then choose "Add Listener". This will create a so-called RFC Listener, which will connect to the RFC destination that we created in the on-premise system via transaction SM59. Choose "Connection Type" TCP/IP and then make sure to specify the parameters "Program ID", "Gateway Host" and "Gateway Service" exactly as you defined them in SM59 on backend side.

Note that the Program ID is one of the rare cases where a parameter of an ABAP system is case-sensitive!

The gateway host and service will be prefilled based on the values you entered on the previous screen. So, if you already entered the same host that you used in the SM59 destination, you will not need to change these values.

The default value for "Number of Threads" is 2, which is ok for scenarios with "occasional" calls. For medium load, 5 threads might be required, and for high-load scenarios with dozens of parallel calls being executed at the same time, you may need 20 or 30. This value can always be changed later, if you find that performance is not good enough and calls are kept waiting for too long on XYZ side, before they get processed.

A few words on the value of the field "Repository Server": The SAP BC needs DDIC information for all function modules and structures/tables it processes. In our case, these can be looked up in the DDIC of either the sending or the receiving system and are then cached in the SAP BC. I recommend choosing the target system (ABC100) that we defined in section 4.1 "Define Connection Parameters for the Cloud System", instead of using XYZ800. This has two advantages:

• A function module must of course exist in the system, where it is to be executed. But the same does not need to hold true for the source system! Therefore, by letting the SAP BC make the DDIC lookup in ABC, the XYZ system can call function modules of ABC, that do not exist in XYZ.


• By using ABC for the DDIC lookups, the SAP BC does not need user credentials for the XYZ system! (Credentials for ABC are needed anyway, as we want to login and execute function modules in that system…)

The disadvantage of this setup is of course that the lookups will be a bit slower: ABC is in the Cloud and needs to be contacted through firewalls and the internet, while XYZ is located in the same LAN segment or even on the same physical machine as the SAP BC. Nevertheless, this penalty needs to be paid only once, and since the data is cached for the lifetime of the SAP BC process and since the SAP BC can usually run for months or even years without a restart, this one-time overhead should be neglectable.

However, if you do want to use the XYZ system for the DDIC lookups, remember that you need to provide user & password (or SNC credentials) in the setup of the XYZ800 alias above.

Note: IDoc definitions cannot be looked up in the S/4HANA Cloud system. Therefore, if you want to send IDocs from XYZ to ABC, you have no other choice than to use XYZ800 as “Repository Server” and provide user credentials for that system also.

Now start this listener. If it turns green, the connection between XYZ and SAP BC should be ok. Additionally, you can go back to XYZ, transaction SM59, open the destination ABC_100_VIA_BC once again and verify the connection by clicking the "Connection Test" button.

4.3 Define Routing for Function Modules or IDocs

The last step necessary on the Business Connector is to define, what the BC should do with the incoming RFC requests and IDocs. SAP BC is designed to perform a variety of actions with the RFC & IDoc data it receives. It could transform it into an XML document and do an HTTP Post to a webserver, it could put it into a mail attachment and send it to an email address, or convert it into a flatfile and send it to an FTP server via FTP put command, or insert it into a database using a JDBC driver, etc.

In our case, we simply instruct the BC "send everything that you receive from XYZ, client 800, to ABC, client 100". The easiest way to do this is as follows:

In the BC admin UI go to "Adapters --> Routing --> Routing Rules". In the "Add Routing Rule" screen enter the following values:

• Sender: XYZ800
  Note: this value is extracted from the RFC data stream received, and not from the definition of the SAP Server alias. So, if you named your alias different from "XYZ800", you will nevertheless have to use the value "SysID+Client" of the sending system here.


• Receiver: the name of the RFC Destination via which the requests are received. See the settings in SM59 above.
  In our case that would be ABC_100_VIA_BC.


• Message Type: *
  This means that this Routing Rule matches any function module and IDoc type. We could also define specific Routing Rules for different function modules, and then the BC would route only those FMs, for which it has a matching Routing Rule, and refuse all others, but I don’t see any use in this: the target system ABC already has a UCON allow list only for those function modules it wants to allow external clients to execute. So, if SAP BC tries to execute a non-allowed FM, the ABC system will refuse it anyway. No need to repeat a similar setup here on the SAP BC, especially if it potentially involves hundreds of different function modules.

The "Add" button will now take you to the next screen, where you can define what the BC should do with incoming calls that match this rule. Here you can leave most fields at their default values and only set the "Transport" field to "RFC" and the "Destination" field to the desired target system "ABC100". If you want to, you can enter some free text into the "Comment" field, which documents the purpose of this Routing Rule.

Save this rule and afterwards activate it by clicking on the "No" in the "Enabled?" column.

 

Things are a little bit different when routing IDocs, because here the "Sender" and "Receiver" values are not taken from the RFC data (Sender = SystemID + Client of sending system, Receiver = Name of receiving RFC Destination), but from the following fields of the IDoc Control Record (IDOC_CONTROL_REC_40):

• Sender: SNDPRN


• Receiver: RCVPRN


• Message Type: IDOCTYP

The exception are IDocs of type ORDERS and ORDRSP, where sender and receiver values are by default taken from the PARTN field of certain E1EDKA1 segments. For the exact details please see the "SAPAdapterGuide" available on SAP Business Connector in Detail.

Also, for processing IDocs, you need to choose the XML Transport instead of the RFC Transport in the corresponding Routing Rule, because an SAP S/4HANA Cloud system uses the XML Port instead of the tRFC Port for ALE inbound messages.

Use the following URL in the settings of the XML Transport:
https://mysystem-api.s4hana.ondemand.com/sap/bc/srt/IDoc
and mark "Use text/xml as content type":

This completes the setup of the entire scenario. If you have additional on-premise backend systems and/or Cloud systems that need to be integrated in the same way, you would repeat the same setup, i.e., SAP Server alias with logon credentials for the target system and SAP Server alias with RFC Listener (and matching SM59 destination) for the sending system, and in the end create another Routing Rule that defines the routing between these two systems.

 

5 Common Problems

The following is a list of common error messages you may encounter on Business Connector side. These may either be caused on SAP S/4HANA side and reported back to SAP BC, or be generated by SAP BC itself.

1. External WebSocketRFC call disabled
   This error may have two different causes:
   a) The SAP S/4HANA Cloud system is using port 443 for incoming RFC requests. Older SAP S/4HANA patch levels had a bug, leading to port 443 not being recognized correctly in UCON allow-lists.
   Solution: Request the installation of the latest kernel patch as described in note 3163547.
   b) Depending on the setup of the WebDispatcher of your SAP S/4HANA Cloud instance, this error may also be caused by using the wrong hostname ("mysystem" instead of "mysystem-api") or by using the wrong client number.
   Solution: Make sure to use the -api host and the correct client number in the definition of the Alias for the Cloud system. Leaving the client field empty may work, since the default client that gets used in this case, is usually the correct choice.


2. WebsocketRFC aliasuser required
   SAP BC is trying to use a standard SAP R/3 user for logging on to the SAP S/4HANA system, but Cloud-based SAP S/4HANA systems require a different user type called "Alias User".
   Solution: Make sure to check the "Alias User" flag in the SAP BC’s connection parameters of the SAP S/4HANA system.
   Note: This flag was added to the BC with Service Release 1. If you don’t have it yet in the connection parameters screen of your BC, the BC is too old.
   --> Install the latest Service Release.


3. SSLContextProvider does not provide an SSLContext for XYZ
   The error message means that currently no SSL Default Certificate is imported into the SAP BC. Older SAP BC versions require such an SSL certificate for opening the TLS connection to S/4, even if logon to the SAP S/4HANA system is user & password based.
   Solution: This requirement has been removed with Service Release 2. Now the SSL handshake can also be performed without a client certificate.
   --> Install the latest Service Release.
   Workaround: Create a client certificate for the SAP BC, e.g., using the SAP BC Certificate Toolkit (installed as part of the Developer tool) or sapgenpse or a freeware toolkit like OpenSSL. This can even be a self-signed certificate. Import this certificate in the SAP BC under "Security --> Certificates --> Default Server Certificate".


4. UCON RFC Rejected
   This error occurs, if the function module you want to execute, is not in the allow-list of any Communication Scenario assigned to your Communication System.
   Solution: Add the function module in question to the allow list of one of your Communication Scenarios as described in section 3 Create a Communication Scenario.If this error happens, while you click on the "Test Connection" button in the SAP BC connection parameters screen, see the end of section 4.2 Define Connection Parameters for the On-premise System.


5. No RFC authorization for function module XYZ
   Same as 2 or 4.


6. JCO_ERROR_CONVERSION: Value char[] {   } cannot be converted to NUM type at field XYZ
   The ABAP datatype NUMC is meant for character data containing only numerical values, i.e. the digits 0-9. Unfortunately, the ABAP runtime never enforced any type checks on this datatype, so over the last decades, all kinds of garbage data has accumulated in the SAP system databases of this world.
   The classic RFC serialization did not verify the field contents of transmitted data, but the column-based RFC serialization relies heavily on optimizations based on data type and can only transmit values between 0-9 for NUMC fields. The above error message means, that in a table/structure field named XYZ, which is of datatype NUMC, the value "   " (three space characters) arrived from the on-premise system via classic (row-based) RFC serialization, and this value cannot be converted to NUMC, which is necessary for further transfer to the Cloud system using column-based RFC serialization.
   Solution: Clean up the data in your database… I.e., make sure that all values in field XYZ that contain spaces or other characters are replaced with digits 0-9.
   Workaround: Of course, the above may turn into a Herculean task, if we are talking about millions of lines in multiple database tables… This might be impossible in practice. Therefore, two workarounds can be used:
   
   
   
   1. Starting with Service Release 2, JCo has been enhanced to silently replace leading spaces in NUMC fields with leading zeros. So, the value "   " would become "000" before being forwarded to the SAP S/4HANA system. However, this still does not solve the problem, if other non-digit characters made it into your NUMC fields. A value like "abc" would still cause a dump.
   
   
   2. In the SAP BC connection parameters screen of the SAP S/4HANA Cloud system, change the field "Serialization Format" from "Column Based" to "Row Based". Then SAP BC will use the classic RFC format for communication with the SAP S/4HANA system. This may yield slower performance, but it will accept any garbage values that the on-premise system may attempt to send.
   
   
   
   

Note: similar problems may also occur with date and time fields (ABAP data type DATS and TIMS).

7. JCO_ERROR_RESOURCE: Maximum number of RFC connections reached [32768]
   This was caused by a connection leak in JCo. Fixed with Service Release 2.
   Solution: Install the latest Service Release.


8. Unknown Partner and Message Type
   The SAP BC received a function call/IDoc, for which it has no routing defined. Most probably there is something wrong in the setup of the Routing Rule as described in section 3 Define Routing for Function Modules Or IDocs.
   Solution: When the BC issues this error message, it has already automatically created a matching incomplete Routing Rule for this call. So, you could perform one of the following two steps in order to fix the problem:
   
   
   
   1. Complete and activate the automatically created Routing Rule, and then optionally delete the one that doesn’t match.
   
   
   2. Use the automatically created Routing Rule as example and change your existing wildcard Routing Rule accordingly.
   
   
   
   

Both steps need to be done in "Adapters --> Routing --> Routing Rules".

 

Summary

After working through this blog, you should now be able to set up the complete end-to-end scenario of calling RFC-enabled function modules from an (older) SAP ABAP system in the on-premise network via SAP Business Connector in an SAP S/4HANA system running in the Cloud, and know the details about the necessary steps in all three systems.

If you want to learn more about the Business Connector and its capabilities, two guides are recommended for further reading, which can also be downloaded from the SAP Business Connector in Detail page:

• SAPBCSapAdapterGuide.pdf, describing the interaction with an SAP backend system and how to make RFC & IDoc data available to systems supporting different technologies like HTTP, FTP, Email, JDBC or various XML formats.


• SAPBCDeveloperGuide.pdf, describing how to develop your own powerful integration scenarios using graphical mappings (Flow), Java or C/C++.