Technical Articles
Extending on-premise systems via Kyma runtime
With the latest release of Kyma, connectivity to on premise systems can now be achieved using the SAP Cloud Connector. Running as an on-premise agent, the SAP Cloud Connector provides a secure tunnel to connect SAP BTP applications and on-premise systems. This is accomplished by using the Connectivity Proxy which is a software component deployed into the Kyma Cluster that interacts with systems exposed by the SAP Cloud Connector.
The provisioning of the Connectivity Proxy is handled by the Kyma Control Plane which is a component that manages Kyma runtimes. Once the creation of a service instance and service binding of the Connectivity Proxy is detected by the Kyma Control Plane, the Connectivity Proxy will be provisioned in the runtime into the namespace kyma-system. From within the Kyma runtime it will be accessible using the URL connectivity-proxy.kyma-system.svc.cluster.local:20003.
Looking forward to your feedback and comments here.
If you have further questions around Kyma, feel free to post them in the answers area of the SAP Community, here is a link.
To stay up to date with everything Kyma, make sure to visit our Kyma topic page.
Disclaimer: This blog post focuses on Kyma runtime version 2.0 on SAP BTP. Keep in mind that adjustments might be needed at a higher release of Kyma.
Is your example expected to work with a SAP S/4HANA ?
The connectivity proxy can be used to connect to an on premise S4HANA system, but the example uses a locally running nodejs app.
Regards,
Jamie
Do you have any examples of a connection to S4 using nodesjs? Similar to your example but a scenario a little closer to reality.
Hello
you could take a look at this https://blogs.sap.com/2022/04/07/veridisquo.-reaching-sap-lob-destinations-with-connectivity-proxy-and-principal-propagation./
I hope that helps
Thanks for your reply, it was exactly what I needed and it worked. A very simple approach. Thanks for the article. An unusual thing happened, the database that is in the same cluster and in the same namespace reset, the data was lost. after the command: kubectl label namespaces <your namespace> istio-injection=enabled, the namespace is the default. Did it already happen to you?
Hello Luiz Gomes,
OK. Glad my article was of help you; kind regards;Piotr
PS.
What was the reason you had to enable istio for your default namespace? How many nodes does your cluster have? More than one ?
Re your database; is it your postgres deployment ? does it have a pvc? if yes, a pvc (it is a pod as well) should be still there (you can check it is present using kyma dashboard or kubectl); Please let us know;
What was the reason you had to enable istio for your default namespace?
R: Follow this guide: https://github.com/SAP-samples/kyma-runtime-extension-samples/tree/main/connectivity-proxy
How many nodes does your cluster have? More than one ?
R: One
is it your postgres deployment ? does it have a pvc?
R: Yes the postgres pod is there. As well as the pvc that is connected to it. but the databases disappeared on Friday after that command and today again.
As it is in dev it has no impact. I'm trying to understand if it was this command or some kyma update, because even the access roles are gone.
Ok Now I recall your postgres bit as you are using LB to access the postgres service you must not have istio enabled for its deployment; you can annotate istio out in your postgres deployment, restart it and it should go back to normal
I hope that helps
So the istio is enabled for the entire Default namespace but not for the postgres deployment, right? I need to understand what impact this label can have. If I disable the default namespace will the connection to the cloud connector stop working as well?
Hello,
The bottom line is you are using a LB for your postgres service. Thus you need take istio out from its deployment....
Why don't you go back to the answer I have already given you on this ? I hope that helps; Piotr
PS. You indeed require istio enabled when using the connectivity proxy; so the "easiest" is to have istio disabled for your postgres deployment via the deployment annotation mechanism, or alternatively, you could keep your postgres deployment in a dedicated namespace where istio injection is disabled for the namespace (that's a default behaviour when creating a new namespace with kyma dashboard)
This is for S4HANA Cloud, but same principle would apply
https://github.com/SAP-samples/kyma-runtime-extension-samples/tree/main/s4hana-materialstock-function
Regards,
Jamie
Thanks for your answer, I have scenarios with the SDK and I'm going to test them. I noticed that you don't create a connectivity_proxy service, is that right? And even for PUT and POST does something change in this example?
That example is for the cloud, so there is no need for the cloud connector/connectivity proxy. They would be needed for a on premise/private cloud scenario.
Jamie
Thanks for this blog,we have a requirement as below:
SAP -> SAP CC -> KYMA-Endpoint
we want to use the SAP CC to call a secured APIRule in our SAP BTP Kyma environment so that we do not go over the unsecured internet.
Do you know how and any document to refer to?we have the following specific question:
We expect that we need to configure a Kubernetes Clsuter for this in the SCC:
But where can we find the URL and the service URL needed for the configuration in the KYMA environment?
Regards,
Sathishkumar V
Hi Jamie Cawley
simple and easy to understand example, thanks a lot. I have deployed the three YAML files from the gitrepo. For the first ca. 10 minutes the curl call responds with
"Couldn't resolve proxy 'connectivity-proxy.kyma-system.svc.cluester.local'"
after that it turns to
"Failed to connect to connectivity-proxy.kyma-system.svc.cluster.local port 20003: Connection refused"
After that I wanted to simplify my test deployment to rule out any errors. Here is what I did:
I don't see anything happening on the cloud connector side. It is a local CC installation. But the curl call doesn't reach it. Is there any change to trace/monitor the proxy? I have a feeling that something is wrong with the connectivity proxy/binding.
Best Regards,
Koray
Do you see the connectivity proxy pod running? You can check with
Hi Jamie,
thanks for the quick reply. Right after I have posted my question I found this help page: https://help.sap.com/docs/CP_CONNECTIVITY/cca91383641e40ffbe03bdc78f00f681/e7a04d9b30144f40ab0ca3b275ced93f.html. With the kubectl command
I could see the instance. I even switched the log level but actually, it didn't help. I could not even reach the proxy. There were no traces for my curl calls. Anyways after that I wanted to have a clean start. I have deleted the cluster and started from scratch. Now it is working. Either there was a temporaryy issue or I've missed a step. Here is a summary of the steps, that I have taken for the working PoC (maybe it helps someone):
Regards,
Koray
after update to kyma 2.11 statefull/connectivy-proxy not found
Hi Luiz,
Have you tried to create a new instance of it? If it still does not appear I would suggest creating a ticket so the support team can investigate it.
Regards,
Jamie
Hi Jamie,
This generated negative impacts, so we opened a ticket to get a position from the SAP team.
It is not possible to do this intervention with each update.
Is it possible to choose when to receive an update in the Kyma runtime?
It is not possible to choose when you receive an update currently, but please share you feedback through the support ticket.
Regards,
Jamie