Skip to Content
Technical Articles

Cloud Integration – How to Connect to an On-Premise AMQP server via Cloud Connector

You may use the SAP Cloud Connector to securely connect to on-premise systems. SAP Cloud Integration supports this configuration via the connection proxy type ‘On-Premise’ currently in several adapters. With version 1.1 of  the AMQP adapter which will be available in January  2020 also the AMQP adapter supports this option.

Connect to an On-Premise AMQP server via Cloud Connector

With the January 2020 update of SAP Cloud Integration we’ve released a new version of the AMQP sender and receiver adapter that supports the connection to On-Premise AMQP servers by using the SAP Cloud Connector. This configuration utilizes the SOCKS5 proxy supported in SAP Cloud Connector version 2.10 and higher.

You may use it in your AMQP sender and receiver adapters to connect to your on-premise messaging system via AMQP.

I assume you’ve already installed the SAP Cloud Connector and connected it to your SAP Cloud Platform account. If not, download the SAP Cloud Connector from our tools page and follow its installation documentation.

All you need to do now is to

  1. configure a new Cloud to On-Premise System Mapping in your Cloud Connector and
  2. configure your AMQP sender or receiver adapter accordingly.

Let’s go step by step.

Configure a Cloud to On-Premise System Mapping in the Cloud Connector

Logon to your Cloud Connector and add a Cloud to On-Premise System Mapping. Maintain the parameter in the wizard as follows:

Set the Backend Type to ‘Non-SAP System’.

Select the ‘TCP’ Protocol. The configuration options for TCP are not as specific as for, e.g. HTTP, that is why the SAP Cloud Connector may not restrict potential misuse from your SAP Cloud Platform account. Therefore, this configuration is classified as a security risk

Note that even for the AMQP connection via WebSocket protocol, which is http based, you need to select TCP as protocol in the Cloud Connector.

Maintain the On-Premise AMQP server Host & Port you want to connect to.

Define the virtual AMQP server & port you want to expose to your SAP Cloud Platform Account (it will be re-used later in the AMQP adapter configuration).

Maintain an optional description, tick the ‘Check Internal Host’ checkbox (to have enable the ping test from SAP Cloud Connector to your On-Premise AMQP server) and Finish.

You can check and maintain your system mapping in the Cloud To On-Premise overview.

Logon to your Cloud Platform account and check the status of the connected Cloud Connector.

If all configurations seem fine, you can start to consume your newly established TCP connection in the AMQP sender or receiver adapter.

Configure the AMQP Sender or Receiver Adapter

Log on to the Cloud Integration WebUI and add the connection parameters in the AMQP adapter properties as follows.

Maintain the virtual AMQP server name & port in Host and Port and for the Proxy Type select ‘On-Premise’. Maintain the Location ID of the Cloud Connector, if configured in the Cloud Connector. Define the Authentication configuration as required by your On-Premise AMQP server.

Once you’re done, save and deploy the integration flow. Start sending messages from SAP Cloud Integration to your own on-premise AMQP messaging server or start consuming messages from your On-Premise AMQP server.


If you run into errors when executing your scenario, you may find information for error analysis at the following places:

  • Integration Content Monitor in Cloud Integration
  • Message Processing Monitor in Cloud Integration
  • Cloud Connector Connectivity Test
  • AMQP connectivity test (will be available with the February 2020 update)
  • Log File in Cloud Connector

Let’s have a quick look at the different tools.

Integration Content Monitor

After deploying the integration flow you should make sure that the integration flow has started successfully n the Integration Content monitor in SAP Cloud Integration. As integration flows with AMQP sender adapters start to consume messages immediately after the integration flow was started, errors during the consumption are shown here. No message processing log is created in this case.

In the sample error below, you see that an error is coming back from the socks5 proxy of the Cloud Connector. In this case, you would have to check the monitor and the log files in the Cloud Connector to get more details. Make sure that the request reaches your Cloud Connector instance at all. If not, maybe the Location ID in Cloud Connector configuration does not fit to the Location ID used in AMQP channel or the host and port do not fit to the virtual host configured in Cloud Connector?



Message Processing Monitor

The second important monitor to be checked if your scenario does not work is the Message Processing monitor in the Cloud Integration Monitoring. If there is an error in sending messages to a specific AMQP receiver the error would be shown here.

