This section lists some of the things you should consider before installing Business Integration Connect. The planning enables you to decide on the exact deployment topology that fits your requirements.
System downtime can seriously affect your business productivity and profitability. When you create a high availability system, you are ensuring your hub community that the system is always up and running and ready to receive documents. A typical high availability environment ensures that the system is working 99.9 percent with some systems achieving 99.999 percent of the time. Availability levels can decrease due to events such as system failure, system overload, network congestion, and network attacks. To maximize availability, you need to provide system redundancy. You can accomplish this by having at least two implementations of each logical function (Community Console, Receiver, and Document Manager) on separate servers in your architecture. Therefore, if you place all three components on one server, you need a second server to provide redundancy. If you separate each component onto its own server, you need six servers in total to provide redundancy. Additionally, you should consider creating another set of servers in your disaster recovery location so that you can run the system from that location.
To create a highly available Business Integration Connect implementation, its supporting infrastructure (such as network, Internet connection, even power coming into your facility) must also be highly available. The high availability requirement also applies to MQ and your RDBMS. If either of these supporting software fails, your production environment will fail.
Business Integration Connect scales horizontally. That is, you increase its processing ability by adding instances of its components. The actual number of servers, instances of a particular component, or network capability that you will need depends on the following factors:
As these factors change, you can scale Business Integration Connect by adding multiple instances of its components. The Receiver, Community Console, and Document Manager instances can live anywhere independently. However, there are some things to consider when creating redundant Business Integration Connect components:
Note that as you scale Business Integration Connect, you must also scale the supporting infrastructure, such as WebSphere MQ and your RDBMS.
Once you have configured your servers, it is important to monitor your system performance to determine when and if additional servers are required to meet demands.
Data storage is a key component in your topology as it is a Business Integration Connect prerequisite. How you address the shared storage requirement depends on your storage needs and the answers to the following questions:
If your requirements are low in these areas, you can consider implementing your shared storage on the same server as one or more of the Business Integration Connect components. If not, it should be on a separate server from Business Integration Connect. When high availability is a requirement, consider a redundant NAS product because it can scale independently from the servers. Note that your RDBMS and WebSphere MQ do not have to be on NAS.
Business Integration Connect will work within a standard secure environment. However, you should consider the following things:
The Community Console requires that sticky sessions be enabled if you are using a load balancer. Note that enabling sticky sessions in a small community that sends many documents may impact scaling by adding Receiver instances.