Emulating modelled faults in WebSphere Integration Developer

Since version 6.1, WebSphere Integration Developer has come with the ability to create test projects containing test suites and programmatic emulators, allowing developers to create repeatable automated tests for their modules. Projects can contain any number of suites, test cases and variations to cover all the behaviours of the module.

One scenario often overlooked in user-defined test suites is the one where the partner reference returns a modelled fault.

For example:

Fortunately, it is possible to return a fault using a programmatic emulator. In this example we will use Java, but the same behaviour can be accomplished using a visual snippet.

First create the payload for the fault. If the payload is a String or other Java type, you can simply create it and assign it to a variable. If the object is a business object then locate the BOFactory and create it as you would any other SDO DataObject

BOFactory boFactory =
  (BOFactory) ServiceManager.INSTANCE.locateService("com/ibm/websphere/bo/BOFactory");

DataObject reservationFault =
  boFactory.create("http://LB_Example","ReservationFault");

Once you have the object set any attributes that are required.

reservationFault.setString("faultCode", "100");

Next create a Java ServiceBusinessException. The exception has four constructor methods, and we want the one that accepts a String and an Object. The string will be name of the fault being returned, and the object will be the payload created above.

Finally, you throw (not return) the ServiceBusinessException

ServiceBusinessException sbe =
  new ServiceBusinessException(reservationFault,"unknownEventFault");

throw sbe;

For completeness, here is the same code represented visually.

Changing a SOAP Endpoint on an Outgoing Message using JAX-WS

This tip comes from Arancha Ocana Diaz-Ufano, who did all the hard work to figure it out!

In WebSphere ESB, there are many ways of changing the endpoint of a SOAP message outbound from a mediation flow, and the normal way is to use the dynamic endpoint support.  To be clear, this is recommended way.

However, there is another technique, and that’s to use a JAX-WS handler (assuming you’re using a JAX-WS Web Services binding) on the outbound message. This might be useful if, for example, you absolutely cannot modify a mediation flow that’s been given to you, you cannot modify the endpoint at administration time (for example, from the administration console), or you want to do the override in a generic fashion across a large number of mediation flows.

The key is knowing the magic incantation to put in your JAX-WS handler. And here it is:

mySOAPMessageContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://myhost:9080/MyEndPoint");

Thanks again to Arancha for allowing us to publish this tip.

Michal Kuzak Joins SOA Tips ‘n’ Tricks

Two new joiners in as many weeks!

My ex-IBM colleague Michal Kuzak has also agreed to join the SOA Tips ‘n’ Tricks team, along with David George. He’s an independent WebSphere Process Server consultant, and will no doubt have many tips ‘n’ tricks to share.

As always, please remember that the postings on this blog are our own and don’t necessarily represent our employers’ positions, strategies or opinions.

David George Joins SOA Tips ‘n’ Tricks

I’m pleased to say that my colleague David George has agreed to join the SOA Tips ‘n’ Tricks team. He’s a WebSphere Process Server consultant, and will be blogging about it, WebSphere Integration Developer, and other related subjects. Like myself, David is part of IBM Software Services and works with IBM customers on a regular basis, so has a wealth of experience to share.

As always, please remember that the postings on this blog are our own and don’t necessarily represent IBM’s positions, strategies or opinions.

WebSphere Application Server 7 Internals

Sorry that there haven’t been many posts here recently. To whet your appetite, I’m currently preparing a series of articles with a working title of ‘Mediation Flow Creation Guidelines’, which will aim to provide some guidance on well-worn ways to develop mediation flows efficiently.

In the meantime, I’d just like to mention a new book coming out soon called WebSphere Application Server 7 Internals. I’ve been lucky enough to take a look at some preview chapters, and I have to say the content is set to be excellent; Colin has done a great job of explaining many of the more detailed and nitty-gritty topics involved in WebSphere Application Server, which underpins several IBM products, including the one I specialise in, WebSphere ESB. I’m sure it’s set to be a handy tome.

Using Message Logger for Lazy Logging in WebSphere ESB and Process Server 6.2

If you’re creating a mediation flow in WebSphere ESB and Process Server 6.2, it’s now even easier to do ‘lazy’ (drop-and-forget) logging for debugging purposes (Note: I’m calling it ‘lazy’ deliberately. I am not suggesting you should do this in a production system – it’s for quick-and-dirty testing).

