/ Development  

BPM sub-process VS. BPM webservice

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

Boy-O-Boy did I (again) see some interesting stuff passing by on the AppWorks platform! Ohw…Tell me, tell me…What is it?? 😍 (Sorry…it’s almost week-end)

Generate a webservice out of a BPM!! WHAT…Is that a possibility? Ohw yeah…It’s possible! Why would we want to do this? Well, that’s exactly what we try to find out in this post…

Let get right into it…

Let’s spin it all up and directly jump into our platform project where we dive into the ‘bpms’ folder…The creation of a new BPM!


Start simple with something like this and save it with a name like ‘bpm_parent’:


We also create 2 BPMs which look the same with names like ‘bpm_sub’ and ‘bpm_service’…The end result in our project:


Preparation in done…Next step…

BPM service generation

Right-click the ‘bpm_service’…Let’s generate a service out of it!


Interesting action…With an interesting modal panel:


To keep the project organized we update the location. Select the ‘Start’ operation and after this update we just hit ‘Finish’.

Now what? Well, let’s check the ‘webservices’ folder…



Let’s publish the full project, so we can test this webservice like we would ‘normally’ do…


We get a modal popup where we can invoke a SOAP call like this:

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<bpm_service xmlns="http://schemas.cordys.com/default" />

Well…INVOKE…damn…[Service Group Lookup failure.](javascript:void(0))

Looks like we need to add a new ‘Service Container’ of type ‘BPM’ in the ‘System Resource Manager’ artifact…

So…Let’s create a new ‘Service Group’ with the ‘Business Process Management’ connector (FYI: I do this in my own organization!):


Hit ‘Next >’


Give a name (whatever you want) and mark the ‘BPM service’ we’ve generated…

Hit ‘Next >’


We make sure it starts automatically and by default it’s assigned to the current application server (our TomEE instance!). BTW: This is also recommended by OpenText.

‘Next >’


We make sure the ‘Admin Database’ as well as the ‘Scheduler’ database will use the default database instance of the platform. This is a choice for you to make, but for this post the most convenient.

When done (for both tabs)…hit ‘Next >’, and hit ‘Finish’ on that final wizard screen!

Let’s retest our BPM service…This time with a proper response like this:

<bpm_serviceResponse xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://schemas.cordys.com/default">
<data xmlns="http://schemas.cordys.com/default">

Let’s check this out in the PIM!


NICE!!…Next step in our BPM journey!

Update the parent process

Back to our parent process ‘bpm_parent’ where we do a first craftsmanship to call our subprocess ‘bpm_sub’. Right-click somewhere on the process model and from the context menu we insert our BPM.


Select the ‘bpm_sub’ BPM we have available and update the parent BPM, so it looks like this:


Now, let’s right-click on the activity with name ‘Activity2’ and insert a webservice operation…That will be our generated ‘bpm_service’ webservice (not the bpm itself!). The end-result:


Nice…Save it all and do a publication.

When ready, go back to the project ‘bpms’ folder where we can right-click the ‘bpm_parent’ to do a ‘run’ from the ‘execution’ context menu…

Let’s take a look in the PIM again to see a result:


Interesting!, but also an expected result!

What do we see?

  • ‘bpm_sub’ is “aware” of a parent process where the ‘bpm_service’ is not!

  • After some more ‘run’ executions, it looks like the ‘bpm_service’ activity execution is much faster.


  • After a property check on the ‘bpm_sub’ activity we see the option ‘Wait until sub process is finished’ where the ‘bpm_service’ just sits and waits till a response is sent back). With the removal of this property we see a decrease in duration speed (and gets even faster than the webservice call!). With this we also introduce a fire-and-forget principle for our ‘bpm_sub’!


That’s it for our first tests…let’s continue as there is more to explore!

“Long lived” vs. “Short lived”

By default, a BPM gets the option ‘Long lived’…Let’s have a first look on the ‘bpm_service’ BPM where we can change this setting in the properties of the model:



  • Long lived is a stateful process and can have manual tasks
  • Short lived is a stateless process and can not have manual tasks

With the update we also need to update the generated webservice. So, jump into the ‘webservices’ folder where we have the ‘bpm_service’ available. Right-click it and execute the ‘Add/Update operations’.


Select the BPM source, make sure to overwrite the existing web service interfaces and select our generated ‘bpm_service’.


When ready…Click ‘Next >’

Select the corresponding model and operation:


Click ‘Finish’ to get an updated service interface…Time for a retest of the service (After you’ve published the project again)!

This time we also get a response, but it’s rather empty!

<data />


Ok…let’s update this same ‘Short lived’ option for the ‘bpm_sub’ process.

After a save on this BPM I was curious if something happened in the ‘bpm_parent’ too…And YES, it does:


Hmmm…interesting again…

Let’s run (with that right-click action menu) the ‘bpm_parent’ BPM…Still, with nice results in the PIM, but still not clear why we would want a service out of a BPM!

Time to have a look in the documentation!…”OpenText AppWorks Platform 21.1 Advanced Development Guide”.

