ESA Genie

SAP XI: FAQ on inbound queues and the QIN Scheduler

Contributed by Administrator
Wednesday, 13 December 2006

- What are the tasks of a QIN Scheduler?

- How many QIN Schedulers are there in a system?
- How can inbound queues be registered/deregistered?
- When does a QIN Scheduler become active?
- How does one recognize the status of a QIN Scheduler?
- What is the meaning of the different statuses of a QIN Scheduler?
- How are registered inbound queues activated?
- Which client/user/language is used to execute a qRFC-LUW?
- How can you debug the execution of a registered queue?
- How can blocking queues be activated again?
- How should the resources for QIN Scheduler be configured?

1. What are the tasks of a QIN Scheduler?

Since inbound queues are "only" described for both applications on the same system and in remote systems (also
possible from external systems via the RFC library) and therefore every application would almost have to provide the
same work for the queue activation, qRFC also provides the QIN Scheduler that has the task of activating as many
inbound queues (not outbound queues) as possible using the current system resources. So that qRFC applications can
still process their queues themselves, the QIN Scheduler will only start queues that are already registered. Moreover, the
QIN Scheduler can also check the runtime of a queue at the end of a LUW execution in order to delay another execution
of the LUWs of this queue if necessary, so that other queues can also be edited.

2. How many QIN Schedulers are there in a system?

A QIN scheduler can be available for every client if you are working in this client with registered inbound queues.

3. How can inbound queues be registered/deregistered?

The registration or the deregistration is carried out using transaction SMQR or programs by calling the RFC enabled
QIWK_REGISTER or QIWK_UNREGISTER function modules. The registration of an inbound queue is required for an
automatic processing of this queue through the QIN Scheduler.The deregistration must be carried out before you can
debug the processing of a queue with ABAP utilities.
During registration, you can determine the following:
- Processing in DIALOG- or BATCH work process (parameter EXEMODE, see also question 7)
- Processing given certain LOGON data (parameters USERDEST, see also question 8)
- Wildcards may be used in queue names (for instance, BASIS_TEST_*) and we recommend this because it will improve
the performance of the QIN scheduler. A registration of the queue BASIS* and deregistration of the queues
BASIS_TEST* means that only queues are registered whose name starts with BASIS but not with BASIS_TEST.

4. When does a QIN Scheduler become active?

As soon as an LUW has been completely registered in an inbound queue, the QIN scheduler is activated by the qRFC
Manager in this client if it is not already active. You can also use SMQR to activate the QIN Scheduler in the current
client.This is necessary if, for example, a QIN scheduler was cancelled during its work (for example, by restarting the
system or the application server) and none of the registered queues is further described. The RSQIWKEX program,
which you can also schedule as a batch job, is available for activating the QIN Scheduler as of qRFC Version 6.10.030.
You should only schedule the program if the automatic processing of the inbound queue does not function correctly. Note
that you must only use the RSQIWKEX program of qRFC Version 6.10.030 or higher for this purpose.

5. How does one recognize the status of a QIN Scheduler?

The status of a QIN Scheduler in the current client is displayed when you start transaction SMQR.As of qRFC Version
6.10.030, you can use transaction SMQR to display the status of the QIN Scheduler in all clients.

6. What is the meaning of the different statuses of a QIN Scheduler?

The following statuses are possible:
- INACTIVE: The QIN Scheduler is not active.
- STARTING: The QIN Scheduler is currently in the START phase
- ACTIVE: The QIN Scheduler is active.
- WAITING: The QIN Scheduler waits for free DIALOG work process
- SYSFAIL:A serious error has occurred while the QIN scheduler is running.Double-clicking on the status will display the
corresponding error
text. Further analyses of the syslog (SM21) or Development Trace (dev_w*, dev_rfc* and dev_rd) may be required to
http://esagenie.com Powered by Joomla! Generated: 28 October, 2010, 05:24
 ESA Genie

identify the error.

- CPICFAIL:A communication error has occurred while the QIN scheduler is running.Double-clicking on the status will
display the corresponding error text. Further analyses of the syslog (SM21) or Development Trace (dev_rd, dev_rfc* and
dev_w*) may be required to identify the error.

7. How are registered inbound queues activated?

When you process in DIALOG work processes, the registered inbound queues are started with parallel RFCs.For this
you can use transaction RZ12 to define a group of application servers and their DIALOG work processes that is allowed
to use a QIN Scheduler.Using SMQR, you must assign the group name to the respective QIN Scheduler. If no group
name is defined, the QIN Scheduler will use all application servers and all possible DIALOG work processes (except for
those reserved in RZ12 as a default) for activating the queues. It is advisable to define a certain group of application
servers and DIALOG work processes if there are a lot of registered queues in order to avoid performance problems for
online users (see point 11).

8. Which client/user/language is used to execute a qRFC-LUW?

During queue registration, you can specify a "logical destination" (parameter USERDEST) that has the standard
destination "NONE" as a reference.Using transaction SM59, define the client, user and language for this "logical
destination".The processing of these queues is then carried out using this LOGON data. If USERDEST is not defined,
you can carry out queue processing under the user ID that currently describes a registered queue (it does not need to be
the same queue).The Logon data of a queue processing may be different in this case.

9. How can you debug the execution of a registered queue?

You cannot debug the execution of the first LUW in a registered queue without any problems, even if the QIN Scheduler
is not currently active, since it can be active at any time by describing a registered queue.Therefore you must first
deregister it (see point 3).You can then debug the queue from transaction SMQ2.

10. How can blocking queues be activated again?

If a serious error occurs during LUW execution, this queue receives the status SYSFAIL or ANORETRY (to be seen in
SMQ2).For this queue, no automatic processing occurs through the QIN Scheduler. After you eliminated the error cause
after consultation with the corresponding person in charge of the application, you can use SMQ2 to reset the status of
individual queues and as of qRFC Version 6.10.030 also
reset the status of several queues at the same time so that the QIN Scheduler also reactivates them automatically. A
queue can be also be blocked by the status "STOP".Note that qRFC itself NEVER blocks a queue.Thus, if you see the
status "STOP" in SMQ2, this status was then set by a qRFC application (for example, CRM) or by an authorized user in
SMQ2.The QIN Scheduler will not activate this queue until this queue is unblocked by the affected application or by
transaction SMQ2. If a queue is blocked with the "STOP" status for quite a long time and you are certain that the queue
was not blocked manually using SMQ2, contact the relevant application.

11. How should the resources for QIN Scheduler be configured?

As already mentioned in point 7, use transaction RZ12 to define a group of application servers for a QIN
Scheduler.Moreover, also use transaction RZ12 to increase the 'Minimum number of free work processes' for each of
these application servers from 1 (default) to 3 so that you can also use the SAPGUI to log on to this application server.
Depending on the number of registered queues, a lot of RFC links may be opened at the same time.Therefore, you must
adjust the default values of some profile parameters for the task handlers or gateway of the chosen application servers.
The following only describes some important parameters.In the case of more problems with a resources bottleneck, you
must read notes on the task handler or gateway (these include SAP OSS note 74141). Refer also to SAP OSS note
74141 for the meaning of the profile parameters described here.

Profile Parameter Default Recommended rdisp/tm_max_no 200500 rdisp/max_comm_entries 500 1,000 gw/max_conn
5001,000 gw/max_overflow_size 5,000,000 10,000,000

http://esagenie.com Powered by Joomla! Generated: 28 October, 2010, 05:24