This content has been marked as final. Show 5 replies
As per the above user, BAM is the best fit for you.
A recorded product demonstration is here.
Get started wtih BAM
*7) Give points - it is good etiquette to reward an answerer points (5 - helpful; 10 - correct) for their post if they answer your question.*
I apologize for the slow reply. I am just back from overseas and did not have chance to go to the forum!
Thank you a lot for your responses!
The BAM looks like a suggested out-of-the-box solution. But it ties too much to Oracle API and will be hard to customise the way you want to interpret the status to end-users. If you want to display the process status with BAM in a web application interface, ADF is the only solution (please correct me if I am wrong). I would prefer a stand-alone, free of proprietary API solution so that we can build a screen that is technology-independent. As ADF UI is not our only supported view technology. For example, a PHP web client should be able to interpret the BPEL process status.
Will really appreciate your suggested solution.
Thanks and regards,
If you want just to know whether the process got completed or not ? you can make use of the MDS database tables.
You can have your own query which will tell you the flow with the interfaces involved in it and it will show you the status as well.
Otherwise we can have a java application which is collecting all those required information in your bpel and with that help we can build a web application.
We need to consider about the performance of the main process as we will be using lots of variables, irrespective of whether its failure or success.
We have to have block which mark all the variables null before exiting the process.
Thanks everyone for the ideas, I really appreciate.
We have designed our own approach, in our architecture, after BPEL invokes a service endpoint, the endpoint will update a few dedicated database tables. By emulating asynchronous invocation using Java thread (1 thread to invoke synchronous BPEL process, 1 thread to keep polling the database for displaying to the users). When the response from BPEL arrives in 1 thread, we notify (using callback) the other thread to stop polling and direct users to result page. This approach is API independent and it can support any type of client. The rationale is instead of hooking into SOA database, we 'd rather extend our own database to support the approach.