Automaticly restarting BPEL processes

At the moment we have a SOA/ BPEL project in production for quite some time. One of the lessons we have learned will be the topic of this post: automaticly restarting BPEL processes.

In this case a process is divided into one root process and a number of subprocesses. The root process is started when a custormer applies for a specific test in a laboratorium. After the application a number of tests (subprocesses) are carried out. After 30 to 50 days the results are returned to te customer. At the moment their are 180.000 process instances, of which approximately 25-30.000 are still active.

We (and the customer) are very pleased with the results Oracle BPEL is bringing. But the implementation of a new product can give you some headache (Out of memory ) As a result of this bug BPEL instances went on abort. The tasks disappair in the worklist and users start calling. They want their tasks back….

At first we kicked off the root BPEL process from the BPEL Console and acquired the tasks and entered the recovered data. We restarted the BPEL proces manualy. This is nice break for 1 or 2 tasks, but becomes expencive when 100 tasks have to be restarted within a few hours. Here is where our creativity came in.
We have developed a webservice to collect all data to kickoff the root BPEL process and data the users entered. The payload for kicking off the root BPEL process is assembled by looking at the xml structure in the BPEL Console.

SELECT '<bpaanvraagcanalyseprocessrequest xmlns="">

02. <aanvraagid xmlns="">0aanvraagid><oogstjaar xmlns="">2006oogstjaar><aanvraagnummer xmlns="">'||
03. decode(p_action,'RESET',a.nummer_aanvraag,0)||'aanvraagnummer> '||chr(10)||
04. '<relatienummer xmlns="">' ||rle.nummer||'relatienummer> '||chr(10)||
05. '<keuringsobjectid xmlns="">'|| kot.ID||'keuringsobjectid> '||chr(10)||
06. '<aantalverpakkingen xmlns="">'|| avrg.aantal_verpakkingen ||'aantalverpakkingen>'||chr(10)||
07. '<verpakkingsvorm xmlns="">'|| lower(avrg.verpakkingsvorm) ||'verpakkingsvorm> '||chr(10)||
08. '<totaalgewicht xmlns="">'|| avrg.gewicht_totaal ||'totaalgewicht> '||chr(10)||
09. '<start xmlns="">'||decode(p_action,'RESET','HERSTEL;'||substr(bmr.nummer,2),'MONSTERONTVANGST')||'start>bpaanvraagcanalyseprocessrequest>'
10. INTO  l_payload
11. FROM  avrg_aanvragen  avrg
12. ,    kot_keuringsobjecten kot
13. ,    kot_basismonsters bmr
14. ,    rle.rle_relaties rle
16. AND
17. AND c.nummer=upper(p_werkmonster)
18. AND
19. AND;

The payloads of the task is found in the BPEL dehydration store. We are storing the process instance id of the root process in our data store. With this id you can find all the child processes in cube_instance in the dehydration database. For every child we fetch the taskid form pc_taskand collect the last payload in the table pc_taskpayload. This payload consists the data the user entered while updating the task. Before returning all payloads to the GUI the old process and subprocesses are deleted.
The GUI will first kick off the BPEL process. Then get the first task and give the collected payload too the taskhandler. This is repeated until the BPEL process is restarted.

Leave a Reply

Your email address will not be published. Required fields are marked *

CommentLuv badge