David Currie

If you find yourself needed to make use of the modifySCAImportHttpBinding command make sure read the documentation in the InfoCenter carefully. Even if you are modifying a property at the import level it isn’t sufficient simply to specify the import parameter. The property that you are modifying must also be enclosed in a tag with the name of the import binding. So the example given is:

$AdminTask modifySCAImportHttpBinding -moduleName MyMod -import Import1 -connectionRetries <Import1>3</Import1>

Thankfully the InfoCenter has been recently updated as a result of APAR JR31724 as previously you just had to guess at the syntax! Perhaps I should now try and get them to fix the description of the command which I see states “The modifySCAImportHttpBinding command changes the JNDI name of one or more of the resources associated with an HTTP import binding.”! One suspects someone may have been a little generous on the old cut and paste…

There has been a WebSphere ESB newsgroup for a long while but it doesn’t see a lot of traffic compared to its sibling Integration Developer and Process Server groups. At least part of that has been due to the fact that they have been mirrored on the developerWorks forums which tend to be the preferred interface for many developers this days (although not myself!) whilst the WebSphere ESB one has not. My colleague Dave Screen has now got this rectified so post your WebSphere ESB questions here!

A top tip just in from the WebSphere Integration Developer team… If you only use WebSphere Integration Developer to develop for WebSphere ESB (and not Process Server) then go to Window > Preferences and select General > Capabilities. Then click the Advanced button and expand Integration Developer. If you uncheck Process Development then the Process Server specific options (e.g. SCA module creation) will be filterered out of the menu structures. It’s not perfect (the new business integration module wizard for example doesn’t take account of the enabled capabilities) but it goes a fair way to removing some of the clutter that is not relevant to you as a WebSphere ESB developer. Thankfully there are plans to make the option easier to find in future releases!

There have been a couple of questions recently on an internal forum asking how best to parameterise a module. For mediation modules the seemingly obvious answer is via promoted properties. However, in these scenarios the parameterisation was required to handle the deployment of a module in to different environments and the originators felt that promoted properties were more about making administrative changes to properties post-deployment. I pointed out that, in the admin console, if you use the J2EE application installation process (rather than the install button on the SCA modules panel) and select the “Show me all installation options and parameters” radio button then you will find a panel entitled “Edit module properties” that allows you to modify promoted properties on installation.

(more…)

This is a long overdue update to a previous post on achieving dynamic JMS endpoints in WebSphere ESB. As several people have commented, WebSphere ESB 6.2 added support for dynamic endpoints for all of the bindings types as documented in the InfoCenter. A couple of points to note:

1. The syntax of the endpoint URI used for the JMS bindings uses JNDI names to refer to the resources and is therefore not truly dynamic in the sense that JMS destinations need to have been pre-configured for all of the messaging provider destinations to which you might want to send.
2. For a native MQ binding, you can currently only modify the queue dynamically and not the queue manager to which you can connect.