Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

2 weeks ago, we saw an interesting post online with the title “Danger; the hidden menace lurking in your “Case Management System”. There was nothing wrong with the post itself, but it challenged me (myself, and I) to make it better (after collaboration in our group of specialists)! And boy, did we find out some interesting things…AGAIN!

Let get right into it…

Where did the discussion start? Well, after a quote that it should be possible to send in the whole XML part instead of unwrapping the XML elements with the string(...) function as explained in the linked post of the introduction! Now we’re talking…We raised the bar! 😉

So, what DO we want? Well, we want to move from:

1
2
3
4

nl.bos.appworks.utilities.Utilities.matches (
 string(ns2:Readsaved_searchOutput/ns2:Readsaved_searchResponse/ns3:saved_search/ns3:ss_reg_ex/text()),
 string(instance:iterator_case)
)

…to an expression like this:

1
2
3
4

nl.bos.appworks.utilities.Utilities.matches (
 string(ns2:Readsaved_searchOutput/ns2:Readsaved_searchResponse/ns3:saved_search/ns3:ss_reg_ex/text()),
 instance:iterator_case
)

See the missing string() method in de second parameter; This will pass the XML structure!

Making the switch gives you an error the expression does not match the method parameters of our function!? So, we need to update (or better), create a new function that will except the input; How? Well, after some debugging and playing around, my first try was like this:

1
2
3
4
5
6
7

public static boolean matches(String regex, int xmlInput) {
    if(logger.isDebugEnabled()) {
        logger.debug(xmlInput);
        logger.debug(Node.writeToString(xmlInput, true));
    }
    return matches(regex, Node.writeToString(xmlInput, false));
}

When you are familiar with the AppWorks SDK, you understand why ‘int’ would be an excellent choice to start with. AppWorks does something magic behind the scenes to convert XML into an integer which we can convert with a ‘Node’ object in Java. It requires native calls to shared libraries (or DLL files in Windows) to make it happen (specifically eibxml.dll and relatives), but it works…At least from a JUnit standpoint (see the code on GitHub). Only, we want to call it from a BPM and that’s an unclear failure!

This does work:

1
2
3
4

nl.bos.appworks.utilities.Utilities.matches (
 string(ns2:Readsaved_searchOutput/ns2:Readsaved_searchResponse/ns3:saved_search/ns3:ss_reg_ex/text()),
 1
)

…But the 1 is not a valid ‘Node’ object input to convert it (you’ll get an error…trust me!). It looks like the expression (in BPM) is always sending back a list of data; Or better, a ‘NodeSet’ of data; Sounds logic as I always see this passing by when I assess it (recognizable?): <!-- X result on current test data: -->. To make a long story short, let’s update our method signature like this: public static boolean matches(String regex, NodeSet nodeSetInput) {...}

This works smoothly, but now we need to move the ‘NodeSet’ data into a ‘String’ object…That’s exactly what you’ll find in the final version.

An updatable “DONE” which works much smoother compared with the public method from the previous post. When I recap my knowledge, the SDK details were already in place! Only, it didn’t “click” yet into the mindset of using it like the above example…AND this is also exactly why you need to find your buddies that have the same mindset to help each other in that creative thinking process. So, thank you for thinking with me (you know who you are!). Have a great weekend…Till next week. Cheers!

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?