Administering IBM webMethods Module for SWIFT in a Cluster
What Is IBM webMethods Integration Server Clustering?
Clustering is an advanced feature of the webMethods product suite that substantially extends the reliability, availability, and scalability of IBM webMethods Integration Server.
Clustering accomplishes this by providing the infrastructure and tools to deploy multiple Integration Servers as if they were a single virtual server and to deliver applications that leverage that architecture.
With clustering, you get the following benefits:
- Scalability: Without clustering, only vertical scalability is possible. That is, increased capacity requirements can only be met by deploying on larger, more powerful machines, typically housing multiple CPUs. Clustering provides horizontal scalability, which allows virtually limitless expansion of capacity by simply adding more machines of the same or similar capacity.
- Availability: Without clustering - even with expensive Fault-Tolerant systems - a failure of the system (hardware, java runtime, or software) may result in unacceptable downtime. Clustering provides virtually uninterrupted availability by deploying applications on multiple Integration Servers; in the worst case, a server failure produces degraded but not disrupted service.
- Reliability: Unlike a server farm (an independent set of servers), clustering provides the reliability required for mission-critical applications. Distributed applications must address network, hardware, and software errors that might produce duplicate (or failed) transactions. Clustering makes it possible to deliver “exactly once” execution as well as checkpoint/restart functionality for critical operations.
For details on Integration Server clustering, see IBM webMethods Integration Server Clustering Guide .
webMethods Module for SWIFT in a Clustered Environment
Clustering Requirements for Each Integration Server in a Cluster
The requirements for each Integration Server in a given cluster are given below:
- All Integration Servers in a cluster must be of the same version.
- All webMethods Module for SWIFT instances in a cluster must be of the same version.
- All the webMethods Module for SWIFT packages on one Integration Server must be replicated to all other Integration Servers in the cluster.
- Each
webMethods Module for SWIFT service must appear on all servers in the cluster so that
any
Integration Server
in the cluster can handle the request identically.
If you allow different Integration Servers to contain different services, you will not derive the full benefits of clustering. For example, if a client requests a service that resides on only one server, and that server is unavailable, the request cannot be successfully redirected to another server.
Clustering Requirements When Installing webMethods Module for SWIFT Packages
For each Integration Server in the cluster, use the standard webMethods Module for SWIFT installation procedure for each machine, as described in Installing IBM webMethods Module for SWIFT.
You must install webMethods Module for SWIFT on each host in the cluster. Each installation must be identical.
Configuring webMethods Module for SWIFT in a Clustered Environment
When you configure webMethods Module for SWIFT - that is, when you use it to create packages of generated services - you must ensure that each Integration Server in the cluster contains an identical set of packages. You can create custom packages of generated services of webMethods Module for SWIFT on one host and use package replication to publish custom packages to each of the other hosts. For information on package replication, see IBM webMethods Integration Server Administrator’s Guide .
Replicating Packages and Configuration Information to Integration Servers
Each Integration Server in the cluster should contain an identical set of packages that you define using webMethods Module for SWIFT. To ensure consistency, make sure that you create all packages on one server and replicate these packages to the other servers. If you allow different servers to contain different packages, you will not derive the full benefits of clustering. For example, if a Trading Networks processing rule requests a service that resides in only one server, and that server is unavailable, the request cannot be redirected to another server.
webMethods Module for SWIFT Configuration Information
webMethods Module for SWIFT stores configuration information updated in the SWIFTNet Client Configuration and SWIFTNet Server Configuration screens as configuration files within packages, and the imported BIC, BankDirectoryPlus, IBANStructure, and SEPAPlus lists are stored in the database. The Trading Networks-related configuration information is stored in the database (JDBC pools).
The SWIFTNet Client Configuration and SWIFTNet Server Configuration information includes the following items:
- SWIFTNet Client Environment Information
- SWIFTNet Client SAG Connection Information
- SWIFTNet Remote Process Connection Configuration
- SWIFTNet Server Environment Information
- SWIFTNet Server SAG Connection Properties
The configuration information is visible only to the server on which SWIFT Module resides; it does not share a common storage facility. Therefore, when using SWIFT Module in a clustered environment, you need to replicate the SWIFTNet Client SAG Connection Information and SWIFTNet Server SAG Connection Properties information in the SWIFTNet Client Configuration and SWIFTNet Server Configuration screens across all the nodes in the cluster.
Trading Networks Configuration Information
About this task
The configuration information created to use webMethods Module for SWIFT with Trading Networks includes the following items:
- Document attributes and type definitions
- Processing rules
- Trading Partner Agreements
The following information is imported into the database from the Import BIC List, Import IBANStructure List, Import SEPAPlus List, Import BankDirectoryPlus List, and Import IBANPlus List screens:
- BIC List
- BankDirectoryPlus List
- SEPAPlus List
- IBANStructure List
- IBANPlus List
When using webMethods Module for SWIFT in a clustered environment, the Trading Networks-related configuration information and the imported lists are in the database, which is common for all the clustered nodes and should not be replicated.
To replicate the configuration
Procedure
- Ensure that all clustered Integration Server nodes point to the same JDBC pools. For information on how to define JDBC connection pools, see Installing IBM webMethods Products .
- Replicate all custom flow services and packages by using the copy and send mechanism from the Integration Server Administrator or Designer. For information about replicating packages, see the chapter on managing packages in IBM webMethods Integration Server Administrator’s Guide .
- Replicate the SWIFTNet Client SAG Connection Information and SWIFTNet Server SAG Connection Properties configurations as specified on the SWIFTNet Client Configuration screen and the SWIFTNet Server Configuration screen. For more information about these screens, see Configuration Steps for InterAct and FileAct Messaging Services over SAG MQHA.
Clustering Implementation Considerations
There is no specific webMethods Module for SWIFT-related implementation when using webMethods Module for SWIFT in a clustered environment, other than the transport considerations described in this section.
AFT Transport
When you use the AFT transport to send and receive SWIFT messages, you must use the procedure described in Using AFT to Communicate with SWIFT to set up the AFT environment across the nodes. You must specify AFT as the transport used for the particular message exchange in the TPA. Because the Trading Networks information is available in the database (pointing to the same JDBC pool across the nodes in the cluster), the information does not need to be replicated.
CASmf Transport
When you use the CASmf transport to send and receive SWIFT messages, you must use the procedure described in Using the CASmf Services to Communicate with SWIFT to set up the CASmf environment across the nodes. You must specify CASmf as the transport used for the particular message exchange in the TPA. Because the Trading Networks information is available in the database (pointing to the same JDBC pool across the nodes in the cluster), the information does not need to be replicated.
MQHA Transport
About this task
When you use the MQHA transport to send and receive SWIFT messages, you must ensure that you:
Procedure
- Install IBM webMethods Adapter for MQ with the latest fix on all the nodes in the cluster.
- Replicate the packages containing the Adapter for MQ connections, listeners, and listener notifications across all nodes in the cluster.
- Enable the replicated Adapter for MQ connections, listeners, and listener notifications across all nodes in the cluster.
Results
You must set MQHA as the transport used for the particular message exchange in the TPA. Because the Trading Networks information is available in the database (pointing to the same JDBC pool across the nodes in the cluster), the information does not need to be replicated.
For more information about the MQHA setup, see Using Adapter for MQ to Communicate with SWIFT.