Highly Available WebSphere Business Integration Solutions

Chapter 8. A few helpful tips 123

8.3 InterChange Server

Some of the best practices specific to the InterChange Server environment are:

򐂰 One of the reasons that the InterChange Server process may fail is due to

out- of-memory exceptions. This can be minimized by configuring properties

such as mem_checker_upperlimits/frequency/sleeptime and

MAX_EVENT_Capacity.

򐂰 Failover time in a InterChange Server environment can be minimized by:

– Tuning the repository database and deleting unnecessary repository

components

– Tuning the JVM

– Configuring deferred recovery for every InterChange Server collaboration,

where event sequencing is not required

– Ensuring that adapter agents are started in parallel. This is critical in

deployments with large numbers of adapters as it can impact startup time

significantly.

– Using the minimum number of required disk groups

8.4 WebSphere Business Integration Adapters

Best practices specific to WebSphere Business Integration Adapters are:

򐂰 Adapter agents should not be critical HA components in most scenarios. This

implies that on adapter failures, InterChange Server, MQ, and Message

Broker should continue to run in their respective nodes and not failover.

For example, let us consider a scenario where a SAP adapter in an HA

environment is designed as a critical HA component. If the SAP application is

shut down for regular maintenance, this will then cause the SAP adapter to

shut down, triggering a failover of the InterChange Server. The failover of the

InterChange Server will not solve the SAP adapter problem and causes

unintentional InterChange Server downtime.

124 Highly Available WebSphere Business Integration Solutions