New ALE mechanism using bgRFC

Mike Sibler – SAP Active Global Support

Questions raised during the
workshop
Questions raised during workshop – part I

 Troubleshooting bgRFC:
– How to identify if the bgRFC scheduler is running?
In 7.40 transaction SBGRFCSCHEDMON exists, in 7.31 the report
RS_BGRFC_SCHEDULER_MONITOR can be used
– How to restart a scheduler?
Not directly possible: Could be done by reducing in SBGRFCCONF the number of schedulers to 0 and
then increase again. But in general AUTOABAP checks every 5 minutes if the scheduler is running and
restarts it if not. This is not the case for RFC.

 How to stop a destination if no messages are in processing:

– This can be done via an API. The relevant lines of code are:
li_monitor = cl_bgrfc_monitor_api=>create_bgrfc_monitor_inbound( ).
li_monitor->lock_destination( dest_name = lv_dest_name ).

 What is stored in Units in bgRFC – whole payload or just pointer to IDoc?

– Just a pointer to the IDoc. Therefore also the normal IDoc processing (RBDAPP01) and the bgRFC can
coexist. In case the IDoc was consumed by RBDAPP01 before the bgRFC unit the final status will be
detected and the unit will be deleted.

 Is it possible to change e.g. the number of connections dynamically in SBGRFCCONF?

– In general yes after Note 1915746 – “Parameter change in SBGRFCCONF does not come into effect
immediately” is implemented

© 2016 SAP AG. All rights reserved. 3

Questions raised during workshop – part II

 Is it required to run the bgRFC scheduler in client 000?

– In our internal tests ALE inbound processing did not work when the scheduler was started on any other
client. It seems to use a similar mechanism like the WS runtime that also requires scheduling on client
000
– An explanation is provided in the first section of the following wiki:
https://wiki.scn.sap.com/wiki/display/ABAPConn/Technical+Setup+and+Reset+of+the+Web+Service+Ru
ntime

 In case of IDoc processing errors will the bgRFC logic be executed again:
– No in case of reprocessing of IDocs after error (non-queued) the IDocs will be posted normally without
using bgRFC resource control.
– Due to the low number of IDocs in error there should be no need to run them via the bgRFC runtime
again.

© 2016 SAP AG. All rights reserved. 4

Introduction
Motivation
Why is a new ALE inbound processing required?

Current ALE framework offers two ways of inbound processing for IDocs:
■ Immediate processing
■ Posting the IDocs in background using RBDAPP01

Challenges and limitations of this approach:

■ Problems with trigger immediate:
■ High number of DIA WPs required for posting the IDocs since posting happens synchronously
■ Two WPs on receiver side till the IDoc is posted
■ DIA WP on sender side has to wait till the IDoc is posted. This is causing high overhead
on sender side and problems with the Max. Connections in SMQS
■ In case of high incoming IDoc load users can be affected
■ Problems with background posting:
■ Business KPIs not met due to high delay in IDoc posting due to latency of jobs
■ Very high number of jobs can cause problems in job scheduling and monitoring
■ No prioritization of IDocs possible for inbound posting
■ IDoc errors due to locking issues can not be addressed properly (except using serialized IDocs E2E)

Idea:
■ Renovation of job based processing to more dynamic process with less jobs, starting processing
faster depending on priorities and with better overall resource control

© 2016 SAP AG. All rights reserved. 6

Delivery of this new feature

 Initially shipped as pilot only via Note 1803547 - Pilot: IDoc Eingang mit Hilfe
von bgRFC

 With EHP6 (SAP Basis 7.31) the feature is shipped per default
 More information at Note 1793313 - ALE: IDoc inbound using bgRFC as standard

 Queued IDocs:
 Will be released with Note 1855518 with basis release 7.31 SP9

 Important bug fix:

 1929952 – Too late release of locks in bgRFC IDoc inbound processing
Can cause Idocs remaining in status 64 without further processing

© 2016 SAP AG. All rights reserved. 7

