It dove into the world of Datapower contexts and what I call the ‘magic’ XSLT functions that datapower adds on. I consider things like dp:prioritiy, dp:variable to be a part of these add-ons.

Example: Printing the headers you can access them via: dp:variable(“var://service/header-manifest”)

When there are multiple match rules in rules, it is “one and done”. You do not continue to execute the next one if two rules have the same match. I blew this question on the cert test, oops 🙂

I like sessions like this where they go through real examples like this one. Theory is only good when you aren’t the last guy in the chain who needs to do the implementation.

‘ dp:responding()=false()’ -> This is a request message. It’s true if we are responding to a message.

dp:request-header(‘IT’) -> Get the header named ‘IT’

<xsl:message dp:priority=”debug”>Log test</xsl:message>

<dp:reject> Reject a message

Question from the crowd: ‘Does dp:requestHeader work for HTTP?’ Answer: “Yes”. “Can I use it all the time?” Answer: “Yes”.

<dp:freeze-headers/> => Allows headers to be sent to backend. An efficiency technique you can use to optimize the writing of output to the output stream. Tells the datapower box that any output after this will be body content.

<dp:url-open target=’url’ …response=’resp’> resp will contain the reponse content.

dp:generate-key(‘..w3.org…) to generate a session 3DES keys.

dp:encrypt-data(‘…’) to encrypt message contents.

These data power extension elements are the back-end runtime glue that the UI uses as needed. You can likely do what you need to do without having to add these into an XSLT transform, but they can give you the power to go beyond the GUI as required.