EVENT_BEGIN
Initializes an event and returns an event identifier
that uniquely identifies it
Syntax
CALL EVENT_BEGIN(eventId, name, rc<,properties, propValue1, ...propValueN> );
Required Arguments
- eventId
-
identifies the new
event.
- name
-
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
-
receives a return code.
Optional Arguments
- properties
-
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:
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. If a user-defined
property is specified, the property value can be any user-specified
character string.
- propValue1, ...propValueN
-
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,
then the default domain that is configured with the UserService is
used.
|
| IDENTITY |
recognized and processed by the Event Broker, it
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, then 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 sends an acknowledgment 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, which specifies that an
acknowledgment message will be sent; NONE, which specifies that no
response will be sent; and RESULT, which 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 returns results
or an acknowledgment message, respectively. If a result or acknowledgment
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, then USER can
be used to authenticate the user who is attempting to access the server.
|
Type:Character or Numeric, Input
Examples
Example 1: Using EVENT_BEGIN
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: Using EVENT_BEGIN with User-Defined Properties
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: Using EVENT_BEGIN with the PRIORITY Property
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: Using EVENT_BEGIN with the SENT_FROM Property and a User-Defined
Property
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: Using EVENT_BEGIN with the RESPONSE and RESULT_URL Properties
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);