Overview
Concept of the new ALE framework
Concept:
■ Usage of bgRFC to queue the IDocs before posting
■ Different bgRFC destinations with different parallelization allow prioritization of interfaces
■ Priority 1 will always try to poste the IDocs immediately to minimize a possible delay. Only if
no resources are available bgRFC will be used
■ Asynchronous processing: the sender can continue operation without waiting for the posting
of the IDoc
■ In WE20 new option to configure new option to post the IDocs

Background on bgRFC:
■ New RFC framework replacing tRFC and qRFC
■ Already in use for other technologies like WSRM
■ Highly scalable and configurable RFC framework
■ More information in the Appendix

Benefits
■ Non-disruptive for business since message types can be switched individually
■ Faster average time until processing per IDOC to improve meeting business KPIs / SLAs
■ Prioritize: process messages with higher business importance before less important ones
■ Locking issues can be avoided by queuing the IDocs based on payload information (e.g.
Material Number)
■ No jobs for posting the IDocs are required
■ Improved operations by less granular configuration
■ Transparent from monitoring perspective (no new status, same monitors and same
troubleshooting methods as before)

© 2016 SAP AG. All rights reserved. 8

Overview of changed architecture
IDoc inbound processing by bgRFC (immediately or ASAP)

communication ALE layer Old logic = avoid impact application

IDoc IDoc IDoc

IDOC_INBOUND_IN_QUEUE Current process
IDoc IDoc IDoc
EDIQI
qRFC
EOIO
collect EDIDC
WEINBQUEUE
IDOC_INBOUND_SYNCHRONOUS
processing status 64
IDoc mode status 75
IDOC_INBOUND_ASYNCHRONOUS

RBDAPP01
immediately (A)synchronous calls to (re)start queue

Asynchronous calls IDoc

no
Switch on/off process Synchronous calls IDoc
by priority
per interface Stop or batch if no resources IDoc
yes

WE20 BADI
IDoc IDoc IDoc
worklist
Determine priority EOIO

Determine high IDoc

sequence

medium IDoc

Multiple queues per

Queue name and
default priority per
low priority IDoc

interface No user switches

New processing logic No qRFC

© 2016 SAP AG. All rights reserved. 9

Planned Key Enhancements “Immediately” processing
1. Avoid affecting current process not affected
• One global decision (customizing) to the new immediately process by priority
• Additionally solution can be switched on explicitly per partner profile

2. Determination of priority: faster processing of IDOCs with higher importance

• 1 + n priorities (e.g. high, medium, low) are possible
• Assignment of default priority per inbound partner profile (tx WE20)
• Assignment of alternative priority via BADI with parameter control record and IDOC data
• priority defines resource assignment.
• Different server groups can be assigned per priority group, plus resource limit (max no of WPs)

3. Determination of sequence: artificial serialization when needed or external FIFO queuing

• avoid parallel process of same objects via queued bgRFC
• Processing in queue needs a queue name (can be defined externally or internally via FM)
• Own queue determination by a rule similar to QRFC IDOC outbound with QRFC techniques
• SAP will provide rules as example, customer own rules possible (own modules like qRFC out)
• After completion: external queuing (currently qRFC) to use same new framework

4. Dynamic retry on error: allow automatic retry in case of temporary issues (e.g. locking)
• Trigger via own criteria (BADI) direct reprocessing IDOCs on error (and allow to limit attempts)
• In case retry is done for queued IDOCs, IDOC on error remains on top of list (enables EOIOIP)

5. Dynamic worklists: worklist is always up to date with latest IDOCs received

• as result of priority and sequence determination;
• Possibility on each priority level to process in queues and transactional (individual parallel units)
© 2016 SAP AG. All rights reserved. 10
 Details on planned processing of worklists
tRFC inbound I/II
Rfc call ends when Idoc is saved and application triggered
 Reduced time when 2 WPs are used
 No more batch jobs for trfc in case of no resources

Highest prio tries to Resource optimization application

ALE layer
process immediately and higher stability
similar to current process
yes
aRFC resources IDoc
worklist
?
DEFAULT or ALE Servergroup

