Hi there “Process Automation” fans,

Welcome to a new installment of “Process Automation” tips.

Last month we saw something strange in the return value of a complex XPath expression for the mapping in a BPM instance. We saw it only in the production environment (via the messagemap resource on a BPM instance) at our customer where Dev, Test, and Acceptance all gave the same, yet different, result! #WTF…Indeed, that was our first reaction too! Because the deployment of the solution (via CAP files) was at the same version across the environments, we were sure it was some setting on the server. After long questioning at the administration team (as we can’t access it ourselves) it became clear that a small timezone setting was different on production! Aha…So, “equal” is not always as equal as we think it is!? Now the great question we want to find an answer for in this post: How can we double-check on production our XPath expression once the server setting is set equal again?

Let’s get right into it…

Boot up your OPA VM and jump into your workspace with corresponding project. There we start with a simple one-activity BPM executing the service GetAllUsers; It’s just that we have some data in the messagemap. I make the BPM “production” ready with the correct monitoring levels:

It’s always good to start with good habits; These monitoring levels are a good start for any BPM. It stores the complete flow to have it visible in the PIM artifact and shows extra details once things go wrong.

Now start an instance of the BPM via <F12> (if you’re still in the BPM designer). Watch the PIM artifact for the instance, but conclude you have a disabled “view messagemap” button!

Now raise the valid question: How do we see the full messagemap for the instance? Well, first the way of how to NOT do it! That’s changing the monitoring levels again in the BPM itself! You always forget to set them back and there is a better way…The production way! Open the artifact ‘Deployed Process Models’ and customize the monitoring level to a new level:

Set it to the required level as shown below:

I do it now in DEV, but this also works in production. So, your DEV-team delivers BPMs with the minimal monitoring level and the administration team can raise it when needed. Be carefully too, as the full messagemap can log a lot of data! Never forget to revert the config back to the default delivered level.

With this change, we can now start new instances of our BPM (with <F12> again) and watch the messagemap from the PIM artifact:

Copy the messagemap and open the messagemap of the activity in our BPM; The one with GetAllUsers. Create a mapping that includes the “usage” option:

Now click on the expression editor, open the XML-tab where you replace to current messagemap with the one you just copied! Yes, this a free pro-tip…Keep on reading as you can now validate your XPath expression with real data from a BPM instance…Aha! 🤗

Let’s update the XPath to something interesting:

substring-after(substring-before(instance:instanceProperties/instance:currentOwner/text(), ',cn='), 'cn=')

The result is now opadev@opa required as input for our webservice, but let’s say the administration team concludes (from the messagemap) that the XPath gives a different result in production!?!? WHAT!? Yes, for this example the chance is small, but we’ve seen the strangest things passing by for our beloved platform (especially with dates, times, and zones!), but how to evaluate the XPath in production where we don’t have this expression editor available with the ‘Test’ button? Now we’re talking…watch and learn!

…

Make your way to the expression editor (in DEV for your BPM), open the developer console of your browser (that’s also <F12>; so, watch it to not start an instance!), hit the ‘Test’ button, and check the result:

This is the XML cleaned for readability:

1
2
3
4
5
6
7
8
9
10
11
12

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
    <!--<SOAP:Header xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">...</SOAP:Header>-->
    <SOAP:Body>
        <EvaluateXPath xmlns="http://schemas.cordys.com/bpm/modeling/1.0">
            <source>
                <!--<messagemap>...</messagemap>-->
            </source>
            <xpath>substring-after(substring-before(instance:instanceProperties/instance:currentOwner/text(), ',cn='), 'cn=')</xpath>
            <!--<namespaces>...</namespaces>-->
        </EvaluateXPath>
    </SOAP:Body>
</SOAP:Envelope>

You see what I see!? Yes, that’s our XPath expression and the messagemap as “source”…NICE! 😎

Watch the full XML payload here

Interesting, as this is just a service call to EvaluateXPath which we can also find in the ‘Web Service Interface Explorer’ artifact…AHA! AND indeed, this artifact does exist in production!!

Where are you waiting for? Test it and paste in your request XML (you can remove the <SOAP:Header> element) from the previous developer console! After the ‘Invoke’, you can find the result to evaluate correctness:

You can even update the value of the <xpath> element to see what the correct expression should be, but as administrator it’s a best practice to send back the messagemap to the developers to further investigate. Once you also conclude it’s some server setting thing causing the difference, you simply change it and invoke the service call again to see if it has an influence on the response.

A great “DONE” where we finally found a straightforward way to see if an XPath expression on production gives the correct result. When server settings are not equal, you want to have a plan to assess it once the administration team changes the setting! Well, now we have the answer available to prove the administration did a fantastic job. Have a good weekend and till next week with another topic on “Process Automation Tips”.

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 Process Automation guy”?