Event Mesh Webhook can't handshake or connect to CAP Application

[DanielKawkab]

Hello fellow devs,
right now we are trying to build an BTP scenario, including Event Mesh, CAP, and HANA Cloud.

The CAP App is working and is correctly creating the queues and topics in the Event Mesh Service. A Webhook is also created, but this is basically where the problem lies.

The webhook is getting created with the URL "https:<appname>-app.cfapps.eu10.hana.ondemand.com/messaging/enterprise". Unfortunately the handshake isnt working at all.

The Url-path "/messaging/enterprise" seems strange to me, but in the source files i saw that its generated by default. So i guess CAP should somehow be able to react to request on this path. (?)

Shouldn't CAP be able to react to the options-request (webhook-request) by itself? I also tried to create a webhook manuelly, where i can exempt the handshake. Unfortunately the communcation is still not working. In the event mesh cockpit i can see a reason for the communication not being successful:

I do not have any authentication infront of my service or CAP application. What i did to recieve the event is the following:

    const messaging = await cds.connect.to('messaging');
<br>    messaging.on('<topic-name>', async msg => {
        let message = JSON.stringify(msg);
        console.log(message)
    })

The configuration in my package.json should be correct. If it weren't i shouldnt be able to connect to event mesh and the queues, topics and webhooks shouldnt be created.
I can also see, that the queue is filling when im calling then function i provided for emitting the event. So this part is working aswell.

Am i missing something? Do i have to provide a custom server to recieve the events? Or does it maybe has something todo with the deprecated "dev"-serviceplan of the BTP Trial event mesh service?

The App is deployed on a BTP Trial CF. Im using the App as the sender and receiver.

Thanks in advance!
Daniel

[martinstenzig]

Are you trying to run it locally? I have tried the webhook approach and it it functions well once deployed, but it does not work locally (unless you have a public address). Based on this thread (https://answers.sap.com/comments/13382027/view.html) I switched to AMQP by changing the package.json to

  "cds": {
    "requires": {
      "messaging": {
        "kind": "enterprise-messaging-shared"
      }
    }
  }

That seems to work even better as you can start your CAP project locally and get the subscriptions into your local machine.

[DanielKawkab]

Hello Martin,
im running it deployed on a BTP Trial CF.

[david_kunz2]

Hi Daniel,

Yes, as said by Martin, if you run your app locally you must make sure to have a public URL address, otherwise Event Mesh will not reach you via HTTP (you can e.g. use ngrok). For local development, you must set the environment variable VCAP_APPLICATION to contain `{"application_uris": ["<your_uri>"]}`, here you need to write your base url.

If you start your app, do you receive an `OPTIONS` call (this is the handshake from Event Mesh)?

If you don't run locally:

> The Url-path "/messaging/enterprise" seems strange to me, but in the source files i saw that its generated by default. So i guess CAP should somehow be able to react to request on this path. (?)

Yes, this is expected, we automatically create the endpoint to receive messages.

> Shouldn't CAP be able to react to the options-request (webhook-request) by itself?

Yes, it should!

> In the event mesh cockpit i can see a reason for the communication not being successful:

What is the reason?

> Do i have to provide a custom server to recieve the events?

No, just a handler for the messages (as you already wrote). Can you provide more infos on your project (file structure, where you put your handler, your package.json file)?

Thanks and best regards,
David

[DanielKawkab]

Hi David,
thank you for your comment!

First of all: Since im using the BTP Trial for this, is it possible that the problem has some connections to the deprecated "dev"-service plan available there? As far as i know we dont have the option to create the "default"- service plan there.

> >In the event mesh cockpit i can see a reason for the communication not being successful

>What is the reason?

HTTP 401, even tho i have to authorization in front of my CAP service.

>> If you start your app, do you receive an `OPTIONS` call (this is the handshake from Event Mesh)?

I don't see any OPTIONS request in the application logs or events. But i did re-trigger the handshake manually in the Event Mesh cockpit. Unfortunately that doesnt help.

>> Can you provide more infos on your project (file structure, where you put your handler, your package.json file)?

file structure:

The handler is located in the receive-service.js file.

package.json :

{
  "name": "<appname>",
  "version": "1.0.0",
  "description": "",
  "dependencies": {
    "@sap/audit-logging": "latest",
    "@sap/cds": "^5.4.5",
    "@sap/xb-msg-amqp-v100": "latest",
    "@sap/xsenv": "latest",
    "@sap/xssec": "latest",
    "express": "^4",
    "hdb": "^0.18.3",
    "passport": "0.4.1",
    "uuid": "^8.3.2"
  },
  "devDependencies": {
    "@sap/hdi-deploy": "^4.2.0",
    "sqlite3": "^5"
  },
  "scripts": {
    "genres": "cds serve test/genres.cds",
    "start": "cds run",
    "watch": "cds watch",
    "build": "cds build/all"
  },
  "cds": {
    "requires": {
      "db": {
        "kind": "hana"
      },
      "messaging": {
        "kind": "enterprise-messaging"
      },
      "uaa": {
        "kind": "xsuaa"
      }
    },
    "hana": {
      "deploy-format": "hdbtable"
    }
  }
}

[david_kunz2]

Hi Daniel,

Thanks for providing this info! I'm assuming the endpoint url in your webhook configuration is the same as the one of your running app?

tobias.griebe , do you know why there's no `OPTIONS` call, does it have something to do with the `dev` plan?

Thanks and best regards,
David

[DanielKawkab]

Hi David,
It just has the /messaging/enterprise-messaging path in it. But that is, as you said, correct.

Thanks,
Daniel

[Tobias_Griebe]

Hi,

david.kunz2 I just verified that the OPTIONS call is also sent when using the webhooks of the 'dev' plan.
So there is no different behaviour from Event Mesh side expected.

Best regards,
Tobias

[david_kunz2]

Hi tobias.griebe , Thanks a lot for verifying! Does it also work if a token endpoint url is provided? Maybe the webhook has problems generating a token. Note: We use the XSUAA credentials of the Event Mesh service binding for that, VCAP_SERVICES -> enterprise-messaging -> messaging[ protocol[0] = 'httprest' ] -> oa2

        "clientid": "xxx",
        "clientsecret": "xxx",
        "granttype": "client_credentials",
        "tokenendpoint": "https://xxx.sap.hana.ondemand.com/oauth/token"

Hi danielkawkab ,

Yes, the path `messaging/enterprise-messaging` is correct, is also the base url correct (the red part in your screenshot)? Can you trigger an OPTIONS call manually and check if it appears in the logs of your app?

Thanks and best regards,

David

[DanielKawkab]

Hi david.kunz2,
the path is correct yes. Just now i could see that the options request is sent to the app. I could find the request in the application logs. The following error log appears:

2021-09-20T22:24:44.310+0000 [RTR/26] OUT e7085cfdtrial-dev-<appname>.cfapps.eu10.hana.ondemand.com - [2021-09-20T22:24:44.246116735Z] "OPTIONS /messaging/enterprise-messaging?q=gxp-cap-srv-app/65e1 HTTP/1.1" 401 0 12 "-" "SAP Event Mesh REST Gateway" "-" "10.32.3.11:61087" x_forwarded_for:"-" x_forwarded_proto:"https" vcap_request_id:"a25a4464-1c52-431c-6f2f-4535d2d75ce3" response_time:0.064209 gorouter_time:0.000092 app_id:"65e11d31-b9c6-4da9-89a1-cdd719423caa" app_index:"0" x_cf_routererror:"-" x_correlationid:"-" tenantid:"-" sap_passport:"-" x_scp_request_id:"af91569c-7896-49d2-8361-62ad4fdee092-61490A2C-182B195" x_cf_app_instance:"-" x_forwarded_host:"-" x_custom_host:"-" x_ssl_client:"-" x_ssl_client_session_id:"-" x_ssl_client_verify:"-" x_ssl_client_subject_dn:"-" x_ssl_client_subject_cn:"-" x_ssl_client_issuer_dn:"-" x_ssl_client_notbefore:"-" x_ssl_client_notafter:"-" x_b3_traceid:"1b539f590e8faa76" x_b3_spanid:"1b539f590e8faa76" x_b3_parentspanid:"-" b3:"1b539f590e8faa76-1b539f590e8faa76"

Seems to be an authorization problem.

Thank you,
Daniel

[david_kunz2]

Hi Daniel, thanks for the info. The option to accept granted authorities is needed to accept the generated tokens in CAP.

Hi tobias.griebe,

Do you know why this isn't possible in the dev plan?

Thanks and best regards,

David

[david_kunz2]

Oh, that's bad, then we won't accept tokens generated by Event Mesh using the dev plan and therefore webhooks won't work at the moment.

danielkawkab , could you switch to the AMQP protocol (using `enterprise-messaging-shared`)?

[david_kunz2]

The alternative is that you don't bind an XSUAA service to your application (in case you don't want to have any security at all).

