Increasing WebSphere Integration Developer’s Heap Size

Sometimes, when working with WebSphere Integration Developer, you may find that you run out of heap space for its JVM – this will typically result in sudden crashes, and often happens when you have a lot of projects loaded or you’re doing a lot of intensive activity.

In this case, you may want to consider increasing the maximum heap size. Because WebSphere Integration Developer is based on Eclipse, you can do this using the standard Eclipse approach, which is documented on the Eclipse wiki.

Broadly, you’ll want to add some command-line arguments to the WebSphere Integration Developer shortcut. Open the properties of the shortcut from your start menu, and append the following:

-vmargs -Xms512M -Xmx1536M

This will set the initial heap size to 0.5GiB and the maximum heap size to 1.5GiB, for example. You can adjust the value for your needs.

 

Advertisements

Default Directory Change for WebSphere Integration Developer/Process Server/ESB in V7

Updated 2010-01-25: Typo corrected.

I’ve just been experimenting with WebSphere Integration Developer (WID) v7. If you’re working with this new release, you might like to know that the default directories for the WID WTE (WebSphere Test Environment, also called ITE or UTE in some places) has changed.

By default (on Windows), WID is now installed in C:\Program Files\IBM\WID7. However, the WTE runtime (and its associated profiles) can now be found in a separate hierarchy instead – C:\Program Files\IBM\WID7_WTE. If you are using WebSphere Process Server or WebSphere ESB, the runtime that’ll interest you is in C:\Program Files\IBM\WID7_WTE\runtimes\bi_v7. The profiles can be found under there, in subdirectories called qesb and/or qwps. This is different from in previous versions of these products, where the profiles were in a separate directory structure from the runtime. Note that as always, there are separate profiles for WebSphere ESB and WebSphere Process Server, even though the underlying runtime is the same – and technically WebSphere Process Server – in both cases. This is possible because WebSphere Process Server is a functionality superset of WebSphere ESB.

Really Easy Logging in WebSphere ESB v7.0 with Weakly-Typed Subflows and the Trace Primitive

I’ve been experimenting with the new release of WebSphere ESB and WebSphere Integration Developer – v7.0. David has already done a good job of describing the new features, but we can combine two of them – untyped subflows and the Trace primitive – to create a very powerful and easy-to-use logging feature.

First, we create a new Mediation Subflow. The best practice is to create this in a Business Integration Library so that it can be re-used between different Modules or Mediation Modules – I placed mine in a Library called LoggingSubflowLib. As of V7, by default the terminal types of this are untyped, which means they don’t expect any particular type of message to flow through, and it can be re-used in any mediation flow. In the middle of this subflow, we place one of the new Trace primitives. The subflow then looks like this:

We leave the settings for the Trace primitive at the default:

These default settings mean that it will output the entire SMO (Service Message Object) that flows through the flow/subflow to the server log. On Windows, if you accept all the default paths during install, this can now be found at C:\Program Files\IBM\WID7_WTE\runtimes\bi_v7\profiles\qesb\logs\server1\SystemOut.log – note that this is changed slightly from the V6.2 location.

Now we can create a mediation flow to try out this logging subflow with. For my tests, I created a mediation flow called ConvertCustomer, which converts between two slightly different customer interfaces – a frontend and a backend – using an XSLT mediation in the both the request and the response flow to do the mapping. I then inserted the subflow by simply dragging it from the library onto the mediation flow, and placed it in both the request flow:

and the response flow:

I then tested it with the Integration Test Client in WID, by right-clicking on my Mediation Flow Component and selecting “Test Component in Isolation” (I manually emulated the front-end and the back-end). In the Events sequence, you can see where the interaction passes through the subflow and the Trace primitive, in both the request and response directions:

Looking at the SystemOut.log file, you can see the output:

<Se:smo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:Se="http://www.ibm.com/websphere/sibx/smo/v6.0.1" xmlns:in="wsdl.http://ConvertCustomerLib/GetCustomerInterface1" xmlns:in_1="http://ConvertCustomerLib/GetCustomerInterface1">
 <context/>
 <headers>
  <SMOHeader>
   <MessageUUID>9C1C9286-0125-4000-E000-03A0C0A8C886</MessageUUID>
   <Version>
    <Version>7</Version>
    <Release>0</Release>
    <Modification>0</Modification>
   </Version>
   <MessageType>Request</MessageType>
  </SMOHeader>
 </headers>
 <body xsi:type="in:getCustomerRequestMsg">
  <in_1:getCustomer>
   <id>123</id>
  </in_1:getCustomer>
 </body>
</Se:smo>, 7

<Se:smo xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:Se="http://www.ibm.com/websphere/sibx/smo/v6.0.1" xmlns:in="wsdl.http://ConvertCustomerLib/GetCustomerInterface2" xmlns:in_1="http://ConvertCustomerLib/GetCustomerInterface2">
 <context/>
 <headers>
  <SMOHeader>
   <MessageUUID>9C1D129C-0125-4000-E000-03A0C0A8C886</MessageUUID>
   <Version>
    <Version>7</Version>
    <Release>0</Release>
    <Modification>0</Modification>
   </Version>
  <MessageType>Response</MessageType>
  </SMOHeader>
 </headers>
 <body xsi:type="in:getCustomer_backendResponseMsg">
  <in_1:getCustomer_backendResponse>
   <customerBackendData>
    <name>myName</name>
    <address>myAddress</address>
   </customerBackendData>
  </in_1:getCustomer_backendResponse>
 </body>
</Se:smo>, 7

What this now means is that we have a powerful and re-usable subflow that we can place in any mediation flow to do logging. Of course, in this case, this is by itself of only limited value – since we didn’t configure the Trace primitive beyond the defaults, it would be almost as easy just to place the Trace primitive in every mediation flow instead of the Subflow. However, had we done any configuration of the Trace primitive to alter the output location, written our own custom logging logic, or made the subflow more complicated in any way, it would then mean that this development effort only needs to be carried out once.

Very broadly speaking, what the weakly-typed subflows now allow you to do is build your own mediation primitive, very simply (this was always possible, but required some knowledge of the WebSphere ESB SPIs and Eclipse programming). This is an extremely powerful feature.

All of the above also applies to WebSphere Process Server, as it is a functionality superset of WebSphere ESB.

WebSphere ESB / Integration Developer / Process Server 7.0 Announced

For those already working with WebSphere Integration Developer, WebSphere ESB, or WebSphere Process Server, or those considering using them, you might be interested to know that version 7.0 has just been announced and is scheduled to be available around the end of Q4 2009.

Please look at the official announcement for more information, but some of the new things I think are particularly interesting are:

  • Service Federation Management between WebSphere Services Registry and Repository and WebSphere ESB.
  • More pattern-based development.
  • Exploitation of WebSphere Application Server V7.
  • Improved Service Gateway scenario support.
  • Event sequencing support in WebSphere ESB.

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:

Example interface with a modelled fault

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.

Fault emulator as visual snippet

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.

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’:

2009-03-09_154556

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.