In the sample below, the error shows that there is an exception in the connection to the socks5 proxy of the Cloud Connector. You need to check if the Location ID and virtual host and port are configured correctly.

AMQP Connection Test (available with the 16-Feb-2020 update)

The Connectivity Test is available in Operations View in Web UI, in section Manage Security Material. Selecting the Connectivity Test tile from Overview Page opens the test tool offering tests for different protocols. To test the communication to the messaging system, the AMQP option is to be selected. Using Proxy Type with value On-Premise you can test the connection to the on-premise messaging system. Enter the Location ID of your Cloud Connector.

In the sample below, the error shows that there is an exception in the connection to the socks5 proxy of the Cloud Connector. You need to check if the Location ID and virtual host and port are configured correctly.


Cloud Connector Connectivity Test

The Cloud Connector Connectivity Test can be used to test if the Cloud Connector connected to the Cloud Integration tenant can be reached via the Cloud Integration’s runtime via the defined Location ID.

Like the SSH Connection Test, the Cloud Connector Test can be found in the Connectivity Tests tile in the Operations View in Web UI under the section Manage Security Material. In the test tool select Cloud Connector. The only input field for the Cloud Connector test is the Location ID. Enter the Location ID you have configured in the Cloud Connector and used in the adapter channel in the integration flow.

The test pings the Cloud Connector with this Location ID. If no Cloud Connector is connected with this Location ID the test will fail:

If the Cloud Connector can be reached with the given Location ID the test executes successfully:

Cloud Connector Log

If you receive errors from the socks5 proxy, you have to check the Cloud Connector log file for more information. Maybe the mapping for the used virtual host does not exist?

Related Blogs

Connecting to Messaging Systems using the AMQP Adapter

