DATA TRANSFER TECHNIQUES

RFC: Remote function call (SM59) it is used to call the other system using the
gateway to fetch or send the information.

There are 4 types of RFCs

1. ARFC

2. SRFC

3. TRFC

4. QRFC

ARFC : Asynchronous RFC: It is used to communicate between two systems but

the source system process may not get the acknowledge from the Target. Some
times the data may be lost in transition. The source system process does not
bother whether the information is received by the target system. It is similar to a
post card. It is not reliable and consistent.

SRFC: Synchronous RFC: It is used to communicate with receiving system and

wait for acknowledgement. If the acknowledgement is delayed it will go into RFC/
Sleep/ CPIC Mode.

It is reliable but the resource gets blocked at the target system. If the
target system is not available (Example BTC Process waiting too long in the
active state)

- All BW Systems uses SRFC.

SM58 - To find all the IDOCS

TRFC: Transactional RFC : It is an advanced version of ARFC. It is used to

communicate with receiving system and if the system is not available it will
generate a Transaction ID in SM58. and a background job RSARFCSE runs for
every 60 Seconds. It is reliable, gets the acknowledgement and data
transmission is consistent.

Example: Central User Administration

Parent client creates users and send it to child clients. If child client is not
available it creates a transaction ID in SM58 and ensures delivery when the child
client is available.

QRFC: Queued RFC: It is an advanced version of TRFC to ensure the jobs are
processed in a queue. To execute QRFC we have a job called QUIN Scheduler

- We have SMQ1 (Outbound), SMQ2 , SMQR - Quin Schedulers

QRFC generates the process of LUW's in the sequence. When the sequence is
mandatory in the data transmission QRFC is recommended. SAP Implemented all
the above services to ensure the quality in the data transmission. SAP named it
as QoS (Quality of Service). SAP consider SRFC, TRFC and QRFC.

1. SRFC --- BE (Best of Efforts) - With best of efforts it will deliver to Target
system. When you find BE it is SRFC. Majorly we are going to use in BI and XI
Systems.

2. TRFC -- EO (Exactly once) - It checks exactly once.

3. QRFC - EOIO - Exactly once in Order.

ALE: (Application Link Enabling): It is used to transfer two loosely coupled

systems (SAP to SAP systems) Eg. BW to CRM; ERP to ERP etc. SALE/ BD64/ BD54
it is used to define the logical systems and sending/ receiving systems. Each
system that participates in the data transmission is identified by it's logical
system name i.e. SIDCLNTCLIENTNO.

Transfer ----------- Exchange -------------- Transmission => Are Same

And is recommended to define the RFC's using logical system name to uniquely
identify in the landscape.

1. Define the distribution model (In Sale TCode) in BD64 (Change) - Create Model
View - Give the tech name - Continue.

2. API's Application Programming Interface: It is an interface in BD64 select the

