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.

Force Remove of old WMQ Cluster information from Qmgr

If you alter your WMQ Cluster, for example change it name or change the full repository Qmgr you may see error messages in the logs.
Errors like there is no full repository cluster for cluster "Name You have renamed" and more others.

You can execute REFRESH CLUSTER() REPOS(YES) command on the partial repository Qmgrs or the reset cluster command.

If those command not work properly I suggest to clean the SYSTEM.CLUSTER.REPOSITORY.QUEUE of the full repository Qmgr. Thus after the restart it will get the latest and the correct status of the WMQ Cluster.

1. change the SYSTEM.CLUSTER.REPOSITORY.QUEUE to get disable.
2. restart the qmgr. (Because the repository queue is in get disabled mode the cluster process will failed to start and won't lock the queue for exclusive use)
3. Clear the SYSTEM.CLUSTER.REPOSITORY.QUEUE
4. Alter it to get enabled mode
5. restart the Qmgr.

This should clean the noise log messages.

Consuming Web Service with SOAP header by Biztalk 2006

There are a lot of information about this subject on-line,
but I think that it not so correct.

The steps to create a working solution are :

1. You need a WSDL which includes the declaration of the SOAP headers elements that are needed. It won't work if you define an external schema for it. as it is described in many posts.

2. Create a property schema with the target namespace set to http://schemas.microsoft.com/BizTalk/2003/SOAPHeader, the root node name set to exactly the same as the root node name in SOAP header, and the Property Schema Base property set to MessageContextPropertyBase.

3. Set the context of the request message with a XML of the SOAP Header structure.

XMLDOM = new System.Xml.XmlDocument();
XMLDOM.LoadXml(@"123456Silver"); WSReqMsg(SubmitPurchaseOrder.SOAPHeaderPropertySchema.Priority) = XMLDOM.InnerXml;


If you have an WSDL which not defines SOAP Header but it's needed (like WS-Security or WS-addressing) by WS provider you will need to ask the provider to provide updated WSDL or to update it by yourself. Otherwise it won't work in Biztalk 2006 with SOAP adapter.

If you need to update the WSDL I suggest you to do it by exposing Orchestration as Web Service with the Web Service Wizard tool. You can use the defined property schema and you need to define custom schema which will include the needed SOAP Header.
During the wizard you can choose to expose SOAP Headers.

In Biztalk 2006 R2 and later you can use WCF adapter which solve this issue without the need to update WSDL.

Exposing And Consuming Web Services by SAP

You can consume Web Services by SAP framework for web services and also expose RFC as Web Services without any need of external integration tools like SAP netweaver xi.
One of the most impotent things in SOA solution is the ability to monitor the traffic.
There is a great logging tool out of the box which is provided as part of SAP WAS, SOA Management. it's provide information on the calls time and also it's can capture the requests/responses.

The process of consuming or exposing Web Services is not difficult at all, it evolves work with:
- Wizards : Creating the BAPI objects or exposing existing RFC.
- BAPI : Developing the Web Service proxy for consuming, working with objects and types created by the Wizard.
- SOA Management : Deploying the WSDLs/Exposing RFC , configure the logs.


There is some interoperability issues that you need to keep in mind when going for this solutions:

- We didn't find a solution for consuming an existing WSDL as an interface and implement it.

- xsi:nil attribute is not supported, opened OSS, waiting for SAP response.

- You can't generate custom Namespace.

There are more...

The throughput was much more faster than thru XI. (10 times faster).

In conclusion it is more than possible to expose SAP structures and types as standard Web Services and to consume them.
So if synchronous solution is suite for you you don't need to use adapters or XI.

If you need help on this fill free to contact me for forward details.