Monitoring events

Through the Service Configuration Manager, you can configure the Event Service to monitor any known configurations from any and all servers.

Use these guidelines:

  • Select an optimal combination for best load balancing.
  • It is pointless to monitor a configuration whose application database contains no event handlers or fires no events. However, note that Infor or another vendor from whom you purchased an add-on product might have included event handlers or code that fires events in their distribution, so you should check for these when you consider which configurations to monitor.
  • You can create new configurations solely for monitoring by the Event Service.

Each configuration in the monitoring list represents an independent software timer on an independent operating system thread whose time slices can be scheduled (by the operating system) to run on a different CPU than the others, where available.

Example 1

Hardware: One superfast/multiprocessor server.

Goal: You want to handle all events on one server.

Implementation: Pick a set of configurations, each of which points to a different application database, and which together span all application databases. Monitor that set.

This table provides the details:

Configuration App database Monitor?
ILL_Prod ILL_App Yes
ILL_Test ILL_App No
CAL_Prod CAL_App Yes
OH_Prod OH_App Yes

Example 2

Data: Six sites (ILL, CAL, OH, COL, CHINA, and FRANCE) and two entities (USA and CRP). The entities will not have events in this example, because they are only used for G/L roll-up.

Hardware: Three servers, one of which (Util1) is comfortably loaded with other functions such as replication, TaskMan, or IDO communications.

Goal: Spread the load from the six site application databases over the two free servers (Util2 and Util3).

Implementation: Monitor the largest, heavy-traffic site alone or with another lesser site. Monitor the rest together.

This table provides the details:

Server Configuration App database Monitor?
Util2 ILL ILL_App Yes
Util2 CAL CAL_App Yes
Util3 OH OH_App Yes
Util3 COL COL_App Yes
Util3 CHINA CHINA_App Yes
Util3 FRANCE FRANCE_App Yes

Example 3

Data: One heavily used site (ILL_App) with many events firing per second, and/or a need for immediate response to queued and adjourned events.

Hardware: One superfast/quadprocessor server (Util1), plus other slower servers.

Goal: Select items from the super-site’s event queues on as many processors as possible.

Implementation: Monitor the super-site multiple times from the superfast server (once per CPU) and once from the other servers. Monitor the other sites from the other servers, evenly.

This table provides the details:

Server Configuration App database Monitor?
Util1 ILL_1 ILL_App Yes
Util1 ILL_2 ILL_App Yes
Util1 ILL_3 ILL_App Yes
Util1 ILL_Prod ILL_App Yes
Util2 CAL_Prod CAL_App Yes
Util2 OH_Prod OH_App Yes
Util2 ILL_Prod ILL_App Yes
Util3 ILL_Prod ILL_App Yes
Util3 COL_Prod COL_App Yes
Util3 CHINA_Prod CHINA_App Yes
Util3 FRANCE_Prod FRANCE_App Yes