Skip to Content

After reading through this short blog you should know all that you need to know on how to configure and monitor ‘daemons’ in SAP Sourcing. If you have any further questions, just write a comment and I would be glad to answer them!

Before diving deep, let us be clear what ‘daemons’ mean in this context. They are nothing but “background processes/threads” that takes care of various complex, time-consuming, repeated & critical tasks (e.g. Sending emails, Cache replication, Rfx Response Preparation, etc) in SAP Sourcing.

In a typical installation of SAP Sourcing, you may have two or more application servers clustered to support varying loads. Some system level daemons are expected to run in ALL of these application servers (e.g. System daemons like Cache Synchronization daemon).  These daemons are called Multicast Daemons. There is another category of daemons that are expected to run in “exactly one” application server in the cluster. These daemons are called Point-to-Point Daemons (P2P). P2P daemons are generally responsible for processing a complex process just once (e.g. Rfx Response Prepare Daemon).

SAP Sourcing provides flexibility and fine grained control to distribute these P2P daemons among different application servers in the cluster. OK, but why should you care about distributing the daemons? You don’t have to if you don’t need to. Let us assume for a second that you have a cluster of two or more SAP Sourcing servers and all your P2P daemons are running on the same server. What if you frequently have large sourcing events? Can the fact that all of the daemons are running on the same server impact the application performance for your users? The answer to this is yes. The users who have been load balanced to the application server where all the daemons are running are going to experience a non-negligible performance decrease compared to the other users who have been assigned to a different application server. The extent of this is largely dependent on the size and number of events that are running. In such a situation, it is beneficial to either distribute the daemon load across multiple application servers in the cluster or to explicitly assign the daemons to a dedicated daemon server that users will not be load balanced to.

The first part of the blog mainly focuses on how these daemons can be distributed.

Distributing P2P Daemons

SAP Sourcing has over 100 Daemons. These are logically grouped into approximately 20 different Daemon Categories. The daemon categories are just there to allow for easy and efficient daemon administration. To give administrators added control over the resource consumption of each of their servers, SAP Sourcing provides a way to distribute daemons across application servers. The way daemons are distributed is by ‘negation logic’.  Each application server in the cluster has a possibility to switch off or disable a particular daemon category. What this means is that for a given application server where a daemon category has been disabled,  that application server will not at anytime run the daemons within that category. If you want to assign a daemon to application server 3, in application server 1 & 2, the daemons should be disabled. If you don’t want a particular daemon to run in an application server, just disable it in that particular application server. Here is the 3 step instruction on how to do this:

  1. Login in as ‘enterprise’ user. Navigate to ‘System Administration’ tab, under ‘System Management‘ click on ‘Registered Servers’

Figure 1

  2. Now you can see all the registered servers. Choose the server where you want to disable daemons by clicking on the service link. This will take you to the Service Registration page of that cluster member

Figure 2

  3. Now ‘Edit’ and navigate to the ‘Daemons’ tab in the Service Registration page. Uncheck “Auto-Enable All Daemons” (if enabled) to see the master list of daemons. By default all daemons are enabled to run in all the application servers. As you can see in figure 3, some of the system level daemons (e.g. Cache Management) cannot be disabled. Depending upon which daemon category you want to distribute (‘User Management’ in this case) to other application servers, disable them in this application server. This means all daemons belonging to the User Management category are not allowed to run on this application server.  Make sure at least one application server has this daemon category enabled to make sure this daemon is runnable in the cluster.

Figure 3

Note on Auto Recovery of Daemons: Daemons are fault tolerant and they recover on any failure (including hardware). If a daemon fails due to a hardware failure, it will be restarted in another system in the cluster. If we disable the daemon to run in all the servers except for one with the hardware failure, then at the time of failure, the daemon is completely stopped, which would lead to reliability issues. For this reason, it is recommended that administrators configure their daemons so that they are enabled to run in more than one application server.

Monitoring Daemons

When you suspect there are issues with processing of the daemons or if you are just curious to see which servers they are running on, you can navigate to ‘Setup > Background Task Status’ and view the various reports associated with the background task status. The key reports are ‘Pending Damon Alerts’, ‘Pending Daemon Events’, and ‘Daemon Registration’. In the first two reports, you can see all the events and alerts that are yet to be processed. If you are sure a particular event/alert is causing problem and is no longer required to be processed, you can delete alerts/events from these reports. Caution should be taken here since once an event or alert is deleted, the task that is associated with it will no longer be completed. For tasks such as an import job that can be manually retried later, this is fine. But for tasks such as the closing of an auction, incorrectly deleting these could leave you in a bad state. In the third report (Daemon Registration), you can see a list of all of the daemons and where they are running. Deleting a daemon from this page will cause it to be restarted once it finishes its current task. If the daemon is enabled on multiple application servers, then it will be restarted on one of the other servers. Otherwise, it will restart on the same server.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Baski Janarthanam Post author
      Hi Jeff,
      Thanks for the comments. yep, this infromation is valid for 7.0 as well and infact screenshots were taken from that. This support is available even in earlier releses as well including 5.X.
      – Baski
  1. Former Member
    Hello Baski,

    This is a very informative blog.

    I reached here since we got stuck in our Quality Box due to a Workflow Issue (Sourcing 7.0).

    Our system is sending all emails except the workflow emails. We checked the ‘Pending Daemon Alerts’ and its blank.

    In Pending Daemon Events, I can see lot of line items with Event Type ODP_EVENT_WORKFLOW_ENGINE. However there is No Retry information I could see which I have seen in our DEV server. Also there are some events of type ODP_SCRIPT_CLASS_CONFIG_CHANGED pending.

    So I went to the Daemon Registration Report and deleted the ODP_EVENT_WORKFLOW_ENGINE. As per my understanding from your blog, it should have been restarted. But it did not restart.

    Any pointers which report can help us solve the issue. We have checked the eso.log but there is no error shown.

    Thanks for your help.

    S Tripathi

    1. Baski Janarthanam Post author
      Hi Tripathi,
      Please check if you see any errors reported under setup>system administration>Background Task Status, if you haven’t done already. This may give some clue

      Based on your inputs, I guess one be the following could be the case:
      – Workflow Engine Crashes: the workflow engine crashes soon after it is started. It takes about 5 minutes to recover. once recovered it tries to execute a faulty workflow (invalide xpdl) and crashes again. If this is the case that workflow event that causes this issue should removed from the queue. Again background status/logs should give some inputs on this.
        – Workflow daemon is disabled: Go to setup>system information >daemon registration tab & see if the workflow daemon is disabled..

      Refer to this link where I provided some debugging tips on a simillar case: [Workflow locking document – analysis, debug?]
      Good luck…

  2. Former Member

    Hi, this article was very useful for me and my team to understand Daemon functionalities but I have few questions about this.

    1) From report “Pending Daemon Events” / “Pending Daemon Alerts” I was not able to delete or modify any record. Any Idea why?

    2) I can see my tasks I.E: Monitor Data Import on “Pending Daemon Alerts” but nothing happened , it looks like the job never runs or something, there is any Log or Report that I can check in order to find out why my processes still pending?

    thank you in advance!


  3. Former Member

    Hi Baski,

    I started working on E-Sourcing recently. I am running one explicitly called script through Scheduled tasks. It used work perfectly, but all of the sudden now events are moving to “Pending Daemon Events” and it is not picking up at all.

    There are around 900 events in queue. We tried restarting the instance but no use. Can you please help how can i resolve this.




Leave a Reply