Dynamic invocation of Enterprise Information Systems using WebSphere ESB mediation flows in WebSphere Adapters

This article shows you how to dynamically invoke enterprise information systems (EIS's) using WebSphere Adapters and WebSphere ESB mediation flows, and how to apply this model to various business scenarios.

Jeffrey I S Dare (jeffdare@in.ibm.com), Software Engineer, IBM

Photo of Jeffrey DareJeffrey I S Dare is a Software Engineer at the IBM India Software Lab in Bangalore, India. He has three years experience working on WebSphere Adapters, and is currently working in Support and Development for file-based resource adapters and ECM resource adapters. You can contact Jeffrey at jeffdare@in.ibm.com.



Ramya Rajendiran (ramya.raji@in.ibm.com), Staff Software Engineer, IBM

Photo of Ramya RajendiranRamya Rajendiran is a Software Engineer at the IBM India Software Lab in Bangalore, India. She has five years experience working on WebSphere Commerce and WebSphere Adapters, and is currently working in Support and Development for file-based resource adapters. She authored the IBM Redbook "WebSphere Commerce Line-Of-Business Tooling Customization." You can contact Ramya at ramya.raji@in.ibm.com.



Ramkumar Ramalingam, Software Developer, IBM  

Photo of Ramkumar RamalingamRamkumar Ramalingam is an Advisory Software Engineer at the IBM India Software Lab in Bangalore, India. He is a Committer and Management Committee member on the Apache Tuscany project, and a member of the OASIS SCA Java Specification Community. You can contact Ramkumar at ramkumar_rj@in.ibm.com.



03 October 2012

Also available in Chinese Portuguese

Introduction

The IBM® WebSphere® Adapter family consists of a variety of technology and application adapters based on the JCA 1.5 standard. These adapters enable integration developers to seamlessly integrate various runtimes -- such as WebSphere Application Server, WebSphere ESB, and IBM Process Manager -- with various EIS's -- such as SAP, Siebel, Oracle, PeopleSoft, JD Edwards, Lotus Domino, JDBC databases, FTP/FTPS/SFTP protocols, flat file systems, and E-mail servers.

WebSphere Adapters are used at the heart of the business integration logic in many complex business systems. Their outbound functionality is used when the business flow needs to invoke certain EIS functions. In many scenarios, the Adapters must connect to different EIS instances dynamically based on routing criteria -- such as business data or conditions -- which are known only at runtime. This article provides a solution to the challenge that WebSphere Adapter users face when the business logic requires their application to dynamically invoke different EIS's dynamically at runtime. The solution uses WebSphere ESB mediation flows in a "no coding" approach that reduces complexity, duplication, and maintenance.

Business scenarios for dynamic invocation

Here are some use cases for dynamic invocation for EIS's:

  • For all WebSphere Adapters: When the EIS does not provide load balancing and the customer wants to implement adapter-based load balancing.
  • For all WebSphere Adapters: When one EIS instance is down and the application needs to fail-over to a different EIS instance dynamically.
  • For WebSphere Adapter for Email: When the customer application using the adapter wants to direct incoming e-mail messages to a specific mail server based on some value. This capability is a limitation with WebSphere JCA Adapter.
  • For WebSphere Adapter for FTP: When the mediation flow needs to connect to different FTP servers dynamically based which users log in.

Limitations with Websphere JCA Adapters

The current framework of WebSphere Adapters does not allow adapter configuration for dynamic connection to different EIS instances. Nor does the JCA specification explicitly support dynamic connection. Therefore it is difficult for WebSphere Adapters to provide this feature, and the use cases listed above under "Business scenarios for dynamic invocation" currently cannot be implemented in a straightforward manner. Instead, users have to develop and deploy multiple adapter instances, which creates the following pain points:

  • Increased duplication of assets and code
  • Increased complexity of business logic
  • Increased development time
  • Increased maintenance time

Dynamic invocation using WebSphere ESB

WebSphere ESB supports re-routing of messages, via dynamic override of statically-defined endpoints, or dynamic invocation using a target import. WebSphere ESB also supports dynamic redirection of response messages. When a mediation module is developed and deployed, the flow of messages through the module uses static information. You can enter fixed values describing the imports, bindings, and targets using WebSphere Integration Developer. Messages passing through the mediation module then use these values.

For some applications, you can override or change some of these static values at run time. You can do this dynamically by overriding a value specified for an endpoint address, or alternatively, you can select a new target import. In each case, the message flow changes according to the information in the message. For more information, see Dynamic invocation in the WebSphere ESB information center. This article explains how you can dynamically invoke EIS's using WebSphere Adapters and the dynamic invocation feature of WebSphere ESB mediation flows.

Prerequisites

  • IBM Integration Developer
  • Working knowledge of mediation flows
  • Working knowledge of WebSphere Adapters

Assumptions

  • WebSphere Adapter for FTP and its Create operation are used.
  • WebSphere Adapter for FTP is deployed at the node level of WebSphere Application Server.
  • Different managed connection factories are defined, with each one referenced by its JNDI.

Dynamic invocation steps

The steps below configure WebSphere Adapter for FTP for an outbound Create operation, but they apply to any outbound adapter configuration. In a normal scenario, the FTPImport can use only one set of properties defined in its Managed Connection Factory (MCF). The following steps show how the same FTPImport can be used with different sets of properties to connect to different FTP servers dynamically.

  1. Drag and drop the FTP Outbound Adapter from the palette to create an FTPImport using the External Service wizard. Select FTPImport to configure a Create operation and input the required properties:
    Figure 1. Create FTPImport in wizard
    Create FTPImport in wizard
  2. On the palette, click on Components, then drag the Mediation Flow component to the assembly diagram:
    Figure 2. Create Mediation Flow component
    Create Mediation Flow component
  3. Now you need a new business object (BO), which takes the JNDI name for the managed connection factory (MCF). Create a BO that takes all properties required for the FTP outbound and the JNDI name for the MCF:
    Figure 3. Create a new business object
    Create a new business object
  4. Create a new interface and add a Request and Response operation, which has the BO created in the previous step:
    Figure 4. Create a Request and Response operation
    Create a Request and Response operation
  5. Add this interface to the mediation flow and wire it to FTPImport:
    Figure 5. Wire the mediation flow to FTPImport
    Wire the mediation flow to FTPImport
  6. Double-click the Mediation Flow and click Operation Map to map the operations for these two interfaces:
    • The input interface that you created in Step 4
    • The interface created by the FTP Adapter
    Figure 6. Map the operations of the two interfaces
    Map the operations of the two interfaces
  7. Step 6 creates an input_map between the two operations, as shown in Figure 7:
    Figure 7. Mediation map of the two interfaces
    Mediation map of the two interfaces
  8. Double-click on input_map to map all required fields in accordance with your business needs:
    (Click here to enlarge the image.)
    Figure 8. Map all required fields
    Map all required fields
  9. To dynamically invoke the EIS, you only need to map the target address field in the SMOHeader, which is available in the smo/headers/SMOHeader/Target/address path of the tree structure:
    (Click here to enlarge the image.)
    Figure 9. Map the target address field
    Map the target address field
  10. 10 Based on the input provided in MCF_JNDI, the request will be executed using that MCF.
  11. Provide the JNDI of the MCF n the following URI format: jca:jndi:<JNDI of the MCF>.

Examples

Here are some examples that illustrate the use of JNDI of MCF as part of the outbound request. In these examples, with a single configured FTPImport, you can dynamically invoke different EIS's via the outbound request.

Example 1

Outbound Create request to the MCF referenced by jca:jndi:jndi/ftp1 using FTPImport:

Figure 10. Request for Example 1
Request for Example 1
Figure 11. Response for Example 1
Response for Example 1

Example 2

Outbound Create request to the MCF referenced by jca:jndi:jndi/ftp2 using the same FTPImport:

Figure 12. Request for Example 2
Request for Example 2
Figure 13. Response for Example 2
Response for Example 2

The above two examples show that just using a single FTPImport, you were able to send requests to two different FTP servers based on the two different MCFs jndi/ftp1 and jndi/ftp2

Conclusion

In this article, you learned a technique and solution approach for dynamically invoking different EIS's at runtime, using WebSphere Adapters and leveraging WebSphere ESB mediation flows. This "no coding" approach enables you to address the use cases listed above under Business scenarios for dynamic invocation.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=839263
ArticleTitle=Dynamic invocation of Enterprise Information Systems using WebSphere ESB mediation flows in WebSphere Adapters
publish-date=10032012