How to setup Webhook subscription in Event Mesh to send messages to CPI for AMQP sender adapter

[vinaykumardigaveedi]

Hello Experts,

We need to replicate Quotes from SAP CPQ --SAP BRIM via CPI using Event Mesh.

We have a standard iflow for this Where Event Mesh is used as sender and AMQP is used as Sender Adapter.

The iflow is deployed successfull and we don't have end point created for iflow.

We are able to get messages from CPQ-->Event Mesh.

How do we push messages from Event Mesh to CPI, I created a Separate Instance for CPI as well.

How to create Webhook Subscription in Event Mesh for CPI. What should be provided in Webhook URL?

Thanks,

Vinay

[Tobias_Griebe]

Hi vinaykumard,

the recommended way to connect CPI with Event Mesh is to use the AMQP adapter. This can also be used as input adapter to start your iFlow.

mandy.krimmel has written a great bog post describing the details: https://blogs.sap.com/2019/11/20/cloud-integration-connecting-to-external-messaging-systems-using-th...

If you would like to use the webhooks, you would need to expose a REST endpoint from CPI as the input adapter. Still I would strongly recommend you to use AMQP instead.

Best regards,
Tobias

[vinaykumardigaveedi]

Hi tobias.griebe ,

We are using AMQP sender adapter itself in the iflow.

If we use AMQP sender adapter, you mean webhook subscription is not necessary to be created in Event Mesh Instance

Thanks,

Vinay

[Tobias_Griebe]

Hi vinaykumard,

somehow you need to start your iFlow, correct? For that you should use the AMQP adapter as decsribed in Mandy's blog.

Once you deploy your iFlow CPI will establish a connection to Event Mesh and subscribe to the queue. Whenever there is a message stored in your queue, this triggers your iFlow. As such CPI is in control of the connection and also the flow control.

Using the webhook is just a different approach: CPI needs to expose an REST endpoint and Event Mesh will PUSH all the messages to this URL via the webhook functionality.

You need to decide for one or the other approach, where AMQP is the recommended protocol. Using both approaches in parallel with one and the same queue will lead to different unpredictable side-effects as you can consume a message only once out of a queue.

Best regards,
Tobias

[vinaykumardigaveedi]

Hi tobias.griebe ,

From CPQ the messages are coming into Queue created for CPQ in Event Mesh.

We have created another Queue for CPI. Here CPI iflow is successful and we are using AMQP sender Adapter.

We are not getting any messages into SAP CPI.

Could you please help us resolve this issue.

[Tobias_Griebe]

Hi vinaykumard,

I still have a hard time understanding what your issue actually is. Is my understanding correct:

• CPQ send events to EM --> working
• When you say "CPI iflow is successful and we are using AMQP sender Adapter", does this mean CPI sends and event to EM, or do you want to consume events from EM? It sound like something is working?!

For consuming events you obviously would need to use the "AMQP Receiver Adapter".

Are you working with 2 messaging clients (= EM instances), one for CPQ and another one for CPI. As a result, are you having issues subcribing the topics across clients?

Do you get any errors?

[ToMi]

Hi Tobias Griebe,

could you please explain the reason why the AMQP sender adapter is the recommended way to connect Event Mesh to CPI in order to trigger a CPI IFlow? What is the advantage with AMQP in comparison with a webhook subscription and triggering the CPI IFlow with HTTP sender adapter?

In the following SAP literature both techniques are described but the information is missing when to prefer which technique:

- example scenario with AMQP sender adapter in chapter 5.5 "Using Event-driving Messaging"
-> https://www.rheinwerk-verlag.de/sap-cloud-platform-integration-the-comprehensive-guide/

- example scenario with HTTP sender adapter:
-> https://www.sap-press.com/sap-enterprise-messaging_5299/

Best Regards,

Tobias Miller

[Tobias_Griebe]

Hi tobias.miller87,

technically both options are valid.
I would assume that the above linked SAP Press article was written before the AMQP adapter was released by CPI.

When using the webhook feature of Event Mesh, it is EM that is in charge of the flow control. In case CPI is not reachable or CPI is rejecting an event, it's up to the predefined re-try mechanism of the webhook feature when an event gets redelivered. Using the webhooks has also an effect and the occupied resources (connections) on EM.

When using the AMQP adapter, it is CPI establishing the connection to EM. In this case CPI is in charge of the flow control. CPI can define how many events shall be sent in parallel (unacknowledged messages in-flight). Still if CPI is running on multiple nodes, you will have as many connections to EM as you have nodes.

You see there are pros and cons for each approach. I personally would like to have the control on the consumer side if possible.

Best regards,
Tobias

[ToMi]

Thanks Mr Griebe for your fast and valuable reply. I have a last question:

How the polling of the AMQP sender adapter works internally (keyword: "continous consumption" from Manage Integration Content tab)? Is it equivalent to an SFTP sender adapter where CPI polls in a given time interval the sender system or has the AMQP sender adapter a smarter logic (based on the AMQP protocol) that CPI at first gets automatically notified from Event Mesh messaging broker and afterwards polls the event queue? I just want to know how fast a newly event from Event Mesh is transmitted to CPI.

Best Regards,

Tobias Miller

[Tobias_Griebe]

Hi tobias.miller87,

I'm not in the details of the CPI specifics and the SFTP adapter, but I would say it works differently.

When connecting via AMQP the consumer (CPI) establishes a connection. Once this technical connection is established, it subscribes to the topics/queues it is interested to. So again this is initiated by the consumer. Whenever Event Mesh receives an event on the subscribed topic/queue, this is instantly "pushed" to the consumer. So the consumer never needs to poll the event broker.

Hence the transmission is close to realtime/instantly.

Best regards,
Tobias

[ToMi]

Hi Tobias Griebe,

thank you for your explanation. Based on the heading "polling information" from CPI's Manage Integration Content tab I thought that the AMQP sender adapter works on the basis of a pull-based mechanism (1. Consumer asks iteratively "is data ready", 2. Event broker at some time says "Yes", 3, Consumer must pull the message from the queue) and that seems slower to me in comparison to the push-based webhook mechanism. But following your explanation the AMQP sender adapter also works on the basis of a push-based mechanism.

Best Regards,

Tobias Miller