Sterling Control Center monitoring Sterling B2B Integrator invokes SOA_MessageHandler too frequently

Cause

There are two methods SCC uses to call the SCCInteropService in SBI, SOAP-sync and SOAP. The standard way is to call the synchronized SOAP request which causes the SOA_MessageHandler BP to be run on the same Java thread as the SCCInteropService, and as such you will not see it recorded in the SBI BP process monitor. If for some reason SCC is unable to use the synchronized SOAP call (and there can be any number of reasons, for example, load, timeouts, or previous request still running) then it will fall back to the old SOAP request which causes the SOA_MessageHandler BP to be run in its own thread, and you will see the SOA_MessageHandler BP. The SCCInteropService BP is always running at the monitor rest interval, whether you see the BP process or not depends on which method SCC used to invoke the SOAP request. SBI logs will not record an async SOAP request, but if there was a problem you would see it on the SCC Engine for that SOAP request.

The reason for the apparent flood of SOA_MessageHandler requests is because SBI cannot keep up with the rate SCC is asking for information. Most likely a SOAP-sync request was still in progress when the next arrived and SCC switched to old SOAP and triggered the SOA_MessageHandler BP to become visible.