We see a chapter called Generating a web service operation on a business process model which mentions information about input/output messages on short lives BPMs!…ahaa!!?

Put on your ‘nerdy glasses’ 🤓…There we go!

Input / Output messages

Back to the ‘bpm_service’ BPM where we open the ‘Message Map’ (in the bottom of the process modeler panel). On the ‘Source’ side we are able to add new ‘Process Specific Messages’.


Make sure to create one ‘input’ message and one ‘output’ message. Both can have just one element of data, so we can put in some value.

Once you have those messages in place, we jump back to the ‘Model’ overview where we get the properties of that ‘Green’ start-construct. On the properties panel we make sure the trigger type is a ‘Message’, and the ‘Input message’ is off-course our just created input message.


We do that same trick for the ‘Red’ end-construct where we select the output message! The BPM will look like this:


To make sure our BPM also has some value in the output message we just map the input to the output in the ‘End’ construct in the message map:


Nice…Save, and publish the BPM

Just for you to know: When you right-click somewhere on the BPM model you can also execute a ‘Validate and Build’ action, so you are sure the BPM in fine before publishing it.

You can already right-click the BPM and do a run directly from the project (where you also see a popups passing by for the input/output messages), but we want to execute it from the generated service! Before we are able to do this, we need to update the service (because of our changed BPM). Have a look back in the post as we already did an update like this…After a publication of the service too, it’s time to test it again with a SOAP message like this to invoke:

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
<bpm_service xmlns="http://schemas.cordys.com/default">
<Element>Hello world</Element>

With also an expected response:

<bpm_serviceResponse xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://schemas.cordys.com/default">
<input xmlns:instance="http://schemas.cordys.com/bpm/instance/1.0" xmlns:sm="http://www.w3.org/2005/07/scxml" xmlns:bpm="http://schemas.cordys.com/default" xmlns:ns2="http://schemas.cordys.com/default_080027ab-36d6-a1eb-a453-d7e9439d09d3" xmlns:ns3="http://schemas.cordys.com/casemanagement/1.0" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" xmlns:c="http://schemas.cordys.com/cws/1.0" xmlns="http://schemas.cordys.com/default">
<Element xmlns="http://schemas.cordys.com/default" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">Hello world</Element>

Great!…What about changing this messaged BPM back to the ‘long-lived’ option!? I tried it out with a logic outcome. A still needed input message, but the output message is not available in the response…The only feedback I get in the response is (as already concluded) the ‘instance_id’ of the running BPM.

Time to update our ‘bpm_parent’ BPM, so our service call gets an injection with a nice input message like this:


After a save, publish, and a run we can check the PIM again to see if our output message is fine.


OK…that’s it…we start to see some advantages in generating a service out of a BPM, but to get fully proof we would like to do one last thing!? What would it be?…Well, we have another BPM called ‘bpm_sub’…let’s add those input/output messages also to this flow and see how it results in the PIM!

Quick steps:

  • Open BPM ‘bpm_sub’
  • Add two messages (input/output) in the message map. Each message will also have one element like the ‘bpm_service’.
  • In the ‘Message Map’ we make a mapping between input and output in the ‘End’ construct (like we also did in the ‘bpm_service’)
  • Save it all and publish

Because of this update, we also need to re-assign the updated BPM to our ‘bpm_parent’ BPM. We can do this by right-clicking the activity and ‘Insert BPM’ (where we can re-select the ‘bpm_sub’ BPM)


When ready you should be able to also make a mapping to the input message of our ‘bpm_sub’ in the message mapper:


Let’s save, publish, and do a run…What is the PIM telling us?


Exactly the same as we already saw for the ‘bpm_service’ call!

Let’s make a final conclusion as I can’t find out what will be the real benefit for generating a service out of a BPM!? The only advantage I can see for now is the ‘loosely coupled’ way of thinking for starting a BPM (with or without an input message). I also see a disadvantage because the service call is not ‘aware’ of a parent process from the PIM point of view.

OK…We are one day further with a sleepless night, and it still gnaws at me why-o-why I would want a service out of a BPM! But I saw the light during some BPM activity exploring!

Have a look again at the properties of the ‘bpm_service’ activity we’ve created in the ‘bpm_parent’ BPM:


With this knowledge in mind I got a grip on the documentation again where I found this table:


After re-reading the table again and again I come to this conclusion: With a webservice call you are much more in control on what should happen in a particular scenario on when you receive or not receive any message response, but does this outweighs the unawareness of a parent process in the PIM? Well, as always…this depends on what you try to accomplish. What would I recommend? Start by calling a normal sub process and if it does not feed your needs you can always generate a webservice out of it.

That’s it…I give it a “DONE” where we learned much more about the differences of calling a sub process by just calling it directly versus calling it in a webservice wrapper. Both have their own advantages and disadvantages; it all depends on what you try to accomplish for your solution. Have a great week-end, and I see you in the next post on another nice AppWorks Tips topic.

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”?