Skip to Content

Explanation of bgRFC processing and configuration


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


Add a comment
10|10000 characters needed characters exceeded

Assigned Tags

Related questions

1 Answer

  • author's profile photo Former Member
    Former Member
    Posted on Jul 28, 2016 at 09:39 AM

    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


    Add a comment
    10|10000 characters needed characters exceeded

    • 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


Before answering

You should only submit an answer when you are proposing a solution to the poster's problem. If you want the poster to clarify the question or provide more information, please leave a comment instead, requesting additional details. When answering, please include specifics, such as step-by-step instructions, context for the solution, and links to useful resources. Also, please make sure that you answer complies with our Rules of Engagement.
You must be Logged in to submit an answer.

Up to 10 attachments (including images) can be used with a maximum of 1.0 MB each and 10.5 MB total.