Simply drop a Message Logger primitive onto the mediation flow, and change the type from ‘Database’ to ‘Custom’:

The default handler, formatter, and filter classes shown will be used to do the logging. This means that files named MessageLogN.log will appear in your system’s temporary folder (on Windows, for example, this is normally C:\Documents and Settings\YourUsername\Local Settings\Temp). These will contain lines like this:

3/9/09 3:08 PM,EBC7634C-011F-4000-E000-02BCC0A80A8A,MessageLogger1,LogTest,<?xml version="1.0" encoding="UTF-8"?>
<body xsi:type="i1:operation1RequestMsg" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:i1="wsdl.http://LogTest/i1" xmlns:i1_1="http://LogTest/i1">
  <i1_1:operation1>
    <input1>some data</input1>
  </i1_1:operation1>
</body>
,6

The six fields you see in the comma-delimited line are:

1. Timestamp
2. Service Message Object message ID
3. Mediation primitive name
4. Module name
5. Actual message itself – i.e. the Service Message Object serialized as XML.
6. Service Message Object version

This can be really handy for quickly instrumenting a mediation flow.

If you want to get more sophisticated, you can override the handler, formatter, and filter classes with your own, and in any production system, you’d probably want to do that. This document from the Java documentation explains more.

Auto Starting Applications with WebSphere

There is a handy feature of WebSphere Application Server which allows you to control whether applications start automatically when the server is (re)started. By default, all applications (which are Mediation Modules or Modules in WebSphere ESB and Process Server terminology) start automatically when the server starts, but you can turn this off on an application-by-application basis. This is particularly useful to speed up server startup time, or if the applications consume resources as soon as they are started.

You can enable or disable Auto Start using the admin console – simply navigate to Applications / Enterprise Applications / Your application / Target specific application status:

If you have the application installed on multiple servers in a Network Deployment topology, you can select a different Auto Start status for each server.

Thanks to Victoria Amor for the help with this tip.

WS-Addressing Headers in WebSphere ESB v6.2

I wrote previously about how WS-Addressing headers could be accessed in a WebSphere ESB mediation flow, by writing a JAX-RPC handler to intercept them and insert them into a custom SOAP header.

However, in WebSphere ESB 6.2, this is much easier – these headers will now automatically appear as part of the ServiceMessageObject at /headers/WSAHeader. They are effectively read-only; any changes that you make will not affect outgoing messages.

Specifying Transitions for WSRR Promotion

If you’re using the promotion feature of WebSphere Services Registry and Repository (WSRR) to copy content from one registry instance to another on governance state changes, you’ll need to specify which transitions are used for promotion. This is described here. However, what may not be entirely clear are the names to be used for the transitions. These must map to the operation name of the governance transition, and not to the transition name itself. For example, the ‘Plan’ transition of the default governance lifecycle is defined in SACL like this:

<sacl:stateMachineDefinition ...
 targetNamespace="http://www.ibm.com/xmlns/prod/serviceregistry/6/0/governance/DefaultLifecycle">
    ...
    <sacl:transition name="Transition1">
      <sacl:sourceState>InitialState1</sacl:sourceState>
      <sacl:operation name="Plan" portType="_:DefaultLifecycle"/>
      <sacl:targetState>State1</sacl:targetState>
    </sacl:transition>

Therefore, the transition is defined like this in the Promotion Properties:

  <transitions>
    <transition
     name="http://www.ibm.com/xmlns/prod/serviceregistry/6/0/governance/DefaultLifecycle#Plan">
     ...
    </transition>
  </transitions>

Note the use of Plan rather than Transition1.

Thanks to Steve Groeger and Martin Smithson for their help with this tip.

SOA Tips ‘n’ Tricks Joins Twitter

I (Andrew Ferrier – the primary author of this blog) recently joined Twitter. However, I was bothered that folks who were interested in me and my ramblings wouldn’t be interested in my day job – i.e. the technical content on this blog regarding WebSphere ESB and related products. On the other hand, folks interested in that may not know me personally, and may not want to read my potentially controversial personal ramblings. I don’t think it’s appropriate to mix the two.

To that end, SOA Tips ‘n’ Tricks has started posting on Twitter. You can see the feed on the sidebar of this blog, and follow it on Twitter here. At the time of writing, the Twitter account automatically re-publishes links to all posts on the blog, as well as the WebSphere ESB support feed. However, I expect to be posting more unique-to-Twitter micro-blog entries as time progresses.