La “política de la calidad” de Luis Zanón contra

This chapter describes the events sent by the EDU server. It also explains how to assign and how to establish monitoring criteria.

This section includes the following topics:

● EDU event monitoringon page 35

● Starting and stopping event monitoringon page 38 ● Setting event monitoring criteriaon page 39

EDU event monitoring

The EDU server continuously monitors the contents of EDUs for changes, and reports those changes to interested clients through event messages.

Clients register their interest in EDUs by assigning themselves to the EDU server with monitoring criteria, which is a specification describing the condition that should generate an event notice. For example, the client might request notification for every phone call originating from a specific ANI, or for every customer contact handled by a particular agent. The client receives event messages about EDUs that match the specification. The client continues to receive all events generated for those EDUs as long as they match the specified monitoring criteria.

Event Monitoring

The EDU server generates seven types of events that describe changes to existing EDUs. The following table lists the events and the contents of the event messages written in the EDU and sent to monitoring clients.

When a client first assigns monitoring criteria to the server:

● All existing EDUs are checked to see if any of them match the client’s specification. All

subsequently created EDUs are checked for a match.

● Any EDUs that do match the monitoring criteria are placed under watch. A VDU.Watch

event message is sent to the monitoring application.

● Changes to EDUs under watch are reported to the application by a VDU.Change event.

Event Description Message

VDU.auRevoir When the EDU server sends the EDUs to the DUStore, it issues "VDU.auRevoir" to the Report server.

The ID of the object being send to the DUStore.

VDU.Change A monitored EDU was changed. All affected {name, value} couples and the EDUID. VDU.Delete Values were deleted from the

EDU. All deleted values.

VDU.Drop The EDU has changed and it no longer matches the assign criteria. It is no longer monitored. If there are more EDU changes that make it again meet the assign criteria, the client gets a VDU.Watch event.

The EDUID.

VDU.End The EDU was terminated. When it terminates, the EDU server sends a VDU.End message to all of the monitoring applications.

All of the data elements in the EDU.

VDU.LostConnectivity Two connected EDU servers lost their connection to each other.

The clients assigned to these servers who prepended notify/drop to their assign criteria receive this event. VDU.Transfer The EDU was transferred. The new client and the

EDUID. VDU.Watch The EDU matches the

EDU event monitoring

Note:

Note: When a client has assigned to the EDU server, the client should monitor the

event data stream for the data it wants, rather than repeatedly invoking VDU.Get…() methods. As values are set in the EDU, the EDU server sends Change events to assigned clients. The timing, order, and content of the Change events depend on the components setting the values, which makes them variable.

Event Monitoring

Starting and stopping event monitoring

The EDU server methods VDU.Assign()and VDU.Monitor() set up monitoring conditions. The VDU.Deassign() method revokes them.

Note:

Note: By default, a client does not receive change events for the EDU changes it

initiates. This reduces needless event traffic. The client does receive other sorts of events, as well as event messages for changes caused by other clients. If the change causes a VDU.Watch or VDU.Drop event, it is reported to the client. To receive change events for the client's own changes, prefix the Assign or Monitor expression with a plus symbol (+).

For example:

[VDU.Assign("+*")]

(The asterisk (*) in the example indicates that all EDUs in the local (assigned to) EDU server should be monitored, as described in Monitoring criteria: syntaxon page 39.) Assigning to the EDU server and monitoring an EDU does not add a client's name to the internal list of EDU-modifying clients. (This list of clients is described in EDU terminationon page 22.) Assigning allows the client to watch the activity of an EDU. The client does not have to issue a VDU.Terminate() for each EDU that is being watched.

Setting event monitoring criteria

Setting event monitoring criteria

EDUs are selected for monitoring by criteria matching. Criteria is an expression that selects some EDUs and rejects others according to a defined specification. If a criteria expression is provided as a parameter to the Assign() or Monitor() method, each name/value pair in the EDU is tested against it. If the criteria finds a match, the EDU is watched. Subsequent changes are sent to the client as change events.

The createtime, duration, endtime (historical), owner (historical), termination, and transfercount cannot be used in an Assign criteria.

This section includes the following topics:

● Monitoring criteria: syntaxon page 39 ● Relational operatorson page 41 ● Boolean operatorson page 42

● Monitoring criteria: wildcardson page 42 ● Monitoring criteria: exampleson page 43

Monitoring criteria: syntax

The general syntax of a criteria statement is:

method "name relationship value" [booleanop] "name relationship value"

For example:

VDU.assign "loginid=Joe & ani=808863244"

In the above example, the client has assigned to the EDU server, asking it to watch for any EDU that contains these two values:

● “Joe” in the field loginid

● originated from (800) 886-3244.

The EDU will notify the client every time Joe gets a telephone call from Avaya Support. You can construct complex statements that evaluate multiple conditions by grouping expressions together with parentheses to control the order of evaluation.

A single * character has a special meaning when used as a monitor criteria. It causes all local (assigned to) EDUs (those in the local EDU server) to be watched. This monitor

Event Monitoring

The Assign method does not accept special tokens !, +, or the null token in container names. These tokens have specific meanings for a particular EDU and vary from one EDU to another. The Assign method has no provision for names that do not have EDU-

