WSF_MESSAGE_PROCESSOR

processor WSF_MESSAGE_PROCESSOR
processor <name> WSF_MESSAGE_PROCESSOR
   processor Commands ...
   Platform Part Commands ...
   ... WSF_SCRIPT_PROCESSOR Commands ...

   # Specify the parameters for handling messages to be delayed.

   queuing_method ...
   number_of_servers ...

   # Specify message selection and processing rules.
   # (May be repeated as necessary...)

   process

      # Specify the messages to be selected for this process.
      # (May be repeated as necessary...)

      select
          ... Message Selection Commands ...
      end_select

      # Specify how the selected messages are to be processed Message Processing Commands

      ignore_message
      delay_time ...
      'script ... <script commands> ... end_script'
      ... External Link Commands ...
      ... Internal Link Commands ...

   end_process

   # Define the processing for messages not selected by a process block.

   default_process
      ignore_message
      delay_time ...
      'script ... <script_commands> ... end_script'
      ... External Link Commands ...
      ... Internal Link Commands ...
   end_default_process

   # Define the routing to be used when the selected process (or default_process)
   # block does not include any routing commands.

   default_routing
      ... External Link Commands ...
      ... Internal Link Commands ...
   end_default_routing

   # NOTE: Message Processing Commands that occur outside of process and
   # default_process are assumed to be part of the default_process.

   delay_time ...
   ... External Link Commands ...
   ... Internal Link Commands ...
   ignore_message
end_processor

Overview

WSF_MESSAGE_PROCESSOR provides the ability to control the flow of received messages by applying user-defined time delays and routing. The user provides process blocks which specifies the messages to which the accompanying message delays and routing are applied.

Input Requirements

Input to the processor consists of the following:

  • Zero or more process blocks which contain:

    • One or more select blocks that define the messages to be acted upon.

    • Commands that define the actions to be applied to the selected messages (e.g., time delay, routing or ignoring).

  • An optional default_process block that defines the actions to be applied to messages that are not selected by a process block.

  • An optional default_routing block that defines the routing to be applied to messages that do not contain any routing commands.

  • Commands to configure the queue manager that is responsible for processing messages with a non-zero delay_time.

Processing Flow

The general flow of processing a received message is as follows:

  • Search the process blocks for the first entry that applies. If an applicable process block is not found, use the default message handling as defined by the default_process block.

  • If the message handling specified ignore_message, simply ignore the message and exit.

  • If the message handling specified a non-zero delay_time, put the message in the processing queue according to the queuing_method and number_of_servers.

  • When any necessary delay has been completed (or immediately if no delay was selected), route the message as required:

    • Use the internal and external link commands from the selected process or default_process block, if defined.

    • If not defined, use the internal and external link commands from the default_routing block.

Message Queuing Commands

These commands define the how messages are queued if they require a time_delay.

queuing_method [ first_in_first_out | last_in_first_out | none ]

Specifies how incoming messages are to be queued if all of the servers are busy. A value of none indicates the message will be discarded if no server is available.

Default: first_in_first_out

number_of_servers [ <integer-reference> | infinite ]

Specifies the maximum number of messages that can be ‘in process’ at any given instant of time. If a new message is received and all the servers are busy, the message will be queued according to the queuing_method

If ‘infinite’ is specified (the default), received messages are simply delayed by the required amount before being forwarded.

Default: infinite

Message Selection Commands

The message selection commands occur inside select blocks and specify what messages are to be acted upon by the Message Processing Commands in the process block in which they occur. A message will be selected for processing if all of the selection criteria specified in any select block within the process block are true.

Note that with the exception of the sender command, each of the selection criteria commands should occur at most once within a given select block. For example, if one desires to select two different types of messages then two select blocks must be provided, each with a different type selector.

type <message-type>

Returns true if the supplied message type matches the type from the message. Standard message types are as follows:

Type String
Script Class
WSF_ASSOCIATION_MESSAGE
WsfAssociationMessage
WSF_CONTROL_MESSAGE
WsfControlMessage
WSF_IMAGE_MESSAGE
WsfImageMessage
WSF_STATUS_MESSAGE
WsfStatusMessage
WSF_TASK_ASSIGN_MESSAGE
WsfTaskAssignMessage
WSF_TASK_CANCEL_MESSAGE
WsfTaskCancelMessage
WSF_TASK_CONTROL_MESSAGE
WsfTaskControlMessage
WSF_TASK_STATUS_MESSAGE
WsfTaskStatusMessage
WSF_DROP_TRACK_MESSAGE
WSF_TRACK_DROP_MESSAGE
(See note below)
WsfTrackDropMessage
WSF_TRACK_MESSAGE
WsfTrackMessage
WSF_TRACK_NOTIFY_MESSAGE
WsfTrackNotifyMessage
WSF_VIDEO_MESSAGE
WsfVideoMessage

Note

on_message and WSF_MESSAGE_PROCESSOR will accept either WSF_DROP_TRACK_MESSAGE or WSF_TRACK_DROP_MESSAGE as a valid handler for WsfTrackDropMessage. When WSF was created the string type associated with WsfTrackDropMessage was confusingly called WSF_DROP_TRACK_MESSAGE instead of WSF_TRACK_DROP_MESSAGE. At some point the string type will be changed to be consistent, but in the mean time either form will be accepted in the indicated context.

subtype <message-subtype>

Returns true if the supplied message subtype matches the type from the message.

sensor_name <sensor-name>

Returns true if the message is a WSF_TRACK_MESSAGE, WSF_IMAGE_MESSAGE or WSF_VIDEO_MESSAGE, and if the supplied sensor name matches the sensor name from the message.

sensor_type <sensor-type>

Returns true if the message is a WSF_TRACK_MESSAGE, WSF_IMAGE_MESSAGE or WSF_VIDEO_MESSAGE, and if the supplied sensor type matches the sensor type from the message.

sensor_mode <sensor-mode>

Returns true if the message is a WSF_TRACK_MESSAGE, WSF_IMAGE_MESSAGE or WSF_VIDEO_MESSAGE, and if the supplied sensor mode matches the sensor mode from the message.

system_name <system-name>

Returns true if the message is a WSF_STATUS_MESSAGE and if the supplied system name matches the system name from the message.

sender commander | peer | subordinate | self

Returns true if the sender of the message was one of the identified platforms.

Note

This command may be repeated to build the set of acceptable senders. The return value will be true if any of the sender commands returns true.

script … script commands … end_script

Defines a script that returns true if the message is to be selected. The script variable MESSAGE refers to the current message.

Message Processing Commands

delay_time <random-time-reference>

Specifies the amount of time the message should be delayed before being processed,

Default: delay_time 0 sec (no delay)

Note

This is a <random-time-reference>, and as such can specify a distribution from which the delay is ‘drawn’ for each received message.

ignore_message

Indicates the message should be ignored.

Default: false (The message will be processed)

script … script commands … end_script

Defines a script that will be called to ‘process’ the message. The script variable MESSAGE refers to the current message.

This is similar to the script block inside of an on_message block in WSF_SCRIPT_PROCESSOR.

Note

This form of the script command (no return type, name and argument list) is allowed only within a process or default_process block. The script command that occurs outside of these blocks is treated as a normal script definition and must include a return type, name and argument list.