1 Reply Latest reply on Oct 14, 2008 6:54 AM by Bernd Ruecker

    jBPM Integration, EsbActionHandler and payload location

    Peter Mischke Newbie

      In the last few weeks I've tried some of the jBPM-ESB integration features. Now and then I run into trouble with the payload location. I would like to discuss the problems with you.

      The EsbActionHandler (and EsbNotifier too) is able to map jBPM context variables to the ESB message. See samples and docs for the element. Sometimes (maybe most of time) you map more than one variable. Each mapping is given a name by the "esb" attribute. Inspecting the resulting ESB message you will see that the body of the message contains one object for each variable. They all can be retrieved inside the actions by calling


      This approach works fine when developing custom actions.

      But is does not work with all these useful ESB actions supplied out-of-the-box. For example the org.jboss.soa.esb.actions.soap.SOAPClient or org.jboss.soa.esb.actions.Notifier. As described in the Programmers Guide in section "Getting and Setting Data on the Message Body" all standard ESB actions expect the payload as a single object located at the default payload location. This object can be a String, a byte-array, a Map containing several more Java objects, or anything else. Nevertheless they all expect a single object. This message format is not compatible with ESB messages created by the EsbActionHandler.

      After discovering this contradiction I thought about using the SmooksAction to transform the message format. Unfortunately the SmooksAction expects a single object at the default payload location too :-(

      Another work-around is to configure a different default payload location. But this work-around only helps with a single variable.

      Now I am thinking about patching the EsbActionHandler to store all mapped variables inside a Map at the default payload location.

      I would be grateful for any ideas on this topic. Thanks in advance!

        • 1. Re: jBPM Integration, EsbActionHandler and payload location
          Bernd Ruecker Master


          I wouldn't patch/change the EsbActionHandler in this case, because it leads to a design trap in my eyes:

          You start to hand in variables from jBPM to the DefaultBodyLocationMap with the keys you need in one special service (e.g. calling a WebService, so you will have "sayHello.toWhom" and stuff like that as variables).

          A cleaner approach is really to use Smooks (I think it should work even this way, but I would have to look at it) or maybe an own ESB-Action, which gets together all objects into a Map or maybe is configurable to create the correct map.

          Does this sound logical?