XPath 2.0 string indexof

translate(substring($s,
1,
index-of(string-to-codepoints($s),
string-to-codepoints('_')
)[last()] -1
),
'_',
''
)

How to extend XSLT using built in extension functions. – Intel Software Network Blogs

XSLT 2.0 and to some extent 1.0 are powerful languages when it comes to transforming documents and even for performing some tasks. But, as is often the case, to do something odd or unusual can often be impenetrable or just plain difficult. One of the advantages of using Intel® SOA Expressway is that most of the extension functions we have written to make configuration easier for BPEL based workflow are also available to the XSLT developer.
For those not familiar with SOA Expressway extension functions, they are granular operations that can be performed on the contents of messages or XML / JSON documents which SOA Expressway can embed into XPath or XSLT. What they add up to is a Swiss Army Knife for doing all sorts of useful things, especially when SOA Expressway is used in some message mediation or security mediation capacity.
The range of functions encompasses:

• digest generation (MD5, SHA, etc.)
• exslt functions for dates and regular expressions.
• crypto and canonicalization.
• full digital signature generation and verification.
• encoding and decoding to binary, base64 etc.
• timestamping, UUID generation, random numbers.
• cookie and authentication token handling.
• MIME attachment get and set.

Okay I could go on; there were more than two hundred functions the last time I counted. Go to our site at www.dynamicperimeter.com and request the full documentation set to find out more.
So how does an extension function get used in everyday life?
Here's how to write a message to the transaction log from within your XSLT. I'm assuming you have constructed a basic workflow and already have an XSL Transform action within it.
The basic form would look like this:

<?xml version="1.0" encoding="ISO-8859-1"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" xmlns:soae-xf="http://www.intel.com/soae/xpath/">

<xsl:variable name="log" select="soae-xf:write-transaction-log('info',concat('Transaction ID:  ',soae-xf:get-transaction-id(),'; Comment: ','test',';'))"/>

<xsl:template match="/">

<!-- The variable is parsed lazily and is only evaluated when it is used in the test below. -->

<xsl:if test="$log"></xsl:if/>

<xsl:apply-templates /&g;

</xsl:template>

</xsl:stylesheet>

 There are three parts to remember:
1, Make sure your transform has the soae-xf, exslt or soae-cache namespace declared as appropriate (shown in blue).
2, Declare your Extension Function with a variable. In this case $log (shown in green).
3, Do something with the variable to force the evaluation of the variable. In this case we test $log for some contents. This is a necessary step since one of the performance features of the XSLT engine is lazy parsing which eliminates the evaluation of variables which may turn out to be unnecessary.
Interoperation between the workflow variables and execution steps and the nitty gritty of XSLT is necessary because it gives the developer added flexibility when it comes to mediating messaging in a product that's used as a gateway or ESB.

Chintan Shah's Blog: XSLT Troubleshooting

XSLT Troubleshooting

May be it is just based on my experience, but I feel in general XSLT doesn’t have lot of troubleshooting support. E.g. in Java, no matter what JVM you use, you can pretty much get stack trace (even in NPE errors). In XSLT, based on XML parser you use, sometime you get line numbers and some time you don’t, plus it doesn't provide lot of details in log. Moreover there are not really any good tools to do much troubleshooting. In AIA world, it gets even crazier. Most of the XSLT functions come with AIA just runs only on server side, so you are hopeless and helpless when you want to do some troubleshooting on your local box. It gets even worse, when you get FOTY0001 type errors. Sometime you get more details in log file when there is FOTY0001, and sometime you don't.

Here are couples of ideas which can make your life easier.

1) XSL comment
You can put XSL comment in your code, so it will show up when XSLT is completed. It does help a lot when you are trying to just print values of variables. Pretty much all credit goes to Mahesh Narayanaswamy (absolute XSL genius) for this suggestion.

2) XSL out
This was very cool idea came out of disucssion with Amol Vaidya. XSL comment didn’t help much when XSLT was completely breaking and we were unable to get the line number or the root cause. All we needed is the similar capability like System.out inside the XSL, so we know how far in XSL we went and what are the variables. We just want to get all information before the point of failure. A custom XSLT log function came pretty handy for putting trace log in your XSLT. This way we can get as much information about the XSLT before the point of failure.
We wrote custom XSL function called XSLTLog, and registered that function in BPEL RT and ESB XSL Library.

3) Java code
I also wrote a Java code which can take XML input and execute the XSL. We have to register this Java code to the server as lot of AIA XSL functions relies on server side components. We also took it further to find exact line number in XSL using binary search approach.