Daemons
Daemons are server-based processes that let you run background tasks. The user has no direct input with the daemon processes.
Daemon processes apply only to component-based functions. They can be run on the same application server as QAD Financials, or you can specify a different appserver for each daemon. You should define the appservers to be used for daemon processing during system implementation.
Important: Some daemon processes must be running to ensure the integrity of your application. You should ensure that these processes are configured to start when the database is started.
Overview of Daemon Processing
In general, tasks for the daemon are stored in a queue in a dedicated database table. The daemon regularly checks its queue for tasks and then processes them. If no more tasks remain in the queue, the daemon enters a period of inactivity known as sleep mode. After a predefined period, the daemon exits sleep mode and check its queue for new requests.
The behavior of each daemon and its request queue are controlled and monitored using specific maintenance programs. You can start multiple instances of a daemon if the workload requires this.
The system has the following daemons:
• Balance daemon
• Batch daemon
• Budget daemon
• Cube daemon
• Cross-Company daemon
• Event daemon
• History daemon
• Replication daemon
• Report daemon
• Scan daemon
• Time Out daemon
• XML daemon
All daemons, except the XML daemon and Report daemon, share the same control activities. The XML daemon differs from the others in that it creates its own requests by importing files from a specific directory on the file system. Otherwise, the XML daemon behaves like the other daemons.
The Event daemon publishes Financials events as XML messages that can be exported to other application instances or external Financial applications using QXtend.
Requests to the Report daemon are handled by the .NET Report Service, which is a separate server installation. You also use the Report Service to stop and start the Report daemon, and can monitor Service activity using the daemon Monitor function.
The Replication daemon is only used during the creation of new domains to propagate shared set data.
Daemon Architecture
Daemon User
Each daemon must log in to the system to perform its updates, and you specify the user login ID and password to associate with each daemon when you configure it. The recommended practice is to use the same user ID for all of the daemons, to make maintenance easier.
The user you specify must have access to all activities in Role Permissions Maintain and all domains and entities.
Important: Whenever you create a new domain or entity, you should assign access to this system user. When you create a new domain and confirm it, the replication will fail if the Replication daemon user does not have access to the new domain.
