With the latest patch set of Oracle a new BPEL Activity got introduced. Well actual it’s not a new feature but it’s available as a item now in the Component pallet in JDeveloper. It’s the checkpoint activity. It’s the equivalent of the java call checkpoint();. This forces the Java thread to store it’s current state in the dehydration store. In previous versions we would solve this by adding some java code into the process. Like below:

<bpelx:exec name="checkpointJavaExec" language="java" version="1.4">
     <![CDATA[
     checkpoint();
     ]]>
</bpelx:exec>

This is not needed any more. Now we can simply add a nice xml element to force dehydration storage:

<bpelx:checkpoint name="CheckPoint_alpha"/>

with the introduction of this Activity we can also specify ‘skipCondition’ as the name implies we can specify an validation to skip the current activity.

Example

To prove the work of the checkpoint activity i have made a simple BPEL including the following code:

<bpelx:exec name="Java_Embedding_1" version="1.5" language="java">
    <![CDATA[System.out.println("Thread ID before Checkpoint 1 = " + Thread.currentThread().getId());]]>
</bpelx:exec>
<bpelx:checkpoint name="CheckPoint_1" skipCondition="1=1"/>
<bpelx:exec name="Java_Embedding_2" version="1.5" language="java">
    <![CDATA[System.out.println("Thread ID after Checkpoint 1 = " + Thread.currentThread().getId());]]>
</bpelx:exec>
<bpelx:checkpoint name="CheckPoint_2" skipCondition="1>1"/>
<bpelx:exec name="Java_Embedding_3" version="1.5" language="java">
    <![CDATA[System.out.println("Thread ID after Checkpoint 2 = " + Thread.currentThread().getId());]]>
</bpelx:exec>

I use embedded java to log the id of the thread processing the instance. I log the thread ID before and after Checkpoint_1. I i monitored the server log file to catch the output:

Thread ID before Checkpoint 1 = 176
Thread ID after Checkpoint 1 = 176

The thread id’s are the same because i have specified the spectacular skipCondition: 1=1 to skip dehydration.
I have changed the skip condition for Checkpoint_2 to fail so the process will be forced to dehydrate. After dehydration an other thread will pickup the instance process the last steps of my BPEL.

I got the following logging:

Thread ID after Checkpoint 2 = 186

That’s all about the Checkpoint activity

Popularity: 52% [?]