Overriding a Web Service Endpoint in WebSphere ESB

When working with Mediation Flows in WebSphere ESB, and you have a Web Service import defined that connects out to an external Web Service, you might want to override the default endpoint. Here’s a (not exhaustive) list of ways to do that (the numbers in brackets indicate the version that the feature is available from):

  • (6.0.2+) The most flexible and long-term way: integrate with the Web Services Registry and Repository product by using the Endpoint Lookup mediation primitive. This allows you to dynamically look up service endpoints (i.e. URLs), by retrieving them from the registry based on criteria you set. The primitive, in some modes, automatically sets the /headers/SMOHeader/Target/address section of the Service Message Object (SMO), which exploits the dynamic callout capability in WebSphere ESB to override the default endpoint when the callout is performed. In other modes, multiple endpoints might be retrieved, so you would to select the appropriate one and populate that section manually.
  • (7.0+) Use the new UDDI Endpoint Lookup primitive, which works in a very similar way to the regular Endpoint Lookup primitive, but instead looks up endpoints from a UDDI registry.
  • (6.0.2+) Use the dynamic callout facilities of WebSphere ESB directly by populating the /headers/SMOHeader/Target/address section of the SMO directly. You could do this by writing your own logic in a custom mediation, for example, or you could populate it with a hardcoded value using a Message Element Setter.
  • (6.0.1+) Override the endpoint statically in the admin console after deploying the application. To do this, you’d first locate the relevant SCA module deployed in the admin console, then select the import binding you are interested in:
    Then, you can modify the endpoint accordingly:

    This might be useful if you are deploying different copies of your mediation flow to different servers, and wanted to use different endpoints in each case. Note that the methods above, which use dynamic endpoint support, will override whatever you set here, so this is only useful if you aren’t using dynamic endpoint support.

(Note: this tip applies equally to WebSphere Process Server)

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.

Looking up Governance States in WSRR using WebSphere ESB

Let’s say you want to use the Endpoint Lookup primitive in WebSphere ESB to lookup an endpoint stored in WebSphere Services Registry and Repository (WSRR), but matching against the governance state of the endpoint. For example, you might want to only lookup endpoints which are in the ‘Managed’ state – i.e. they are deployed and ready to work with. How would you do this?

Well, in WebSphere ESB, when you’re specifying the properties of Endpoint Lookup primitive, you get the ability to specify Classifications. These are matched against Classifications in WSRR – including the governance state.

For example, let’s assume that we’ve loaded a WSDL document into WSRR and already transitioned it into the ‘Managed’ state. We’ve specified most of the properties for the Endpoint Lookup primitive already, such as the interface we are looking up. We now need to know what the syntax is for the Classification that we’re going to use. In WSRR, we go to the Configuration perspective in the admin console. Then we navigate to Active Configuration Profile / Classification Systems. We select Life Cycle Classifications and then click Edit. This should look like this:

Now click on Classes, expand out the tree, and you should see something like this:

Click on Managed and you’ll get to see the Class ID:

This is the important value, because this is the value that you’ll need to specify as a classification in your Endpoint Lookup primitive:

Now, when the lookup is performed, only endpoints in the Managed state will be returned.

Note: The classifications are logically ANDed together: if you specify multiple ones, the endpoint must match all of the classifications.

Thanks to Andrew Borley, Bernard Kufluk and David Bell for help with this tip.