Developing in WebSphere Message Broker Best practices guide Part 1

In this post I will provide with some guidelines you need to keep in mind when developing message flows in WMB (WebSphere Message Broker).

WMB is a good integration software but you need to know some internals for developing suit solution.

1. Avoid using hard wired looping in the message flows, Use PROPAGATE statement instead.

When using hard wired looping in message flow All the resources of the loop participant are stored on the stack storage. Nodes , message trees, variables copied and held in memory.
Therefore while message processing the stack storage of the Execution Group (process) can ran out.
You also probably will get abends and core dumps.

By using the PROPAGATE statement the data won't be copied and stored during the loop iterations. After each iteration all the iteration data will be freed and re-used.

2. Work with reference variable and don't navigate through message tree directly.

SET OutputRoot.XML.Root.Child.Field1 = 1;
SET OutputRoot.XML.Root.Child.Field2 = 2;


For those simple assigning statements about 20 navigation action will be made. And it's only if the OutputRoot element is empty.
If not it can be much more.


If you have complex message transformation and performance is your concern work with Reference variable and Create statement.

DECLARE ref REFERENCE TO OutputRoot;
CREATE LASTCHILD OF ref as ref DOMAIN('XML') NAME 'XML';
CREATE LASTCHILD OF ref as ref NAME 'Root';
CREATE LASTCHILD OF ref as ref NAME 'Child';
CREATE LASTCHILD OF ref NAME 'Field1' VALUE '1';
CREATE LASTCHILD OF ref NAME 'Field2' VALUE '2';


We no using SET statement and since all CREATES specify relative keywords no navigation are required. But we got more code :-(.
You can use the ROW statement to get more code visibility and simplicity combined with SET statement.

remember to work with REFERENCE.

3. Avoid using Environment tree to handle local variables.

All data which stored in the Environment tree are stored in Memory during the whole message flow and not freed after it's out of scope.
so if you need space to store local data for node work with the LocalEnvironment tree. Thus avoiding high memory consumption.
Even if you delete the fields from the Environment tree it still won't free the memory till message flow end processing the message. The broker use pool allocation and reuse an pointed resources of the Environment Tree.

more will come soon.

Websphere Message Broker HTTP Reply Node default behaviour changed after fix pack installation

I installed a 6.0.0.9 fix pack םn one of my clients site. After the installation I notice that some client applications that work over HTTP began to get strange errors. They couldn't parse the response. I checked the response with tester tool for WS SoapUI and notice that hebrew characters represented in something that looked like unicode encoding and not UTF-8 ( just hebrew characters ).
This was my mistake. will explain it shortly.

This was the behavior when I worked through biphttplistener.
But if working through IE01: WebSphere Message Broker - Proxy Servlet for the HTTP nodes the communication worked great. The response was interpreted in UTF-8, no errors in clients apps.

Problem

The problem is that IBM changed the default behavior of the HTTP Reply node. After the fix pack 4 of WMB 6 by default the Content-Type: text/xml;charset=UTF-8 was removed from the reply. Thus when the client got the reply without any specific encoding it tried to read it as Ascii and not UTF-8. The data returned in the same UTF-8 encoding as you can see below the raw data before and after the fix :

Before Fix Pack

POST /SOA/unicodeproblem/workdude HTTP/1.1
Content-Type: text/xml;charset=UTF-8
SOAPAction: "urn:recache"
User-Agent: Jakarta Commons-HttpClient/3.1
Host: localhost:9999
Content-Length: 248




hello
[0xd7][0xa9][0xd7][0x9c][0xd7][0x95][0xd7][0x9d] [0xd7][0xa9][0xd7][0x9c][0xd7][0x95][0xd7][0x9d]




After the Fix Pack

POST /SOA/unicodeproblem/workdude HTTP/1.1
SOAPAction: "urn:recache"
User-Agent: Jakarta Commons-HttpClient/3.1
Host: localhost:9999
Content-Length: 248



hello
[0xd7][0xa9][0xd7][0x9c][0xd7][0x95][0xd7][0x9d] [0xd7][0xa9][0xd7][0x9c][0xd7][0x95][0xd7][0x9d]




[0xd7][0xa9][0xd7][0x9c][0xd7][0x95][0xd7][0x9d] [0xd7][0xa9][0xd7][0x9c][0xd7][0x95][0xd7][0x9d] is equal to שלום שלום

Solution

You have couple of options:

1. set the content type manually in the code.
2. set default header by the checkbox on Http Reply Node. (Need to redeploy all your flows)
3. Work through IE01 sp, the content header is always set.