Additional configuration options for IBM MQ Bridge to Salesforce
IBM MQ Version 9.2.0 additional configuration options are available that permit two major classes of additional topology, dealing with "inbound" (events generated from Salesforce, being published to IBM MQ applications) and "outbound" (IBM MQ applications publishing events that are sent to Salesforce) work. In addition, there is a change to the way in which tracing and logging work.
Changes from the Version 9.1.0 IBM MQ Bridge to Salesforce
By default, there are no changes to behavior from the Version 9.1.0 bridge, other than the log file now starting to rotate. See Rotating logs for more information.
The main change is that a queue manager now supports multiple bridge instances. To enable this feature, and the remainder of the additional topologies, we must make some manual configuration changes.
See runmqfsb for more information on the additional configuration options and Example configuration output for an example of the revised configuration information.
Separated inbound work
Multiple instances of the bridge can handle inbound work from Salesforce to IBM MQ, but these must be working on independent sets of Salesforce push topics and events. Otherwise, there would be the possibility of repeated events seen by IBM MQ applications, as there is no cross-bridge protocol to stop duplicating the events. Each instance uses its own configurable synchronization queue to hold the ReplayId.
This is likely to be useful when:
- Different Salesforce topics have different security authorizations. Each bridge instance has a different set of credentials for accessing Salesforce.
- We have concerns about the workload coming from Salesforce being too much for a single bridge to handle. Therefore, you might arrange for the topics to be partitioned with "A-M" going through one bridge, and "N-Z" through another.
Shared outbound work
The bridge supports multiple instances to support outbound work being sent from IBM MQ to Salesforce. If one instance of the bridge fails, then other instances subscribed to the same topics on the same queue manager can continue processing the publications.Note: No changes to IBM MQ topic configuration are needed for this.These cooperating instances must be set up so that, at most, one of the instances is handling inbound work from Salesforce, as that instance must have exclusive access to the synchronization queue.
This is likely to be useful when you have concerns about the:
- Workload coming from IBM MQ. As the requests to Salesforce are synchronous, the bridge cannot process new work while still processing one message. Having multiple consumers alleviates that situation.
- Availability architecture. For example, it is now possible to run multiple instances in separate data centers, with better failover and disaster recovery options. Running as an IBM MQ client also separates the bridge from the queue manager location.
Trace and debug interaction
The debug flag continues to act as before. That is, -d1 gives bridge debug information and -d2 turns on debug logging for the prerequisite components. However, if you have enabled IBM MQ trace when you start the bridge, the -d2 level reporting is automatically turned on.
Rotating logs
The default behavior for the log file changes to have three log files, each of size 2 MB. We can override these values using additional configuration properties. The existing configuration attribute, or command line parameter for the log file, is taken as the base name for the logs, with an index added.
If the configured log file has:
- No filetype, the index is added to the end of the filename.
Set the log file to abc, results in logs called abc.0, abc.1, and so on.
- A filetype, the index is inserted before the filetype.
Set the log file to abc.log, results in logs called abc.0.log, abc.1.log, and so on.
Notes:
- As the bridges can be running with arbitrary user permission, it is not possible to force a particular directory, for example, /var/mqm/qmgrs/<qm>/errors, for the logs.
- The same information continues to be written to the stdout and stderr streams.
- Whenever an individual log file gets reopened, basic configuration information is reprinted. The information will always be available, instead of being printed once only at the start of the program.
Preserving logs
The new topologies make it more likely that there will be multiple instances of the bridge running against a specific queue manager.
To avoid the instances interfering with each other, and to avoid overwriting previous runs of the bridge, the bridge will not start if the .0 log already exists.
You need a startup procedure that deletes previous copies of the log before starting the bridge, or adds something like a timestamp to the name.
- Example configuration output
An example configuration output, showing the changes from the Version 9.1.0 IBM MQ Bridge to Salesforce.Parent topic: Configure IBM MQ for use with Salesforce push topics and platform events
Related tasks
Related information