The system-wide Connector Framework can create separate threads
for processing an application event and a business object request.
When processing multiple requests from the integration broker, it
can create multiple threads to handle multiple business object
requests. For example, when InterChange System is the integration
broker, the connector can receive multiple business object requests
from multiple collaborations or from a multi-threaded
collaboration.
- Important:
- BAPI business object handlers generated before the connector
for SAP version 4.3.0 are not thread-safe. To guarantee data
consistency and integrity when using multi-threading, you must
regenerate these business object handlers. The business objects do
no require any change.
Figure 3 illustrates the
multi-threading architecture.
Figure 3.
Multi-Threading Architecture of the Connector for SAP

The connector performs the following steps when handling a poll
call:
- The system-wide Connector Framework creates a single dedicated
thread to handle poll calls. This thread calls the
pollForEvents() method of the vision connector framework
at the frequency specified in the PollFrequency
configuration property.
- The thread polls SAP, which uses a dialog process to locate and
return the event.
- Note:
- If the connector's MaxNumberOfConnections
configuration property evaluates to a number greater than
1, the vision connector framework dedicates a connection
to SAP for polling. If MaxNumberOfConnections evaluates to
1, event and service-call request processing share a
single connection to SAP.
The polling thread dies only when the connector shuts down.
- Note:
- Because the RFC Server connector agent pushes events out of SAP
instead of polling for events, it spawns its own threads instead of
using threads created by the connector framework. Because the ALE
connector agent uses the RFC Server connector agent to access
events, it also it spawns its own threads instead of using threads
created by the connector framework when it processes events.
Independently of polling, the system-wide Connector Framework
can create multiple request-processing threads, one for each
request business object. Each request thread instantiates the
appropriate business object handler.
For example, when processing business object requests from
InterChange Server, the number and type of business object handlers
depends on the number and type of the collaborations sending the
requests:
- If multiple collaborations send business objects, each request
thread instantiates a business object handler of the appropriate
type.
- If a multi-threaded collaboration sends multiple business
objects of the same type, the request threads instantiate an equal
number of business object handlers of that type.
If the connector's MaxNumberOfConnections configuration
property evaluates to a number greater than 1, the vision
connector framework dedicates one connection to SAP for polling and
allocates the remaining connections to a pool used only for request
processing.
As illustrated in Figure 3, the
connector performs the following steps when handling a business
object request:
- The system-wide Connector Framework creates a separate thread
for each business object request. Each thread calls the
doVerbFor() method of the Vision business object
handler.
- If the connector's MaxNumberOfConnections
configuration property evaluates to a number greater than
1, the Vision business object handler checks the vision
connector framework's connection pool to determine if a connection
handle is available.
- If the handle is available, the thread sends the request to
SAP, which uses a dialog process to handle the request.
- If the handle is not available, the thread waits until one
becomes available. Thread sequencing determines the order in which
each business object handler thread claims or waits for an
available connection handle.
If the connector's MaxNumberOfConnections configuration
property evaluates to 1, the Vision business object
handler shares a connection with event processing.
- SAP releases the dialog process after it completes processing
and sends a return code.
- The connector releases the connection handle after it receives
the return code from SAP.
Use the MaxNumberOfConnections configuration property
to specify the maximum number of connection handles available. The
number of connections cannot exceed the number of dialog
processes.
SAP locks the dialog process while processing an interaction,
releasing it only when the interaction completes. Therefore,
multiple concurrent requests lock an equal number of dialog
processes until processing finishes.
- Important:
- Before setting a value for MaxNumberOfConnections, contact your
SAP BASIS administrator to determine an appropriate value to
maximize throughput without negatively affecting performance on the
application server.
By default the connector supports only single-threading. To
cause the connector to support multiple threads, remove the
following flag from your connector startup script:
-tMAIN_SINGLE_THREADED
-tSINGLE_THREADED
For more information, see the Connector Development Guide
for Java.
