Useful Design Practices for Application Development in IIB

Using Shared Libraries:

The concept of static libraries was introduced in WMB V8 to isolate common components that can be shared across multiple applications. However, this had a key limitation, as the library is maintained as a local copy by the referred applications and hence any change in the library requires redeploying all the referred applications. The latest version of IIB v10 has given an enhancement to the libraries where it can be deployed as a standalone on a server.

  • Most commonly used services such as Add, Update, Lookup are packaged as separate applications, but they use the same Schema and WSDL definitions, which can be created as a Shared library and referenced by the individual applications.
  • Functionalities such as auditing, logging and error handling are common across applications. The resources used for implementing such functionalities such as ESQLs, Java classes and Sub flows can be packaged into a shared library.
  • External JAR files such as JDBC/ODBC drivers needed for DB integration.
  1. As a standalone on a server — Multiple applications referring the library can be deployed on the same server after the library is deployed. Changes to the library only require redeploying the library and the referenced applications can automatically pick up the changes from the library.
  2. Packaging into the BAR of the individual application in which it is referred and deployed as one component on the server. Changes to the library would require a build to the application’s BAR and redeploy.

Configuring node properties

The simplest way to specify node properties is within the application/library it is contained in. But in some scenarios the properties might vary for different environments, in which case a separate BAR has to be created for each environment.

  1. The Manage tab of the BAR in the Integration Development perspective provides an easy way to locate resources and provide property values for different nodes. The BAR need not built again and only requires to be saved and deployed
  2. Alternatively, to facilitate configuring properties without a development environment, an override property file can be created for each environment. In this case, the original BAR file with the source code needs to be rebuilt or overridden to a new BAR file with the help of ANT scripts.
  1. Specifying queue name and queue manager for MQ Input/Output/Reply nodes
  2. Specifying file directory for logging/caching in File Input/Output/Read nodes
  3. Binding Policy Set and Security profiles for SOAP Request nodes

Setting runtime properties

Applications under a broker could be dependent on external services. In such cases, instead of defining on nodes in a message flow, we might need to define properties on the broker level that could be changed at runtime so that all the applications under the broker can access the properties without the need of a redeploy. One way to define such properties is by creating a user defined configurable service, such as following:

  1. Web service URL and authentication parameters can be defined using mqsicreateconfigurableservice command, instead of setting directly on SOAPRequest node. The configurable service values can be retrieved in compute node and set
  2. For DB integrations from a compute node, connection URL format and attributes can be set using mqsicreateconfigurableservice command. Authentication parameters can be set using mqsisetdbparms command

About the Author:

Kirthana is a Technical Consultant at InfoTrellis and has good knowledge on IBM Integration Bus. She has over 3 years of experience in developing Master Data Management solutions.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store