Académique Documents
Professionnel Documents
Culture Documents
RFC: Remote function call (SM59) it is used to call the other system using the
gateway to fetch or send the information.
1. ARFC
2. SRFC
3. TRFC
4. QRFC
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)
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
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.
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.
EDI: Electronic Data Interchange: It is used to transfer the data between SAP to
Non-SAP systems and vice versa.
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
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.
Solution:
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).
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.
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:
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.
• 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.
Process Flow
To monitor tRFC and qRFC calls, use the Transactional RFC and Queued RFC
monitor.
See also:
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
...
2. The Monitoring: Properties and Methods screen appears. Choose Technical Infrastructure →
Configure qRFC monitoring.
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).
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
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:
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.
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:
Prerequisites
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.
...
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
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
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.
Prerequisites
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.
...
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.
-----