bgRFC Architecture
Dependencies
The classic qRFC model detects the dependencies among the individual units only when the data is processed by the RFC scheduler. For each destination, the outbound scheduler starts a scheduler that processes the data for this destination.
The schedulers run on each destination only for a limited period of time to ensure processing is consistent for all destinations. For this reason, the scheduler must determine the sequence again every time before it processes a destination.
In contrast, with the bgRFC, the dependencies are determined when the data is stored. In doing so, the RFC scheduler can find all units that can be executed instantly with minimum effort and all dependencies are detected only once. The additional effort when storing the data is compensated to a large extent by efficient algorithms and optimizations in the database design.
For each client a defined number of outbound schedules are started that process the queued load in parallel, although the load on the target systems is determined in shorter intervals and is, therefore, more accurate than before.
Delete Procedure for Units and Queues
Unlike the classic procedure, if any units or queues are deleted, the dependencies are retained, since the units are first flagged and only then deleted by the scheduler.
After deleting Unit4, Unit6 can only be executed after Unit3, as Unit4 is only deleted once the scheduler has processed Unit3. If you delete queue2, the following situation occurs:
Unit6 is executed after Unit2. All the selected units are deleted by the scheduler.
Deleting a queue or unit is, therefore, always risky. In our examples, it could occur that Unit6 encounters an error or causes a database inconsistency in the target system, since the required preparations in Unit4 were canceled by the deletion.
Gateway
The gateways, another potential source of bottlenecks, have also been optimized. The new concept regulates the maximum number of outbound schedulers that are allowed to run at the same time on an application server, and the maximum number of connections that all RFC schedulers can use. This limitation prevents the local gateway from becoming overloaded.
The gateways of the destinations are protected from overload as well by making the number of parallel outbound schedulers for each sender system and their maximum number of connections configurable.
Effects on Performance
The improvements implemented with the new bgRFC design become noticeable primarily under high-load conditions when there are many dependent units for each destination. For the first time, a linear logarithmical scalability (dependent on the system capacity) is possible for RFC data processing.
The transactional behavior of the queuing function does not allow for significant savings when an individual unit is being processed, but the application of more or faster hardware produces more noticeable results in throughput. The limiting factors are the performance of the database and the processing speed of the units.
In addition, a new API also contributes to an optimized procedure. Redundant functions have been removed and some of the limitations of the old API no longer apply. This has resulted in a smoother and more efficient concept that will reduce time and effort for both support and development teams.