|
Oracle® Sensor Edge Server Guide
10g Release 3 (10.1.3) B25142-01 |
|
 Previous |
 Next |
|
Oracle® Sensor Edge Server Guide
10g Release 3 (10.1.3) B25142-01 |
|
|
Previous |
Next |
This chapter includes the following sections:
"Overview of Device, Filter Instance and Dispatcher Configuration"
"Managing Dispatchers for an Oracle Sensor Edge Server Instance"
This chapter describes the extensions (drivers, filters, and dispatchers) that the Oracle Sensor Edge Server supports out of the box and how to configure their parameters when you create instances of these objects (or, in the case of the dispatcher, when you set the current dispatcher for an Oracle Sensor Edge Server instance). Because these extensions are static objects, you must create instances of them to enable an Oracle Sensor Edge Server instance to use them to process event data. Fore more information, see "Setting the Dispatcher for the Oracle Sensor Edge Server Instance" and "Setting the Devices and Filters Used by the Oracle Sensor Edge Server".
Some of the device and current dispatcher configuration requires you to define a URI parameter. This parameter, which requires a String value, tells the Transport Library which transport and parameters to use. Enter the value for the URI parameter in the following format:
esc://<transport>?<param1>=<value1>&<param2>=<value2>&...
Where:
<transport> is the name of the transport to use (as in transportstransport@name in the transports.xml file).
<param1> is a parameter name for the transport.
<value> is the value for the parameter.
You can specify as many parameters as you need. For example, to connect using TCP/IP to a server called test.oracle.com at port 9999, enter the value for the URI parameter as:
esc://tcp&hostname=test.oracle.com&port=9999
To connect to a serial port COM1 at 9600 baud, enter the value for the URI parameter as:
esc://com?port=COM1&baud=9600
To connect to TCP port 9999 at IP 1.2.3.4, enter the value for the URI parameter as:
esc://tcp?hostName=1.2.3.4&port=9999
To write output to a file and read from another file (which is useful for testing and logging), enter the value for the URI parameter as:
esc://file?inputFileName=/tmp/myInFile.txt&outputFileName=/tmp/myOutFile.txt
The values defined for the URI parameter are specific to the transport type. Table 6-1 describes each supported transport type and its associated parameter values.
Table 6-1 Supported Transport Types
| Name | Description | Parameter Values |
|---|---|---|
|
com |
Serial Communication Port |
port is the name of the port (such as COM1, COM2, tty1S). baud is the baud rate (such as 9600, 38400, 115200). Example: esc://com?port=COM1&baud=9600 |
|
tcp |
TCP/IP Connection |
hostname is the IP address or hostname to connect to (for example, 127.0.0.1). port is the port number. timeout is an optional parameter that sets the number (in seconds) in which to wait for a valid connection. Example: esc://tcp?hostName=127.0.0.1&port=9999 |
|
stdout |
Use standard input and output streams. |
N/A |
|
file |
Files used for input and output. |
outFileName is an optional parameter naming the output file. If you do not enter a value, then the output is discarded. inFileName is an optional parameter naming the input file. If you do not enter a value, then there is no input. purgeOnClose is an optional parameter requiring a Example: esc://file?inputFileName=/tmp/myInFile.txt&outputFileName=/tmp/myOutFile.txt |
|
http |
Post to a URL through HTTP. |
URL is the URL to post to. proxyServer is an optional parameter specifying which proxy server to use. proxyPort is an optional parameter specifying the port for the proxy. |
|
ftp |
Post and retrieve files through FTP. |
hostname is the name of the FTP server user is the name of the user. password is the password for the user. |
|
Tip: You can also define commonly used parameters in the transports.xml file. All of the values defined in the URI parameter override those defined in thetransports.xml file.
|
The Oracle Sensor Edge Server provides drivers that support RFID readers (described in Table 6-3).
Table 6-2 RFID Readers
| Driver Name | Supported Devices |
|---|---|
|
Alien Reader Driver |
All of the Alien Technology RFID readers, such as the Alien NannoScanner (Model 915MHz, the ePC Reader). See "Configuring Alien Reader Driver-Based Devices". |
|
BarcodeDriver |
Any barcode reader that works with standard ASCII mode through serial or network communication. |
|
Intermec BRI Driver |
All of the Intermec RFID readers that support BRI (Basic Reader Interface), such as the IF5 Fixed RFID Reader. See "Configuring Intermec BRI Driver-Supported Devices". |
|
Intermec Reader Driver |
Devices include:
|
|
Matrics Driver |
Supported fixed Readers by Symbol Technologies include:
|
|
Samsys Driver |
SAMSys EPC UHF Long-Range Reader (Model MP9320 2.7) |
|
Tyco Reader |
Tyco Sensormatic Agile2 Reader (Powered by ThingMagic) |
In addition, Oracle Sensor Edge Server provides drivers that support printer devices and those for display and notification (described in Table 6-3).
Table 6-3 Printer Drivers and Display and Notification Drivers
| Driver Name | Supported Devices |
|---|---|
|
AnimationDriver |
This is a software-only driver used for device simulation. |
|
ConsoleDriver |
This is a software-only driver used for device simulation. |
|
Edge Simulator Driver |
This is a software-only driver used for device simulation. |
|
LpmlDriver |
Supported printer devices include:
|
|
PatliteDriver |
PHE-3FB PC-Controlled Light by Patlite (USA) Corp. The Lightstack Device Controllers are available for download from Oracle Technology Network (http://www.oracle.com/technology/ |
|
Prolite Driver |
Pro-Lite TruColorII LED Display (Model PL-M2014RV6) |
The Oracle Sensor Edge Server also ships with Edge Echo Driver. The Edge Echo Driver does not control any physical device; instead, this driver receives an instruction event, copies the event, and then sends it back out. This event has all of the same attributes as the original instruction event, depending on the configuration of the Edge Echo Driver instance. The Oracle Sensor Edge Server processes the event as any other event generated by a device: the event is filtered and then dispatched by the current dispatcher. See also "Configuring Edge Echo Driver-Based Instances".
The Alien Reader Driver supports all of the Alien Technology RFID readers.
To configure an Alien Reader Driver driver-based device, define the following parameters:
IPAddress -- The hostname or IP address of the machine running the Device Controller. If it runs on the same machine as the Oracle Sensor Edge Server, enter 127.0.0.1.
Port Number -- The port number used to communicate with the device (23 is the default).
username and password
AntennaSeqIDList -- The list of identifiers for each antenna.
AntennaMappedDeviceNameList -- The list of mapped device names associated with each antenna.
Observation events are events that are generated by the driver and are dispatched out to the system. Table 6-4 lists the events generated by the Alien Reader Driver.
Table 6-4 Observation Events Generated by the Alien Reader Driver
| Type | Subtype | TagID | Data | Description |
|---|---|---|---|---|
|
200 |
Various |
Tag ID |
The data field (payload) stored in a tag. |
General tag observation event. |
|
1 |
0 |
Null |
"alive or dead" |
Each event using data property to indicate whether the device is alive or not. |
|
1 |
0 |
Null |
"dis" |
An event indicating a successful device startup operation. |
|
1 |
2 |
Null |
"dif" |
An event indicating a failed device startup operation. |
|
1 |
0 |
Null |
"dss" |
An event indicating an successful device stop operation. |
|
1 |
2 |
Null |
"dsf" |
An event indicating a failed device stop operation. |
|
1 |
2 |
Null |
"drf" |
An event indicating a failed event-receiving operation. |
|
1 |
0 or 2 |
Null |
<callResults> <callResult name="write-tag"> <code>0/1</code> <message/> </callResults> |
An event indicating a successful or failed tag-writing operation. |
Applications send devices instruction events to tell them to perform certain tasks. Table 6-5 lists the instruction event accepted by the Alien Reader Driver.
Table 6-5 Instruction Event Sent by the Alien Reader Driver
| Type | Subtype | TagID | Data | Description |
|---|---|---|---|---|
|
101 |
0 |
Null |
<methodCalls>
<methodCall name="write-tag"">
<params>
<param name='tagid'>%TAGID%</param>
<param name='tagdata'>%TAGDATA%</param>
</params>
</methodCall>
</methodCalls>
|
Write data to a tag identified by the specified tag ID. |
The AnimatorDriver does not support a device; this driver supports interactive software simulations of devices. The configured instance of this driver accepts user input or events from the Oracle Sensor Edge Server and runs animation sequences defined in the configuration file (Example 6-1) on the screen.
To configure an AnimationDriver instance, define the fileName parameter as the full or relative path to the configuration file, an .xml file in the format described in Example 6-1. Using this file, you can configure the AnimationDriver instance to accept and generate any type of event.
Example 6-1 Configuration File for the AnimationDriver
<animate> <window>... </window> <task>...</task> </animate>
To configure this file, define its <window> and <task> elements.
Defining the <window> Element
The <window> element enables you to define a window. Each window appears as a top level window in the server's display. Within the <window> element, you can define any number of user interface controls in the window that trigger tasks.
The <window> element is comprised of three attributes which define the window and its dimensions: name, width, and height.
name is a unique name for the window, which appears on the window's title bar.
width is the width of the window, in pixels.
height is the height of the window, in pixels.
Once you define the window, you can then define the controls within in it. Example 6-2 illustrates a window with a single push button control. The AnimationDriver supports button, a control type for a push button.
Example 6-2 Defining Windows in the Configuration File
<window name='myWin' width='200' height='100'> <control type='button' name='Pass Thru'/> </window>
You define the tasks triggered when the users clicks the button using the <task> element.
Defining the <task> Element
A task is a set of actions triggered by either a control or an event. Example 6-3 illustrates the <task> element, with its <when> and <action> child elements. The <when> element tells the task when to run the <action> element. There can be multiple tasks that map to overlapping conditions.
Example 6-3 Defining Tasks in a Configuration File
<task name='TaskA'> <when> ... </when> <action> ... </action> </task>
You define the <when> element using the following conditions:
<onClick> matches a user clicking a control in a window. This condition takes one argument, the name of the control for the event. For example, <onClick name='Pass Thru'/> is matched if the user clicks the control button named Pass Thru (illustrated in Example 6-2).
<onEvent> is fired if an event is received by the driver instance that matches the criteria defined for this event. You can define the following criteria for the event.
type, which matches the type of the event.
subtype, which matches the subtype of the event.
id, which looks for an exact match of the ID.
ids, which looks for any event with any ID that matches from the list. The value of the attribute should be a comma separated list of IDs it's looking for.
data, to look for a match in the data field of the event.
<onInterval> is fired on a periodic basis. You define this element by specifying the frequency attribute. Set this attribute using a String value or using a number (int) to define the repeat interval to fire <onInterval> in seconds. For example, setting this attribute using a String value once sets <onInterval> to fire once upon startup.
Once you define when the task starts, you can then define what the task performs in the <action> element. Within the <action> element, you can define the following:
<audio> which plays an audio file.
<img> which shows a picture at a certain location.
<delay> to delay between frames.
<send> to send an event out to the system.
To configure a BarcodeDriver -based device, define the uri parameter as the connection to the lightstack. See "Setting the URI Parameters for Devices and Dispatchers".
Table 6-6 describes the RFID observation event returned by the BarcodeDriver.
The ConsoleDriver is a simulation driver that displays all of the events it receives to a graphical window, which includes the following views:
Event List -- Displays a list of all of the events received by a device since startup.
Details -- If you double-click an event displayed in the Event List view, the details specific to that event display in this window.
Send -- Select this view to send an event to the system. Before sending an event, ensure that the TYPE, SUBTYPE, and ID fields have data (that is, they are not empty). The TIME field displays current time stamp.
This driver is agnostic to event types and data. It only displays the events that it has received and sends any user input from the Send dialog. The user interface enables you to input event data and send it out for dispatching as if it had been generated by an actual device. Use this driver to monitor and debug the event flow in the system.
The Edge Echo Driver does not control any physical device; instead, this driver receives an instruction event, copies the event, and then sends it back out. This event has the same attributes as the original instruction event except for the Timestamp attribute, which you can configure to display the current time. The Oracle Sensor Edge Server processes the event generated by an instance of the Edge Echo Driver the same as any other event generated by a device: the event is filtered and then dispatched by the current dispatcher. See also "Viewing Event Data".
To configure an instance of the Edge Echo Driver driver, define the following parameters:
stamptime -- Enter true to set the Timestamp attribute of the event generated by the Edge Echo Driver instance to the current time.
logFileName -- Enter the location of the log file. This is a String value.
The Edge Simulator Driver generates events to simulate a real device. In general, you use the EdgeSimulator driver to test configurations and deployment designs; however, you can also use it for internal functional testing to see how events are processed throughout the system. The Edge Simulator Driver acts the same as any driver, except that instead of connecting to a physical device to read events, it takes parameters from an input file (such as Example 6-6) as instructions on when to generate fake events. This begins as soon as the device starts (which starts when the Oracle Sensor Edge Server starts).
Configuring an Edge Simulator Driver-based device requires that you define the device's FILENAME parameter by entering the name of this input file, which instructs the Edge Simulator Driver-based device how to generate fake events using the following instructions.
<EventList>
The <EventList> element defines a loop. This element is also the main block that groups all of the other instructions together. <EventList> has one attribute, repeat, which must be present to control looping. The value for repeat must be a decimal number from 0 to LONG_MAX. To generate events only once, set the repeat attribute to 1. Setting repeat to n results in all instructions looping n times. Setting repeat to 0 disables the block and causes the parser to skip it.
Example 6-4 illustrates the syntax for generating two events, pausing, generating two more events, and then looping 20 times:
Example 6-4 Defining a Loop
<EventList repeat='20'> <Event> … </Event> <Event> … </Event> <EventInterval>…</ EventInterval> <Event> … </Event> <Event> … </Event> </EventList>
You can include any number of instructions inside the <EventList> element. The order in which they are defined is the order in which they are executed.
<EventInterval>
The <EventInterval> element instructs the Simulator to pause for a certain period of time before proceeding. This is usually used to throttle the data rate. A decimal number defines the time period, in milliseconds, to wait for before executing the next instruction. Chapter6 illustrates how to instruct the Simulator to wait for half a second between each event and three seconds between loops:
Example 6-5 The <EventInterval> Element
<EventList repeat='20'> <Event> … </Event> <EventInterval>500</ EventInterval> <Event> … </Event> <EventInterval>500</ EventInterval> <Event> … </Event> <EventInterval>3000</ EventInterval> </EventList>
<Event>
The <Event> element tells the Simulator to send an event. The child elements (described in Table 6-7) control the event's fields.
Table 6-7 Event Elements for the Simulator
| Event Field | Value |
|---|---|
|
|
The number value that corresponds to the type of event. |
|
|
The number value for the subtype. For example, the subtype value in Example 6-6 corresponds with a General Instruction Event, which is an event sent by application or a device to tell a specific device to perform an operation. In Example 6-6, the value of 1 turns on the device. |
|
|
The text value of this field identifies a tag (that is, a read or target) to an event instruction. In Example 6-6, one of the |
|
|
The tag data. This is an optional field. |
|
|
The name of the device or application that generates the event. The |
Example 6-6 illustrates an input file which includes two groups of events: the first one runs only once and the second runs 20 times.
Example 6-6 Simulator Input File
<EdgeEventSimulation>
<EventList repeat='1'>
<Event>
<type>100</type>
<subtype>1</subtype>
<id>03ffff045679</id>
<data>No Data</data>
<deviceName>My Device</deviceName>
</Event>
<EventInterval>500</ EventInterval>
<Event>
<type>100</type>
<subtype>1</subtype>
<id>03ffff045680</id>
<data>No Data</data>
<deviceName>My Device</deviceName>
</Event>
<EventInterval>3000</ EventInterval>
</EventList>
<EventList repeat='20'>
<Event>
<type>100</type>
<subtype>1</subtype>
<id>04ffff045679</id>
<data>No Data</data>
<deviceName>My Device</deviceName>
</Event>
<EventInterval>500</ EventInterval>
<Event>
<type>100</type>
<subtype>1</subtype>
<id>04ffff045680</id>
<data>No Data</data>
<deviceName>My Device</deviceName>
</Event>
</EventList>
</EdgeEventSimulation>
Although the format of the Event Type is fixed, you can extend the Event Type by mapping its fields to different meanings depending on the type of event.
The HtmlDriver is a display driver that enables you to display a window on either the Oracle Sensor Edge Server screen or to connect to remote servers to display HTML content. Use the HtmlDriver for applications that push data to display complex status or messages on graphical displays.
The HtmlDriver includes the Display Server (which is included in htmlDriver.jar), which enables display windows on remote servers. The Display Server runs as a Java process that waits for a network connection from the HtmlDriver instance. You can set up any number of Display Servers on a network. You must note the IP or hostname of the machines running the Display Server processes. More than one Display Server can run on the same machine provided that each Display Server is assigned to a different port.
|
Note: JDK 1.3 or higher must be installed on the machine andjava.exe is in the path.
|
To install the display server on a machine:
Copy htmlDriver.jar.
Extract the files to a local directory. For example, create a directory called displayServer and run jar xf htmlDriver.jar.
Navigate to the classes directory (cd classes).
Run the DisplayServer application using
java oracle.edge.impl.driver.HtmlDriver <port> [title] [x] [y] [width] [height] [showHistory]
Where:
<port> specifies the TCP/IP port on which the Display Server listens. The port cannot already be in use. This is a required parameter.
[title] is an optional text string that names the window.
[x] is the display window's x position on the screen.
[y] is the display windows's y position on the screen.
[width] is the width of the window. If set to 0, then the window uses the screen width.
[height] is the height of the window. If set to 0, then the window uses the screen height.
[showHistory] -- If set to true, then a small list displays at the top of the window showing all of the previously shown documents. Using this window enables users to manually scroll back to the last displayed document.
For example, to run the Display Server on your desktop using port 8999 with a full-screen window, run:
java oracle.edge.impl.driver.HtmlDriver 8999 "My Window" 0 0 0 0 false
|
Note: This command contains quote strings that have spaces. Refer to the shell documentation. |
To configure an HtmlDriver instance to enable display on remote servers, define the following parameters:
Define the serverlist parameter by entering a comma-separated list of Display Servers that this driver instance can contact. The String value for this parameter is in the following format:
<hostname or IP>:<port>,...
To provide security, you must list each Display Server.
Enter the TCP/IP port on which the Display Server listens. This port cannot already be in use on the machine.
If you do not define the serverList parameter, then the instance displays on a local window at the Oracle Sensor Edge Server's display. Running the instance on the local window any does not require Display Servers.
To display the instance on the local window:
Define the display window by first entering a name for the window in the title field and then enter a boolean (true or false) in the ShowHistory field to display a window of viewed pages.
Set the dimensions of the window by entering int values the following parameters:
x -- The x position of the window on the screen, in pixels.
y -- The y position of the window on the screen, in pixels.
Enter the width and height of the window, in pixels. Entering 0 sets the window to the screen's height and width.
Table 6-8 describes the events supported by the HtmlDriver.
Table 6-8 Events Supported by the HrmlDriver
| Type | Subtype | Direction | Title | Description |
|---|---|---|---|---|
|
210 |
1 |
From application (outbound) |
Display |
Display the HTML document embedded in the DATA field of the event. The ID is a number, starting from 0, that defines which server to send it to. This is the index of server as defined in the serverList parameter in the driver instance. |
|
210 |
2 |
From application (outbound) |
Print LPML Directly |
Display the HTML document referenced by the URL provided in the DATA field of the event. The ID is a number, starting from 0, that defines which server to send it to. This is the index of server as defined in the serverList parameter in the driver. |
The Intermec BRI Driver supports all of the RFID readers by Intermec that support BRI (Basic Reader Interface) and communicate with the Oracle Edge Sensor Server either though a serial or network (TCP/IP) connection. The Oracle Edge Sensor Server has been tested against the IF5 reader.
For more information, see http://www.intermec.com
Configuring an Intermec BRI Driver-based device, you must define the parameters described in Table 6-9.
Table 6-9 Parameter Values for an Intermec BRI Driver Based Device
| Parameter Name | Value Type | Description |
|---|---|---|
|
URI |
String |
The connection identifier that indicates the connection type and connection parameters as described in "Setting the URI Parameters for Devices and Dispatchers". |
|
Status Query Response Timeout |
Int |
The timeout for waiting response from status query. The value set for the timeout must be lower than that set for the Status Query Interval parameter. |
|
Status Query Interval |
Int |
The time, in milliseconds, between two consecutive status inquiries. |
|
AntennaIds |
String |
The identifier(s) for connected antennae. Use a comma (,) to separate multiple identifiers for multiple antennae. |
|
DataFieldLength |
Int |
The size of the data field to be retrieved in terms of the number of bytes. 0 means no data fields need to be retrieved. |
|
DataFieldValueType |
String |
Specify one of the three value types for the data field:
This parameter is effective only if the DataFieldLength parameter is larger than 0. |
|
TagType |
N/A |
Specifies the types of tags to read: Options include:
|
Observation events are events that are generated by the driver and are dispatched out to the system. Table 6-4 lists the events generated by the Intermec BRI Driver.
Table 6-10 Observation Events Generated by the Intermec BRI Driver
| Type | Subtype | TagID | Data | Description |
|---|---|---|---|---|
|
200 |
Various |
Tag ID |
The data field (payload) stored in a tag. |
General tag observation event. |
|
1 |
0 |
Null |
"alive or dead" |
An event using a data property to indicate whether the device is alive or not. |
|
1 |
0 |
Null |
"dis" |
An event indicating a successful device startup operation. |
|
1 |
2 |
Null |
"dif" |
An event indicating a failed device startup operation. |
|
1 |
0 |
Null |
"dss" |
An event indicating an successful device stop operation. |
|
1 |
2 |
Null |
"dsf" |
An event indicating a failed device stop operation. |
|
1 |
2 |
Null |
"drf" |
An event indicating a failed event-receiving operation. |
|
1 |
0 or 2 |
Null |
<callResults> <callResult name="write-tag"> <code>0/1</code> <message/> </callResults> |
An event indicating a successful or failed tag-writing operation. |
Applications send devices instruction events to tell them to perform certain tasks. Table 6-5 describes the instruction event accepted by the Intermec BRI Driver.
Table 6-11 Instruction Event Sent by the Intermec BRI Driver
| Type | Subtype | TagID | Data | Description |
|---|---|---|---|---|
|
101 |
0 |
Null |
<methodCalls>
<methodCall name="write-tag"">
<params>
<param name='tagid'>%TAGID%</param>
<param name='tagdata'>%TAGDATA%</param>
Name='tagdataVauleType'> (String/HexString)</param>
</params>
</methodCall>
</methodCalls>
|
Write data to a tag identified by the specified tag ID. |
For more information, see http://www.intermec.com
Requirements
Creating an Intermec Reader Driver-based device requires the following components, which are bundled and shipped with the Intermec Reader driver:
IntelliTag IDK
The IntelliTag IDK (the IDK) is a set of Intermec-supported software libraries and tools. This library, which is the only supported method of communicating with Intermec devices, is supported only on the Windows 32 platform (that is, Windows 2000 and Windows XP). The IntelligTag IDK is available at
http://www.oracle.com/technology/products/iaswe/edge_server/extensions.html
Intermec Reader Driver
Configuring an Intermec Reader Driver-based device requires that you define the following parameters:
Set IPAddress to the hostname or IP address. If it runs on the same machine as the Edge Server, enter 127.0.0.1.
Set PortNo to the port number. The default is 6666.
Set the AntennaSeqIDList to the list of identifiers for each antenna.
Set AntennaMappedDeviceNameList to the list of mapped device names associated with each antenna.
LPML (Label Printing Markup Language) is an XML-based printer language defined by Oracle Corp. which is supported by label printers and printer server vendors. The LpmlDriver supports any printer or print server systems that support the LPML language and binding.
To configure a device based on the LpmlDriver, you must define the parameters of the device as follows:
URI -- The string used by the transport layer to connect to the printer. See "Setting the URI Parameters for Devices and Dispatchers".
Selecting Response Mode sets the device to expect that the printer its communicating with supports LPML response messages. As a result, the device waits for responses from the printer for each print job.
Selecting Batch Mode instructs the printer to send out as many jobs as possible in a single connection session before waiting for responses. This option enables the device to use a windowing algorithm instead of a half duplex communication mode with the printer.
If Batch Mode is selected, set the ReadTimeOut parameter to the amount of time (in milliseconds) to wait before considering that the printer failed to respond.
maxRetryCount -- The number of times to retry a printing job. This is an int value.
PerJobDelay -- The interval (in seconds) to delay between each print job. This is an int value.
Table 6-12 lists the Printer Response observation event generated by the LpmlDriver, which are dispatched to the system.
Table 6-12 Printer Response Observation Event Generated by the LpmlDriver
| Type | Subtype | Tag ID | Data | Description |
|---|---|---|---|---|
|
210 |
2 |
Not used. |
LPML response message |
The response message from either the printer (if Response Mode is selected), or from the driver itself to tell the sender the result of the print job. The correlationId and sourceName fields are taken from the original print job request. |
Instructions are events sent to a driver by an application the command the driver to perform a certain task. Table 6-13 describes the instruction event accepted by the LpmlDriver.
The Matrics Driver supports the Matrics Readers made by Symbol Technologies that communicate with the Oracle Sensor Edge Server using a serial or network (TCP/IP) connection.
Configuring a Matrics Driver-based device requires that you define the following parameters:
URI -- The connection type and connection identifiers. See "Setting the URI Parameters for Devices and Dispatchers".
Status Query Interval -- The time (in milliseconds) between to consecutive status queries. This is an int value.
Status Query Response Timeout -- The time (in milliseconds) for the timeout for the waiting response from the status query. This int value must be less than the value set for the Status Query Interval parameter.
AntennaIds -- The connected antennae. Use a comma (,) to separate entries.
Node Address -- The node address for the reader connected under RS485. The address must match the value in the Matrics administration console.
Observation events are events that are generated by the driver and are dispatched out to the system. Table 6-4 lists the events generated by the Matrics Driver.
Table 6-14 Observation Events Generated by the Matrics Driver
| Type | Subtype | TagID | Data | Description |
|---|---|---|---|---|
|
200 |
Various |
Tag ID |
The data field (payload) stored in a tag. |
General tag observation event. |
|
1 |
0 |
Null |
"alive or dead" |
An event using a data property to indicate whether the device is alive or not. |
|
1 |
0 |
Null |
"dis" |
An event indicating a successful device startup operation. |
|
1 |
2 |
Null |
"dif" |
An event indicating a failed device startup operation. |
|
1 |
0 |
Null |
"dss" |
An event indicating an successful device stop operation. |
|
1 |
2 |
Null |
"dsf" |
An event indicating a failed device stop operation. |
|
1 |
2 |
Null |
"drf" |
An event indicating a failed event-receiving operation. |
|
1 |
0 or 2 |
Null |
<callResults> <callResult name="write-tag"> <code>0/1</code> <message/> </callResults> |
An event indicating a successful or failed tag-writing operation. |
Applications send devices instruction events to tell them to perform certain tasks. Table 6-5 lists the instruction events accepted by the Matrics Driver and their usage.
Table 6-15 Instruction Event Sent by the Matrics Driver
| Type | Subtype | TagID | Data | Description |
|---|---|---|---|---|
|
101 |
0 |
Null |
<methodCalls>
<methodCall name="write-tag"">
<params>
<param name='tagid'>%TAGID%</param>
<param name='tagdata'>%TAGDATA%</param>
</params>
</methodCall>
</methodCalls>
|
Write data to a tag identified by the specified tag ID. |
The Patlite series of lightstacks supported by the PatliteDriver do not generate events, but instead act as indicator lights and signals. Sending events to Patlite lightstacks and trees turns on lights or causes them to blink for certain intervals.
To configure a device based on the PatliteDriver, define the URI parameter. See "Setting the URI Parameters for Devices and Dispatchers".
To configure a device based on the Prolite Driver, define the URI parameter by entering the connection URI. See "Setting the URI Parameters for Devices and Dispatchers".
The Samsys Driver supports the SAMSys MP320 2.7 EPC reader that communicates with the Oracle Sensor Edge Server either through a serial or network (TCP/IP) connection. The Samsys MP9320 2.7 EPC reader, which supports CHUMP (Cookie-handling UDP Message Protocol), has been tested against the Oracle Edge Sensor Server.
Configure a Samsys Reader Driver-based device by defining the following parameters:
Connection Identifier -- The connection type and connection identifiers. See "Setting the URI Parameters for Devices and Dispatchers".
Status Query Interval -- Enter the time (in milliseconds) between to consecutive status queries. This is an int value.
Status Query Response Timeout -- The amount of time of the timeout for the waiting response from the status query. This int value must be less than the value set for the Status Query Interval parameter.
Tag Scan Mode -- Specify either autonomous or polling. Selecting autonomous mode sets the MP9320 2.7 EPC reader to notify the device whenever it scans tags. Selecting polling mode sets the MP9320 2.7 EPC reader to scan tags only if the driver sends out the get-tag-list command.
Tag Type -- Specify the type of tag for the device to read, such as EPC1, EPC0, IS18gA, IS186B, STG.
AntennaIds -- The connected antennae. Use a comma (,) to separate entries.
Observation events are events that are generated by the driver and are dispatched out to the system. Table 6-4 lists the events generated by the Samsys Driver.
Table 6-16 Observation Events Generated by the Samsys Driver
| Type | Subtype | TagID | Data | Description |
|---|---|---|---|---|
|
200 |
Various |
Tag ID |
The data field (payload) stored in a tag. |
General tag observation event. |
|
1 |
0 |
Null |
"alive or dead" |
Each event using data property to indicate whether the device is alive or not. |
|
1 |
0 |
Null |
"dis" |
An event indicating a successful device startup operation. |
|
1 |
2 |
Null |
"dif" |
An event indicating a failed device startup operation. |
|
1 |
0 |
Null |
"dss" |
An event indicating an successful device stop operation. |
|
1 |
2 |
Null |
"dsf" |
An event indicating a failed device stop operation. |
|
1 |
2 |
Null |
"drf" |
An event indicating a failed event-receiving operation. |
|
1 |
0 or 2 |
Null |
<callResults> <callResult> <callResult name="write-tag"> <code>0/1</code> <message/> </callResult> </callResults> |
An event indicating a successful or failed tag-writing operation. |
Applications send devices instruction events to tell them to perform certain tasks. Table 6-5 lists the instruction event accepted by the Samsys Driver.
Table 6-17 Instruction Event Accepted by the Samsys Driver
| Type | Subtype | TagID | Data | Description |
|---|---|---|---|---|
|
101 |
0 |
Null |
<methodCalls>
<methodCall name="write-tag"">
<params>
<param name='tagid'>%TAGID%</param>
<param name='tagdata'>%TAGDATA%</param>
</params>
</methodCall>
</methodCalls>
|
Write data to a tag identified by the specified tag ID. |
The SimpleAudioDriver accepts instruction events and enables applications to use the Oracle Sensor Edge Server machine's sound card to play any .wav file. For security reasons, only files in a specific directory (defined in the audioFiles parameter) are played.
|
Note: The driver uses thesun.audio package that ships with any standard JRE or JDK. The package only requires special configuration for special setups, such as multiple sounds cards in one machine. For such cases, refer to the JDK documentation from Sun Microsystems, Inc.
|
To configure a Simple Audio Driver instance, define the audioFiles path parameter by providing the path (a String value) to the audio files. The path is an absolute or relative path with no trailing slashes. Because the path is relative to the edge extension classes directory, you must traverse from this directory if you enter a relative path. For example, to locate the audio files on the Oracle Sensor Edge Server home path (meaning the sample level, the locale for such directories as config or persistent), use:
..\..\edge\audio
This value sets the parameter to use the audio directory on top of the Oracle Sensor Edge Server home path.
|
Tip: Using an absolute path provides greater security than the relative path. |
Example 6-6 describes Event Type 207 (Audio), which is supported by the Simple Audio Driver.
Table 6-18 Event Type 207 (Audio)
| Type | Subtype | Direction | Title | Description |
|---|---|---|---|---|
|
207 |
1 |
From applications (outbound) |
Play Audio File |
Play audio jobs defined in the |
The XML file, which is embedded in the DATA field, uses the standard XML-RPC call format, and has the format described in Example 6-7.
Example 6-7 XML File Embedded in the DATA Field
<methodCalls>
<methodCall>
<params>
<param name='paramName'>paramValue</param>
</params>
</methodCall>
</methodCalls>
Where paramName is the name of the parameter, and paramValue is its value. <methodName> can be omitted since the Type and Subtype define this function. You can define paramName using fileName and url.
For security, the value defined by the fileName parameter is used as the name for the audio file. The fileName value cannot contain any extensions and the audio file must be a .wav file. For example, if the fileName parameter's value is defined as welcome (as in Example 6-8), then the audio file is called welcome.wav.
Example 6-8 XML File That Plays welcome.wav
<methodCalls>
<methodCall>
<params>
<param name=fileName'>welcome</param>
</params>
</methodCall>
</methodCalls>
The url parameter is the URL that points to the audio file.
|
Note: fileName and url parameters are mutually exclusive, meaning that you cannot define both parameters for the same call. If both parameters are defined, then only the latter parameter is used.
|
The Tyco Reader Driver supports all readers made by Tyco readers by Sensormatic that communicate with the Oracle Sensor Edge Server either through a serial or network (TCP/IP) connection.
Configuring a Tyco Reader Driver-based device requires that you define the following parameters:
Connection Identifier -- The connection type and connection identifiers. See "Setting the URI Parameters for Devices and Dispatchers".
Data Collection Timeout -- The timeout (in milliseconds) for collecting data to the physical device. This is an int value.
Status Query Interval -- The time (in milliseconds) between to consecutive status queries. This is an int value.
Observation events are events that are generated by the driver and are dispatched out to the system. Table 6-4 lists the events generated by the Tyco Reader Driver.
Table 6-19 Observation Events Generated by the Tyco Reader Driver
| Type | Subtype | TagID | Data | Description |
|---|---|---|---|---|
|
200 |
Various |
Tag ID |
The data field (payload) stored in a tag. |
General tag observation event. |
|
1 |
0 |
Null |
"alive or dead" |
Each event using data property to indicate whether the device is alive or not. |
|
1 |
0 |
Null |
"dis" |
An event indicating a successful device startup operation. |
|
1 |
2 |
Null |
"dif" |
An event indicating a failed device startup operation. |
|
1 |
0 |
Null |
"dss" |
An event indicating an successful device stop operation. |
|
1 |
2 |
Null |
"dsf" |
An event indicating a failed device stop operation. |
|
1 |
2 |
Null |
"drf" |
An event indicating a failed event-receiving operation. |
|
1 |
0 or 2 |
Null |
<callResults> <callResult> <callResult name="write-tag"> <code>0/1</code> <message/> </callResult> </callResults> |
An event indicating a successful or failed tag-writing operation. |
Applications instruction events to devices to tell them to perform certain tasks. Table 6-5 lists the instruction event accepted by the Tyco Reader Driver.
Table 6-20 RFID Instruction Event Accepted by the Tyco Reader Driver
| Type | Subtype | TagID | Data | Description |
|---|---|---|---|---|
|
101 |
0 |
Null |
<methodCalls>
<methodCall name="write-tag"">
<params>
<param name='tagid'>%TAGID%</param>
<param name='tagdata'>%TAGDATA%</param>
<param name='antennaID'>%ANTENNA_ID%</param>
</params>
<param name='protocol'>EPCO/CC915/CC1356/ISO15693/ISO18000-6B</param>
</params>
</methodCall>
</methodCalls>
|
Write data to a tag identified by the specified tag ID. |
The following sections describe how the pre-seeded filters generate events and their configuration parameters:
A Check Tag is any normal tag used to test if the device (in this case, a reader) is reading tags. Because the Check Tag itself should be physically located within the field of the reader, it should always be read; when other tags move through the field of the reader, the device also reads the Check Tag in conjunction with them.
The Check Tag ID Filter ensures that the device reads a Check Tag periodically. Using this filter enables you to check the status of a device, its corresponding reader, and attached antennae. Because the Check Tag ID Filter is used solely for diagnostic purposes, it does not provide any events for dispatching to client devices. Instead, this filter generates an event if it does not detect that the device has read a Check Tag for a specified period of time.
|
Note: You can apply the Check Tag ID Filter only to devices. |
Table 6-21 describes the parameters (and associated values) of the Check Tag ID filter.
Table 6-21 Parameters of the Check Tag ID Filter
| Name | Value Type | Description |
|---|---|---|
|
Check Tag Id |
A |
The tag ID of the Check Tag, which is the ID that the filter searches for to see if the tag is being read. |
|
Tag Check Time Window |
An |
The period of time, in milliseconds, after which an event is generated if the filter has not seen the specified Check Tag. |
To define the parameters for the Check Tag ID Filter, you must note the ID of the Check Tag itself (which must be placed within the field of the reading device). Enter this ID as the String value of Check Tag Id. If the filter does not detect that a device has read a Check Tag bearing the specified ID for the period defined in the Tag Check Time Window parameter, it generates an event. Table 6-22 describes the signature of the generated event.
Table 6-22 The Event Signature of the Check Tag ID Filter
| Event Field | Value |
|---|---|
|
|
This field identifies the originator of the event. This is an optional field; its value is set by the client. |
|
|
The client sets the value for this field, which is used for message responses to a particular client (such as checking if a device functions). Any message sent back by the client has the same ID. This is an optional field. |
|
|
The name of the site that generated this event. |
|
|
The name of the device that generated this event. |
|
|
The time that the filter generated this event. |
|
|
A Message Event (type 1). Note: Applications should subscribe to this message type for notifications of when devices fail. |
|
|
Error report (subtype 2) |
|
|
The ID of the Check Tag (this is the value defined in the filter's Check Tag Id parameter). |
|
|
An additional error message (if any). |
The Cross-Reader Redundant Filter blocks redundant events that are sent from the devices of a device group and does not generate any events. This filter considers events redundant if it finds they have the same tag ID. The filtering occurs during a window of time corresponding to a driver read cycle.
The Cross-Reader Redundant Filter is for group-level filtering only; it performs no functions if applied to a device. This filter has no parameters to configure.
The Debug Filter traces events passing through the system. Upon receiving events from its associated device, this filter writes events to a log file. This filter has a single parameter called Event Output File. To define this parameter, enter the full path of the log file to which you want the Debug Filter to write events. (The server must make this file writable.) The format of the Debug Filter's output is as follows:
"Devicename: <devicename> Type: <type> Subtype: <subtype> EventTime: <time>TagIds:<tagid(,tagid)*>Data:<dat(,data)*>\n"
Each event is on a separate line; each line is separated by a newline character (LF or CRLF, depending on the operating system). The <time> value is a long as returned by the time(2) call.
This filter can only be attached to a device, not to a device group. This filter has no parameters to configure.
The Javascript Filter enables you to write filter logic in a scripting language. Changes made to the source scripts are loaded dynamically, thus eliminating the need to restart the server or any components. This filter relies on an external JavaScript engine that executes the source script, such as Mozilla Rhino (http://www.mozilla.org/rhino/).
The JavaScript filter has a single parameter called scriptFileName. To define this parameter, enter the relative or full path name of the source script that the driver loads and monitors.
Writing the Source Script
The JavaScript Filter looks for functions in the source script to perform the processing. The functions are:
function filter(events) -- If specified, this function is called when the filter is asked to filter out the events. This method is only called if the filter is attached to a specific device. An array of events is passed in. You can modify the events within this array, remove them, or construct a new array from scratch. You must return the array of events that you want the system to continue to process. The parameter events are an array of edge events (oracle.edge.common.Event[]).
function groupFilter(events) -- This call is invoked when the device group calls the filter for filtering. This is only used if the filter is attached to a group instead of a single device. The parameter events are an array of edge events (oracle.edge.common.Event[]).
function instructionFilter(instruction) -- This is called when the system attempts to an instruction event to a device. You can modify the event, or return null if you want to block it all together. The parameter is a single event (oracle.edge.common.Event).
You can write any one of these functions. Other functions are ignored. The initialized block is called at filter startup time. The source script described in Example 6-9 prints all of the tag IDs that it encounters to the console.
The Movement Filter smooths out movement tracking using Real Time Location System (RTLS) observations by averaging out spikes or sudden motion changes from errors or interference. The Movement Filter calculates the distance between the current and previous locations. If the distance is less than the distance threshold, then the current event is filtered out.
The Movement Filter has one parameter, Distance Threshold. To define this parameter, enter a positive number (an int value) that indicates the smallest movement that should be reported.
Table 6-23 describes the signature of the Movement Filter.
Table 6-23 Signature of the Movement Filter
| Event Field | Value |
|---|---|
|
|
This field identifies the originator of the event. This is an optional field; its value is set by the client. |
|
|
The client sets the value for this field, which is used for message responses to a particular client (such as checking if a device functions). Any message sent back by the client has the same ID. This is an optional field. |
|
|
The name of the site that generated this event. |
|
|
The name of the device that generated this event. |
|
|
The time that the event was generated. |
|
|
An observation event. The range is 200-299. |
|
|
RTLS Moved (Subtype 4) |
|
|
The ID of the tag. |
|
|
The data payload of the tag. |
The Pallet Pass Thru Filter collects all of the events received during a specified period and sends them out as a single event. When a pallet or container passes through a gateway or through the field of transmission of a reader device, this filter generates a single event for all of these tags. This filter enables you to see what items a container or pallet may hold.
The Pallet Pass Thru Filter includes the following parameters:
Exit Event Threshold Time
To define this parameter, enter the time (an int value), in milliseconds, since the device last read a tag before it is considered to have moved out of the device's transmission field. The parameter settings, which range from 50 milliseconds to under two seconds, dictate the frequency (that is, the reader cycle) in which the device reports these "tag is seen" events. If you set this frequency too high, such as to two seconds, then the device may miss the tag altogether.
Event Collect Control Time
To define this parameter, enter the time (an int value), in milliseconds, for a device to complete a reading cycle of the tags included in a pallet or container before starting a new reading cycle. When this time elapses, the reading cycle concludes (that is, the device has read all of the new tags) and the Pallet Pass Thru Filter then generates an event with the following signature (described in Table 6-24).
Table 6-24 Signature of the Pallet Pass Thru Event
| Event Field | Value |
|---|---|
|
|
This field identifies the originator of the event. This is an optional field; its value is set by the client. |
|
|
The client sets the value for this field, which is used for message responses to a particular client (such as checking if a device functions). Any message sent back by the client has the same ID. This is an optional field. |
|
|
The name of the site that generated this event. |
|
|
The name of the device that generated this event. |
|
|
The time that the event was generated. |
|
|
An observation event. The range is 200-299. |
|
|
RFID Pallet Pass (Subtype 6) |
|
|
A comma-separated list of tag IDs. |
|
|
A comma-separated list of datum. |
The Pallet Shelf Filter collects all of the events received during a set interval and then sends them as a single event. This filter enables you identify when new containers or pallets holding many items enters an area, or exits the field or gateway of a device reader.
The Pallet Shelf Filter has the following parameters:
Exit Event Threshold Time
To define this parameter, enter the time (an int value), in milliseconds, from the last time that the device read the tag before it is considered to have moved out of the device's transmission field. The Pallet Shelf Filter silently clears its cache once the interval defined for the Exit Event Threshold Time parameter elapses and does not generate an event.
Event Collect Control Time
To define this parameter, enter the time (an int value), in milliseconds, for a device to complete a reading cycle for the tags of a pallet or container before starting a new reading cycle. When this time elapses, the reading cycle concludes (that is, the device has read all of the new tags) and the Pallet Shelf Filter then generates an event.
The Pallet Shelf Filter generates two events:
MULTIPLE IN FIELD Event
The Pallet Shelf Filter generates the MULTIPLE IN FIELD event when the device first detects the tags. This event has the following signature (described in Table 6-25):
Table 6-25 Signature of the MULTIPLE IN FIELD Event
| Event Field | Value |
|---|---|
|
|
This field identifies the originator of the event. This is an optional field; its value is set by the client. |
|
|
The client sets the value for this field, which is used for message responses to a particular client (such as checking if a device functions). Any message sent back by the client has the same ID. This is an optional field. |
|
|
The name of the site that generated this event. |
|
|
The name of the device reading the pallet or container that generated this event. |
|
|
The time that the Pallet Shelf Filter generated this event. |
|
|
An observation event. The range is 200-299. |
|
|
RFID Pallet In-Field (Subtype 4) |
|
|
A comma-separated list of tag IDs. |
|
|
A comma-separated list of datum. |
MULTIPLE OUT FIELD Event
The Pallet Shelf Filter generates the MULTIPLE OUT FIELD event when the interval defined for the Exit Event Threshold Time parameter elapses. This event has the following signature (described in Table 6-26):
Table 6-26 Signature of the MULTIPLE OUT FIELD Event
| Event Field | Value |
|---|---|
|
|
This field identifies the originator of the event. This is an optional field; its value is set by the client. |
|
|
The client sets the value for this field, which is used for message responses to a particular client (such as checking if a device functions). Any message sent back by the client has the same ID. This is an optional field. |
|
|
The name of the site generating this event. |
|
|
The name of the device reading the pallet or container that generated this event. |
|
|
The time that the Pallet Shelf Filter generated this event. |
|
|
An observation event. The range is 200-299. |
|
|
RFID Pallet Out Filed (Subtype 5) |
|
|
A comma-separated list of Tag IDs. |
|
|
A comma-separated list of datum. |
When a tag passes through the range of transmission, or through the gateway of a device reader, it generates a series of "tag is seen" events. The device reports these events periodically, starting when the tag enters the transmission field. The reporting stops when the tag moves out of the reader field.
Applications often do not require the series of events that a device reader generates; instead, these applications only need to know that a tag has passed through a device's gateway or range of transmission. The Pass Filter applies to such situations, as it reduces all of the "tag is seen" events into single events for each unique tag that passes through the field of a reader device.
The Pass Filter has one parameter, Exit Event Threshold Time. To define this parameter, enter the time (an int value), in milliseconds, since the device last read the tag before it is considered to have moved out of the device's transmission field. The parameter settings, which range from 50 milliseconds to under two seconds, dictate the frequency (that is, the reader cycle) in which the device reports these "tag is seen" events. If you set this frequency too high, such as to two seconds, then the device may miss the tag altogether.
When the device first reads a tag, the Pass Filter caches the tag's ID (tagid), notes the time that the tagid was read into the cache, and then immediately sends the pass-through event. The filter blocks subsequent reads for this cached tagid. Each time the filter receives a new read from the device, it updates the time that it read the tagid into the cache. If the sum of the caching time and the value set for Exit Event Threshold Time is less than the current time, then the Pass Filter clears the tagid from the cache. The next time the device reads this tag, the filter considers it a new event, caches its tagid and sends out a new pass-through event.
The pass through event has the following signature (described in Table 6-27).
Table 6-27 Signature of the Pass-Through Event
| Event Field | Value |
|---|---|
|
|
This field identifies the originator of the event. This is an optional field; its value is set by the client. |
|
|
The client sets the value for this field, which is used for message responses to a particular client (such as checking if a device functions). Any message sent back by the client has the same ID. This is an optional field. |
|
|
The name of the site that generated this event. |
|
|
The name of the device that generated this event. |
|
|
The time that the event was generated. |
|
|
An observation event. The range is 200-299. |
|
|
A pass-through event (subtype 3). |
|
|
The ID of the tag. |
|
|
The data payload of the tag. |
The Polygon Filter filters out all movement observations reported by Real Time Location System (RTLS) devices and generates events only if the tag moves in or out of any predefined polygons. The polygons are defined using a set of x, y coordinates that define the vertices and parenthesis. For example: ( (x,y), (x,y), ... ), (....), ... .
The Polygon Filter has a single parameter, PolygonCoordinates, which you define by entering a String value in the format of ((x1, y1), (x2, y2)...,(xn, yn)).
The Regex Filter performs a regular expression search that looks for tags to either remove or to allow to pass through the streams. This filter enables you to define a set of patterns for the filter to search for in any of the event's fields. When the filter finds matches to the search criteria, it allows the event to pass through the system; if it finds no matches, then it filters out the event. The RegexFilter is a generic filter and can work with any Event Type.
The Regex Filter has a single parameter called allow. To define this parameter, enter a regular expression (a String) for the events that are allowed to pass through the filter in the following format:
<field>~<pattern>&&<field>~<pattern>||...
Where <field> is the name of the event field that the filter matches. The filter supports the following fields:
TAGID
DATA
CORRELATIONID
SOURCENAME
TYPE
SUBTYPE
DEVICENAME
SITENAME
TIME
|
Note: the TIME field is converted to thetime() long value before it is compared to the <pattern>.
|
<pattern> is a standard regular expression, && is a AND connective, and || is a OR connective. For example, to enable the RegexFilter instance to look for all events with the Event Type 103 and a tag with first three digits matching 0FE, enter:
type~103&&tagid~^0FE
The Shelf Filter is a device-level filter that generates events when a tag is detected within the field of a reader or when the tag has left the field. Like the Pass Filter, the Shelf Filter has a single parameter, Exit Event Threshold Time. To define this parameter, enter the time (an int value), in milliseconds, since the device last read the tag before it is considered to have moved out of the device's transmission field. Unlike the Pass Filter, however, the Shelf Filter silently clears its cache once the interval defined for the Exit Event Threshold Time parameter elapses and does not generate an event.
The Shelf Filter generates two events:
IN FIELD Event
The Shelf Filter generates this event when the device first detects the tag. This event has the following signature (described in Table 6-28).
Table 6-28 Signature of the IN FIELD Event
| Event Field | Value |
|---|---|
|
|
This field identifies the originator of the event. This is an optional field; its value is set by the client. |
|
|
The client sets the value for this field, which is used for message responses to a particular client (such as checking if a device functions). Any message sent back by the client has the same ID. This is an optional field. |
|
|
The name of the site that generated this event. |
|
|
The name of the device that generated this event. |
|
|
The time that the Shelf Filter generated this event. |
|
|
An observation event. The range for observation events is 200-299. |
|
subtype |
An in-field event (subtype 2) |
|
|
The ID of the tag. |
|
|
The data payload of the tag. |
OUT FIELD Event
The Shelf Filter generates this event when the interval defined for the Exit Event Threshold Time parameter elapses. This event has the following signature (described in Table 6-29).
Table 6-29 Signature of the OUT FIELD Event
| Event Field | Value |
|---|---|
|
|
This field identifies the originator of the event. This is an optional field; its value is set by the client. |
|
|
The client sets the value for this field, which is used for message responses to a particular client (such as checking if a device functions). Any message sent back by the client has the same ID. This is an optional field. |
|
|
The name of the site that generated this event. |
|
|
The name of the device that generated this event. |
|
|
The time that the Shelf Filter generated this event. |
|
|
An observation event. The range for an obsevation event is 200-299. |
|
|
An out-field event (subtype 2). |
|
|
The ID of the tag. |
|
|
The data payload of the tag. |
When a device first detects the tag, the Shelf Filter caches the ID of the tag and then generates an IN FIELD event. At this point, the tag is read during every reader cycle. While the tag may not be read during some of these cycles, it is read during others. When the device does not read the tag consistently for a period longer than that designated for the Event Exit Threshold Time parameter, then the filter removes the tag's ID from the cache and generates an OUT FIELD event. The devices stops reading the tag once it passes from the field of the device.
The main output of the Oracle Sensor Edge Server is filtered data events. The devices and respective filters both normalize and minimize this event data. Out of the box, the Oracle Sensor Edge Sever delivers event data through the following dispatcher methods:
Web Services
HTTP/Post
EPC PML
Application Level Events (ALE)
Oracle Streams/Advanced Queueing
The following sections describe how to configure these dispatcher methods.
"Configuring the Dispatcher to Send Event Messages to a Web Service"
"Configuring the Dispatcher to Send Event Messages Through HTTP"
A client device or application can register a SOAP call which the Oracle Sensor Edge Server invokes when a new message must be delivered.
To configure the WebService Dispatcher to distribute event messages through Web Services, enter the service URL of the WSDL (Web Service Definition Language) document that describes the client call. This URL must point to the EndPoint (port) of the Web Service. For example, enter http://localhost:8888/wsdl/mytest.wsdl. This document must contain the portType of EdgeClientCallback and the call, processEvent, as its child element. Upon startup, the Oracle Sensor Edge Server attempts to connect and bind to the service defined in this WSDL document.
Configuring the dispatcher to route events to clients using HTTP 1.0 results in the Oracle Sensor Edge Server posting each event message to the client separately. Because the Oracle Sensor Edge Server performs these posts sequentially, if one post is blocked, then all following posts are also blocked.
To configure the Oracle Sensor Server to route events using HTTP define the following parameters:
URL -- Enter the URL of the servlet, JSP, or CGI to which the Oracle Sensor Edge Server posts event messages whenever they are dispatched. To configure this dispatcher, enter the URL in the following format:
http://hostname:port/serverPath
If the Oracle Sensor Edge Server uses the HTTP dispatcher, then the client interface must tell the Oracle Sensor Edge Server how (and when) to call it.
proxyServer -- Enter the proxy server IP or host name.
proxyPort -- Enter the proxy server port. For example, enter 80.
The PML Dispatcher posts events in the EPC PML format using the Transport Library for such protocols as HTTP, FTP, and FILE.
|
Note: PML is a legacy format used to report observations. |
To configure the Oracle Sensor Server to use the PML Dispatcher, define the destination URI. See "Setting the URI Parameters for Devices and Dispatchers".
The Template Dispatcher (also known as the EventFlowDispatcher), sends and receives events from different sources and processes them through a finite state machine configured using the eflow.xml configuration file. This dispatcher sends and receives both to and from HTTP, POJ, Web Services, HTTP, and direct data streams using the Transport Library.
To configure the Oracle Sensor Server to use the Template Dispatcher, enter the location of the eflow.xml file.
Use the ALEDispatcher with the ALE Web Services interface to notify any ALE subscribers when a report specification is satisfied.
The Null dispatcher, which is created by default, discards all of the events passed to it. These events are not saved or spooled. Use this dispatcher only if you want to prevent the Oracle Sensor Edge Server from dispatching events.
Configuring the Oracle Sensor Edge Server to use Oracle Streams and Advanced Queuing enables you to control how the edge dispatcher retrieves and distributes event messages. Unlike the Web Services, or HTTP dispatcher options, event messages dispatched using the Oracle Streams dispatcher do not have to be relayed directly to an entry point. The Oracle Streams dispatcher supports rule-based process and agent technologies. In addition, the Streams dispatcher only supports UTF-8 encoding.
|
Tips:
|
Event messages are data that is deposited to a staging area (an internal queue). This data, in turn, can be aggregated in different ways for different client devices and applications (the consumers of the event messages). Using Oracle Streams as the dispatcher, the Data and Event layer of the database, not the Oracle Sensor Edge Server or applications, determines what an event is and when it is generated. The Data and Event layer provides a rule-based process that determines the appropriate event message for each client device or application.
Once the event messages are captured and placed into the staging queue, the event message data can be processed through the Rules Evaluation Job, which takes event messages from the staging queue and then compares them to the Oracle Sensor Edge Server rule set. Each rule has an action, which is executed if the rule applies. These actions include a PL/SQL callback for propagating the event message to other queues which could then be consumed by other applications.
In addition to these rule-based actions, the Rules Evaluation Job invokes applications by calling the Sensor Data Repository (SDR), which receives sensor data from the Oracle Sensor Edge Server or from other sources. The SDR includes a set of archive tables that store all of the filtered sensor events in the system. For more information, see Chapter 4, "Using the Sensor Data Repository".
|
Note: Applications requiring raw, unfiltered event data that has not been processed by the rules can connect to the staging area using AQ notification. |
To configure the Streams Dispatcher, enter the maximum number of threads to create for processing outbound observations in the threadnum field. Because each thread holds a connection, this is also the number of connections to the Sensor Data Repository uses for outbound events (there is another connection used for in-bound events). 0 is an invalid value. See also "Manually Configuring Sensor Data Repository and Sensor Data Streams in Release 10.1.3".
