You are on page 1of 19

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 R!s
". #R!
$. SR!
%. TR!
4. &R!
ARFC : #synchronous R!: 't is used to communicate (etween two systems (ut
the source system process may not get the ac)nowledge from the Target. Some
times the data may (e lost in transition. The source system process does not
(other whether the information is recei*ed (y the target system. 't is similar to a
post card. 't is not relia(le and consistent.
SRFC: Synchronous R!: 't is used to communicate with recei*ing system and
wait for ac)nowledgement. 'f the ac)nowledgement is delayed it will go into R!+
Sleep+ !,'! Mode.
't is relia(le (ut the resource gets (loc)ed at the target system. 'f the
target system is not a*aila(le (-.ample /T! ,rocess waiting too long in the
acti*e state)
0 #ll /1 Systems uses SR!.
SM52 0 To find all the '34!S
TRFC: Transactional R! : 't is an ad*anced *ersion of #R!. 't is used to
communicate with recei*ing system and if the system is not a*aila(le it will
generate a Transaction '3 in SM52. and a (ac)ground 5o( RS#R!S- runs for
e*ery 67 Seconds. 't is relia(le8 gets the ac)nowledgement and data
transmission is consistent.
Example: Central User Administration
,arent client creates users and send it to child clients. 'f child client is not
a*aila(le it creates a transaction '3 in SM52 and ensures deli*ery when the child
client is a*aila(le.
QRFC: &ueued R!: 't is an ad*anced *ersion of TR! to ensure the 5o(s are
processed in a 9ueue. To e.ecute &R! we ha*e a 5o( called &:'; Scheduler
0 1e ha*e SM&" (4ut(ound)8 SM&$ 8 SM&R 0 &uin Schedulers
&R! generates the process of <:1=s in the se9uence. 1hen the se9uence is
mandatory in the data transmission &R! is recommended. S#, 'mplemented all
the a(o*e ser*ices to ensure the 9uality in the data transmission. S#, named it
as &oS (&uality of Ser*ice). S#, consider SR!8 TR! and &R!.
". SR! 000 /- (/est of -fforts) 0 1ith (est of efforts it will deli*er to Target
system. 1hen you find /- it is SR!. Ma5orly we are going to use in /' and >'
Systems.
$. TR! 00 -4 (-.actly once) 0 't chec)s e.actly once.
%. &R! 0 -4'4 0 -.actly once in 4rder.
ALE: (#pplication <in) -na(ling): 't is used to transfer two loosely coupled
systems (S#, to S#, systems) -g. /1 to !RM? -R, to -R, etc. S#<-+ /364+ /354
it is used to define the logical systems and sending+ recei*ing systems. -ach
system that participates in the data transmission is identified (y it=s logical
system name i.e. S'3!<;T!<'-;T;4.
Transfer 00000000000 -.change 00000000000000 Transmission @A #re Same
#nd is recommended to define the R!=s using logical system name to uni9uely
identify in the landscape.
". 3efine the distri(ution model ('n Sale T!ode) in /364 (!hange) 0 !reate Model
Biew 0 Ci*e the tech name 0 !ontinue.
$. API's #pplication ,rogramming 'nterface: 't is an interface in /364 select the
model clic) on #33 #,' defined (ased on your application either to send or
recei*e data (ased on the (usiness it is called as /#,'. (/usiness #,'=s). The /#,'
will (e assigned (etween the sending and recei*ing system
/#,' contains one or more methods.
Methods are similar to function modules to perform certain tas)s.
EDI: -lectronic 3ata 'nterchange: 't is used to transfer the data (etween S#, to
;on0S#, systems and *ice *ersa.
'n order to monitor the -3' used T!43- E!"
ID#C: 'ntermediate 3ocument: 't is in the understanda(le format of (oth sender
and the recei*er. ;on S#, systems could communicate directly with S#,
systems. They re9uired adapters (ile #dapter8 D$-- #dapter8 '34! #dapter8
ETT, #dapter etc)
1hen the supply chain mar)et is growing the necessity of =-0!ommerce=
-lectronic (usiness -/=s) is gaining importance and the *endors8 suppliers wants
the documents flow electronically with out any paper 'n order to monitor multiple
senders and recipients it will (e difficult to use S#, Standard transactions8 S#,
standard systems and mechanisms.
-.tensions:
!#R 0 !ompressed #rchi*e 000 Mostly for ,atches
S#R 0 S#, #rchi*e 00 Mostly for S#, Fernel.
D#R 0 D#B# #rchi*es
1#R 0 1e( #rchi*es
S!# 0 S#, !omponent #rchi*es
S3# 0 3eploya(le archi*es software S#,
-,# 0 -nterprise ,ortal #rchi*es
.G', 0 Gip iles
-#R 0 -nterprise #rchi*es
T,G 0 >'+ ,' !ontent
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 usrsaptrans data and cofile directory. Copy the transport requests to your target
system!"ata 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 &est method for the client copy is Client Export and import process compare to RFC.
RFC process wor's fine for small amount of data copies and depends on the profile you are
going to choose for the copies. For large d&(s &etter go for export import and file split options
if you are n unix )*.+*. ,nix has file limitations for + g&.
A large client copy ith export an! import post processing too" # !ays $or the export%
&# !ays $or
the import on 'nix &(.)( $or *8 gb o$ !ata.
+o to increase maxim'm n'mber o$ SA, sessions per
'ser?
-ome times user may get an informative message ./aximum num&er of sessions reached..
0ou should alter the parameter rdisp/max_alt_modes for this purpose. Ta'e transaction R1)*
!profile edit#. Ta'e instance profile. Then ta'e the option Extended maintenance. 2ts default
value is 3. Restart the instance.
System -og Errors
./0R1A/0ERR2R at 1able 1S,(A% Error *# rspog!io )3 The cause of this error is that
the system tries within the spool wor' process to carry out archiving with a formatting that
does not exist.
4,.A1E S1A14S
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).
! Response to $UPDATE STATUS$
Transactional RFC and Queued RFC 5onitor
Use
Transactional R! and 9ueued R! are *ariants of the Remote unction !all
that ma)e the data transfer (etween different systems more relia(le and more
secure.
Transa%tional RFC guarantees the following attri(utes:
The call is executed exactly once in the target system.
Calls that &elong to a -ogical 4nit o$ Wor" 6-4W7 are either completely executed$ or
not executed at all.
'f the target system is not a*aila(le when the call is made8 the call remains in the
local wait 9ueue. The calling dialog program can8 howe*er8 proceed. 'f the target
system does not (ecome acti*e within a certain amount of time8 the call is
scheduled as a (ac)ground 5o(.
#lthough tR! significantly impro*es the relia(ility of the data transfer8 it also
has disad*antages. This method does not ensure that the se9uence of <:1s
specified in the application is o(ser*ed. Eowe*er8 there is a guarantee that all
<:1s will (e transferred at some point.
Q&e&ed RFC '(RFC )it* #&t+o&nd Q&e&e,
To offset this disad*antage8 a serialiHation of tR! is performed using wait
9ueues. 't is called 9ueued R! (9R!). 1ith this serialiHation8 an out(ound
9ueue for tR! was created8 which is therefore referred to as 9R! with
out(ound 9ueue. The main features of 9R! are as follows:
4 5,W is only transferred if it has no predecessor !in reference to the sequence defined
in the applications# in the participating queues. 4fter a qRFC transaction is executed$ the
system attempts to start the next qRFC transaction in the sequence from the queue.
4 queue name and a queue counter are required fore each qRFC transaction for queue
administration. Each tRFC call that is to &e processed chronologically is assigned a queue
name determined &y the application.
(RFC )it* In+o&nd Q&e&e
SerialiHation of the incoming R! calls from other systems is also possi(le. This
ensures that incoming calls are always e.ecuted in the order of their arri*al. This
serialiHation of incoming calls also limits the ma.imum load on the target ser*er
caused (y R!.
-onitorin. )it* t*e Alert -onitor
:sing the Transactional R! and &ueued R! su(tree8 you can 9uic)ly detect
errors and (loc)ed 9ueues (in the conte.t of transactional R! and 9ueued
R!s). The corresponding special monitors with which you can 9uic)ly eliminate
the cause of the error are set as analysis methods. The su(tree is in the
!ommunications monitor of the S#, !!MS Monitor Templates monitor set.
Prere(&isites
Iou ha*e performed the setting up of the monitoring of 9R! calls.
Feat&res
T*e monitor %ontains t*e /ollo)in. monitorin. tree elements '-TEs,:
/TE 6ame
!/TE Class#
/eaning
4RFC--T4TE: 7ut&ound tRFC Calls
!CC/-8tRFC87ut&ound8T&l#
/onitoring o&9ect with information a&out the
5,Ws and tRFC calls that are waiting to &e
executed on their target system or on an external
component.
Calls w Communication Errors :
C;2CERR
!CC/-8tRFC8qRFC8C;2C8Errors#
;um(er of tR! calls that were not
e.ecuted due to pro(lems creating the
connection or the communication with the
target system or an e.ternal component?
depending on the settings (transaction
SM59)8 the attempt may (e repeated a
num(er of times
Calls w Execution Errors : -0-F425
!CC/-8tRFC8qRFC8-0-F4258Errors#
6um&er of tRFC calls that could not &e executed
due to a pro&lem with the execution in the target
system or an external component
Calls wo -erver Resources : -0-574"
!CC/-8tRFC8qRFC8-0-574"8-tatus#
6um&er of tRFC and qRFC calls with out&ound
queue with status -0-574"< these are calls that
could not &e executed due to a lac' of resources in
the target system
4RFC--T4TE: 2n&ound tRFCqRFC
Calls
!CC/-8tRFC8qRFC82n&ound8T2"s#
/onitoring o&9ect with information a&out tRFC
and qRFC calls that are waiting to &e executed in
this system< after they have &een executed$ they
are deleted from ta&le 4RFCR-T4TE
Total Calls
!CC/-8qRFC82n&ound8Total#
6um&er of tRFC and qRFC calls that are waiting
to &e executed in this system and are therefore
stored in ta&le 4RFCR-T4TE
7ut&ound =ueues
!CC/-8qRFC87ut&ound8
=ueues8-ummary#
-u&trees that contain the log messages of the
out&ound qRFC calls to external systems< these
messages are sorted &y the different queue groups:
there is a monitoring o&9ect for each group with
the name >?roup 6ame@ 7ut&ound =ueues
2n&ound =ueues
!CC/-8qRFC82n&ound8
=ueues8-ummary#
-u&trees that contain the log messages of the
in&ound qRFC calls from external systems< these
messages are sorted &y the different queue groups:
there is a monitoring o&9ect for each group with
the name >?roup 6ame@ 2n&ound =ueues
Aloc'ed =ueues: Client >6um&er@
!>techn. name queue
group@8/-C8>no.@#
5og messages for the queues of an application$
sorted &y the different clients< the log messages
contain the error messages that are returned during
the qRFC call
The following statuses are immediately identified
as B&loc'ingC:
C;2CERR7R !for 2n&ound7ut&ound$ error
text availa&le#
-0-F425 !for 2n&ound7ut&ound$ error text
availa&le#
-T7; !for 2n&ound7ut&ound$ no error text#
467RETR0 !for 2n&ound7ut&ound$ error
text availa&le#
W42T-T7; !for 2n&ound7ut&ound$ error
text availa&le#
4RETR0 !for 2n&ound7ut&ound$ error text
availa&le#
RETR0 !always for in&ound$ for out&ound as
of qRFC version 3.)*.*D*$ error text availa&le#
-0-574" !for out&ound$ up to qRFC
version 3.)*.*EE$ no error text#
The following statuses are identified as B&loc'ingC
if they remain unchanged for longer than E*
minutes:
RE4"0 !for in&oundout&ound$ no error text#
R,6626? !for in&oundout&ound$ no error
text#
W42T,;"4 !for out&ound$ no error text#
EFEC,TE" !for in&oundout&ound$ no error
text#
For information a&out the possi&le statuses$ see
the 4ppendix.
=ueues not processed: 4ge 4lerts
!>techn. name queue group@84ge85og#
5og messages for the queues of an application< the
queues have not &een processed for longer than
the time defined in the associated threshold value
!&y default$ seven days#
=26 -chedulers: Errors
!CC/-8qRFC8=268-cheduler87&9ect#
Monitoring o(5ect that contains information
a(out the status of the &'; scheduler? the
&'; scheduler controls the processing of
incoming tR! and 9R! calls within a
client (see S#, ;ote %9677J)
=7,T -chedulers: Errors
!CC/-8qRFC8=7,T8-cheduler87&9ect#
/onitoring o&9ect that contains information a&out
the status of the =7,T scheduler< the =7,T
scheduler limits the maximum num&er of parallel
tRFC and qRFC connections to an RFC
destination !see -4; 6ote D**EE*#
=26 -cheduler Error: 4ll Clients
!CC/-8qRFC8=268-ched85og#
5og messages with error messages for the =26
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
=26 ,nregistered =ueues: 4ll Clients:
!CC/-8qRFC8=268,nreg85og#
5og messages with error messages for the =26
schedulers of all clients< an alert here indicates
that the scheduler found an RFC call with a non%
registered queue
=7,T -cheduler Error: 4ll Clients
!CC/-8qRFC8=7,T8-ched85og#
5og messages from communication and system
errors for the =7,T schedulers of all clients
A%ti0ities
To start the monitor8 follow the procedure (elow:
). -tart the 4lert /onitor using transaction R1+* or choose CC/- Control/onitoring
4lert /onitor.
+. 7n the CC/- /onitor -ets screen$ expand the -4; CC/- /onitor Templates set.
E. -tart the Communications monitor from the list &y dou&le%clic'ing it.
D. Expand the Transactional RFC and =ueued RFC su&tree.
Pro%ed&re i/ an Alert Is Tri..ered
/TE ;rocedure
4RFC--T4TE:
7ut&ound tRFC Calls
The transaction Transactional RFC !-/GH# is assigned as
analysis method to all /TEs of this monitoring o&9ect. This tool
lists only those transactional RFCs that could not &e carried out
successfully or that had to &e planned as &atch 9o&s.
Calls
wCommunication
Errors % C;2CERR
Errors often occur in this attri&ute when an instance is shut down
for maintenance. 7nce the instance is availa&le again$ the calls
are automatically processed.
2f this is not the case$ you should chec' the RFC connection
using the "isplay and /aintain RFC "estinations transaction
!-/GI#.
Calls w Execution
Errors % -0-F425
Errors in the execution of RFC calls are often caused &y errors in
the programs. These errors must therefore usually &e individually
processed.
Calls wo -erver
Resources % -0-574"
R! calls with the status SIS<4#3 are automatically
scheduled in a 5o(. or more information a(out SIS<4#3
status8 see S#, ;ote %"9267.
4RFC--T4TE:
2n&ound tRFCqRFC
Calls
For information a&out possi&le statuses and pro&lems for ta&le
4RFCR-T4TE$ see -4; 6otes EJHI*E and E33H3I.
7ut&ound =ueues
2n&ound =ueues
-tart the assigned analysis method. For the /TEs of this
monitoring o&9ect$ this is transaction -/=) or -/=+ !qRFC
/onitor#.
=26 -chedulers: Errors
=7,T -chedulers:
Errors
-tart the assigned analysis method. For the /TEs of this
monitoring o&9ect$ this is transaction -/=R or -/=-
!=26=7,T -cheduler#.
See also:
5onitoring 8R9C an! tR9C Calls
P&rpose
Transactional R! and 9ueued R! are *ariants of the Remote unction !all
that ma)e the data transfer (etween different systems more relia(le and more
secure. Iou can monitor these calls using the #lert Monitor. To do this8 in the
!ommunications monitor of the S#, !!MS Monitor Templates monitor set8 there
is a Transactional R! and &ueued R! su(tree. These functions automatically
(ecome acti*e at the start of the system? you can8 howe*er8 maintain and
e.tend the functions.
-onitored #+1e%ts in t*e Transaction RFC and Queued RFC S&+tree
The num&er of out&ound transactional RFC calls that could not &e 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#. 4lerts are generated if the num&er of calls with errors exceeds the
threshold value.
The num&er of in&ound calls from transactional and queued RFCs that are waiting for
processing is reported. 4n alert is generated if the num&er of waiting calls exceeds the
threshold value.
Error messages for in&ound and out&ound qRFC queues are reported. 4n error message
means that the affected queue cannot &e processed and that all other calls for the queue must
wait until the error is corrected. The following applies here:
/y default8 a red alert is generated for e*ery 9ueue error. 4nly one alert
is generated for an error8 irrespecti*e 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 pro(lem. 'f you delete or complete an
alert8 a new alert can (e generated if a 9ueue error occurs.
The errors are grouped (y client? all clients are monitored for 9ueue
errors.
Transfer and execution errors for in&ound and out&ound RFC schedulers are reported.
The monitoring tree for in&ound schedulers also reports a&out queues that are not registered
for processing. Calls to these in&ound queues are not executed until the queues are registered.
C&stomi2in.
Iou can ma)e the following settings in !ustomiHing (see Setting :p Monitoring of
tR! and 9R! !alls):
0ou can create separate su&trees for the messages of individual queues that you specify
&y name.
0ou can perform extended monitoring for every su&tree &y specifying exit function
modules.
For every su&tree$ you can change the color of the alert from red to a lower level$ or set
no alert to &e generated.
/y default8 the tR!+9R! monitor is deli*ered (y S#, without !ustomiHing. This
means that all 9ueue errors are monitored in a single su(tree. ;o e.it function
modules are e.ecuted to e.tend the monitoring functions or to change the alert
*alues.
Some S#, applications pro*ide !ustomiHing for this monitor or ma)e
recommendations for !ustomiHing. or recommendations a(out !ustomiHing
9R! monitoring8 see the installation guidelines for the applications.
Pro%ess Flo)
To monitor tR! and 9R! calls8 use the Transactional R! and &ueued R!
monitor.
See also:
S#, ;ote 44"$69
Set 4p 5onitoring o$ 8R9C Calls
P&rpose
&ueued R! is a *ariant of the Remote unction !all that ma)es the data
transfer (etween different systems more relia(le and more secure? among other
things8 9ueued R! guarantees chronological processing of R! calls.
or monitoring tR! and 9R! calls8 there is the Transactional R! and &ueued
R! su(tree in the #lert Monitor. or information a(out the structure of the
su(tree8 see Transactional R! and &ueued R! Monitor. This section descri(es
how to set up the monitoring.
or optimal usage of 9R!8 there are different 9ueues for different applications8
so that a (loc)ed 9ueue does not affect the other application processes. These
9ueues are differentiated using their names? in this way8 you can assign each
9ueue to the associated application.
To pro*ide a (etter o*er*iew8 each of these 9ueues that is (eing monitored using
the monitoring architecture should (e assigned a separate su(tree. 1ithout
!ustomiHing8 all 9ueue errors are reported in a single su(tree. Iou can create the
desired monitoring su(trees in !ustomiHing. Iou can ma)e the following
changes:
0ou can create separate su&trees for specific queues. 2n this way$ you can display the
errors for queues whose names &egin with CR/8-2TE-K in a separate tree. Error messages
for these queues are then no longer displayed in the default su&tree =ueues 6ot 7therwise
/onitored.
0ou can activate additional monitoring functions separately for each su&tree using exit
function modules. Function modules for chec'ing the age of the queue !the age of the oldest
call that is waiting for processing# and the num&er of calls waiting in a queue are already
availa&le to you.
0ou can change the color of the alerts that are reported to the monitoring architecture
separately for each su&tree. This can &e done &y assigning a queue status to an alert color or
flexi&ly using function modules.
"efault CustomiLing settings are delivered for applications and components that use the
qRFC monitoring data. This means that the associated su&trees should already &e active after
delivery. 0ou only need to perform more far%reaching CustomiLing if the default
CustomiLing does not meet your particular needs.
Pro%ess Flo)
...
). Choose CC/- Configuration 4lert /onitor$ or call transaction R1+).
+. The /onitoring: ;roperties and /ethods screen appears. Choose Technical 2nfrastructure
Configure qRFC monitoring.
E. Confirm the warning that the ta&le is cross%client.
D. The system displays the Change -ettings 7wner: 7verview screen. Changes to CustomiLing
always &elong to an owner. 7riginally$ there is only the owner -4; here. -ince you cannot
ma'e any changes to owners that &egin with -4;$ you must first create an owner for
CustomiLing.
G. 6ow select the settings owner for which you want to perform CustomiLing$ and choose the
=ueue ?roups level at the left edge in the "ialog -tructure tree. The system displays the
Change =ueue ?roups: 7verview screen.
3. 7n this screen$ you specify which su&trees are to &e created for in&ound or out&ound queues.
These are the queue groups. Each queue group creates a su&tree in the qRFC monitor !see
Creating =ueue ?roups#.
J. 0ou can assign one or more queues to each queue group. -elect the desired queue group and
dou&le%clic' the =ueue 4ssignments level on the left side in the "ialog -tructure tree. The
system displays the Change =ueue 4ssignments screen !see Creating =ueue 4ssignments#.
H. 0ou can change the color of the alerts that are reported to the monitoring architecture
separately for each su&tree or queue. -elect the desired queue group or queue assignment$ and
dou&le clic' the 4lert Malue -hifts level on the left side in the "ialog -tructure tree. The
system displays the 4lert Malue -hifts screen !see Creating 4lert Malue -hifts#.
I. -ave your entries.
Res&lt
Iour !ustomiHing changes (ecome acti*e the ne.t time the data collection
method !!MSKtR!K!ollector runs. /y default8 this method runs e*ery "5
minutes.
Comments
0ou can only add su&trees for new queue groups using CustomiLing. 2f you delete queue
groups$ the associated su&trees in the monitoring architecture are simply no longer provided
with data. The su&trees in the 4lert /onitor are not automatically deleted. "elete the
corresponding su&tree in the 4lert /onitor tree manually !see "eleting and Recreating 6odes
in the 4lert /onitoring Tree#.
2f you are ma'ing extensive changes$ it can &e easier to delete the complete Transactional
RFC and =ueued RFC monitor and to start again. 0ou can force a re&uild &y resetting the
monitoring segment of the central server of your system !the server with the enqueue service#
to W4R/,; status.
0ou can restore the default settings &y setting the Active field for the owner -4; to x.
See also:
S#, ;ote 44"$69

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 oner, meaning that you can create different monitoring strategies using different
settings oners.
Prerequisites
!his procedure is part of the process setting up monitoring of qRFC calls. It is therefore a prerequisite
that you ha"e already performed the part of the process that is to be performed before this procedure.
Procedure
!he system is displaying the Change Settings Owner: Overview screen. !he system displays the
entries for the oners of the Customizing settings. If the #$% Customizing as deli"ered to you, you
see only the oner entry SAP.
&o create your on oner for Customizing. $n oner combines "arious entries for Customizing the
qRFC monitoring. !he oner can be, for e'ample, the name of your company. (ou can create a ne
settings oner in to ays)
Copying an Existing Owner Entry
*. Copy an e'isting oner entry (such as the entry
SAP) by selecting the desired entry and choosing Edit Copy as.
$. !he system displays the Settings Owner table ith the copy source as the only entry. Enter
the desired name of the ne oner by o"erriting the e'isting name. $ccept your input by
choosing E&!ER.
%. If the copy source contains queue groups, queue assignments, or alert "alue shifts, you can
decided hether you ant to copy these for the settings of the ne oner. $s you ant to
copy an oner entry, this is usually the case+ in this case, choose Copy All.
,. Confirm the number of dependent copied entries and sa"e your entries.
Creating a New Empty Owner Entry
". Choose Edit New Entries and enter the desired name of the ne oner.
-. #a"e your entries.
!he Active column in the Settings Owner table specifies the oner hose
Customizing settings are currently acti"e. Enter X in this column for the
desired user. Ensure that only one entry is "alid.
Resu!t
(ou ha"e specified an oner for additional Customizing settings and can ma.e the other settings.
"ee a!so:
8R9C 5onitoring3 Creating :'e'e ;ro'ps
Use
'n !ustomiHing of the 9R! monitoring using the monitoring architecture8 you
can define su(trees (9ueue groups) that are to display messages for particular
9R! 9ueues. # 9ueue group can include multiple in(ound or out(ound 9ueues.
'n this way8 9ueue groups pro*ide you with an o*er*iew8 as the messages for
different 9ueues are reported in a single su(tree (y default.
Prere(&isites
This procedure is part of the process setting up monitoring of 9R! calls. 't is
therefore a prere9uisite that you ha*e already performed the part of the process
that is to (e performed (efore this procedure.
Pro%ed&re
The system is displaying the !hange &ueue Croups: 4*er*iew screen. The
system displays the entries for the 9ueue groups that already e.ist for the
selected owner of !ustomiHing settings.
...
). 2f you want to create a new queue group$ choose 6ew Entries.
+. 2f you want to change an existing queue group$ choose the desired queue group &y dou&le
clic'ing it.
E. 2n &oth cases$ the system displays the Change =ueue ?roups: "etail screen. 0ou can enter
the following data here. There is also help for each of the entries availa&le &y choosing 9&.
Entry /eaning
7wner 0our owner name
=ueue ?roup 6ame 6ame of the monitoring su&tree in the 4lert /onitor< choose a
descriptive name$ such as CRM* Outbound Queues or APO
Outbound Queues
/TE Class Technical name for the queue group and therefore the name of the
/TE class that is assigned to the queue group< use only letters$
num&ers$ and underscores here !such as CRM_Outbound_Queues#
=ueue Type !2$7# 2ndicator for out&ound queue !O# or in&ound queue !I#
F) /essage 2" 2dentification of a message from ta&le T)** for the documentation of
the queue group
F) /essage
6um&er
4nalysis /ethod 4lternative analysis method< &y default$ the out&ound queues are
assigned transaction -/=) and the in&ound queues are assigned
transaction -/=+ as an analysis method
4uto%React.
/ethod
4uto%reaction method that is performed in the case of an alert in this
queue group< for example$ the method CC/-8Email87n4lert that
automatically informs you a&out an alert &y e%mail or pager !see
"efining 4utomatic 4lert 6otification#
Exit F/ 6ame of a function module that is to perform the additional
monitoring for this queue group
.e$inition o$ the inter$ace3
-ee example function module
-45N8=RFC8C455A4CN8-4/;5E
Rea!y<to<4se Examples3
-45N8CR/8=,E,E84?E !4ge of the oldest entry in days#
-45N8CR/8=RFC8=,E,E8E6TR2E- !6um&er of entries in the
queue#
Exit ;arameters ;ossi&le static parameters in addition to the parameters transferred in
the interface< dependent on the function module
-45N8CR/8=,E,E84?E:
Maximum_Queue_Age displays the age of the queue in days as of
which an alert is generated !&y default seven days#
;arameter Malue
Rec. Exits per Clnt 2f 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
-45N8CR/8=RFC8=,E,E8E6TR2E-.
The entries 4wner8 &ueue Croup ;ame8 MT- !lass8 and &ueue Type ('84) are
re9uired8 all others are optional.
D. -ave your individual entries.
0ou should only use the named exit function modules if it is a&solutely necessary to do so. 2f
you use qRFC extensively$ the associated ta&les &ecome very large$ meaning that the
modules could create a large wor'load.
Res&lt
Iou ha*e created one or more 9ueue groups meaning that messages for
different 9R! 9ueues are to (e displayed in different su(trees. or an e.ample
of the output of the 9ueue groups in the #lert Monitor8 see Transactional R! and
&ueued R! Monitor.

8R9C 5onitoring3 Creating :'e'e Assignments
Use
'n !ustomiHing of the 9R! monitoring using the monitoring architecture8 you
can define su(trees (9ueue groups) that are to display messages for particular
9R! 9ueues. # 9ueue group can include multiple in(ound or out(ound 9ueues.
Iou define which 9ueues (elong to which 9ueue groups using 9ueue
assignments.
Prere(&isites
This procedure is part of the process setting up monitoring of 9R! calls. 't is
therefore a prere9uisite that you ha*e already performed the part of the process
that is to (e performed (efore this procedure.
Pro%ed&re
The system is displaying the !hange &ueue #ssignments: 4*er*iew screen. The
screen displays the entries for the 9ueues that are already assigned to the
selected 9ueue group.
...
). 2f you want to create a new queue assignment$ choose 6ew Entries.
+. 2f you want to change an existing queue assignment$ choose the desired assignment &y
dou&le clic'ing it.
E. 2n &oth cases$ the system displays the Change =ueue 4ssignments: "etail screen. For new
assignments$ you can ma'e all entries$ while for existing assignments$ you can only change
the "eactivate /onitoringindicator. F) help is availa&le for every entry:
Entry "escription
7wner 0our owner name and the name of the monitoring su&tree in the
4lert /onitor< enter owners and queue groups that already exist here.
0ou can use input help here.
=ueue ?roup 6ame
=ueue 6ame 6ame 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 su&tree for the
queue group. Every use of exit function modules for the queue group
includes the queues.
Client Client num&er !or the wildcard character *$ to select all clients in the
system#< the queue assignment applies only to the specified clients.
=ueue
4ssignments:
"eactivate
/onitoring
2ndicator with which you can deactivate the monitoring for specific
queues and clients$ &y entering X in this field.
0ou 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 !K# with activated monitoring$ and an assignment for the
desired client with the "eactivate /onitoring indicator activated.
-ort the list of entries so that the su&groups of the same queue are processed first. 0ou
should$ for example$ sort a queue assignment with the queue name CRM_SITES* &efore 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*.
D. -ave your individual entries.
G. Repeat the procedure a&ove 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 =ueued RFC
/onitor in the =ueues 6ot 7therwise /onitored su&tree.
00000

You might also like