22. How to deal RFC Error - "Direct connect to hostname failed" in RISE/ECS/Private Cloud system ?

Yes. "Direct connect to hostname failed" will be occurred due to Network/Firewall Blockage only.

It's just an basic connectivity port opening issues which applicable even for usual sap connectivity - Direct connect to  apps-support-com 443 failed

For on-premise systems, we will usually check with Network or Firewall team to unblock hostname and their port number.

 

Once port opened, we can do telnet/tnc to crossverify the same.

Telnet hostname port

Let's have an quick info on Rise/ECS scenarios as well.

Scenario:

 

⭐SAP strongly recommends to use proxy for RFCs especially connection to Non SAP/BTP Services/Third Party systems having Port 80/443. In other words, there should not be any SAP component or 3rd party add-on (without 80/443 port).

All BTP Subaccount services usually ends up with 443 only which in turns we need to use Proxy mandatorily.

Mostly valid for - HTTP to External server type RFCs - Say Integration Suites/Biztalks/Logic Apps etc.,

For all Rise customers,

Proxy hostname would be "Proxy" itself

Port number would be "3128"

We need to raise service request - "Allow list Squid Proxy Access"- HTTP/HTTPS - Outbound to External" category to allow hostname and port number.

Example 1:

Assume we need to connect SAP System to Integration Suite - Outbound RFCs. Connection will be established via RFC. Once SR raised and ECS team completed their actions, we can create RFC and include proxy details - Proxy:3128 in RFC Connections to have successful connection.

 

Above condition applies to Cloud ALM as well. Port blockage on eu10-alm-cloud-sap - port 443 which same actions needs to be taken.

Note 3106170 -  SAP Cloud ALM: Registration error Connection Refused while connecting ABAP systems 

 

Note 3454314 - Request for SAP Private Cloud (formerly ECS/HEC) - Allowing SAP Cloud ALM Registration in RFCs to use Proxy is not yet added in allowlist URLs. It's recommended to add both URLs as mentioned in note 3454314.

Example 2:

In other cases which RFCs not used, such as using gateways, TCP/IPs with Program registration, we can use service request category - "Allowlist Hyperscaler LB access: Outbound to External"

If RFC, Ensure to have proxy - it's sufficient 99%

All the above mentioned related to Outbound RFCs which connection will be established from SAP system to Target.

However, Most basis peoples confuse this and open connections with "Allowlist Hyperscaler" despite it's not required as well as considers as Inbound.

Example 3:

Let's have short info on Inbound RFCs. 

Assume, I'm having one SAP System TC1

TC1 has two webdispatchers WD1 and WD2 (connected)

Azure load balancer exists to distribute loads 

SAP System uses load balancer for all HTTPS connection - Say Fiori Launchpad

Set in HTTPURLLOC

Users will open launchpad with load balancer url - which connects SAP System via WD1/WD2.

I'm having Rise Cloud connector as well which SAP Build Workzone Subaccount added (To fetch SAP system fiori apps and do researches)

Destinations for SAP System TC1 maintained in Build Workzone Subaccount as well as relevant connection information setup done in Access control - cloud connector with Load Balancer Information as well.

Now, Inbound RFCs flow will be below.
BTP Build Workzone (when launching fiori app) -> Cloud connector -> Via Load Balancer -> Via Web Dispatcher -> Reaches SAP System and fetches relevant data of fiori app -> Show results in BTP Fiori app 

We will allow only specific SICF services which uses fiori apps in WebDispatcher (Permit) as well as Cloud connector Access Control Resources (/sap/bc/xx) instead of allowing entire path.

In this way, Connection will be secured as well as relevant access will be allowed.

Hope you like this scenarios

Thanks for visiting !!!