independent meaning.

The Assign and Monitor methods contain criteria strings that allow additional syntax. At the end of the string is a list of fields, called a projection list, enclosed in curly brackets where filter criteria can be specified. The list is comma separated with no spaces between the fields.

For example:

{specification,specification…}

You can specify the type of field name in three ways.

To specify the type of field name:

1. Use a simple field name, such as a, b, or c.

2. Enter a wildcard container name, such as a.* or a.*.d. The wildcard designation (*) can be used after a dot (.), at either end of the specification, or followed by a dot (.) in the specification.

3. Issue a request to retrieve all of the fields below a specified point in a container tree, as in “a.b?”. This format collects all of the field names below the specified point in

container tree. It does not collect field names at its own level or higher on the tree. Example:

+vdu_id> "" {call?,data.*,loginid}

Spaces are optional after the selection criteria and before the projection list. The projection list itself is optional, but no filtering is done without one.

● This assign criteria watches all EDUs in the system because all EDUIDs are longer than

empty strings.

● Change events that do not reflect a change in the loginid, any matching data.*, or any

subcontainer of the call container are also suppressed.

● Change events that not suppressed are trimmed to list only the names that are provided

on the projection list. The duid, time, and modifier fields are also provided.

Note:

Note: Watch and drop events are not modified and they are always sent with their

full content. User events, which are very rare, would be modified as they are actually change events with a different name.

Setting event monitoring criteria

Relational operators

Values can be compared to each other as described below. The following table illustrates the supported relational operators. In the description column, the term couple refers to a name/value pair.

The EDU server compares the name/value data within an EDU against the criteria string one character at a time, starting with the leftmost character, until either a mismatch occurs or one field runs out of characters. Comparisons are case-sensitive. “Foo” is not the same as “foo” or “FOO”. To avoid ambiguity, enclose the specified value within double quotes (“”). Within a quoted string, (\") means quote and (\\) means backslash.

If the strings match character for character, they are equal. Strings can also be relatively compared. If one field runs out of characters without a mismatch, the relatively longer field is greater (for example, abc < abcd). If a mismatch occurs, the field containing the greater character is greater, (for example, 111 < 119). Because the comparison is string-based, not numeric, the field with the greater initial character is greater, (for example, 2 > 119). Wildcards are permitted only with the equal (=) operator.

Symbol Definition Description

= equal Find a couple that matches the specified name and value. Wildcards are accepted.

< less than For a given name, find all couples with values less than the specified search value (string-based). > greater than For a given name, find the set of couples with

values greater than the specified criteria (string- based).

: exactly equal to For a given name, find a couple that exactly matches the specified value. Wildcards are not accepted.

Event Monitoring

Boolean operators

Boolean comparisons that return evaluations of true or false can be performed between two values. The two boolean operators are described below.

For example:

ani=508* | dnis=3315

selects all contacts received from the 508 area code or all contacts directed to extension 3315. Terms may also be grouped with parenthesis for more complex expressions.

Monitoring criteria: wildcards

Instead of specifying each individual instance of a set, you can use wildcard symbols to replace other values. The wildcard symbols can be used in setting criteria given the following restrictions:

● Wildcard usage is restricted to the equal (=) relational operator. You cannot use

wildcards with the less than (<), greater than (>), or exactly equal to (:) operators.

● Single character wildcards must have a character to match.

Each ? symbol can stand in for one character. The * symbol can either be placed at the end of a value (a value trailing wildcard), or can be entered by itself to find EDUs with an instance of any value (selects all EDUs as matching).

Symbol Definition Description

& and Both expressions must be true.

| or True if one or both expressions are true.

Wildcard Definition Example

? Match one

character pbx = ???

Find all couples named “pbx” which contain a three-character value.

* Find all VDUs transfercount= *

Setting event monitoring criteria

Container names used in an Assign can use limited wildcarding. Within an Assign, an expression like:

agent.*.problem > “”

selects any EDU in which any subcontainer in agent having a name of problem has nonempty text. Note that the ! token is not available in an Assign, but this wildcard token can be used instead.

A simple way to have an EDU transferred to the attention of an agent would be for: 1. Assign the agent to the EDU server using: agent.* : agentloginid

2. Change the application setting: agent.+agentloginid to a value of agentloginid.

In this way, the Assign criterion is satisfied because there is a subcontainer in agent whose value is agentloginid, and that agent, on getting an event about the EDU, can use agent.! to refer to the subcontainer created for him.

Monitoring criteria: examples

The following examples demonstrate how to have the server to monitor EDUs that meet specific criteria. The last three examples all identify the same set of EDUs–those from area code (203). Choose the method that best fits the current circumstances.

Criteria Example Description

ani = "8008863244" Identify any EDU containing the value "8008863244" in the field “ani”. (ani > "2029999999") & (ani < "2040000000") Monitor all calls from the “203” area

code.

ani = "203*" Monitor all calls from the “203” area code. (This is the most efficient way to do this.)

ani = "203???????" Monitor all calls from the “203” area code.

In document Ocupar, resistir y producir (página 65-70)