SAP Cloud Integration — URL escaping hack

[vbalko-claimate]

Problem description

Recently, I received a ticket from a customer regarding an integration flow that had been running smoothly for a long time but suddenly ended in error.

After a brief analysis, I identified the source of the problem: a special character in the URL value of the sender HTTP adapter.

Example URL:

http://<host>:<port>/sap/opu/odata/<service_name>(<attr_name>='abcd/1')

The issue arises from the slash character in the value for <attr_name>. Even though it is enclosed in parentheses—indicating that its value should be ignored or encoded—it is interpreted as a functional character for dividing URL path segments instead of being part of the <attr_name> value.

Note: The same problem occurs with the ‘?’ and ‘&’ characters since they also function as special characters in URLs. However, other characters like ‘’, ‘,’ etc., are typically URL-escaped and processed correctly by the HTTP adapter.

Initially, the slash character was not part of the value, but issues began when it started being included. This change likely happened due to an update in the data or how URLs were constructed.

Problem resolution

The solution to such problems is to escape those characters. However, when dealing with special functional characters (‘/’, ‘?’, ‘&’), simple escaping doesn’t work. For instance, using ‘%2F’ for ‘/’ results in an unescaped ‘/’ in the final URL string, causing an error. Similarly, escaping with a backslash (as in regex) like ‘/’ results in ‘%5C/’, where the backslash is additionally escaped by the HTTP adapter, but the slash still appears as ‘/’.

I tried several variations and tricks to escape it, but without success. Finally, I found an SAP Ticket that provided the solution: SAP Note 0003131448.

The key to the correct solution is to escape the slash character itself (%2F in my case), and according to the ticket, also escape the ‘%’ character (%25). Thus, the correctly escaped slash is in the form of

%252F

which changes to

%2F

after the first unescape (decoding). This is the desired result.

So the whole URL should be in a form of

http://<host>:<port>/sap/opu/odata/<service_name>(<attr_name>='abcd%252F1')

The ticket also mentions that there are three rounds of decoding, but in my version of the HTTP adapter, only one round takes place, so only one ‘%25’ is necessary.

Additional Explanation

URL encoding (or escaping) converts characters into a format that can be transmitted over the Internet. URLs can only be sent over the Internet using the ASCII character set, so URL encoding converts non-ASCII characters into a ‘%’ followed by two hexadecimal digits. For example, a space is encoded as ‘%20’. The decoding process reverses this, converting ‘%20’ back to a space.

Conclusion

I must say, this behavior is rather unexpected and non-intuitive, and the workaround is of the same nature. However, there is at least some workaround available.

DISCLAIMER: This blog post can be found on my other blog https://medium.com/@vbalko/sap-cloud-integration-url-escaping-hack-34a45f5a1f37 

[AleGuarneri]

SAP Note 0003131448 is wrong. One more encode is enough

e.g. for / (fw slash) it's gonna be %252F

[AleGuarneri]

def str = "N/A"
str = URLEncoder.encode(str, "UTF-8")
str = URLEncoder.encode(str, "UTF-8")
println(str)

N%252FA

[vbalko-claimate]

@AleGuarneri , Yes, I`m writing it in my blog. One round is enough

[AleGuarneri]

We shall agree that this is a serious and trivial bug in the standard HTTP Receiver Adapter… for what it’s worth I also mentioned it as a comment in the SAP KB article…

I love SAP BTP Integration Suite but now and then you catch how young it is.