overview
RiftSaw (ODE) uses the same database table to store all status' process instances, (like completed and active status). This means these tables will go bigger and bigger as the time goes by, which will affect the runtime performance when data reaches a threshold, because the database operation performance will be degraded.
clean up on completion
One approach to clean up the process instance is to configure it on the deploy.xml file to indicate when and what level of instances need to be cleaned up. Detailed configuration can be found at the ODE's documenation, which can be found at the links[1].
clean up the BPAF table
If you want to clean up the events table, namely BPAF_EVENT, BPAF_EVENT_DATA, table, this forum thread might be of your interest.
clean up on batch
Since the bpel console 2.4.2.Final version (since RiftSaw 3.0.0.M5), we have added another approach to clean up the process instances. (This can also be traced at: RIFTSAW-515 jira) .
ODE has a set of Management API as you can find on the links[2], however, it is exposed as the web service only in ODE-axis2 distribution, which means is not availbe in the RiftSaw. We leverage the API and expose it as a RESTful service in part of the BPEL Console.
The RESTful service url is: ${server}/bpel-console-server/rs/process/instances/delete, the @GET method. Following is the list of parameters and available values as part of the query string:
- status : available options: active, suspended, error, completed, terminated and faulted.
2. started: the value format is like ">2013-02-07", the available operator is: '>' and '<'.
3. last-active: the value format is as same as started.
Example: ${server}/bpel-console-server/rs/process/instances/delete?status=completed&started=<2012-12-21&last-active=<2013-01-01
Comments