"apestel" wrote : So, they want to expose a second web service on the ESB that
allows the requester to get back status on the loan application in process. This status
may be stored in a textual jBPM variable or maybe the ESB service returns the root
token's current process node name or something. The point is, without the process
instance ID that was created with the application submission, how will the status check
web service be able to know which process ID to check for intermediate status?
We already agree on returning the process instance and, with that, the status of the
process is easy to retrieve. It should also be possible to provide restricted access to
variables although it is often cleaner to have the process instance control this.
"apestel" wrote : Currently, the only way to do something like this (that
I'm aware of) is with Sync Continuation which means the customer really has to
understand the internals of our ESB, has to create a separate replyTo service in the ESB
and update the jBPM process to call back to it so that the replyTo service can response to
the replyTo endpoint of the original SubmitLoanApplication WS that is basically hanging
out there waiting for a reply-to message.
This is the only way for a very good reason, it is the only way that is guaranteed to work
in all circumstances. What you have been asking for (and have already been telling
customers) is not safe.
"apestel" wrote : I'm sure some of my terminology is wrong there, but the
point is that the customer doesn't want to hear about that complexity. They want to
just create a SubmitLoanApplication WS, have that service kickoff the jBPM service
orchestration, and return a result when the jBPM process finishes.
What they are interested in hearing, however, is that their integration works. Having
something that appears to work for simple cases, then breaks once they change things, is
not what they want.
View the original post :
Reply to the post :