[DanielKawkab]

Hi david.kunz2,
i think i will just use an productive account as soon as i have access to it.

Still, thank you many many times for clarifying!!

Best regards,
Daniel

[david_kunz2 · Accepted solution]

Hi Daniel,

Thanks for clarifying. Yes, it seems to be an authorization problem. Did you bind your application to XSUAA? If yes, then you must grant the necessary scope to tokens generated by the XSUAA instance of Event Mesh.

So you need this scope in your settings for your own XSUAA:

{
  ...,
  "scopes": [
    ...,
    {
      "name": "$XSAPPNAME.emcallback",
      "description": "Event Mesh Callback Access",
      "grant-as-authority-to-apps": [
        "$XSSERVICENAME(<SERVICE_NAME_OF_YOUR_EVENT_MESH_INSTANCE>)"
      ]
    }
  ]
}

and in the service descriptor of Event Mesh you need to add the following:

{...,"authorities":["$ACCEPT_GRANTED_AUTHORITIES"]}

Best regards,
David

[DanielKawkab · Accepted solution]

Hi david.kunz2,
i added the scope for the xsuaa. The xs-security.json in its current state:

{
  "xsappname": "p36/gxp/poc/receiver",
  "tenant-mode": "dedicated",
  "scopes": [
    {
      "name": "$XSAPPNAME.emUser",
      "description": "emUser"
    },
    {
      "name": "$XSAPPNAME.emcallback",
      "description": "Event Mesh Callback Access",
      "grant-as-authority-to-apps": ["$XSSERVICENAME(em_gxp_poc)"]
    }
  ],
  "attributes": [],
  "role-templates": [
    {
      "name": "emUser",
      "description": "generated",
      "scope-references": ["$XSAPPNAME.emUser"],
      "attribute-references": []
    }
  ]
}

Unfortunately the parameters will not be recognized as an parameter in the service descriptor:

I noticed the same behaviour for the "version"-parameter of the instance descriptor. I think i read in the documentation, that this is because of the dev plan.

Adding the scope to the xsuaa didn't change anything 😞 The options call still results in a 401 error.

Best regards,
Daniel

[Tobias_Griebe · Accepted solution]

Hi david.kunz2,

unfortunately this feature is not supported by the DEV plan. 😞

Best regards,
Tobias