You must be Logged on to comment or reply to a post.
  • Mandy

    I have configure the Cloud Connector and AMQP server as mentioned.  My Connectivity test for the cloud connector is fine but when I test connectivity for AMQP I get the following exception


    javax.jms.JMSException: failure when writing TLS control frames Cause: org.apache.qpid.jms.provider.exceptions.ProviderIOException: failure when writing TLS control frames Cause: failure when writing TLS control frames Cause: io.netty.handler.proxy.ProxyConnectException: socks5, jwt, => rabbit:5671, status: FORBIDDEN(2)


    my AMQP server port and destination are correct.  Can you kindly advise. I'am using cloud foundry

    trial version.

    Best regards


    • Hello Ramesh,

      the error you see comes from the Cloud Connector (socks5 proxy). It looks as something is wrongly configured there. Please check the cloud connector logs and configuration.

      Best regards


  • Hi Mandy,

    I am trying to connect to onPremise AcrtiveMQ server from CPI iFlow, as you have mentioned in your blog above.

    But while sending an message to the AMQP TCP receiver channel, I am getting below error.

    Can you please suggest what could be the issue here?

    org.springframework.jms.UncategorizedJmsException: Uncategorized exception occurred during JMS processing; nested exception is javax.jms.JMSException: not an SSL/TLS record: 0000018d014163746976654d510000000c010000017b0000000c00115463704e6f44656c6179456e61626c65640101001253697a6550726566697844697361626c656401000009436163686553697a650500000400000c50726f76696465724e616d650900084163746976654d510011537461636b5472616365456e61626c65640101000f506c6174666f726d44657461696c730900564a564d3a20312e382e305f3133312c2032352e3133312d6231312c204f7261636c6520436f72706f726174696f6e2c204f533a2057696e646f77732053657276657220323031322052322c20362e332c20616d643634000c4361636865456e61626c6564010100145469676874456e636f64696e67456e61626c65640101000c4d61784672616d6553697a65067fffffffffffffff00154d6178496e61637469766974794475726174696f6e06000000000000753000204d6178496e61637469766974794475726174696f6e496e6974616c44656c6179060000000000002710000f50726f766964657256657273696f6e090006352e31342e35, cause: io.netty.handle...

    Appreciate your support.
    • Hello,

      this sounds like the messaging server expects TLS but you do not sent a TLS request. Did you activate TLS in the channel and added the server certificate in the keystore?

      It's always also helpful to check the logs of the messaging system



  • Hello Mandy,

    Appreciate your quick reply.

    Yes i have checked the checkbox "Connect with TLS" in the channel.

    But i have not added Server certificate in the keystore. Do we need this as well?


    When i check the OnPermise Active MQ server URL, its with HTTP configured and not with HTTPS.




    • Hello Varun,

      if you want to use TLS with the server you need the server certificate in the keystore.

      Have you checked the logs in the messaging server?



      • Hello Mandy,

        Can i also access the OnPremise ActiveMQ server without TLS as well? So i assume in this case i will not need to import the Server Certificate.

        Also as suggested i will check the messaging server logs and get back with relevant details.





        • Hello Varun,

          you have to check the configuration of the messaging system if it expects TLS or not. In Cloud Integration you need to set what is required for the messaging system.



          • Hello Mandy,

            We are going to have a joint session today with the Messaging team and figure out the required configurations needed. I will keep you posted.


            Also can you please confirm if I have to enter the Destination name/Queue name in the below way.


            AMQP channel setting




          • Hello Mandy,

            We checked together on the messaging server logs. And now with the below settings we are getting this error message.

            Settings in SCPI: -

            1. TLS not used (As there is no server certificate configured on Message Server)
            2. SASL Authentication used

            Error message in SCPI: - 

   An internal server error occured: AMQP SASL header mismatch value 0, expecting 41. In state: HEADER0.


            Error Message on Active MQ side:  -

            failed: | | ActiveMQ Transport:


            Could be the reason that OnPremise ActiveMQ server is not supporting this SASL Authentication?



          • Hello Mandy,

            We found a solution how to configure this on SCPI side.

            So basically the ActiveMQ supports SASL Authentication via port 5672 and not via 61616.

            Ref Doc: -

            So from SCPI side, if we have to use SASL Authentication without using TLS, then we need to use port as 5672.


            Just for ref in the below screenshot you can see the channel configuration


            Channel Config


            Successful Message Sent: -


            Message Sent to Active MQ


            Thanks for your support and Wish you a Merry Christmas!


          • Hello Mandy,

            We identified another issue with the SCPI AMQP adapter.

            When the message is successfully sent to ActiveMQ queue, we see that in the Queue along with the XML Payload all the Header properties are also added.

            Below is the copy of the message added in the Queue. AS you can see the XML payload is highlighted in bold, but along with all the Header details as well.

            CamelHttpPath¡Sw±n<ns1:voryouOrder xmlns:ns1=""><orderType>Main</orderType><orderNumber>VP10000233</orderNumber></ns1:voryouOrder>


            Screenshot of the Message in the Queue.




            Can you please suggest, what can be done to avoid sending the Header Properties in the ActiveMQ message? We need only Payload message to be queued in the ActiveMQ.



          • Hello Varun,

            we have not seen this behavior before. Could you please open a ticket on LOD-HCI-PI-RT and attach the integration flow and the screenshots?

            Thank you,


          • Hello Mandy, Hello Varun,

            we experience the same issue.
            We are consuming the message with Java, like in the example here:

            However we do not receive a message of type TextMessage but of type ActiveMQBytesMessage.

            After transforming it to a string, expecting the message to be UTF-8 we receive a message quite similar to yours including headers besides our expected json-body.

            CamelHttpPath�Su�{"prod": 14}

            We kept the flow simple for troubleshooting:





            Any help would be appreciated.

            Kind regards,


          • Hello Johannes Neubauer ,

            I have got the below reply from SAP when i have raised a ticket.

            Basically we are producing a message using the SCPI AMQP adapter and sending it to an external JMS Queue.

            But from this external ActiveMQ queue, the application fetches this as an JMS message and not an AMQP message.

            That's the reason the message is shown like this. We solved the issue by adding a script to sub string the message Payload from this.


            SAP Reply

            11.01.2021 at 15:02

            Hi Varun,

            this is a common misunderstanding. With the AMQP adapter, we produce an AMQP message. If you render this message as a plain JMS message, this is expected. The active mq dashboard does not know that this is an AMQP message.

            If your consuming application simply fetches a JMS message (and not an AMQP message), I predict the same problems.

            The test with the CPI AMQP sender adapter will confirm this.

            Best regards