Require the ability to make deferred processing and workflow activity execution inline

Overview:
The customer is really looking to be able to bypass our deferred processing and db2jms mechanism under certain situations. The example here is through the use of a batch process to do bulk updates of a system. Here they do not want to wait of deferred processes that are part of the OOTB application or have to introduce other settings for db2jms etc.
This also relates to straight through processing where there is a need to get through the import of applications as quickly as possible. There have been requests previously for inline processing.

Request Statement:
I would like to request an enhancement in how delayed processing and workflow work. I would like to have a setting which would allow batch process to specify whether dbtojms mechanism should be used to invoke the processing or whether the delayed process should be executed synchronously at the point when delayed processing/workflow is invoked. This setting would be most useful when doing data migration where the following conditions are met:
- we are processing huge volumes of data
- invoking existing application facade methods that contain some sort of delayed processing/workflow. During data migration we quite often want to invoke unmodified OOTB facade methods and at the end of the execution be sure that the records has been fully migrated without extra reliance on dbtojms call and without waiting for online application to do the remaining bit of migration. Considering that one of the main points of delayed processing is making sure that user does not have to wait for long running process to complete, I think invoking delayed processing in serial fashion does not have to deal with this issue. Summary
The proposal is to add a setting (app property or some TransactionInfo method) which would allow a batch job or a unit test to invoke methods containing delayed process/workflow invocation and instead of invoking standard delayed processing mechanism invoke the methods serially. Rationale
This would allow to avoid extra integration points (dbtojms settings, dependency on server being up, dependency on correct tuning of app server to handle large load in workflow/delayed processing). Background/history for the request

In order to do data migration for DSCIS we have relied on invocation of existing OOTB and custom facade methods.

A batch job was created which invoked the existing application methods for:
- registration of a person
- registration of a case
- addition of evidence
- addition of verification items
- creation of product delivery cases (PDC)
- approval and assessment of PDC (that's the bit which invokes eligibility checking as a delayed process)
- creation of service plans The process went smoothly up until the point where we had to invoke dbtojms to do the delayed processing (approval and eligibility check for the PDCs created by migration process). However dbtojms call caused us issues:
- The application started throwing some exceptions when we had more that 250 messages (we have later traced that to an issue with the version of IBM WAS 6.1.0.29 - broken, 6.1.0.31+ - not broken). (Lapsed time - 7 days. Effort 6 person days.)
- Later we had several instances of dbtojms call failing. This involved effort to track down the cause of an issue (server down, incorrect port number, firewall issues, incorrect settings thread pool/db connectgion pool settins that would stop processing of all messages once the pools have been exhausted). But this reduced customer's and the team's confidence in the validity of this migration approach. This second point seems to be quite important, just because TCG consultants are usually the first point of contact when app server settings have to be updated, despite the consultants often not having enough expertise/training regarding fine tuning of these settings. This quite often results in us doing guess work to see which semi-random settings would have a desired effect of successfully executing the required dbtojms load. This sort of setting would let us to avoid this guess work by moving all processing into the context of a batch job.