4.3.9 System Event

Owned by Jenni Wallin
Last updated: May 08, 2023 by Former user (Deleted)
5 min read

In this section some of the circumstances during which the System event is triggered that may be useful for Event Notification configurations are listed:

  • If the Event Server cannot be reached.
    Message: Cannot access EventServer.
  • If an attempt to resend an event to the EventServer is made.
    Message: Retrying to send event to listener <listener> at <host>. Retry count <attempt number>.
  • If an event listener is abandoned.
    Message: The listener <listener> at <host> is abandoned.
  • If a license violation has occurred.
    Message: Violation report <message>.
  • If a pico instance was disconnected from the Platform by a user.
    Message: The pico instance <pico instance> at host <host> was disconnected from platform by <user>.
  • When the Platform thread pool size has been set for workflows and workflow groups.
    Message: The platform thread pool size for workflows and groups is set to <thread pool size>.
  • If the mz.platform.wf.threadpool property cannot be parsed with default thread pool size.
    Message: Failed to parse the <mz.platform.wf.threadpool> property. Using default size <default thread pool size>.
  • If the mz.platform.wf.threadpool property has been set to a value outside of valid range.
    Message: The property <mz.platform.wf.threadpool> is outside the appropriate range, have set size to <thread pool size>.
  • If configuration data is missing for a workflow in a workflow group that is being loaded to the GroupServer.
    Message: Configuration data is missing for workflow <workflow>.
  • If the GroupServer cannot register to the EventServer in order for workflow groups to be loaded or updated.
    Message: Group server is unable to register to the event server. Groups will not be loaded or updated.
  • If the GroupServer cannot load workflow groups at startup.
    Message: Group server was unable to load groups during startup.
  • If a workflow group is manually stopped.
    Message: Group <workflow group> is being manually stopped by the user.
  • If a workflow group is stopping.
    Message: Group <workflow group> and all its members are stopping.
  • If a workflow group has stopped.
    Message: Group <workflow group> have stopped.
  • If scheduling cannot be set for a workflow group.
    Message: Cannot schedule group <workflow group>.
  • If the scheduling cannot be removed for a workflow group.
    Message: Cannot remove scheduling for group <workflow group>.
  • If a configuration with broken serialization is removed.
    Message: <DR Exception>.
  • If a workflow configuration cannot be loaded.
    Message: Failed to load configuration for <workflow>, changing state to invalid state.
  • If an old version of a workflow has been detected running on an EC.
    Message: Found one old version of the workflow <workflow> with session id <session id> running on an ec. The workflow have been shut down..
  • If a reconnect attempt to an unreachable workflow has failed and a new attempt is made.
    Message: <workflow> is unable to reconnect, reconnect is restarted.
  • If the connection to an unreachable workflow has been re-established.
    Message: Connection to unreachable workflow has been re-established.
  • If a workflow that is supposed to be closed and killed is trying to communicate with the Platform.
    Message: Warning, a presumed closed and killed workflow <workflow> tried to communicate with the platform, ignoring the message.
  • If an old workflow is detected on an EC when attempting to start a workflow.
    Message: Warning an old workflow where found on ec <ec> when the workflow <workflow> where to be started, the old one have been forced to stop.
  • If a workflow cannot be shut down on an EC.
    Message: Workflow <workflow> was unable to shut down on ec <ec>.
  • If a workflow is being manually stopped by a user.
    Message: Workflow <workflow> is being manually stopped by the user.
  • If a workflow is stopped.
    Message: <stop message>.
  • If a workflow aborts and the exception in the abort is not used.
    Message: Workflow <abortException>
  • If trying to retrieve a list with valid workflow configurations, and failing to retrieve any of the workflows.
    Message: Unable to retrieve workflows from the configuration <workflow>. Due to <cause>.
  • If a workflow or workflow group cannot be enabled or disabled in a Suspend Execution configuration, see 3.2.4 Suspend Execution for further information.
    Message: Unable to send enable/disable signal to the workflows/groups in configuration <configuration>.
  • If configurations are missing in a Suspend Execution configuration, see 3.2.4 Suspend Execution for further information.
    Message: Warning, The following members of the suspend execution configuration where not found and they where not <enabled/disabled>. <configurations>.
  • If a Code Manager event occurs, see 4.3.3 Code Manager Event for further information.
    Message: <Code Manager event message>.

Filtering

In the Event Setup tab, the values for all the event fields  are set by default to All in the Match Value(s) column, which will generate event notifications for all state changes for all workflow groups. Double-click-on the field to open the Match Values dialog where you can click on the Add button to add which values you want to filter on. If there are specific values available, these will appear in a drop-down list. Alternatively, you can enter a hard coded string or a regular expression.

The following fields are available for filtering of Group State events in the Event Setup tab:

System event specific fields

  • systemMessage - This field contains the message appended with the System event, as described in the previous section.

Fields inherited from the Base event

The following fields are inherited from the Base event, and described in more detail in 4.3.1 Base Event:

  • category - If you have configured any Event Categories, you can select to only generate notifications for System events with the selected categories. See 4.4 Event Category for further information about Event Categories.

  • contents - The contents field contains a hard coded string with event specific information. If you want to use this field for filtering you can enter a part of the contents as a hard coded string, e g the state you are interested in Idle/Running/Stopping/etc. However, for System events, the content consists of the text "System message:" and then the system message itself, see the description of the system message above.

  • eventName - This field can be used to specify which event types you want to generate notifications for. This may be useful if the selected event type is a parent to other event types. However, since the System event is not a parent to any other event, this field will typically not be used for this event.

  • origin - If you only want to generate notifications for events that are issued from certain Execution Contexts, you can specify the IP addresses of these Execution Contexts in this field.

  • receiveTimeStamp - This field contains the date and time for when the event was inserted into the Platform database. If you want to use timeStamp for filtering, it may be a good idea to enter a regular expression, for example, "2012-04.*" for catching all System events from 1st of April, 2012, to 30th of April, 2012.

  • severity - With this field you can determine to only generate notifications for state changes with a certain severity; Information, Warning, Error or Disaster. This may be useful to filter on if you only want to view System events that generate Warnings for example.

  • timeStamp This field contains the date and time for when the Execution Context generated the event. If you want to use timeStamp for filtering, it may be a good idea to enter a regular expression, for example, "2012-06-15 09:.*" for catching all System events from 9:00 to 9:59 on the 15th of June, 2012.

Note!

The values of these fields may also be included in the notifications according to your configurations in the Notifier Setup tab.

Examples System Event Configuration

Example - System Event sent to Log File



This configuration will give you the following notification setup:

  • When a System event occurs, a System Event notification will be generated.

  • When this notification is generated a new log line will be added in the systemevent.txt file located in the /home/MyDirectory/systemevent/ directory,with the following data:

    • The timestamp for when the System Event was registered.

    • The System Event message.

Example - System Event sent to Mail



This configuration will give you the following notification setup:

  • When a System Event with a message containing the text "Warning" is registered, a System Event notification will be generated.

  • When this notification is generated a mail will be sent to the my.mail@mycompany.com e-mail address with the following data:

    • The subject will say: "System Event".

    • The message will contain the following text: The following warning has been detected: <the system event message>.

Next:

4.3.10 Security Event