For the development of applications on SAP Business Technology Platform we often need multiple services to communicate and work together which sometimes proves to be tricky. In this blog post, I will present a workaround necessary to send messages from a workflow modeled in SAP Workflow Management to a queue of SAP Event Mesh.
At first glance, this does not seem too complicated. Usually, you would take the following steps to make Workflow Management talk to Event Mesh:
The details tab of the service task would then look like this:
You might have noticed that the path configured in the details tab contains the name of the Event Mesh queue which unfortunately contains mandatory slashes. Usually you would simply URL-encode them with %2f as we just did. This approach works e.g. in Postman, but you see that the workflow editor displays an error because the workflow system will encode the path as well and therefore it will end up double encoded which will lead to an error. Also leaving the slashes of the queue name unencoded is not an option because that way each segment of the queue name will be interpreted as a separate URL parameter which also leads to an error and even putting the part with the queue name into the destination leads to the same behavior.
Now we have reached the point where I started googling and found nothing but desperation because at the time when I write this blog post no solution for this problem that I was able to find was publicly documented. To my knowledge, the following solution is right now only described in and incident reported in the BCP system.
The solution is not to transfer the queue name in the URL but in an additional header named x-address. To apply this you need to change the path in the details tab to the following:
and in the headers tab add the header x-address like this:
Disclaimer: I have only tested the first version but according to the BCP incident both should work.
Afterwards your details tab should look something like this:
And your headers tab should look similar to this:
If you configure the service task like this, the message provided in the request variable should be sent to the queue without errors.
I hope this post will save developers who use both Workflow Management and Event Mesh some pain until this workaround reaches public documentation. If there are additional questions I did not cover in this post, feel free to write a comment.
Best regards and happy coding,
Andre
The Intuitive Approach
At first glance, this does not seem too complicated. Usually, you would take the following steps to make Workflow Management talk to Event Mesh:
- Subscribe to the Event Mesh SaaS application and create a service instance of Event Mesh via the Service Marketplace.
- Subscribe to the Workflow Management SaaS application and create a service instance of Workflow via the Service Marketplace.
- Create the queue you want to send messages to in the Event Mesh application.
- Create a service key for your Event Mesh service instance.
- Create a destination to Event Mesh in your subaccount. As authentication type, choose OAuth2ClientCredentials. As URL choose the "uri" from the section of your service key with "protocol" httprest and add the corresponding client id and client secret as well as the "tokenendpoint" as token service URL of the destination.
- Create a service task in your workflow with the following properties in the details tab:
Destination: <Name of the destination to Event Mesh>
Choose a Service from: Others
Path: /messagingrest/v1/queues/name%2of%2fyour%2fqueue/messages
HTTP Method: POST
Request variable: <Context variable which contains your message>
Response variable: <Context variable to save the response in>
The details tab of the service task would then look like this:
- Add the following header in the header tab of the service task
x-qos: 0 or 1
The Problem
You might have noticed that the path configured in the details tab contains the name of the Event Mesh queue which unfortunately contains mandatory slashes. Usually you would simply URL-encode them with %2f as we just did. This approach works e.g. in Postman, but you see that the workflow editor displays an error because the workflow system will encode the path as well and therefore it will end up double encoded which will lead to an error. Also leaving the slashes of the queue name unencoded is not an option because that way each segment of the queue name will be interpreted as a separate URL parameter which also leads to an error and even putting the part with the queue name into the destination leads to the same behavior.
Now we have reached the point where I started googling and found nothing but desperation because at the time when I write this blog post no solution for this problem that I was able to find was publicly documented. To my knowledge, the following solution is right now only described in and incident reported in the BCP system.
The Workaround
The solution is not to transfer the queue name in the URL but in an additional header named x-address. To apply this you need to change the path in the details tab to the following:
/messagingrest/v1/messagesand in the headers tab add the header x-address like this:
x-address: queue://<name of your queue>
or
x-address: queue:<name of your queue>Disclaimer: I have only tested the first version but according to the BCP incident both should work.
Afterwards your details tab should look something like this:
And your headers tab should look similar to this:
If you configure the service task like this, the message provided in the request variable should be sent to the queue without errors.
I hope this post will save developers who use both Workflow Management and Event Mesh some pain until this workaround reaches public documentation. If there are additional questions I did not cover in this post, feel free to write a comment.
Best regards and happy coding,
Andre
- SAP Managed Tags:
1 Comment
