|
Publishing Framework
EVENT_BEGIN
Initializes an event and returns an event identifier that uniquely identifies it.
Syntax
CALL EVENT_BEGIN(eventId, name, rc
<,properties, propValue1, ...propValueN>);
- eventId
- Numeric, output.
Identifies the new event.
- name
- Character, input.
Identifies a user-specified name of the event. The name should correspond to the name of an event that is defined in the Event Broker Service Process Flow Configuration. For more information, see
com.sas.services.events.broker in the Foundation Services class documentation.
- rc
- Numeric, input.
Receives a return code.
- properties
- Character, input.
Identifies a comma-separated list of optional property names. There are two types of properties: well-known and user-defined.
EVENT CALL routines recognize and process well-known properties. Some of the well-known properties are used to build the header portion of the event. Other well-known properties are used by the CALL routines to manage results that are returned as a result of the event execution. Well-known properties are as follows:
- DOMAIN
- IDENTITY
- PASSWORD
- PRIORITY
- RESPONSE
- RESULT_URL
- SENT_FROM
- USER
In addition to the well-known properties, you can also specify user-defined properties.
The user-defined properties are passed to the Event Broker, which passes these properties to the processing nodes, as needed. For more information, see
com.sas.services.events.broker in the Foundation Services class documentation.
If a user-defined property is specified, the property value can be any user-specified character string.
- propValue1, ...propValueN
- Character/numeric, input.
Specifies a value for each specified property name. The order of the property
values must match the order of the property names in the properties
parameter. A value must be specified for each property that is specified in the properties parameter. Valid property values are defined as follows:
- DOMAIN
- recognized and processed by the Event Broker, it is the domain for authenticating the user ID and password that are associated with a process flow. If this property is not specified, the default domain configured with the UserService will be used.
- IDENTITY
- recognized and processed by the Event Broker, uniquely identifies the message. It enables the client to distinguish among possible responses.
- PASSWORD
- recognized and processed by the Event Broker, it is the password that is associated with a process flow. For example, if a node in your process flow communicates with IOM, PASSWORD can be used to authenticate the user who is attempting to access the server.
- PRIORITY
- recognized and processed by the Event Broker, it specifies the Java priority. The default is 10.
- RESPONSE
- recognized and processed by the Event Broker, it identifies whether the Event Broker will send an acknowledgement or a result of the event execution.
RESPONSE is not supported when publishing the event to subscribers. It is supported only when the event is published to an explicit delivery transport, such as to a queue or to an HTTP server.
Valid values are as follows:
- ACK
- specifies that an acknowledgement message will be sent.
- NONE
- specifies that no response will be sent.
- RESULT
- specifies that a complete result set will be sent.
- RESULT_URL
- recognized and processed by the CALL routines, it manages results that are returned. If the RESPONSE property is specified with a value of RESULT or ACK, then the event execution will return results or an acknowledgement message, respectively. If a result or acknowledgement is expected, then the RESULT_URL property must be specified. This property is a URL that identifies where to write the results to. At this time, only a URL is supported.
- SENT_FROM
- recognized and processed by the Event Broker, it is a user-specified text string that identifies where the event was sent from. This property is used by the Event Broker to log the origination of the event message.
- USER
- recognized and processed by the Event Broker, it is the user ID that is associated with a process flow. For example, if a node in your process flow communicates with IOM, USER can be used to authenticate the user who is attempting to access the server.
Examples
Example 1
The following example initializes an event and returns the event
identifier in eventId. No properties are specified.
eventId=0;
rc=0;
name = "startEvent";
CALL EVENT_BEGIN(eventId, name, rc);
Example 2
The following example sets two user-defined properties. The user-defined property COMPANY has a value of "Alphalite Airways, Inc.". The user-defined property YEAR has a value of "1993".
name = "Salary";
prop = "Company, Year";
value1 = "Alphalite Airways, Inc";
value2 = "1993";
CALL EVENT_BEGIN(eventId, name,
rc, prop, value1, value2);
Example 3
The following example sets the well-known property PRIORITY.
name = "Sales Figures";
prop = "Priority"
priority = "10";
CALL EVENT_BEGIN(eventId, name,
rc, prop, priority);
Example 4
The following example sets a combination of well-known and user-defined properties. It specifies the well-known property SENT_FROM and a user-defined property STATE.
name = "Regional Figures";
prop = "sent_From, State";
from = "d1234.us.apex.com";
state = "NC";
CALL EVENT_BEGIN(eventId, name,
rc, prop, from, state);
Example 5
The following example sets the RESPONSE property to "Result" because results are expected from the event execution. Because the RESPONSE property is specified, the destination for the response must also be specified. Therefore, the RESULT_URL property must also be set to indicate where the response should be written to.
name = "Regional Figures";
prop = "Response, Result_Url";
resp = "Result";
furl = "file:/c:/testsrc/output.xml");
CALL EVENT_BEGIN(eventId, name,
rc, prop, resp, furl);
See Also
|