How better can I escape XML special chars from the context variable value?

[Raju Gurram]

Using CA API Gateway assertions, I would like to escape special chars (>, <, &, ...) from my context variable values. If my data arrives as JSON, JSON to XML transformation does take care of the same. But, what if the URI and Query Parameters hold my partial input containing all these special chars. I cannot use them as it is inside the XML message. I could expect there's something similar to Encode/Decore Data assertion to do this job.

 

thanks,

Raju

[Doyle_Reece]

Hey Raju,

I believe what you're looking for is the 'encode/decode Data' assertion using the 'URL Encode' Encoding Type.

 

[Raju Gurram]

I appreciate your time. But I don't think this will fit my scenario. We can use this assertion if the data to be sent/received via URL. What if the destination is BODY and the format is XML. We cannot encode the data using URL encoding rules.

 

thanks,

Raju

[Ben_Urbanski]

Here's an example of using regular expression assertions to escape XML (policy export attached):

 

Attachment(s)

Escaping XML.xml.zip   1 KB 1 version

[Raju Gurram]

Thanks for the reply. It is surprising to me that we have no native support (single assertion which does the job) yet to such an obvious scenario. Wouldn't be good idea to have separate assertion for the same? For performance reasons, would you recommend to have custom assertion in place of these series of REGEX assertions? I think I'm asking too (2) many questions.

 

thanks,

Raju

[Ben_Urbanski]

I agree that it would be nice if our existing Encode/Decode Data assertion included XML escaping, though surprisingly, XML escaping has not been a common requirement across customers in the many years that I've been working with the gateway. I suggest you submit that idea to the community, so it can be added as an enhancement request to our roadmap.

 

Regarding using a custom assertion instead, it's doubtful that you would see much, if any, performance improvement versus the handful of simple regular expression assertions. It's not likely that it would justify the additional complexity of creating and managing a custom assertion in your environment. Frankly, while custom assertions are a really neat way to extend your gateway, they're almost never needed and are rarely a good alternative to policy, policy fragments and encapsulated assertions. It's my opinion that it's not appropriate to use a custom assertion in this case, but you may want to consider creating an encapsulated assertion that wraps the sample policy shared above.

[Raju Gurram]

Thanks for your valuable directions on it. I would definitely consider alternative (encapsulated) first to the custom assertions.