Explanation of bgRFC processing and configuration

[former_member267124]

Hi,

We currently have a number of custom interfaces between BW and ECC that are utilising bgRFC, and having performance issues when the associated queue lengths are very large.

I've read the online help, but am still just trying to get my head around the bgRFC processing and architecture.

I would be grateful if someone could give a quick explanation or overview with regards to:

1. What is the relationship between schedulers, destinations and queues?  For example, if I only have a single destination but multiple queues within that destination...does a single scheduler manage the multiple queues within that destination?  Could multiple schedulers be defined to process the destination, and hence increase throughput?
2. Would having multiple destinations, which could be then be processed by additional schedulers, assist with processing large data volumes?
3. Are units within a single queue always processed sequentially (ie. within a single DIA process), or can a destination / queue be configured to process units in parallel using multiple DIA processes?

Thanks very much

Todd

[Former Member]

Dear Todd,

For your questions, I will answer as much as I can.

For RFCs, we use the construct of a destination to define where to execute the function module.

In case of bgRFC, tRFC, and qRFC, the destination defines where the unit will be executed. The destination is usually not a single server, but it could be. A bgRFC destination could also be a group of application servers - the automatic dispatching of units to these servers is handled by the bgRFC runtime.

We can assign units to virtual queues, which are identified by name and destination.You can see a hierarchical view of the bgRFC with the names of the destinations and queues from transaction SBGRFCMON.

After bgRFC units have been written to the database at COMMIT WORK, they are processed by a scheduler. You can see more configurations in SBGRFCCONF.

Multiple schedulers can be defined to process the destination.

You can specify a value >0 in your configuration. A large number of schedulers can help a system to process more queries in parallel if the system load is heavy. However, if the system load is light, too many schedulers will block each other and reduce throughput.

The bgRFC can be tRFC or qRFC type, so if you need the units within a single queue always processed sequentially, please use qRFC type. Of course, you can configure the destinations/queues  to process units in parallel using multiple DIA processes.

Best regards

Helen

[former_member267124]

Thanks very much Helen - really appreciate the response.

Can I add one more query - within the bgRFC configuration, how does the number of open connections affect execution, when using qRFC?

Does it limit the number of units that can be added to a queue, or does it limit the number of queues that can be processed in parallel?  

Thanks again

Todd