Since inbound queues are client-dependent, there is a QIN Scheduler for each client. The QIN Scheduler is activated (if it is not already) as soon as a qRFC LUW is written to a registered queue.
The following graphic shows the processing of qRFC inbound queues using work process types DIALOG and BATCH.
As soon as the QIN Scheduler is activated, it proceeds as below to process as inbound queue:
Registered queues are read from the database tables and processed. Empty queues are not processed.
If a queue is to be activated in a batch work process, a background job for activating this queue is scheduled in a batch work process.
The QIN Scheduler can only activate as many registered queues simultaneously as there are resources available in the system (work processes and application servers). As many queues can be activated as the number of free work processes permits. These queues are started by the function call Call function ... starting new task ... destination in group GROUP_NAME performing ... on end of task.
The QIN Scheduler runs with the server group DEFAULT as a presetting. This means that all application servers of the local SAP systems are used to activate all the registered queues. You can create a server group according to your requirements.
The server group DEFAULT does not need to be created, and it is not visible in transaction RZ12.
The maximum time that the QIN Scheduler should take to process a queue is specified in parameter MAXTIME during queue registration.
If the Maxtime is exceeded while a LUW is being processed, processing is not terminated immediately, but only when the LUW has been processed.
If all DIALOG work processes are busy, the QIN Scheduler has no resources. It sets the status (displayed in transaction SMQR) to WAITING and waits for the next free work process.
After every queue has been activated once, the QIN Scheduler continues with step 1. At this point, the information is updated concerning registered and deregistered queues, or any changes to a new group of application servers.