Solution Diagram Not Working in WID 6.2?

WebSphere Integration Developer v6.2 has a cool new feature called the Solution Diagram, which shows the whole of a Solution (a Solution being a new concept that allows you to group Modules, Mediation Modules and Business Integration Libraries into conceptual chunks). It looks something a bit like this:

solution-diagram-example1

However, the Solution Diagram won’t appear if you don’t have the latest Adobe Flash Player installed – instead, you’ll just get a plain blue background in the window when you try to open it. Unfortunately there’s no warning for this. The fix is to install the latest Flash Player from Adobe. (Note: this is not an IBM piece of software). Restart WebSphere Integration Developer after installing it and your diagrams should show without a problem.

Advertisements

WebSphere ESB v6.2 Available

Dave has already beaten me in laying out the details, but it’s worth pointing out that WebSphere ESB 6.2 (together with its tooling environment, WebSphere Integration Developer, and larger business-process-choreographing cousin, WebSphere Process Server), are now available. There’s some good stuff in there; check out the DeveloperWorks articles on Integration Developer and Process Server to find out more.

Accessing WS-Addressing Headers inside a Mediation Flow

In many respects, WebSphere ESB mediation modules act as an ‘ultimate endpoint’, which means WS-Addressing (WS-A) headers are normally stripped off on entry to the mediation flow, and so you cannot access them directly in the SOAPHeader section of the SMO. This technote describes the problem and the potential solution: writing a JAX-RPC handler to access the headers. However, it doesn’t go into detail on how this could be implemented. So here’s how you’d implement a simple JAX-RPC handler to extract the WS-A ‘To’ address on an incoming message so you can use it in your mediation flow:

  1. Define a business object that can be used as a pseudo-WS-A SOAP header to contain whatever WS-A content you care about on the incoming message. In our case, we are just interested in the ‘To’ header:

    You must make sure that this BO is available to the mediation module in question at runtime, by placing it in the module itself or a library that it depends on. If you don’t do this, the header will silently fail to appear.
  2. Write a JAX-RPC handler (which is a Java class) to pull out the content of the incoming SOAP header and place it in a new SOAP header of that Business Object’s type. You need to place it somewhere accessible to mediation module in question. It might look something like this:
    import javax.xml.namespace.*;
    import javax.xml.rpc.handler.*;
    import javax.xml.rpc.handler.soap.*;
    import javax.xml.soap.*;
    
    public class WSAHandler extends GenericHandler {
      public boolean handleRequest(MessageContext context) {
        Object object = context
            .getProperty(com.ibm.wsspi.wsaddressing.WSAConstants.WSADDRESSING_INBOUND_TO);
        String to = (object == null ? "" : object.toString());
    
        SOAPMessageContext soapMessageContext = (SOAPMessageContext) context;
    
        try {
          SOAPEnvelope soapEnvelope = soapMessageContext
              .getMessage().getSOAPPart().getEnvelope();
          SOAPHeader soapHeader = soapEnvelope.getHeader();
          SOAPHeaderElement myBO = (SOAPHeaderElement) soapHeader
              .addChildElement("PseudoWSAHeader", "pwsahn",
                  "http://pseudoWSAHeaderNamespace");
          SOAPElement seTo = (SOAPElement) myBO
              .addChildElement("to");
    
          seTo.setValue(to);
        } catch (SOAPException e) {
          e.printStackTrace();
        }
    
        return true;
      }
    
      public QName[] getHeaders() {
        return null;
      }
    }

    The name and namespace of the business object used when creating the new SOAPHeaderElement need to match the name and namespace of the business object you created. Also, be aware that the class in the com.ibm.wsspi.* hierarchy is part of the WebSphere SPI (System Programming Interface); it is not a fully public API and may not be subject to the same terms (please check your license agreement).

  3. Configure the JAX-RPC handler you just wrote on the Web Services export in question:
  4. Now, when you invoke the Web Services export with a message containing a WS-A ‘To’ header, the pseudo-header will appear in the relevant location in the SMO, and you can access it and use it in whatever way you need, perhaps using an XSLT primitive or a custom mediation, for example. Here’s an example of what the SMO looks like when dumped out in the middle of the mediation flow. The value of the WS-A To header is highlighted:
    <p:ServiceMessageObject xsi:type="p:ServiceMessageObject" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:in="wsdl.http://WSADemo/MyInterface" xmlns:in_1="http://WSADemo/MyInterface" xmlns:ps="http://pseudoWSAHeaderNamespace" xmlns:p="http://www.ibm.com/websphere/sibx/smo/v6.0.1">
      <context/>
      <headers>
        <SMOHeader>
          ...
        </SMOHeader>
        <SOAPHeader>
          <nameSpace>http://pseudoWSAHeaderNamespace</nameSpace>
          <name>PseudoWSAHeader</name>
          <value xsi:type="ps:PseudoWSAHeader">
            <to>[http://tomachine:80/toaddress]</to>
          </value>
        </SOAPHeader>
      </headers>
      <body xsi:type="in:operation1RequestMsg">
        <in_1:operation1>
          <input1>Some regular message data</input1>
        </in_1:operation1>
      </body>
    </p:ServiceMessageObject>

Thanks to Chris Markes, Rob Phippen, and David Illsley for the help with this tip.

Viewing Data using WebSphere Integration Developer

WebSphere ESB uses an embedded database for the Message Logger mediation. WebSphere Process Server uses even more – for example, as the backing store for long-running processes. The test environment versions of these products that are embedded inside WebSphere Integration Developer use the Derby Embedded database to run these – it is supplied with WebSphere. But how can you view the data inside it? In older versions, the cview tool was used for this. In 6.1, you can use WebSphere Integration Developer instead. Here’s how:

  • Start WID (if it’s not already started).
  • Stop the server you are using so that the databases aren’t locked.
  • Switch to the Data perspective.
  • In the Database Explorer view, right-click and select ‘New connection…’.
  • Select Derby 10.1 as the database manager.
  • Select the database you are interested in. For example, I selected <WID_INSTALL_PATH>\pf\esb\databases\MEDB, which is the messaging engine database for my WESB test server.
  • Select <WID_INSTALL_PATH>\runtimes\bi_v61\derby\lib\derby.jar as the Class location.
  • Untick Create the database if required.
  • Set the user ID and password to the appropriate values – if you are using an out-of-the-box WID test server, they will be admin and admin.
  • Select Test Connection. If it fails, double-check the values you entered.
  • Now select Finish.
  • Now there should be a connection in your Database Explorer view. You can expand that to navigate through your database. In particular, you are probably interested in the Schemas section.