The power of correct encoding - pass EMS-events through a CPI-iFlow in a cloud integration-toolchain

[drvup]

Let's talk about the power of correct encoding! If you assume that this is no big issue, keep reading! This article is about a part of our integration-toolchain, working with 2 SAP Cloud Platform Services and connecting tenants of the business suite to final consumers.

 

SAP Cloud Platform Services in use

EMS: Enterprise Messaging Service

CPI: Cloud Platform Integration

 

Our use case

We do have a simple use case - provide all events, coming from a tenant of the SAP Cloud Business suite (e.g. S/4 HANA Cloud tenant), to a corresponding EMS queue.

Therefore, we're using a central-message-inbox. All events coming to this queue, will be forwarded by a 'hook' to an iFlow, created in the CPI. This iFlow acts like a dispatcher:



* This graphic is done by myself and does not represent any 'official integration toolchain'. It's based on SAP graphic material to explain the used services in our landscape.

 

The iFlow will read the payload of the event and based on rules decide, which target-queue is the event corresponding to.

Example: All master data events will be passed to a target queue, called "master data".

Other example: All events corresponding to a specific company code can be forwarded to a target queue for this company code.

 

Enterprise Messaging Service (EMS)

Setting up the EMS instance with the 'new' 'default-plan' requires a namespace, to be provided in the json string by creating the instance in the space of your Cloud Foundry (CF) subaccount.

{

	"emname": "my-ems-instance",

	"namespace": "ems/abc/all",

	"options": {

		"management": true,

		"messagingrest": true,

		"messaging": true

	},

	"rules": {

		"queueRules": {

			"inboundFilter": [

				"${namespace}/#"

			],

			"outboundFilter": [

				"${namespace}/#"

			]

		},

		"topicRules": {

			"inboundFilter": [

				"${namespace}/#"

			],

			"outboundFilter": [

				"${namespace}/#"

			]

		}

	}

}

This namespace requires 2 slash-characters '/', this will be a challenge later!

In the new created ems-instance "my-ems-instance" of your CF space, I did create the central inbox queue and a target queue as well.

In the inbox queue I did add the entry for the hook to the CPI iFlow, so every message send to this queue will be forwarded directly.



 

Cloud Platform Integration (CPI) - Dispatcher iFlow

The dispatcher iFlow is doing some filtering and transformation, based on your rules defined in the iFlow. At the end we need to forward the message to another queue of our EMS-instance, this isn't that simple.

 

Why?

With the 'default-plan' of EMS, it's required to provide a namespace and this namespace uses '/'- characters. Sending events to this queues, using postman or other clients, it's required to escape / encode the slashes of the URL, we want to send: "/" = "%2F":



Okay. Knowing his, should be easy to migrate this to the CPI iFlow .... no.

 

Tripple encode required

Our iFlow wasn't working with the same URL, the CPI was automatic resolving the encoded path to slashes, and therefore we got http 404 error back from Enterprise Messaging Service.

I reached out to OSS and got a reply, that we need to tripple-encode:

"Instead of using %2F in the URL, please use %2525252F. "%25" is the encoding for the character "%". Since, HTTP receiver does decoding three times, after first time decoding, URL will contain %25252F ,after the second time, it will be %252F and finally "%2F" which is the required entity in the URI.

If you're using dynamic parameters in the URL, you need to do extra encoding only once."

That 'simple' solution was our final goal. We were able to resolve the issue in our iFlow:



 

Conclusion

Knowing the way to encode, it's an easy journey to use this opportunity of integration to filter and dispatch EMS events by using a CPI iFlow. Both SAP Cloud Platform Services are doing a good job and providing us a simple to use integration-toolchain.

So, happy dispatching!