model click on ADD API defined based on your application either to send or
receive data based on the business it is called as BAPI. (Business API's). The BAPI
will be assigned between the sending and receiving system

BAPI contains one or more methods.

Methods are similar to function modules to perform certain tasks.

EDI: Electronic Data Interchange: It is used to transfer the data between SAP to
Non-SAP systems and vice versa.

In order to monitor the EDI used TCODE WE05

IDOC: Intermediate Document: It is in the understandable format of both sender

and the receiver. Non SAP systems could communicate directly with SAP
systems. They required adapters (File Adapter, J2EE Adapter, IDOC Adapter,
HTTP Adapter etc)

When the supply chain market is growing the necessity of 'E-Commerce'

Electronic business EB's) is gaining importance and the vendors, suppliers wants
the documents flow electronically with out any paper In order to monitor multiple
senders and recipients it will be difficult to use SAP Standard transactions, SAP
standard systems and mechanisms.

Extensions:
CAR - Compressed Archive --- Mostly for Patches
SAR - SAP Archive -- Mostly for SAP Kernel.
JAR - JAVA Archives
WAR - Web Archives
SCA - SAP Component Archives
SDA - Deployable archives software SAP
EPA - Enterprise Portal Archives
.ZIP - Zip Files
EAR - Enterprise Archives
TPZ - XI/ PI Content

Which is better... Remote Client Copy or Client Export /

Import?
Remote client copy is through RFC and it will not create a transport request
Transaction Code: SCC9.

Client Export is via transport. When you do a client export the system will create more than
one transport request depends on the profile you select

Transaction Code: SCC8. Client Export will create cofile and data file in your source
system /usr/sap/trans data and cofile directory. Copy the transport requests to your target
system(Data file and Cofile). These transport you need to import into the target client using
tp addtobuffer and tp import command, after the import you need to run transaction - SCC7
in target system, which will perform the post import activities for the client import.

The best method for the client copy is Client Export and import process compare to RFC.
RFC process works fine for small amount of data copies and depends on the profile you are
going to choose for the copies. For large db's better go for export import and file split options
if you are n unix 10.20. Unix has file limitations for 2 gb.

A large client copy with export and import post processing took 4 days for the export,
14 days for
the import on unix 10.20 for 68 gb of data.

How to increase maximum number of SAP sessions per

user?
Some times user may get an informative message "Maximum number of sessions reached".
You should alter the parameter rdisp/max_alt_modes for this purpose. Take transaction RZ10
(profile edit). Take instance profile. Then take the option Extended maintenance. Its default
value is 6. Restart the instance.

System Log Errors

DB_RTAB_ERROR at Table TSP0A, Error 64 rspogdio 2: The cause of this error is that
the system tries within the spool work process to carry out archiving with a formatting that
does not exist.
UPDATE STATUS
In production system, update entries are getting stuck in 'V2 Processed' state. Details of the same
show that the collective run state is in initial state for functional module 'MCEX_UPDATE_03'.

Solution:

1. Do it manually in sm13,select the requests and repeat update.

2. Check SAP kernel patch leve. Check note: 1118587

Update management supports different statuses for update requests. The status indicates the phase of
the update process that the request has reached, or in which the request has become "stuck". The
background of the status field can be green (not yet processed, currently being processed), yellow (not
yet processed, probably "stuck"), or red (terminated with error). The column Info provides further
information.

The dialog work process passes the update request onto an update work process after the dialog area
has been completed. This then processes the V1 update modules. When the ABAP statement
COMMIT WORK is received, the data is written to the database and the V2 update is output to a V2
work process (providing V2 modules exist in the update request).

0 Response to "UPDATE STATUS"

Transactional RFC and Queued RFC Monitor

Use
Transactional RFC and queued RFC are variants of the Remote Function Call
that make the data transfer between different systems more reliable and more
secure.
Transactional RFC guarantees the following attributes:
• The call is executed exactly once in the target system.
• Calls that belong to a Logical Unit of Work (LUW) are either completely executed, or
not executed at all.
If the target system is not available when the call is made, the call remains in the
local wait queue. The calling dialog program can, however, proceed. If the target
system does not become active within a certain amount of time, the call is
scheduled as a background job.
Although tRFC significantly improves the reliability of the data transfer, it also
has disadvantages. This method does not ensure that the sequence of LUWs
specified in the application is observed. However, there is a guarantee that all
LUWs will be transferred at some point.
Queued RFC (qRFC with Outbound Queue)
To offset this disadvantage, a serialization of tRFC is performed using wait
queues. It is called queued RFC (qRFC). With this serialization, an outbound
queue for tRFC was created, which is therefore referred to as qRFC with
outbound queue. The main features of qRFC are as follows:
• A LUW is only transferred if it has no predecessor (in reference to the sequence defined
in the applications) in the participating queues. After a qRFC transaction is executed, the
system attempts to start the next qRFC transaction in the sequence from the queue.
• A queue name and a queue counter are required fore each qRFC transaction for queue
administration. Each tRFC call that is to be processed chronologically is assigned a queue
name determined by the application.
qRFC with Inbound Queue
Serialization of the incoming RFC calls from other systems is also possible. This
ensures that incoming calls are always executed in the order of their arrival. This
serialization of incoming calls also limits the maximum load on the target server
caused by RFC.
Monitoring with the Alert Monitor
Using the Transactional RFC and Queued RFC subtree, you can quickly detect
errors and blocked queues (in the context of transactional RFC and queued
RFCs). The corresponding special monitors with which you can quickly eliminate
the cause of the error are set as analysis methods. The subtree is in the
Communications monitor of the SAP CCMS Monitor Templates monitor set.
Prerequisites
You have performed the setting up of the monitoring of qRFC calls.
Features
The monitor contains the following monitoring tree elements (MTEs):
MTE Name
(MTE Class)
ARFCSSTATE: Outbound tRFC Calls
(CCMS_tRFC_Outbound_Tbl)
Calls w/ Communication Errors –
CPICERR
(CCMS_tRFC_qRFC_CPIC_Errors)
Calls w/ Execution Errors – SYSFAIL
(CCMS_tRFC_qRFC_SYSFAIL_Errors)
Meaning
Monitoring object with information about the
LUWs and tRFC calls that are waiting to be
executed on their target system or on an external
component.
Number of tRFC calls that were not
executed due to problems creating the
connection or the communication with the
target system or an external component;
depending on the settings (transaction
SM59), the attempt may be repeated a
number of times
Number of tRFC calls that could not be executed
due to a problem with the execution in the target
system or an external component
Calls w/o Server Resources – SYSLOAD Number of tRFC and qRFC calls with outbound
(CCMS_tRFC_qRFC_SYSLOAD_Status) queue with status SYSLOAD; these are calls that
could not be executed due to a lack of resources in
the target system
ARFCSSTATE: Inbound tRFC/qRFC Monitoring object with information about tRFC
Calls and qRFC calls that are waiting to be executed in
(CCMS_tRFC_qRFC_Inbound_TIDs) this system; after they have been executed, they
are deleted from table ARFCRSTATE
Total Calls Number of tRFC and qRFC calls that are waiting
(CCMS_qRFC_Inbound_Total) to be executed in this system and are therefore
stored in table ARFCRSTATE
Outbound Queues Subtrees that contain the log messages of the
(CCMS_qRFC_Outbound_ outbound qRFC calls to external systems; these
Queues_Summary) messages are sorted by the different queue groups:
there is a monitoring object for each group with
the name <Group Name> Outbound Queues
Inbound Queues Subtrees that contain the log messages of the
(CCMS_qRFC_Inbound_ inbound qRFC calls from external systems; these
Queues_Summary) messages are sorted by the different queue groups:
there is a monitoring object for each group with
the name <Group Name> Inbound Queues
Blocked Queues: Client <Number> Log messages for the queues of an application,
(<techn. name queue sorted by the different clients; the log messages
group>_MSC_<no.>) contain the error messages that are returned during
the qRFC call

The following statuses are immediately identified

as “blocking”:

• CPICERROR (for Inbound/Outbound, error

text available)

• SYSFAIL (for Inbound/Outbound, error text

available)

• STOP (for Inbound/Outbound, no error text)

• ANORETRY (for Inbound/Outbound, error

text available)

• WAITSTOP (for Inbound/Outbound, error

text available)

• ARETRY (for Inbound/Outbound, error text

available)

• RETRY (always for inbound, for outbound as

of qRFC version 6.10.040, error text available)

• SYSLOAD (for outbound, up to qRFC

version 6.10.033, no error text)

The following statuses are identified as “blocking”

if they remain unchanged for longer than 30
minutes:

• READY (for inbound/outbound, no error text)

• RUNNING (for inbound/outbound, no error

text)

• WAITUPDA (for outbound, no error text)

• EXECUTED (for inbound/outbound, no error

text)

For information about the possible statuses, see

the Appendix.
 Queues not processed: Age Alerts Log messages for the queues of an application; the
(<techn. name queue group>_Age_Log) queues have not been processed for longer than
the time defined in the associated threshold value
(by default, seven days)
QIN Schedulers: Errors Monitoring object that contains information
(CCMS_qRFC_QIN_Scheduler_Object) about the status of the QIN scheduler; the
QIN scheduler controls the processing of
incoming tRFC and qRFC calls within a
client (see SAP Note 396007)
QOUT Schedulers: Errors Monitoring object that contains information about
(CCMS_qRFC_QOUT_Scheduler_Object) the status of the QOUT scheduler; the QOUT
scheduler limits the maximum number of parallel
tRFC and qRFC connections to an RFC
destination (see SAP Note 400330)
QIN Scheduler Error: All Clients Log messages with error messages for the QIN
(CCMS_qRFC_QIN_Sched_Log) schedulers of all clients; an alert here indicates
that the system could not process an incoming
RFC call due to a communication or execution
error
QIN Unregistered Queues: All Clients: Log messages with error messages for the QIN
(CCMS_qRFC_QIN_Unreg_Log) schedulers of all clients; an alert here indicates
that the scheduler found an RFC call with a non-
registered queue
QOUT Scheduler Error: All Clients Log messages from communication and system
(CCMS_qRFC_QOUT_Sched_Log) errors for the QOUT schedulers of all clients
Activities
To start the monitor, follow the procedure below:

1. Start the Alert Monitor using transaction RZ20 or choose CCMS →Control/Monitoring
→Alert Monitor.

2. On the CCMS Monitor Sets screen, expand the SAP CCMS Monitor Templates set.

3. Start the Communications monitor from the list by double-clicking it.

4. Expand the Transactional RFC and Queued RFC subtree.

Procedure if an Alert Is Triggered

MTE Procedure
ARFCSSTATE: The transaction Transactional RFC (SM58) is assigned as
Outbound tRFC Calls analysis method to all MTEs of this monitoring object. This tool
lists only those transactional RFCs that could not be carried out
successfully or that had to be planned as batch jobs.
Calls Errors often occur in this attribute when an instance is shut down
w/Communication for maintenance. Once the instance is available again, the calls
Errors - CPICERR are automatically processed.

If this is not the case, you should check the RFC connection
using the Display and Maintain RFC Destinations transaction
(SM59).
Calls w/ Execution Errors in the execution of RFC calls are often caused by errors in
Errors - SYSFAIL the programs. These errors must therefore usually be individually
processed.
Calls w/o Server RFC calls with the status SYSLOAD are automatically
Resources - SYSLOAD scheduled in a job. For more information about SYSLOAD
status, see SAP Note 319860.
ARFCSSTATE: For information about possible statuses and problems for table
Inbound tRFC/qRFC ARFCRSTATE, see SAP Notes 378903 and 366869.
Calls
Outbound Queues Start the assigned analysis method. For the MTEs of this
Inbound Queues monitoring object, this is transaction SMQ1 or SMQ2 (qRFC
Monitor).
QIN Schedulers: Errors Start the assigned analysis method. For the MTEs of this
QOUT Schedulers: monitoring object, this is transaction SMQR or SMQS
Errors (QIN/QOUT Scheduler).

See also:

Monitoring qRFC and tRFC Calls

Purpose

Transactional RFC and queued RFC are variants of the Remote Function Call
that make the data transfer between different systems more reliable and more
secure. You can monitor these calls using the Alert Monitor. To do this, in the
Communications monitor of the SAP CCMS Monitor Templates monitor set, there
is a Transactional RFC and Queued RFC subtree. These functions automatically
become active at the start of the system; you can, however, maintain and
extend the functions.

Monitored Objects in the Transaction RFC and Queued RFC Subtree

• The number of outbound transactional RFC calls that could not be processed due to errors
is reported. These errors include data transfer errors (the target server is not reached),
execution errors in the target server, or resource errors (there are not enough servers in the
RFC server group). Alerts are generated if the number of calls with errors exceeds the
threshold value.

• The number of inbound calls from transactional and queued RFCs that are waiting for
processing is reported. An alert is generated if the number of waiting calls exceeds the
threshold value.
• Error messages for inbound and outbound qRFC queues are reported. An error message
means that the affected queue cannot be processed and that all other calls for the queue must
wait until the error is corrected. The following applies here:

− By default, a red alert is generated for every queue error. Only one alert
is generated for an error, irrespective of how often the error is reported in
the monitoring architecture. This means that you do not need to react to
multiple notifications of the same problem. If you delete or complete an
alert, a new alert can be generated if a queue error occurs.
− The errors are grouped by client; all clients are monitored for queue
errors.

• Transfer and execution errors for inbound and outbound RFC schedulers are reported.
The monitoring tree for inbound schedulers also reports about queues that are not registered
for processing. Calls to these inbound queues are not executed until the queues are registered.

Customizing

You can make the following settings in Customizing (see Setting Up Monitoring of
tRFC and qRFC Calls):

• You can create separate subtrees for the messages of individual queues that you specify
by name.

• You can perform extended monitoring for every subtree by specifying exit function
modules.

• For every subtree, you can change the color of the alert from red to a lower level, or set
no alert to be generated.

By default, the tRFC/qRFC monitor is delivered by SAP without Customizing. This

means that all queue errors are monitored in a single subtree. No exit function
modules are executed to extend the monitoring functions or to change the alert
values.

Some SAP applications provide Customizing for this monitor or make

recommendations for Customizing. For recommendations about Customizing
qRFC monitoring, see the installation guidelines for the applications.

Process Flow

To monitor tRFC and qRFC calls, use the Transactional RFC and Queued RFC
monitor.

See also:

SAP Note 441269

 Set Up Monitoring of qRFC Calls

Purpose

Queued RFC is a variant of the Remote Function Call that makes the data
transfer between different systems more reliable and more secure; among other
things, queued RFC guarantees chronological processing of RFC calls.

For monitoring tRFC and qRFC calls, there is the Transactional RFC and Queued
RFC subtree in the Alert Monitor. For information about the structure of the
subtree, see Transactional RFC and Queued RFC Monitor. This section describes
how to set up the monitoring.

For optimal usage of qRFC, there are different queues for different applications,
so that a blocked queue does not affect the other application processes. These
queues are differentiated using their names; in this way, you can assign each
queue to the associated application.

To provide a better overview, each of these queues that is being monitored using
the monitoring architecture should be assigned a separate subtree. Without
Customizing, all queue errors are reported in a single subtree. You can create the
desired monitoring subtrees in Customizing. You can make the following
changes:

• You can create separate subtrees for specific queues. In this way, you can display the
errors for queues whose names begin with CRM_SITES* in a separate tree. Error messages
for these queues are then no longer displayed in the default subtree Queues Not Otherwise
Monitored.

• You can activate additional monitoring functions separately for each subtree using exit
function modules. Function modules for checking the age of the queue (the age of the oldest
call that is waiting for processing) and the number of calls waiting in a queue are already
available to you.

• You can change the color of the alerts that are reported to the monitoring architecture
separately for each subtree. This can be done by assigning a queue status to an alert color or
flexibly using function modules.

Default Customizing settings are delivered for applications and components that use the
qRFC monitoring data. This means that the associated subtrees should already be active after
 delivery. You only need to perform more far-reaching Customizing if the default
Customizing does not meet your particular needs.

Process Flow

...

1. Choose CCMS → Configuration → Alert Monitor, or call transaction RZ21.

2. The Monitoring: Properties and Methods screen appears. Choose Technical Infrastructure →
Configure qRFC monitoring.

3. Confirm the warning that the table is cross-client.

4. The system displays the Change Settings Owner: Overview screen. Changes to Customizing
always belong to an owner. Originally, there is only the owner SAP here. Since you cannot
make any changes to owners that begin with SAP, you must first create an owner for
Customizing.

5. Now select the settings owner for which you want to perform Customizing, and choose the
Queue Groups level at the left edge in the Dialog Structure tree. The system displays the
Change Queue Groups: Overview screen.

6. On this screen, you specify which subtrees are to be created for inbound or outbound queues.
These are the queue groups. Each queue group creates a subtree in the qRFC monitor (see
Creating Queue Groups).

7. You can assign one or more queues to each queue group. Select the desired queue group and
double-click the Queue Assignments level on the left side in the Dialog Structure tree. The
system displays the Change Queue Assignments screen (see Creating Queue Assignments).

8. You can change the color of the alerts that are reported to the monitoring architecture
separately for each subtree or queue. Select the desired queue group or queue assignment, and
double click the Alert Value Shifts level on the left side in the Dialog Structure tree. The
system displays the Alert Value Shifts screen (see Creating Alert Value Shifts).

9. Save your entries.

Result

Your Customizing changes become active the next time the data collection
method CCMS_tRFC_Collector runs. By default, this method runs every 15
minutes.

Comments

• You can only add subtrees for new queue groups using Customizing. If you delete queue
groups, the associated subtrees in the monitoring architecture are simply no longer provided
with data. The subtrees in the Alert Monitor are not automatically deleted. Delete the
corresponding subtree in the Alert Monitor tree manually (see Deleting and Recreating Nodes
in the Alert Monitoring Tree).

• If you are making extensive changes, it can be easier to delete the complete Transactional
RFC and Queued RFC monitor and to start again. You can force a rebuild by resetting the
monitoring segment of the central server of your system (the server with the enqueue service)
to WARMUP status.

• You can restore the default settings by setting the Active field for the owner SAP to x.

See also:
SAP Note 441269

qRFC Monitoring: Create Owner for Customizing

Use
In Customizing of the qRFC monitoring using the monitoring architecture, you can define subtrees
(queue groups) that are to display messages for particular qRFC queues. Each setting in Customizing
belongs to an owner, meaning that you can create different monitoring strategies using different
settings owners.

Prerequisites
This procedure is part of the process setting up monitoring of qRFC calls. It is therefore a prerequisite
that you have already performed the part of the process that is to be performed before this procedure.

Procedure
The system is displaying the Change Settings Owner: Overview screen. The system displays the
entries for the owners of the Customizing settings. If the SAP Customizing was delivered to you, you
see only the owner entry SAP.

Now create your own owner for Customizing. An owner combines various entries for Customizing the
qRFC monitoring. The owner can be, for example, the name of your company. You can create a new
settings owner in two ways:

Copying an Existing Owner Entry

1. Copy an existing owner entry (such as the entry

SAP) by selecting the desired entry and choosing Edit → Copy as….

2. The system displays the Settings Owner table with the copy source as the only entry. Enter
the desired name of the new owner by overwriting the existing name. Accept your input by
choosing ENTER.
 3. If the copy source contains queue groups, queue assignments, or alert value shifts, you can
decided whether you want to copy these for the settings of the new owner. As you want to
copy an owner entry, this is usually the case; in this case, choose Copy All.
4. Confirm the number of dependent copied entries and save your entries.

Creating a New, Empty Owner Entry

1. Choose Edit → New Entries and enter the desired name of the new owner.
2. Save your entries.

The Active column in the Settings Owner table specifies the owner whose
Customizing settings are currently active. Enter X in this column for the
desired user. Ensure that only one entry is valid.

Result
You have specified an owner for additional Customizing settings and can make the other settings.

See also:

qRFC Monitoring: Creating Queue Groups

Use

In Customizing of the qRFC monitoring using the monitoring architecture, you

can define subtrees (queue groups) that are to display messages for particular
qRFC queues. A queue group can include multiple inbound or outbound queues.
In this way, queue groups provide you with an overview, as the messages for
different queues are reported in a single subtree by default.

Prerequisites

This procedure is part of the process setting up monitoring of qRFC calls. It is

therefore a prerequisite that you have already performed the part of the process
that is to be performed before this procedure.

Procedure

The system is displaying the Change Queue Groups: Overview screen. The
system displays the entries for the queue groups that already exist for the
selected owner of Customizing settings.

...

1. If you want to create a new queue group, choose New Entries.

2. If you want to change an existing queue group, choose the desired queue group by double
clicking it.

3. In both cases, the system displays the Change Queue Groups: Detail screen. You can enter
the following data here. There is also help for each of the entries available by choosing F1.

Entry Meaning
Owner Your owner name
Queue Group Name Name of the monitoring subtree in the Alert Monitor; choose a
descriptive name, such as CRM* Outbound Queues or APO
Outbound Queues
MTE Class Technical name for the queue group and therefore the name of the
MTE class that is assigned to the queue group; use only letters,
numbers, and underscores here (such as CRM_Outbound_Queues)
Queue Type (I,O) Indicator for outbound queue (O) or inbound queue (I)
F1 Message ID Identification of a message from table T100 for the documentation of
F1 Message the queue group
Number
Analysis Method Alternative analysis method; by default, the outbound queues are
assigned transaction SMQ1 and the inbound queues are assigned
transaction SMQ2 as an analysis method
Auto-React. Auto-reaction method that is performed in the case of an alert in this
Method queue group; for example, the method CCMS_Email_OnAlert that
automatically informs you about an alert by e-mail or pager (see
Defining Automatic Alert Notification)
Exit FM Name of a function module that is to perform the additional
monitoring for this queue group

Definition of the interface:

See example function module
SALK_QRFC_CALLBACK_SAMPLE

Ready-to-Use Examples:
SALK_CRM_QUEUE_AGE (Age of the oldest entry in days)
SALK_CRM_QRFC_QUEUE_ENTRIES (Number of entries in the
queue)
Exit Parameters Possible static parameters in addition to the parameters transferred in
Parameter Value the interface; dependent on the function module

SALK_CRM_QUEUE_AGE:
Maximum_Queue_Age displays the age of the queue in days as of
which an alert is generated (by default seven days)
 Rec. Exits per Clnt If the content of this field is X, specifies that the exit function module
is to run once for each client; as a consequence, the data that the
function modules return is output separately for each client

This indicator only has meaning if the exit function module is

programmed appropriately. This is, for example, the case for
SALK_CRM_QRFC_QUEUE_ENTRIES.
The entries Owner, Queue Group Name, MTE Class, and Queue Type (I,O) are
required, all others are optional.

4. Save your individual entries.

You should only use the named exit function modules if it is absolutely necessary to do so. If
you use qRFC extensively, the associated tables become very large, meaning that the
modules could create a large workload.

Result

You have created one or more queue groups meaning that messages for
different qRFC queues are to be displayed in different subtrees. For an example
of the output of the queue groups in the Alert Monitor, see Transactional RFC and
Queued RFC Monitor.

qRFC Monitoring: Creating Queue Assignments

Use

In Customizing of the qRFC monitoring using the monitoring architecture, you

can define subtrees (queue groups) that are to display messages for particular
qRFC queues. A queue group can include multiple inbound or outbound queues.
You define which queues belong to which queue groups using queue
assignments.

Prerequisites

This procedure is part of the process setting up monitoring of qRFC calls. It is

therefore a prerequisite that you have already performed the part of the process
that is to be performed before this procedure.
 Procedure

The system is displaying the Change Queue Assignments: Overview screen. The
screen displays the entries for the queues that are already assigned to the
selected queue group.

...

1. If you want to create a new queue assignment, choose New Entries.

2. If you want to change an existing queue assignment, choose the desired assignment by
double clicking it.

3. In both cases, the system displays the Change Queue Assignments: Detail screen. For new
assignments, you can make all entries, while for existing assignments, you can only change
the Deactivate Monitoringindicator. F1 help is available for every entry:

Entry Description
Owner Your owner name and the name of the monitoring subtree in the
Queue Group Name Alert Monitor; enter owners and queue groups that already exist here.
You can use input help here.
Queue Name Name of an individual queue or a name that ends with a wildcard
character (*), such as CRM_SITES*

The queues are monitored as part of the associated queue group. The
system displays all error messages in the monitoring subtree for the
queue group. Every use of exit function modules for the queue group
includes the queues.
Client Client number (or the wildcard character *, to select all clients in the
system); the queue assignment applies only to the specified clients.
Queue Indicator with which you can deactivate the monitoring for specific
Assignments: queues and clients, by entering X in this field.
Deactivate
Monitoring

You can also exclude a queue from the monitoring for only a specific
client using this indicator: Create an assignment for this queue for all
clients (*) with activated monitoring, and an assignment for the
desired client with the Deactivate Monitoring indicator activated.

Sort the list of entries so that the subgroups of the same queue are processed first. You
should, for example, sort a queue assignment with the queue name CRM_SITES* before an
assignment with the queue name CRM*, since this means that errors in queues with the name
CRM_SITES* are separated out and not reported a second time for CRM*.
4. Save your individual entries.

5. Repeat the procedure above until you have assigned all of the desired queues to the queue
group.

The system displays messages from queues or clients that you have not assigned to a
particular queue group using queue assignments in the Transactional RFC and Queued RFC
Monitor in the Queues Not Otherwise Monitored subtree.

-----