Demystifying Fast Connector Architecture for High Volume Real time PI Integration

[Former Member]

High Volume real-time integration/message processing has been a pain point of PI. I had been on a recent client, which had a requirement of processing around a million real time synchronous messages though PI predominantly via the SOAP Adapter for inbound and outbound web services.  Though a JAVA-only AEX based integration model was used, the initial performance testing yielded the following issues:

1. Frequent Message time-out in PI
2. Hanging threads/message blocking due to non-responsive Applications

Further research on performance tuning parameters, led us to the SAP FCA or Fast Connector Architecture threads.

What is the new SAP Fast Connector Architecture?

SAP Fast connector Architecture is a shared memory concept, based on memory pipes and MPI buffers.  The FCAServerThreadCount threads are used by the J2EE Engine to handle HTTP communication as replacement for classic dispatcher in older Netweaver AS Java architecture.

The above diagram summarizes, how an HTTP Request is processed on the JAVA application server

1.      HTTP worker threads wait for new requests in the HTTP request queue. If a request is in the queue, a free worker thread starts processing it.
2. The HTTP worker thread reads the request data from the FCA connection (based on memory pipes and MPI buffer).
3. The HTTP worker thread forwards the request to the associated container of the Java server process: Web container, EJB container, persistence layer, and so on.
4. The response is written to the FCA connection.
5. If the status of the session changes, the session table is updated in the shared memory (Web and EJB session).
6. Once the HTTP has been processed, the HTTP worker thread frees up the FCA connection and waits for new requests

How do FCA server threads eliminate “System Hung” Scenarios?

In a typical high message volume scenarios, all the worker threads on the PI JAVA stack, could be consumed by messages for a given source or target (this could be an SAP system or a 3rd party web server). In such a case, PI JAVA stack might seem to be hung, not processing any further messages.

The shared memory based FCA scheduler, maintains the state of such running threads. In addition it provides a mechanism to define the maximum thread consumption filter via the FCAServerThreadCount Property. In case any application exhausts the allocated thread pool, and subsequently receives another request, which runs for more than the specified time-threshold, the dispatcher assumes that the thread is hung.  Any further HTTP request for the same target receives an HTTP 503 from the application server.

This helps is maintaining the thread pools for messages related to any other application, thus enabling and protecting message parallelism.

The Max receiver setting can be done globally as well as for specific web resources via the ConsumerTypeIsAlias property.

Setting up the FCAServerThreadCount Parameter in PI (The default value is 15 per node)

Using J2EE Configuration Tool. The following are the steps:

1. Start the Configuration Tool.
2. Choose cluster-data - template - instance - <n> - managers - HTTP Provider Service.
3. From the list of properties, select FCAServerThreadCount.
4. Set the required maximum server threads as shown below. Parameter: FCAServerThreadCount to the desired value
5. Choose Set to apply the new value.
6. Choose Apply changes to save the changes.
7. For the changes to take effect, restart the cluster