no bgRFC transactional
no sequence
IDOC saved+received
Other prio is taken

bgRFC inbound
sequence by ratio of IDoc
destination 1
queuename bgRFC in queue
into worklist

ressources
Servergroup 1
number parallel destinations

no sequence
bgRFC ratio of bgRFC inbound
IDoc
in queue or transactional ressources destination 2
sequence by Servergroup 2
queuename number parallel destinations Standard:
Appl called
exactly once
no sequence
bgRFC ratio of bgRFC inbound
ressources
IDoc
in queue or transactional destination 3
sequence by Servergroup 3
queuename number parallel destinations

Repeat processing repeat

on
error?
Avoid idle times
 Free higher prio resources can partially be used Repeat on error triggered via BADI
 Safety buffers ensure lower prio limit use by lower prio  own logic could limit to N times
© 2016 SAP AG. All rights reserved.  If queued this allows EOIOIP, IDOC remains on top. 11
 Details on planned processing of worklists
qRFC inbound I/II
Rfc call ends when Idoc is saved and application
triggered
 Reduced time when 2 WPs are used
Highest prio tries to  Use of bgRFC if current Resource optimization application
ALEqueue
layeris in process
process immediately and higher stability
similar to current process
yes
aRFC resources IDoc
worklist
?
DEFAULT or ALE Servergroup

no bgRFC in queue
IDOC saved+received
Other prio is taken

sequence by
queuename bgRFC inbound
destination 1 IDoc
into worklist

Servergroup 1
number parallel destinations

bgRFC in queue ratio of bgRFC inbound

sequence by IDoc
ressources destination 2
queuename
Servergroup 2
number parallel destinations

ratio of bgRFC inbound

sequence by bgRFC in queue ressources
IDoc
destination 3
queuename Servergroup 3
number parallel destinations

Avoid idle times

 Free higher prio resources can partially be used
 Safety buffers ensure lower prio limit use by lower prio
© 2016 SAP AG. All rights reserved. 12
Details on planned processing of worklists II/II

1. bgRFC resource management per priority level

• for each priority level an own bgRFC inbound destination can be created.
• each inbound destination is assigned to own or same servergroups.
• The number of parallel processes can be restricted for each inbound destination.

2. Processing logic of highest priority

2.1. No sequence necessary (no serialization)
• If no queue name has determined inbound processing will be started by asynchronous RFC call without
resource check.
• If no ALE inbound servergroup (tx OYEA) has been maintained servergroup DEFAULT (all servers are
included) is used.
• No waiting for end of task. If it fails because of technical RFC issues (e.g. no resources) further processing will
be started using by bgRFC transactional using inbound destination 1 (highest).
2.2. Serialization via bgRFC queues
• If a queue name was determined inbound processing will be started by bgRFC in queue using inbound
destination 1 (for highest).
2.3. inbound destination
• Idocs of that priority will use just the ’high’ inbound destination.

3. Process of others lower priority

• bgRFC is used transactional if no queuename is provided, it is used as queue if a queuename is provided.
• Prioritization is possible because each inbound destination can use own server groups and for each inbound
destination the number of parallel processes can be restricted.
• Idocs with priority can use other inbound destination (after configuration) using is partly possible if resources
are available and different server groups are available
• this part is restricted by percent due to customizing (e.g. ALE scheduler medium can use 20% resources of
scheduler high).

© 2016 SAP AG. All rights reserved. 13

Configuration & Monitoring
ALE configuration to use
bgRFC
ALE Configuration – WE20

 New option available when selecting “Trigger Immediately”

 Here assignment from IDoc type to priority is done

© 2016 SAP AG. All rights reserved. 16

