#5 BPM 12c New Features - forced commit after execution

Can be used to avoid re-invoke of activity in case of rollback

Here is a simple example of this new functionality.

To begin, here is my composite - write an order to a file and then the orderNr to the DB.

I deploy the composite and test.

Here is my file -

You can ignore the other contents of this directory.

Here is my row in the DB. The table has only one column - order_nr. This is also the primary key.

I execute the same test again -

I get the expected error - due to primary key violation.

Naturally, I now have 2 output files -

I now delete the row in my orders DB.

I recover the error in em.

Now I have 3 files -

and 1 row in the DB.

So we all agree, this is not good?

So let's say how 12c can help us here -

I check Force commit after execution on the Write2File activity.

I re-deploy and delete the 3 output files, as well as the DB row.

Re-test with order_nr = 1

Output file is written -

DB row is written -

I resubmit the same order -

The fault is thrown.

I now have 2 output files -

I delete the DB row and re-submit the message from em.

No extra output file has been written.

Ergo, recovery started from the WriteDB activity.