Recently I was working with a client who wanted to implement a recursive
process (i.e. one that calls itself). Now Recursion is a classic
programming pattern, and in theory it should be pretty straight forward
for a process to call itself. However at first sight it’s not so
obvious.
The issue here is that the way a BPEL Process calls out
to another process is to drag a Partner Link on to your BPEL Process and
then use the Service Browser to select the deployed process that you
wish to call.
Of course with our scenario, the first issue
we hit is that we haven’t yet deployed the process as we’re still
writing in it! The obvious thing to do here is create a stub process,
with just the basic receive and reply operations defined and then deploy
the stub. This works great, we can now select the process within the
‘Service Browser’ and finish implementing the process.
However the next problem
occurs when we try and re-deploy the completed process. Here the
deployment fails with an error that it is unable to validate the WSDL
for the Partner Link. The issue here is that as part of the deployment
process we are “over-writing” the old stub version of the process, with a
new version (as we want to keep the version number the same).
The way BPEL PM achieves this, is to un-deploy the
old version of the process, before deploying the new version. As part
of the deployment, the BPEL engine validates the WSDL for all Partner
Links including our recently un-deployed version of the process and as a
result fails!
Fortunately there is a simple work
around. First create and deploy the sub process as before, then once
deployed go to the BPEL Console and select the process from the
dashboard. Then select the WSDL tab and click on the URL for the WSDL
Location.
This will open a browser containing the WSDL for the
BPEL Process, save the file to your local file system (File-> Save As
in IE) as .wsdl file. Now when you create your Partner Link in the
process, instead of using the ‘Service Browser’ use ‘Browse WSDL files
from your Local File System’ and select the WSDL file you just saved.
Note: When prompted to make a local copy specify ‘yes’.
From here you will be able to implement and deploy your BPEL process without any problems.
Example
I’ve created a simple example process, based of course on the classic Factorial example. You can download this here.
Deployment Considerations
The
one drawback with this approach is that the WSDL file will now contain
the Endpoint location for the service within in it. Thus is you were to
deploy the process on a different server it would fail at run-time.
So
you need to modify the WSDL file at deployment time so that the
endpoint reflects the hostname and port number of where the process is
actually being deployed. The simplest way to do this is update your
build script so that ant will automatically do this for you.
Final Thought
Now
in theory you could have incredibly nested processes using this
approach, however I would advise is bad practice and is likely to have
performance implications.
For example; if we ran the Factorial
process to work out 50 Factorial, that would result in 50 process
instances. Now if we expected to handle 1000 process running in
parallel, this would result in 50,000 process instances – so the actual
number of process instance could increase very dramatically.
So I
would recommend using this approach with caution to ensure that it
doesn’t result in a dramatic increase in the overall number of process
instances. |
1 comments:
And the conversation ID will create a infinity looping of messages, you think in one workaroud for it?
Post a Comment