Soa Suite – ESB, BPEL – Nice-to-knows, pitfalls

I’ve been checking out the different capabilities and new features of the Adapter-framework in ESB and BPEL for some weeks now and came across some nasty pitfalls, nice-to-knows, … which I would like to share with you.

Of course I would like to share thoughts, opinions and start discussions on these topics.


  • How to define xsd-validation on file-adapter (validate payload at runtime-option isn’t available in file adapter) : In the ESB console, select the routing service which is invoked after the inbound file adapter. See the “Definition” tab. The validation option is in the “Operation Details” section. (with thanks to Ronald)


  • Inserting master-detail data using DB Adapter functionality : Referring to my experiences so far it’s best best way to make use of stored procedures instead of the toplink mappings file. I am mainly using the stored procedures because the tooling support in Jdeveloper (wizards, toplink ui), I still miss a good ui for the toplink support. Also it is easy to give the task to create an PL/SQL api to the PL/SQL developers that are working on a certain application. (with thanks to Orjan)

  • [Error ORABPEL-10007]: unresolved messageType for “{}RuntimeFaultMessage”: When you’ve defined an empty bpel process (which is best practice to do the brain-work) you will face this issue when defining fault-handling inside your bpel-process. To solve this error you need to import the RuntimeFault.wsdl inside the adapter you’re using. Following import statement needs to be added:

  • Best practices when invoking Bpel Processes from different UI’s (Flex, JSF, …) : Many thanks to Hajo for his explanation: It is best practice to use the default ways to invoke a BPEL process – create a WSDL that maps to WSIF binding in a controlled environment and to a SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would be a “custom” solution that needs way more governance to communicate with fellow developers and to maintain properly, when compared to the straightforward standard way. . For more details see OTN Thread:

  • Use multiple sources in transform-activity: In 11g a new feature has been added to be able to use multiple sources using bpel 2.0 (bpel:doXslTransform(string, node-set, (string, object)*)). The workaround in is by using the params-approach => Or by using an assign-activity with append-functionality to add the variable inside your source-target and in the same assign-activity add the process-xslt functionality to call your xsl to populate the source with the target-information.

Invoking Web Services from Database:

  • Call an esb service using the UTL_HTTP package => ORA-29266: end-of-body reached => make sure to pass variables using String-notation instead of Character-notation

Interesting New Features in :

  • Controlling the Size of a Rejected Message (10133technotes.pdf):
    You can now control the size of a rejected message by specifying the following
    endpoint property for the inbound File/FTP adapter partner link.
    In this example, you reject 100 lines from the file since the actual file is too large.

  • ESB Endpoint Properties : e.g. ability to add RejectedMessageHandler to file adapter services

Enhancement Requests:

  • Ability to validate xml payload at runtime on Adapter-level instead of on domain level or routing service level
  • Ability to add xsi:nil attribute using xsl-functionality in transform-activity
  • File-adapter: Ability to skip columns besides skipping rows + ability to use special characters in column headers

Well that’s it for now … feel free to share thoughts, comments, etc.


6 thoughts on “Soa Suite – ESB, BPEL – Nice-to-knows, pitfalls

  1. Hi can you give details on the Best practices when invoking Bpel Processes from different UI’s.I am not able to open the forum thread.

  2. I’ve created a new post regarding this matter, so we’re able to start a discussion regarding this topic and have more insight on todays’ approach.

  3. Matt, I am not really sure this is the right place to ask this question. But hopefully you might have something in your armour to help me out.I would like to manipulate the Endpoint property of an ESB Service (SOAP Service/Routing Service/Adapter Service)??My requirement is to configure an inbound File/FTP adapter to read from a Directory which can be known only at runtime. I guess one way possible is, you configure a File/FTP Adapter with a logical name for directory and set the physical directory path using the endpoint property. But in that case, I should know the Physical directory @ deployment time.So is there any way to get the enpoint property configured during runtime???Any help would be appreciated.-Sudheer

  4. Hi Sudheer,Sorry for the late reply, but you could add a parameter as an endpoint property or in the header information of the esb-service and bind this parameter/variable to the output property of the file-adapter.When you define the file location field in the adapter, instead of using “c:\inputdir” use $var_outdir (or whatever name you want) and register. Then you can go to the ESB Control, Adapter service Properties tab and edit the value for $outdir.Otherwise you could add the same porperty or parameter inside the header-information to define a directory at runtime.A question I have? How do you know the directory at runtime? The problem that’s already tackled with esb and the jndi-locations, is the different environments at deployment time. I’m wondering how you’re notifief about the directory at runtime?

  5. Hi Natha,

    I’m using a 3 FTP inbound Adapters from different location. If any error occurred in any of the Adapter , the Error has to trapped as custom message to identify the exact Error file name.

    Using ESB . Please advice your view.


    1. Hi Lara,

      Depending on your needs for error handling there are different approaches you can follow.
      You can read about the error handling framework using the error hospital in the ESB-documentation and there are a couple of examples as well, such as:

      Here is an interesting post of a fellow developer:

      Kind regards,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

About nathalieroman