External Bulk Update APIs from Entity Object in bulk update mode

[srinigenie]

Dear All,

 ADF Entity Object support bulk updates using the batch mode option. This I presume uses the Oracle SQL FORALL syntax to batch updates and send to DB as one call instead of individual calls. The batch mode functioning becomes interesting when there are third party APIs to be invoked against each entity operation - more so if the third party API supports batch update API!

I was researching this and found no standard solution or blog on this and though would invite discussion on this forum A practical use case could be described as below:

Take the case of a custom worklist built in ADF. We have an object say an insurance claim and we have a Human Task against each insurance claim for approval. The present implementation invokes a human task API in the afterCommit() method of the insurance claim EO to trigger a status change in human task.

Now if an insurance agent processes multiple claims in bulk, Human Task bulk update APIs could be of use if EO layer could provide some means of invoking human task bulk update API.

Best Regards,
Srini

[srinigenie]

One crude way of achieving this is to use the AMImpl - afterCommit() method.

We could use a transient attribute on EO (marked to passivate) & set this attribute to flag the entity for batch. We can retrieve this Entities that have this flag turned ON in the AMImpl.afterCommit() step & invoke the external API to bulk update.

But I really wish we could keep this bulking closer to the EO rather than at the AM stage. So still searching for an elegant solution.

[John Flack]

Well, it actually doesn't use FORALL - that is a PL/SQL construct, but it is similar.  My understanding - and I'm willing to be corrected on this - is that when you use the batch insert option, you are telling ADF BC not to do individual INSERT commands for each row to be inserted, but instead do a batch insert, passing an array of rows to be inserted.  The cost is a little more memory on the middleware, but the advantage is that there is ONE exchange of data over the network to the database instead of many.  It is faster and conserves network bandwidth.

There is a subtle difference between a POST operation and a COMMIT operation, that you may need to understand.  POST is when the framework issues the DML commands to the database - INSERT, UPDATE, and DELETE.  So of course, batch insert affects how the framework posts.  COMMIT is directly related to when the framework issues a COMMIT command - telling the database to commit- i.e. save the changes permanently.  Normally, both post and commit happen in succession.  When your application executes commit, it starts a process where first there is a check for unposted changes, they are posted, then the AM commits.

That means to me that -
1. It really doesn't matter to your human task API whether the batch insert is used or not.  All it cares about is that the claims needing approval are in the database.
2. afterCommit is probably the correct place to call the API.
3. When multiple claims are processed in bulk, you may need to define the difference between this and a single claim being processed.  Is there a master entity to which the multiple claims being processed in a group belong as details?

[srinigenie]

We donot have a master entity unfortunately that gets updated when the claims are updated.

We are exploring the below approach:
1. Override the prepareForDML() of the ClamisEOImpl & prepare the payload for the human task.
2. Maintain the attributes to be updated for the Human Task in a separate transient VO as VO attributes & a View Linked VO for the payload.
3. Override the beforeCommit() method of the AMImpl & check for records in the transient VO created in step2 & invoke the Human Task Bulk APIs.
4. Clear the Transient VO of any rows.