ALE Configuration – WE20BGRFC
 WE20BGRFC is used to define priorities and assign it to the corresponding inbound destination:
 Define priorities:

 Assign priorities to its inbound destinations (have to be configured in SBGRFCCONF before

 In case of queued processing additional queue naming rules can be specified here

© 2016 SAP AG. All rights reserved. 17

bgRFC configuration options
for ALE inbound processing
Potential setup for ALE processing

 Screenshots shows setup of three different

priorities:
 Main difference is the number of connections
(Higher parallelism for higher priority) and
the prefix for monitoring in SBGRFCMON
 Furthermore the number of active requests per
application server can be restricted using the
“Open connections”

© 2016 SAP AG. All rights reserved. 19

Monitoring examples for ALE
over bgRFC
bgRFC Monitoring examples during runtime

 SBGRFCPERFMON

Number of Executed messages

based on connections per destination

 SBGRFCMON:

© 2016 SAP AG. All rights reserved. 21

ALE monitoring for bgRFC steps

 WE05 – additional status 64 for transfering data to bgRFC

 In table EDIDS:
 Time between countr second status 64 and 62 is the time IDoc spend in bgRFC (in example 3:41
minutes)

© 2016 SAP AG. All rights reserved. 22

Test results of new ALE framework
Latency
Baseline test - Compare latency of IDocs

 Test setup:
– 240 IDocs send per minute for one interface only
– Test 1: Using RBDAPP01 scheduled every minute
– Test 2: Using bgRFC with 5 parallel connections

 Result :
– IDoc wait time with bgRFC 0 seconds compared to 38 seconds with job based approach (see graph
below)
– 38 seconds is around average wait time till job is running + time till backlog is consumed by job

© 2016 SAP AG. All rights reserved. 25

Work Process utilization
Compare DIA Work process usage
 Test setup:
– 150 IDocs send per minute with an IDoc posting time of around 5 seconds
– Test 1: Using RBDAPP01 scheduled every minute
– Test 2: Using bgRFC with 6 parallel connections

 Result :
– With bgRFC clearly controllable DIA WP utilzation for IDoc processing
– With RBDAPP01 very high DIA WP usage

Test with RBDAOPP01

Test with bgRFC

© 2016 SAP AG. All rights reserved. 27

Processing times with
different priorities
Test A: different priorities with different volumes

 Test setup:
– 2 Message Types:
o COMAS using MP with 5 connections
o ZCOALM using LP with 1 connections

 Result :
– 7770 ZCOELEM and 4200 COSMAS
– MP: Average 0 secs wait time
– LP Average 9 secs wait time

© 2016 SAP AG. All rights reserved. 29

Test B: different priorities with same volumes

 Test setup:
– 2 Message Types:
o COMAS using MP with 5 connections
o ZCOALM using MP with 2 connections
– Same volume planned : 240 messages every minute
– At the end 5180 Idocs of both message types

 Result :
– Average MP: 0 secs
– Average LP: 8 secs

© 2016 SAP AG. All rights reserved. 30

Test C: same as test B but with RBDAPP01

 Test setup:
– 2 Message Types:
o COMAS using MP with 7 connections
o ZCOALM using MP with 2 connections
– Same volume planned : 240 messages every minute
– RBDAPP01 scheduled every minute for both interfaces (two individual jobs)

 Result :
– Only medium priority evaluated:
o With bgRFC the average response time was 0 seconds. Now the average wait time is 33 seconds
due to the 1 minute scheduling interval of the RBDAPP01.

© 2016 SAP AG. All rights reserved. 31

Impact on sender system
Check resource consumption on sender side - Test I

 Test setup:
– Done on internal AGS system
– Posting of IDoc takes several seconds to simulate a higher impact on sender system
– Both tests are using trigger immediately on Sender and Receiverside:
o Test I: On Receiver side with standard trigger immediate
o Test II: On Receiver side with new ALE framework using priority 01 (using bgRFC in case of shortage)
 Test I:
– Regular peaks can be seen during the test period
– Very high backlog in case

Test period

© 2016 SAP AG. All rights reserved. 33

Check resource consumption on sender side – Test II
 Test II – new ALE framework:
– No backlog can be see in SM58

– Al resources on SMQS for this receiver were free (unfortunately no screenshot taken)
– On receiver side overload occurred and therefore HP messages were processed using bgRFC

– In general less peaks during message processing

Test period

© 2016 SAP AG. All rights reserved. 34

Check resource consumption on sender side - Summary

 Summary:
– Better decoupling of sender and receiver system with new ALE framework
– In case of performance problems on receiver side much less resources will be blocked on
sender side
– Number of work processes per SMQS destination are used less and therefore risk of
blockage of high priority messages on sender side is reduced significantly.

© 2016 SAP AG. All rights reserved. 35

Thank you
Appendix
bgRFC concepts & architecture
History of Remote Function Calls

In the beginning...
 Synchronous RFCs (sRFC)
 Systems involved must be available at the time the call is made
 Executes the function module (at most) once.
 Quality of Service (QoS): Best Effort (BE)

© 2016 SAP AG. All rights reserved. 39

History of Remote Function Calls

Next developments...
 Asynchronous RFCs (aRFC)
 Executes the function module (at most) once in the RFC Server.
 Remote server must be available at the time the RFC client executes the RFC.
 The parameters of asynchronous RFCs are not logged in the database but sent directly to the server.

 QoS: Best Effort

© 2016 SAP AG. All rights reserved. 40

History of Remote Function Calls
Next developments...
 Transactional RFCs (tRFC)
 Based on the aRFC
 Executes the function module just once (guaranteed) in the RFC Server at COMMIT WORK.
 Remote server need not be available at the time the RFC client executes the tRFC.
 Call remains in the local queue under a unique transaction ID (TID) – 24 byte GUID

 QoS: Exactly Once

© 2016 SAP AG. All rights reserved. 41

History of Remote Function Calls
Next developments...
 Queued RFCs (qRFC)
 Extension of the tRFC
 Multiple LUWs guaranteed to be processed in correct order.
 QoS: Exactly Once In Order

© 2016 SAP AG. All rights reserved. 42

The next step… Background RFC

Since NetWeaver 2004s...

 Background RFCs (bgRFC)

 “Offered” as a replacement of tRFC and qRFC (Type T and Type Q).
 bgRFC comes with new API and data model.
 bgRFC process “UNITS” rather than “LUWs”.
 The units are persisted to the database at COMMIT WORK
 Increased performance compared to tRFC/qRFC.
 Based on a scheduler-driven queuing framework (remote function calls are recorded and
execution takes places at a later time).
 Several schedulers can be started to process bgRFC units.
 Provides 2 Qualities of Service (QoS): EO (Type T) and EOIO (Type Q) processing (Exactly Once;
Exactly Once In Order)

© 2016 SAP AG. All rights reserved. 43

bgRFC – supported scenarios
bgRFC Scheduler...

 Three scenarios for Inbound

 “Inbound Scenario” used for NBS – not supported by classic tRFC

© 2016 SAP AG. All rights reserved. 44

Use Case bgRFC Inbound
Client System

create
Inbound database Server System
units

fetch units

Inbound Scheduler

process units

FM calls

 In the inbound scenario client and server system are identical.

© 2016 SAP AG. All rights reserved. 45
Use Case bgRFC Outbound

Client System

create
Outbound units database Server System

fetch units
process
Outbound scheduler units FM calls

 In the outbound scenario client and server system are different.

© 2016 SAP AG. All rights reserved. 46
Use Case bgRFC OutInbound
Client System

create
OutInbound units database Server System

fetch units
transfer database
Outbound Scheduler units

fetch units

Inbound Scheduler
 In the OutInbound scenario unit data is only
transferred to the server system. process units
 The execution will be done locally by the inbound
scheduler of the server system. FM calls

© 2016 SAP AG. All rights reserved. 47

bgRFC – processing units

bgRFC Scheduler...

 Units processed as a Logical Unit of Work

 A Unit is a recorded sequence of collected function modules to be performed

“remotely”
 The recorded unit data is persisted in the database at COMMIT WORK.
 Function modules executed by the scheduler in the same order.
© 2016 SAP AG. All rights reserved. 48
bgRFC Unit Type T: Creation Phase

Transactional Remote Function Call

Quality of service EO
Supported scenarios
 Inbound
 Outbound
1
Each unit is an independent thread

© 2016 SAP AG. All rights reserved. 49

bgRFC Unit Type Q: Creation Phase

bgRFC Type Q
Quality of service EOIO
Supported scenarios Q-A 11 8 7 4 1
 Inbound
Q-B 11 9 6 4 2
 Outbound
 OutInbound Q-C 10 6 5 3

Units with sequence dependencies

8 7 4 1

11 9 6 2

10 5 3

© 2016 SAP AG. All rights reserved. 50

bgRFC Unit Type Q: Schedule Phase

bgRFC Type Q
Quality of service EOIO
Supported scenarios Q-A 8 7 4 1
11
 Inbound
Q-B 11 9 6 4 2
 Outbound
 OutInbound Q-C 10 6 5 3

Units with sequence dependencies

8 7 4 1

11 9 6 2

10 5 3

© 2016 SAP AG. All rights reserved. 51

bgRFC – process flows

© 2016 SAP AG. All rights reserved. 52

bgRFC configuration
Prerequisites to run bgRFC

Supervisor destination
Necessary for the scheduler to start
Outbound scenario
A destination in SM59 has to exist
The destination has to be maintained for bgRFC
 Select tab strip Special Options -> Protocol -> bgRFC

Inbound scenario
A destination for the inbound scenario is an identifier for the application
This destination can be maintained in SBGRFCCONF
 For Type Q maintain an additional queue prefix

© 2016 SAP AG. All rights reserved. 54

bgRFC – Configuration

Transaction SBGRFCCONF
System-wide Settings:
 Scheduler: System • No. of Log Messages: number of
entries in SLG1
• Log lifetime (h): Lifetime of the
SLG1 entries
• Unit Delete Time (s): Deletion
time for units in seconds
• Compression On: Unit is
compressed before it is stored.
Reduced network load but slightly
more resources are needed.

© 2012 SAP AG. All rights reserved. 55

bgRFC – Configuration

Transaction SBGRFCCONF
Inbound/Outbound Settings:
 Scheduler: App. Server • Scheduler Count: number of
schedulers per application server.
• Open Connections: Max. No. Of
open connections per scheduler.
• Gateway Resource %: % of “free”
gateway resources available to the
scheduler.
• Scheduler Idle Time: How long
Per app the scheduler waits if no queries
server are currently waiting to be
Available processed.
per • Entry Expiration: Automatic load
server
balancing data normally collected
“-1” by returning calls. Request made if
means information is older than this
“1” value.
• Dest. Per Scheduler: Max. No. Of
Recommendation:
60s destinations processed by a
scheduler.

© 2012 SAP AG. All rights reserved. 56

bgRFC – Configuration

Transaction SBGRFCCONF
Destination Settings:
 Scheduler: Destination • Scheduler Count: number of
schedulers per destination.
• Max. Auto. Retries: Number of
retries if a Unit fails.
• Wait per Unit (s): Wait time
between 2 successive retries.
• Wait/Destination (s): Wait time
between 2 successive attempts to
Per Transaction: connect to a destination.
destination SBGRFCHIST
• Dest.Proc Time (s): Max. time a
scheduler can process units for a
particular destination.
• Open Connections: Max. No. Of
connections per destination.
• Unit Alive Checks: If a scheduler
Access protection exits while units are being
for queues and
destinations
processed, the next scheduler
checks the status of the units at
regular intervals. Once exceeded,
units are locked.
© 2012 SAP AG. All rights reserved. 57
bgRFC – Configuration (number of schedulers)

Number of schedulers (increases possible parallel load)

• The number of schedulers can be configured as a „default entry“ for all application servers
• or specific to a single application server
• -1 means „default“ and this is 1, so the configuration below would start 1 Inbound scheduler and 1
outbound scheduler on each application server in the system

© 2012 SAP AG. All rights reserved. 58

bgRFC – Configuration (number of schedulers)

Recommendation for the number of schedulers

• Spread schedulers over (almost) all application servers
• You may exclude an application server which is reserved for special use (sometimes
customers do not want additional load on central instances)
• You should spread over as many application servers as possible, because this is a kind of
failover strategy. The schedulers still work
• if one or many application servers are shut down
• If an application server suffers from a lack of resources
• If more than 2 application servers are used, then keep default -1, because you would then have at least 3 schedulers
• If 1 or 2 application servers are used set the value to 2

Estimation for throughput of bgRFC

• A single scheduler is expected to be capable to handle up to 70-100 units/s. The main
limitations in scaling are
• Number of work processes available
• Number of cores(cpu)„s available
• I/O throughput. In internal systems at some point in time the duration for commit„s get„s so high that the schedulers do not scale
any more

© 2012 SAP AG. All rights reserved. 59

bgRFC – Configuration (idle time)

Idle time (can decrease latency)

• Normally a scheduler is immediately triggered when a new unit is created,
however under some circumstances this trigger might fail
• There is a timeout where a scheduler will look for new work even then when it got
no trigger
• Decreasing the timeout can decrease the latency, but will slightly increase the
load in case of no work
• Recommendation: Decrease to smallest value 60

© 2012 SAP AG. All rights reserved. 60

bgRFC – Configuration

Transaction SBGRFCCONF
Inbound Dest. Settings:
 Define Inbound Dest. • Destination: Name of the
destination linked to a RFC
destination (SM59).
• Logon/server group: Load
balancing for inbound processing
(RZ12). Transaction SARFC
shows available resources per app
server (Dialog WPs).
• Prefixes: Name extension for a
queue in bgRFC processing. If no
queue is found, exception thrown.
• Using a server group: specific to
a destination, it is possible to
control where units are processed.
Leaving this empty will balance
processing across ALL available
application servers (SPACE
group)

© 2012 SAP AG. All rights reserved. 61

bgRFC – Configuration (supervisor destination)

Transaction SBGRFCCONF
Supervisor Dest. Settings:
 Define Supervisor Dest. • Destination: Name of the RFC
destination.

• The supervisor destination for

bgRFC receives the configuration
settings for the bgRFC scheduler.

• It also stops and starts the

schedulers as required.

© 2012 SAP AG. All rights reserved. 62

bgRFC – Configuration example

Scheduler typical Recommendations

 Scheduler: App. Server:
 Scheduler Count: -1
 Number of Open Connections per Scheduler: 500
 Gateway Resources: 50%
 Scheduler Idle Time: 60 seconds
 Entry Expiration: 10
 Dest. Per Scheduler: 5
 Scheduler: Destination
 Scheduler Count: -1 (no restrictions to the number of schedulers)
 Max. Auto Retries: 30
 Wait per Unit: 60 seconds
And control all resources using profile
 Wait per Destination: 60 seconds
parameter rdisp/rfc_min_wait_dia_wp
 Dest.Proc. Time: 0 seconds
 Open Connections: <depending on priority>
 Unit Alive Checks: 30
 History: Not Active
 Define Inbound Destination
 Initially no server group defined (equally balanced)

© 2012 SAP AG. All rights reserved. 63

Important bgRFC bugfixes

 1915746 - Parameter change in SBGRFCCONF does not come into effect

immediately
 1866696 - SBGRFCCONF - Field for Check Class is too short
 1802863 - Deadlock for heavy load during access to QRFC_I_QIN
 1764977 - No data is collated for bgRFC errors in CCMS (transaction RZ20)
 1666612 - bgRFC scheduler : older units not executed during heavy load

© 2012 SAP AG. All rights reserved. 64

bgRFC monitoring & alerting
bgRFC Monitor SBGRFCMON

© 2016 SAP AG. All rights reserved. 66

bgRFC Monitor SBGRFCMON Detail

© 2016 SAP AG. All rights reserved. 67

 bgRFC Monitor SBGRFCMON Detail

Transaction SBGRFCMON

 Monitor for bgRFC Units

• Destination: All configured destinations available

• Unit Types: Both queued and transactional units displayed.

© 2012 SAP AG. All rights reserved. 68

bgRFC – Monitoring

Transaction SBGRFCPERFMON (Program: RS_BGRFC_PERFORMANCE_MONITOR)

© 2012 SAP AG. All rights reserved. 69

bgRFC – Monitoring

Transaction SBGRFCMON

 Some Key Tables for Inbound bgRFC Units

 TRFC_I_UNIT
 Inbound tRFC: Unit Header
 QRFC_I_UNIT
 Inbound qRFC: Unit Header
 TRFC_I_SDATA
 Inbound tRFC: Unit Payload
 QRFC_I_SDATA
 Inbound qRFC: Unit Payload
 BGRFC_I_RUNNABLE
 Inbound tRFC/qRFC: Executable Units
 BGRFC_I_DESTLOCK
 Inbound tRFC/qRFC: Destination Locks
 QRFC_I_QIN
 Inbound qRFC: Queue Order
 QRFC_I_EXE_STATE
 Inbound qRFC: Unit State
 TRFC_I_EXE_STATE
 Inbound tRFC: Unit State

© 2012 SAP AG. All rights reserved. 70

bgRFC – Data Model

Data Model... TRFC_I_SDATA

PK, FK1 UNIT_ID TRFC_I_UNIT_LOCK

TRFC_I_UNIT
PK UNIT_ID FUNC_DATA PK LOCK_ID

UNIT_ID
PRED_CNT
REDO_CNT FK1 LOCK_KIND
VALID_UNTIL
IS_DELETED
TRFC_I_ERR_STATE
IS_NOOP
CTIMESTAMP PK, FK1 UNIT_ID
UNAME
CLIENT MSGNR
LANGU
TRFC_I_QIN
TCODE
CPROG
PK, FK1 UNIT_ID
HOST_NAME
TRFC_I_EXE_STATE
UNIT_SIZE
QUEUE_NAME
IS_TRACE_ON
PK, FK1 UNIT_ID
PW_HASH

TIMESTAMP
SCHEDULER_ID
STATE

© 2012 SAP AG. All rights reserved. 71

 bgRFC – Monitoring with Business Process Monitoring

Business Process Monitoring of bgRFCs...

5 NBS business processes defined:

• Bulk Payments IN
• Bulk Payments OUT
• Base24 Card Status Out
• Immediate Payments Out
• Proactive Risk Out Manager

© 2012 SAP AG. All rights reserved. 73

bgRFC – Monitoring with Business Process Monitoring

Business Process Monitoring of bgRFCs...

9 KPIs provided for BPM of bgRFCs:

• BL – Backlog
• Total Number
• ST – Status
• Lock Status
• Error Status
© 2012 SAP AG. All rights reserved. 74
bgRFC – Monitoring in Application Log

Application Log SLG1...

SLG1 Logs are client specific

 Scheduler runs in client 000 – SLG1 entries for scheduler visible only in client 000
 Units are executed in business client – SLG1 entries for units visible only in the business client

© 2012 SAP AG. All rights reserved. 75

bgRFC – Monitoring with CCMS

CCMS...

Destination
 Current number of parallel tasks for this bgRFC destination
 Ratio of communication steps with errors to total number of communication steps (in %) during
the observation period
 Number of bytes processed within the observation period, with reference to the length of the
time interval

© 2012 SAP AG. All rights reserved. 76

bgRFC – Monitoring with CCMS

CCMS...

Scheduler
 Start time of bgRFC scheduler instance
 Current size of program context of bgRFC scheduler instance in KB
 Current throughput of a bgRFC Scheduler instance (units per hour)
 Average throughput of a bgRFC Scheduler instance (units per hour)

© 2012 SAP AG. All rights reserved. 77

bgRFC – Monitoring with CCMS

How to find the entries:

 SAP CCMS Technical Expert
Monitors
 All Monitoring Contexts
 Instance
 bgRFC - inbound

© 2012 SAP AG. All rights reserved. 78

bgRFC – Monitoring of Enqueue locks

Enqueue Monitor... Transaction code SM21

More info at Note 1887188 - Various locks in transaction SM12 on WSRM and bgRFC tables

© 2012 SAP AG. All rights reserved. 79