I551317
commented
1 year ago Attaching BTP Destination configuration as well:
Closed I551317 closed 1 year ago
I551317
commented
1 year ago Attaching BTP Destination configuration as well:
CharlesDuboisSAP
commented
1 year ago Go to you application in the BTP cockpit -> Service Bindings -> Bind Service, then select your destination service.
Alternatively define your destination service in the manifest.yml that is used to deploy to Cloud Foundry:
services:
- <my-destination-instance>Hi @CharlesDuboisSAP , thanks for your response. Unfortunately in BTP Cockpit there is no Service Binding option (at least I don't see that). Keep also in mind that I'm using Kyma Runtime Environment and I create both: Service Instance and Binding from Kyma/K8s side using above components. So I'm not sure if Cloud Foundry approach is a solution for me.
(In the attachment BTP console screen shoot)
CharlesDuboisSAP
commented
1 year ago Here is our Kyma guide to follow from start to end (I suggest updating the deployment.yml).
It also contains a section on how to bind the destination service.
I551317
commented
1 year ago @CharlesDuboisSAP I followed exactly that documentation (frankly speaking two pages of that documentation, indicated by you and the one with Destination description that I directly pointed in the ticket description). As you may see in the issue description my configuration is done in the deployment.yml exactly as described and I get an error. That's why I'm rising the ticket as due to unknown problems it's still not working.
I've also tested that and in case described in the documentation configuration is missing or done in a wrong way there are different exceptions thrown by application than the one I get right now: "Please make sure you have the Destination Service bound to your application." and "Could not resolve destination to Destination Service on behalf of TECHNICAL_USER_CURRENT_TENANT". I'm struggling with different problem
I551317
commented
1 year ago To increase readability of my *.yml script I edited ticket description resolving all parametrized values
CharlesDuboisSAP
commented
1 year ago Suggestion from Teams chat:
volumes:
- - name: crcm-destination-instance-rcc-882-launchpad-acc
+ - name: crcm-destination-instance-rcc-882-launchpad-acc-binding
secret:
- secretName: crcm-destination-instance-rcc-882-launchpad-acc-secret
+ secretName: crcm-destination-instance-rcc-882-launchpad-acc-binding-secret
defaultMode: 420 volumeMounts:
- - name: crcm-destination-instance-rcc-882-launchpad-acc
+ - name: crcm-destination-instance-rcc-882-launchpad-acc-binding
- mountPath: /etc/secrets/sapbtp/crcm-destination-instance-rcc-882-launchpad-acc
+ mountPath: /etc/secrets/sapbtp/crcm-destination-instance-rcc-882-launchpad-acc-binding
readOnly: trueTested introducing above changes and still get the same error:
2023-09-08T14:11:35.892688313Z 14:11:35.892 [http-nio-8080-exec-2] WARN c.s.c.s.c.s.RequestAccessorFilter - Unexpected servlet filter exception: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is com.sap.cloud.sdk.cloudplatform.connectivity.exception.DestinationAccessException: Failed to configure on-premise proxy for destination 'Hello'. Please make sure to correctly bind your application to a service instance.
2023-09-08T14:11:35.892779214Z com.sap.cloud.sdk.cloudplatform.thread.exception.ThreadContextExecutionException: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is com.sap.cloud.sdk.cloudplatform.connectivity.exception.DestinationAccessException: Failed to configure on-premise proxy for destination 'Hello'. Please make sure to correctly bind your application to a service instance.Deployment script with above changes:
# Source: service-chart/templates/customer-connectivity-data.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: crcm-backend-app
spec:
replicas: 1
selector:
matchLabels:
app: crcm-backend-app
template:
metadata:
labels:
app: crcm-backend-app
spec:
imagePullSecrets:
- name: backend-docker-registry-secret
containers:
- name: crcm-backend-app
image: rcf.common.repositories.cloud.sap/rcp-container/customer-connectivity-data/feature:1.0-SNAPSHOT-20230904133713_bf0aaf42741aaa301f1031e23fe466a27b88d268
imagePullPolicy: Always
ports:
- containerPort: 8080
protocol: TCP
env:
- name: dev-mode
value: "true"
- name: SERVICE_BINDING_ROOT
value: /etc/secrets/sapbtp
volumeMounts:
- name: crcm-xsuaa-instance-rcc-882-launchpad-acc
mountPath: /etc/secrets/sapbtp/crcm-xsuaa-instance-rcc-882-launchpad-acc
readOnly: true
- name: crcm-destination-instance-rcc-882-launchpad-acc-binding
mountPath: /etc/secrets/sapbtp/crcm-destination-instance-rcc-882-launchpad-acc-binding
readOnly: true
- name: crcm-connectivity-instance-rcc-882-launchpad-acc-binding
mountPath: /etc/secrets/sapbtp/crcm-connectivity-instance-rcc-882-launchpad-acc-binding
readOnly: true
volumes:
- name: crcm-xsuaa-instance-rcc-882-launchpad-acc
secret:
secretName: crcm-xsuaa-instance-rcc-882-launchpad-acc
defaultMode: 420
- name: crcm-destination-instance-rcc-882-launchpad-acc-binding
secret:
secretName: crcm-destination-instance-rcc-882-launchpad-acc-secret
defaultMode: 420
- name: crcm-connectivity-instance-rcc-882-launchpad-acc-binding
secret:
secretName: crcm-connectivity-instance-rcc-882-launchpad-acc-secret
defaultMode: 420
---
# Source: service-chart/templates/customer-connectivity-data.yaml
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
name: crcm-destination-instance-rcc-882-launchpad-acc-binding
namespace: rcc-882-launchpad-acc
spec:
serviceInstanceName: crcm-destination-instance-rcc-882-launchpad-acc
externalName: crcm-destination-instance-rcc-882-launchpad-acc-binding
secretName: crcm-destination-instance-rcc-882-launchpad-acc-secret
---
# Source: service-chart/templates/customer-connectivity-data.yaml
apiVersion: services.cloud.sap.com/v1
kind: ServiceBinding
metadata:
name: crcm-connectivity-instance-rcc-882-launchpad-acc-binding
namespace: rcc-882-launchpad-acc
spec:
serviceInstanceName: crcm-connectivity-instance-rcc-882-launchpad-acc
externalName: crcm-connectivity-instance-rcc-882-launchpad-acc-binding
secretName: crcm-connectivity-instance-rcc-882-launchpad-acc-secret
---
# Source: service-chart/templates/customer-connectivity-data.yaml
apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
name: crcm-destination-instance-rcc-882-launchpad-acc
namespace: rcc-882-launchpad-acc
spec:
serviceOfferingName: destination
servicePlanName: lite
externalName: destination-instance-rcc-882-launchpad-acc
---
# Source: service-chart/templates/customer-connectivity-data.yaml
apiVersion: services.cloud.sap.com/v1
kind: ServiceInstance
metadata:
name: crcm-connectivity-instance-rcc-882-launchpad-acc
namespace: rcc-882-launchpad-acc
spec:
serviceOfferingName: connectivity
servicePlanName: connectivity_proxy
externalName: connectivity-instance-rcc-882-launchpad-accI've also logged to the pod and to confirm that secret is mounted correctly:
Any suggestions what else is expected by the DestinationAccessor?
newtork
commented
1 year ago Hi @I551317,
Can you check whether there are hidden files present, is there a .metadata?
- ls
+ ls -lAAlso can you confirm, the type file contains the string connectivity?
Kind regards Alex
I551317
commented
1 year ago The .metadata file is there, however type file doesn't contain connectivity string
/etc/secrets/sapbtp $ ls -alt
total 8
drwxr-xr-x 5 root root 4096 Sep 11 21:39 .
drwxr-xr-x 3 root root 4096 Sep 11 21:39 ..
drwxrwxrwt 3 root root 460 Sep 11 21:39 customer-connectivity-instance-rcc-882-launchpad-acc-binding
drwxrwxrwt 3 root root 480 Sep 11 21:39 customer-destination-instance-rcc-882-launchpad-acc-binding
drwxrwxrwt 3 root root 560 Sep 11 21:39 customer-xsuaa-instance-rcc-882-launchpad-acc
/etc/secrets/sapbtp $ cd customer-destination-instance-rcc-882-launchpad-acc-binding/
/etc/secrets/sapbtp/customer-destination-instance-rcc-882-launchpad-acc-binding $ ls -alt
total 4
drwxr-xr-x 5 root root 4096 Sep 11 21:39 ..
drwxrwxrwt 3 root root 480 Sep 11 21:39 .
drwxr-xr-x 2 root root 440 Sep 11 21:39 ..2023_09_11_21_39_04.3874069286
lrwxrwxrwx 1 root root 32 Sep 11 21:39 ..data -> ..2023_09_11_21_39_04.3874069286
lrwxrwxrwx 1 root root 16 Sep 11 21:39 .metadata -> ..data/.metadata
lrwxrwxrwx 1 root root 15 Sep 11 21:39 clientid -> ..data/clientid
lrwxrwxrwx 1 root root 19 Sep 11 21:39 clientsecret -> ..data/clientsecret
lrwxrwxrwx 1 root root 22 Sep 11 21:39 credential-type -> ..data/credential-type
lrwxrwxrwx 1 root root 19 Sep 11 21:39 identityzone -> ..data/identityzone
lrwxrwxrwx 1 root root 29 Sep 11 21:39 instance_external_name -> ..data/instance_external_name
lrwxrwxrwx 1 root root 20 Sep 11 21:39 instance_guid -> ..data/instance_guid
lrwxrwxrwx 1 root root 20 Sep 11 21:39 instance_name -> ..data/instance_name
lrwxrwxrwx 1 root root 17 Sep 11 21:39 instanceid -> ..data/instanceid
lrwxrwxrwx 1 root root 12 Sep 11 21:39 label -> ..data/label
lrwxrwxrwx 1 root root 11 Sep 11 21:39 plan -> ..data/plan
lrwxrwxrwx 1 root root 11 Sep 11 21:39 tags -> ..data/tags
lrwxrwxrwx 1 root root 15 Sep 11 21:39 tenantid -> ..data/tenantid
lrwxrwxrwx 1 root root 17 Sep 11 21:39 tenantmode -> ..data/tenantmode
lrwxrwxrwx 1 root root 11 Sep 11 21:39 type -> ..data/type
lrwxrwxrwx 1 root root 16 Sep 11 21:39 uaadomain -> ..data/uaadomain
lrwxrwxrwx 1 root root 10 Sep 11 21:39 uri -> ..data/uri
lrwxrwxrwx 1 root root 10 Sep 11 21:39 url -> ..data/url
lrwxrwxrwx 1 root root 22 Sep 11 21:39 verificationkey -> ..data/verificationkey
lrwxrwxrwx 1 root root 16 Sep 11 21:39 xsappname -> ..data/xsappname
/etc/secrets/sapbtp/customer-destination-instance-rcc-882-launchpad-acc-binding $ cat type | grep connectivity
/etc/secrets/sapbtp/customer-destination-instance-rcc-882-launchpad-acc-binding $ cat type
destination/etc/secrets/sapbtp/customer-destination-instance-rcc-882-launchpad-acc-binding $Hi @I551317,
Please ignore my earlier questions.
Unfortunately, handling OnPremise connectivity on Kyma is still a bit challenging. We outlined two possible approaches that we found working in our documentation:
Have you seen the document already? Can you try out one of the two approaches (trusted / untrusted)?
Kind regards Alex
I551317
commented
1 year ago Yes, I saw the documentation and before raising the issue I've tried to find the answer there (the page that you point to and the one focused on the destination). I've tried the approach without Transparent Proxy as that fulfils our current needs and suppose to be simpler in configuring.
What I've also just noticed is that trying to call Destination Service via AppRouter (not using SAP Cloud SDK) with following routing configuration:
{
"source": "/dest/(.*)",
"destination": "Hello",
"authenticationType": "none"
},app router returns an error that looks similar to the one that comes from SAP Cloud SDK
Of course it may be coincidence, though I'm not sure if sth is missing in the configuration.
newtork
commented
1 year ago Unfortunately we (Java developers) can't comment on approuter behavior. And after speaking with the team, we can't draw a conclusion from the observed error.
However if you are using the "without transparent proxy" approach then to our knowledge you would need to go with the
It would require you to create a custom Kubernetes secret as explained in the linked page.
Kind regards Alexander
I551317
commented
1 year ago Sure, I posted approuter findings as it might suggested some common problem.
Going back to the topic: thanks for pointing to this documentation. At the moment as I managed to achieve required behavior using approuter we are temporary proceeding with that approach. However as I noticed a few details working on that approach that may be common for SAP Cloud SDK configuration as well, later on I will try to check if they solve this issue here for mentioned library too and post it for others/to have some conclusion here
I551317
commented
1 year ago When it comes to the other approach defaultMode was one of the problems and proper secret paths that were binded another one. With those fixes Destinations started to be visible for AppRouter scenario, however testing that for SAP Cloud SDK library it still ends with the same problem. As at the moment seems that we have sufficient alternative solution we decided to park further investigation of this approach and this ticket can be closed
I would like to consume in my Java application Destination Service using SAP Cloud SDK DestinationAccessor.getDestination() however configuring that according to the following documentation I'm getting following exception
Destination service with name "Hello" is correctly added to my BTP account (check status is OK) and I'm additionally adding and binding both: destination service and connectivity proxy using helm script in following way:
deployment:
Versions:
Could you guide me how to solve following problem and check above "Failed to configure on-premise proxy for destination 'Hello'. Please make sure to correctly bind your application to a service instance.".