Bug 961530 - Please allow user direct access to "bpmToEsbVars" and "esbToBpmVars" in sub-classes of EsbActionHandler
Please allow user direct access to "bpmToEsbVars" and "esbToBpmVars" in sub-...
Status: NEW
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: JBossESB (Show other bugs)
5.3.1
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rick Wagner
:
Depends On:
Blocks: 966231
  Show dependency treegraph
 
Reported: 2013-05-09 16:25 EDT by Rick Wagner
Modified: 2013-10-04 14:24 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 966231 (view as bug list)
Environment:
Last Closed:
Type: Support Patch
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rick Wagner 2013-05-09 16:25:07 EDT
This BZ is related to the following BZs:

https://bugzilla.redhat.com/show_bug.cgi?id=896634
https://bugzilla.redhat.com/show_bug.cgi?id=896640
https://bugzilla.redhat.com/show_bug.cgi?id=902888

The customer is unhappy with the solution provided in the above.  They wish to sub-class EsbActionHandler and manipulate variables individually.  

The customer describes how the did it in 4.3, but not in 5.x:
------------------------------------------------------------------------------
Here is the code from the 4.3.0 CP05 version of the EsbActionHandler:

protected EPR createReplyTo(String esbToJBpmXml, Boolean globalProcessScope, ExecutionContext executionContext)
    {
        EPR replyTo = new LogicalEPR(ServiceInvoker.INTERNAL_SERVICE_CATEGORY, JBpmCallback.JBPM_CALL_BACK_SERVICE_NAME);
        PortReference portReference = replyTo.getAddr();
        if (esbToJBpmXml!=null) {
            portReference.addExtension(Constants.ESB_TO_BPM_VARS_TAG, esbToJBpmXml);
        }
        if (globalProcessScope!=null) {
            portReference.addExtension(Constants.PROCESS_SCOPE_ATTR, globalProcessScope.toString());
        }
...

and here is the code from the 5.3.0 version of the same class:

protected EPR createReplyTo(String esbToJBpmXml, Boolean globalProcessScope, ExecutionContext executionContext)
    {
        EPR replyTo = new LogicalEPR(ServiceInvoker.INTERNAL_SERVICE_CATEGORY, JBpmCallback.JBPM_CALL_BACK_SERVICE_NAME);
        PortReference portReference = replyTo.getAddr();
        if (globalProcessScope!=null) {
            portReference.addExtension(Constants.PROCESS_SCOPE_ATTR, globalProcessScope.toString());
        }
--------------------------------------------------------------------------

The customer's specific complaints about the fix provided by the above BZs:

****************************************************************
Concerning the mapping of variables, I think that it worth a patch as only "half the job" has been done. Effectively being able to set variables mapping during the execution of the action is really useful and may be mandatory depending on the process. Here are some of the issues the current solution may cause:

- really overloading our process definitions as all the possible variables must be defined within it and due to that, they are a lot less readable. In addition to that, the size of the message/executing context will remain bigger and will take more space in the  JBPM or ESB database. This could cause issues in several of our customers having a lot of processes generated on a regular basis.

- introducing more human error possibilities as no default variables mapping may be defined through a default abstract action behavior.

- giving a lot less flexibility.

******************************************************************


Please consider, look for another way to restore the functionality the customer desires.

Thank you,

Rick
Comment 1 Rick Wagner 2013-07-26 11:06:22 EDT
Needs more input from GSS.

GSS (Rick) to read customer comments and better explain the desired implementation.

Note You need to log in before you can comment on or make changes to this bug.