Understanding Events and Process Flows

The Event Broker Service configuration allows you to configure one or more events. When an event is received, the Event Broker Service maps the event name to a configured event name. If an unstructured event is received, the Event Broker Service maps the unstructured event to a configured default event name.

An Event configuration consists of the following information:

• Name: the name of the event in the incoming XML request maps to the configured event name. You can also name events so that they are part of a naming hierarchy. Events in a naming hierarchy are separated by a period. For example: Animals, Animals.Dogs, Animals.Dogs.Retriever. Naming hierarchies are handled differently based on the event type:
  • If a broadcast event for Animals.Dogs.Lab is received, the event is delivered to all handling agents (process flow or application) that are registered for Animals.Dogs.Lab, Animals.Dogs, and Animals.
  • If a request/response event is received, it is delivered to a single handling agent. If the incoming request contains an event name that does not exactly match an event name in the Event Broker Service configuration, the naming hierarchy is searched for the best possible event name match that is also configured as a request/response event type.
• Type: events can be one of the following types:
  • Broadcast, where a notification is sent to all handling agents, and either no response or an acknowledge receipt, is sent to the originating client.
  • Request/Response, where notification is sent to one handling agent and a response is sent to the originating client.
  Configure the event type as follows:
  • If the incoming XML request specifies a response type of none or ack (acknowledge), the event sender does not require a reply. To configure an event for no response or acknowledge, you specify Broadcast as the event type. For unstructured events, specify Broadcast as the event type.
  • If the incoming XML request specifies a response type of result, the event sender requires a reply. To configure an event for a response, specify Request/Response as the event type.
  The following table summarizes information about the incoming event request/response type and configured event type.

  Event Request/Response Type	Configured Event Response Type	Event Notifications	Event Response
  none	Broadcast	Notification sent to all process flows configured for the event and all listening applications registered for the event.	No response sent
  ack	Broadcast	Notification sent to all process flows configured for the event and all listening applications registered for the event.	Acknowledge receipt sent to the event sender.
  result	Request/Response	Notification sent to only one handling agent (listening application or process flow). If there is a listening application, it takes precedence over the process flow.	Response sent to the event sender.

  Note: If the event configuration does not match the incoming event request response type, then an error is returned (Event not configured).

• Security: you can specify different security attributes for each event:
  • To authenticate and authorize the sender's credential, select the Check sender's authorization. If you select the Check sender's authorization property, the event's process flows will not run unless the sender's credentials are successfully authenticated by the SAS Metadata Server's authentication provider and then authorized by the SAS Metadata Server's authorization facility as having the Execute permission for the event.

    Note: The sender's event request must contain the sender's user ID and password, and optionally, the authentication domain. You can configure a default authentication domain in the configuration for the User Service (see Additional Security Configuration); if you configure a default authentication domain in the User Service, then the sender is not required to specify the authentication domain in the event request.

  • To run event process flows under a particular identity, you must configure the events to run under one of the following:
    • the sender's identity
    • the broker's identity
      Note: You can only configure event process flows to run under the broker's identity if the Event Broker Service is deployed using a SAS Metadata Server (instead of an XML file) as the metadata source.
    • an identity that you supply in the configuration

    You can also specify that the event run with no security.

Additional Security Configuration

To set up security for sender's credentials or event process flows, you must

• use the User Manager plug-in to SAS Management Console to define user or group identities in the SAS Metadata Repository.
• create, configure, and deploy the User Service (of the SAS Foundation Services). You must configure and deploy the User Service as part of the Event Broker Service's service deployment; the User Service must be available to the Event Broker Service at run-time.

  To authenticate users, the User Service requires an appropriate login module configuration file. In addition, other Java 2 policy and JAAS policy files might be required. For example, to run an event's process flows under a particular security context, you must set up subject-based security with the JAAS policy configuration file in order to restrict access to the appropriate resources.

  For details about required User Service configuration, see the SAS Foundation Services class documentation for the User and Security Services. For details about additional User Service configuration in the Foundation Services Manager, see Modifying the Session and User Service Configurations.

In addition, to set up authorization for sender credentials, you must grant the sender the Execute permission for the event. To grant the Execute permission:

1. Use the Authorization Manager plug-in to SAS Management Console to define the Execute permission.
2. From the Foundation Services Manager, open the event properties.
3. On the event's Authorization tab, click Add to add the appropriate user or group for the sender.
4. Also on the event's Authorization tab, select the sender's user or group identity and grant the Execute permission.

After you define an event, you can define your process flows.

Understanding Process Flows

Process flows are used to process event messages. Process flows contain process nodes, which contain logic to process messages, and message nodes, which encapsulate the inputs and outputs for the process nodes.

• For broadcast events, you can configure one or more process flows for an event.
• For request/response events, you can only configure one process flow for an event.

You can configure a process flow by using the Process Flow Editor to define a Process Flow Diagram (PFD). A process flow configuration consists of:

• Name and description: the process name and optionally, a description.
• Process nodes: a process node is a Java class that can have one or more inputs and outputs. You diagram these inputs and outputs as message nodes. When an event is received and a process flow needs to be instantiated for the event, a runtime flow engine is instantiated. The runtime flow engine calls a process node by instantiating the Java class associated with that node. Currently, all process nodes are executed synchronously. A process node configuration consists of:
  • Name and description: the process node name and optionally, a description.
  • A class: the Java class is used to instantiate the process node. You can then generate the skeleton for the class, define your logic for the class, and compile the class.
  • Attributes for the class: attributes are name/value pairs for the class.

  Note: If a process node has no predecessors, it is the starting node for the process flow. Each process flow can have only one starting node.

• Message nodes: a message node encapsulates the outputs and inputs to process nodes in a process flow. A message node configuration consists of:
  • Name and description: the message node name and optionally, a description.
  • Details: details specify whether a message is required from the previous process node in order to make a process node eligible for firing.

The following screen capture shows an example of a portion of a process flow diagram: