Hi there “Process Automation” fans,

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

Almost forgotten as the idea was to move on with a new topic for this post, but in some spare time I couldn’t resist to do a performance session on a longer for-loop to see who would win; This post compares the BPM engine with the Node-RED engine!

Let get right into it…

We first need a plan which can be simple, but structured testing happens with a plan! So, what do we have so far on our three previous Node-RED posts? We have a long-lived BPM that first retrieves a SAMLart ID (for the current user) and calls our Node-RED flow which calls back the OPA service GetUserDetails with the SAMLart ID for authentication! Agree? That’s our starting point!

What we need for a proper test is some looping which makes the BPM run longer, so we can see a difference in durations. We can do looping in a Node-RED flow, but also in a BPM; After a ReThink I get to these scenarios:

1. We want the current BPM with a loop in the Node-RED flow.
2. We want a copy of the current BPM, doing a loop, and calling the Node-RED flow (with only one loop; So, we can reuse the Node-RED flow!).
3. We want a new BPM doing the looping calls without Node-RED!

To make the test solid, we also want those situations in a short-lived BPM execution mode…Aha! Now we’re getting somewhere.

For a test run, we can use the ‘Test Web Gateway’ artifact calling the ExecuteProcess service call (read here), but we just hit <F12> 10 times from the BPM designer after a publication.

…

Time for the implementation phase where we first start with a loop in the Node-RED flow (download my flow here for you to import). I make a copy of our final set of nodes from the previous post within the current flow including the below described tweaks for the looping part:

Tweaks are:

• Make sure the old set of nodes “listen” to something else than /api; I didn’t try what happens, but I suppose both will trigger!
• I got rid of the ‘Inject’-node; We only want to start from an HTTP POST request.
• The Remap opaUrl ‘Change’-node will initialize a nrOfLoops from my JSON payload and sets a number type of index to 0.
• Two additional nodes to build the if-else-construction over the increasing index; If true, we call the regular path, else sends back the 200-response.

After the changes, you can do a CURL command like this (with the extra nrOfLoops in the JSON data):

1

curl -X POST http://192.168.56.107:1880/api -H "Content-Type: application/json" -d "{\"SAMLartId\":\"...\", \"opaUrl\":\"http://192.168.56.107:8080/home/opa_tips/com.eibus.web.soap.Gateway.wcp\", \"nrOfLoops\":\"2\"}"

Make sure this works properly before you continue and also assess with nrOfLoops=1 to do the regular non/one-loop trick!

When the CURL is working, you can also do the same from the ‘Web Service Interface Explorer’ artifact within OPA design-time on the api operation over the HTTP connector (also from last week with the extra nrOfLoops!):

1
2
3
4
5
6
7
8
9
10

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Body>
      <api xmlns="node_red">
         <opaUrl>http://192.168.56.107:8080/home/opa_tips/com.eibus.web.soap.Gateway.wcp</opaUrl>
         <!--Get it from http://192.168.56.107:8080/home/opa_tips/com.eibus.sso.web.authentication.AuthenticationToken.wcp-->
         <samlArtId>{your_samlart_id}</samlArtId>
         <nrOfLoops>2</nrOfLoops>
      </api>
   </SOAP:Body>
</SOAP:Envelope>

…

Next is the BPM updates and creations where we first move into our previous post BPM which I called bpm_dummy. The BPM itself is still the same, but we want to add the extra input on the nrOfLoops which we can even read from an input message (for flexibility!):

In the api service call we send it out with the rest of the request:

It’s a bit high-over, but you can download my synced OPA project here

Publish it and run the BPM a couple of times with different loop values on the input-popup. After the run, check the debug console in Node-RED and find yourself completed BPM instances in the PIM. This will probably not happen the first time but continue the tweaking as the next step is to copy this BPM (with a “save as…”).

…

The “save as…” on the BPM brings us to the second BPM bpm_dummy_loop. This one works the same, but we set the nrOfLoops for the API call to a static value of 1 and we use the input nrOfLoops for the loop in the BPM itself:

It’s not a complex thing to do; Just watch out to connect the sources with the correct targets:

Publish it and give it a go…Again, watch the PIM and Node-RED on correct outputs!

…

Now make a copy for our third BPM bpm_dummy_loop_non_api. This is the easiest one as you can replace the API call with the direct GetUserDetails service call AND you can get rid of the Request call!

The GetUserDetails requires a runtime reference of Method Set LDAP 1.1; That’s something you can do in your project:

The consolidated message map? Well, there is not much left over 🤣:

Publish this one as well…You should be OK on all the BPMs now.

The test results

Shall we first do a bet on who is going to win on a 50-loop input? I give it this order:

1. bpm_dummy_loop_non_api; It will win as there is no overhead on first getting a SAMLart ID and calling a backend API.
2. bpm_dummy; It makes one API request and loops within Node-RED.
3. bpm_dummy_loop; It calls the API one by one and makes it slow on each API request.

I’m curious on the duration differences…Let’s give it a go!

Ohwww, before I run the BPMs in short-lived, I update the execution mode in the BPM, publish it, and run it again. Be aware I would normally not advise to run a short-lived BPM calling external services! Why? Well, it’s a dependency you want to fail-save with a proper-catch mechanism also informing your administrator; Read about it here

…

The results:

Long-lived (BPM without Node-RED; bpm_dummy_loop_non_api)

Long-lived (Loop in BPM; bpm_dummy_loop)

Long-lived (Loop in Node-RED; bpm_dummy)

Short-lived (BPM without Node-RED; bpm_dummy_loop_non_api)

Short-lived (Loop in BPM; bpm_dummy_loop)

Short-lived (Loop in Node-RED; bpm_dummy)

It’s always fascinating to run such assessment; It looks like we won our own bet (at least for the short-lived side)! 😎 For long-lived, number 1 (pure BPM-loop without Node-RED) and 2 (do the looping in Node-RED in one API call) are almost equal! Also, (as expected!) the duration difference between short-lived and long-lived! Calling an external API can still be long-lived (as we also advise!); A pure internal only BPM (without manual activities or delays) can perfectly set to short-lived with a duration decrease of 50%!

That’s a final concluded “DONE” on our Node-RED journey. A lot of shared details, and we learned a lot of information. I hope you enjoyed it all…Let’s see what project will first embrace this knowledge and where we can embed it into the ecosystem. Never stop learning, share the knowledge; I see you next week in another great 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”?