|
Oracle® Sensor Edge Server Administrator's Guide
10g Release 2 (10.1.2) B14455-02 |
|
 Previous |
 Next |
|
Oracle® Sensor Edge Server Administrator's Guide
10g Release 2 (10.1.2) B14455-02 |
|
|
Previous |
Next |
This chapter, through the following sections, describes how to configure the Oracle Sensor Edge Server to receive, filter, and dispatch data.
Section 1.2, "Overview of the Oracle Sensor Edge Server Configuration File"
Section 1.3, "Starting and Stopping the Oracle Sensor Edge Server"
Section 1.4, "Configuring the Dispatchers for an Oracle Sensor Edge Server"
The Oracle Sensor Edge Server enables enterprises to incorporate information received from sensors devices into their I.T. infrastructure and business applications by receiving event data from sensor devices and then normalizing this data by putting it in a common data format and filtering out excess information. The event data, which is now a normalized event message, is then sent to database applications.
To receive and process event data from sensor devices, the Oracle Edge Sesor Server uses driver and filter objects to receive, read events and then process the event data. The Oracle Edge Sensor Server then sends the processed event data on to applications using a dispatcher. Depending on the configuration of the Oracle Sensor Edge Server's dispatcher, an Oracle Sensor Edge Server client application receives event messages through database streams, JMS (Java Message Service), Web Services (SOAP), or HTTP. The payload of the message is always an event. For more information on dispatching events, refer to Section 1.4.
The drivers provided out of the box support the 9RE-001 by Alien Technology, the Penn, Delaware, and PCMCIA readers manufactured by Intermec and the PHE-3FB PC-Controlled Light indicator manufactured by Patlite Corporation. For more information on drivers, refer to Chapter 2, "Managing Drivers". For filtering event data, the Oracle Sensor Edge Server provides filters that perform not only such functions as device monitoring, event tracking, and data cleansing by blocking redundant events, but can also send events that signal when new containers or pallets enter or exit the field or gateway of a device reader, or enable you to see all of the tag IDs of items held in a container or on a pallet. For more information on the filters provided by the Oracle Sensor Edge Server, refer to Chapter 3, "Managing Filters".
You can change or further enhance the capabilities of the Oracle Sensor Edge Server by adding extensions: custom-built drivers, filters and dispatchers. You add the drivers, filters and dispatchers by downloading an Extension Archive file (a JAR file containing all of the class files as well as other related files) to the repository. For more information, refer to Chapter 4, "Managing Extensions".
For the Oracle Sensor Server to use extensions, however, you must create instances of these objects. For example, for a sensor to use a driver, you must create an instance of the driver object called a device instance. Similarly, for device instance to utilize a filter, you must create a filter instance of the filter object. When you assign a dispatcher as the current dispatcher used by the Oracle Sensor Edge Server, you create an instance of a dispatcher. For more information on the components of the Oracle Sensor Edge Server, refer to the Oracle Application Server Wireless Developer's Guide
|
Note: If you modify the devices, device groups, or current dispatchers (or modify the devices, device groups, or dispatchers in the template section ofedgeserver.xml), then you must stop and restart the Oracle Sensor Edge Server so that any changes can take effect. For more information on starting and stopping the Oracle Sensor Edge Server, refer to Section 1.3.
|
The Event type represents a message sent from one component of the Oracle Sensor Edge Server to another. These event messages are specific to each type of driver or filter. The Event type is divided into the following sections:
Header
The Header sections includes the routing headers and the message headers, which contain fields that designate the delivery of an event message. The routing fields include <sourceName> and <correlationID>. The message headers include the <siteName> and <deviceName> fields.
<sourceName>
This field identifies the originator of the event. This is an optional field, one set by the client.
<correlationId>
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 response sent back by the client will have the same ID. This is an optional field.
<siteName>
The site that originally generated the message.
<deviceName>
The name of the device or application that generates the event.
<time>
The date and time when the observation or message was created.
Type Info
The Type Info section contains the formatting information for the payload: the type and subtype of the event.
<type>
The number value that corresponds to the type of event. Table 1-1 describes the values of the <type> field. The Oracle Application Server Wireless Developer's Guide describes the values for the <type> field in further detail.
Table 1-1 Value Ranges for the <type> Field
| Range | Message Type |
|---|---|
|
0-99 |
System messages. The range of values includes:
|
|
100-199 |
Instructions or commands. The range of values includes:
|
|
200-299 |
Observations. The range of values includes:
|
|
500-599 |
Custom messages |
<subtype>
The number value for the subtype. For more information on Instruction Events, refer to the Oracle Application Server Wireless Developer's Guide
Payload
The Payload section, which is the event-specific section with the following fields:
<id>
The text value of this field identifies a tag (that is, a read or target) to an event instruction.
<data>
The tag data. This is an optional field.
You configure the Oracle Sensor Edge Server by editing its configuration file, edgeserver.xml. This file defines all of the parameters and runtime settings for the Oracle Sensor Edge Server. When the Oracle Sensor Edge Server first starts, it reads the file to setup all of the runtime data and loads all of the necessary components and extensions. edgeserver.xml is located at
ORACLE_HOME/edge/config/edgeserver.xml
|
Note: The Oracle Sensor Edge Server also stores its cache file at this location. |
Example 1-1 illustrates the basic structure of this XML file.
Example 1-1 Structure of edgeserver.xml
<EdgeServer>
<DispatcherList>
<Dispatcher>...</Dispatcher>
</DispatcherList>
<DriverList>
<Driver>...</Driver>
</DriverList>
<FilterList>
<Filter>...</Filter>
</FilterList>
<CurrentDispatcher>
<DispatcherName> ...</DispatcherName>
</CurrentDispatcher>
<DeviceGroups>
<DeviceGroup>
<DeviceList>
<Device>...</Device>
</DeviceList>
</DeviceGroup>
</DeviceGroups>
</EdgeServer>
The file's root element, <EdgeServer> encompasses high-level configurations (described in Table 1-2) and contains elements that enable you to configure not only the dispatchers, filters, and drivers available to the Oracle Sensor Edge Server, but the instances of these objects that enable the Oracle Sensor Edge Server to receive and process events.
Table 1-2 General Configuration for the Oracle Sensor Edge Server
| Element | Description |
|---|---|
|
|
The name of the Oracle Sensor Edge Server. |
|
|
The name of the site where the Oracle Sensor Edge Server resides. |
|
|
The mode for the internal queue. Values include:
|
<IsExtensionMonitorEnabled>
|
When set to true (enabled), the extension monitor can add extensions at runtime. |
|
|
Notify, Warning, Error |
The <DispatcherList>, <DriverList> and <FilterList> elements comprise the template section of the configuration file, where you define the filters, dispatchers and drivers that are available to the Oracle Sensor Edge Server.
Dispatchers, filters and drivers are extensions, downloadable components that add functionality to the Oracle Sensor Edge Server. By themselves, these extensions are not active components; they are not executed. For the Oracle Sensor Edge Server to use these components, you must instantiate an extension by creating an instance of it. For example, to connect a driver to a reader, you must create a device instance of the driver extension. Table 1-3 describes the components for extensions that can be configured. The instances of these extensions (described in Section 1.2.4.1) are called devices and filter instances. The instance of a dispatcher is the current dispatcher.
Table 1-3 Structure of the Extensions
| Component | Description |
|---|---|
|
ClassName |
The name of the class that implements the specific extension interface. This class is loaded first when an instance is created from an extension. |
|
Description |
A text description of the extension or instance. |
|
Name |
A unique name for the extension or instance. |
|
Parameters |
A list of parameters specific to the extension or instance. |
Defining Parameters for Extensions and Instances
Both extensions and their instances contain dynamic lists of parameter settings which are defined within the <Parameters> elements of the configuration file. These parameters are specific to the type of extension and can be configured for each instance. For extensions, the <Parameters> elements and its child, <Parameter> tell the Oracle Sensor Edge Server the default values of the parameters and which parameters (if any) are exposed.
<Parameter> requires the following fields:
id
An attribute with a unique identifier. Some of the tags in edgeserver.xml (including <Parameters>) require a unique identifier so that they can be referenced by other tags. The identifier is defined in the id attribute and must be unique across the configuration file (although they do not have to be consecutive). When adding new elements that do not have references, you do not have to manually add the value of the reference id attribute; the Oracle Sensor Edge Server automatically assigns a value once it starts.
|
Note: Entering an incorrect reference id might lead to incorrect behavior. |
name
The name of the attribute, unique within the <Parameters> tag.
defaultValue
The default value for the parameter. This is used as the initial value in any UI or when first creating the object
description
Text that describes the value (mostly for the user interface).
encrypted
Indicates whether the value for the parameter should be encrypted so that the value does not have to be stored in clear-text format.
isClearText
Enables the default value (and the value for the parameter instance) to be reset to clear-text format. If the encrypted parameter is set to true, then the clear-text format is read and then set to encrypted format the next time the Oracle Sensor Edge Server starts.
required
Indicates whether the parameter value is required.
valueType
The type attribute specifics the type to use for the value. It could be
string for string values
int for integer values
boolean for true or false values
double for a double-precision number
The <DispatcherList> element specifies all of the dispatcher extensions that are uploaded to the system and are available to the Oracle Sensor Edge Server. It contains an array of <Dispatcher>, which defines an uploaded dispatcher. There can only be one <DispatcherList> in the <EdgeServer> node. Each <Dispatcher> is an extension and is in the format described in Table 1-3.
The <DriverList> element defines all of the uploaded driver extensions. All supported drivers must be listed within this element. The <DriverList> contains a list of <Driver> elements. For the format of the <Driver> element, refer to Table 1-3. Only one <DriverList> can be defined in the system.
<CurrentDispatcher> defines which dispatcher the Oracle Sensor Edge Server uses as well as the dispatcher's parameters. This is the only instance object that is not defined in the <DeviceGroup> section (described in Section 1.2.4). An Oracle Sensor Edge Server can use only one dispatcher at a time. Even if you have only one dispatcher defined within <DispatcherList>, the Oracle Sensor Edge Server can use it only if it is defined within the <CurrentDispatcher> element. After you assign a dispatcher as current, you must stop and then start the Oracle Sensor Edge Server. For more information setting the current dispatcher method in edgeserver.xml, refer to Section 1.4.1. For information on starting and stopping the Oracle Sensor Edge Server, refer to Section 1.3.
Device groups are similar to the root or top-level directories of a file system. Because all devices (the instances of drivers) and filter instances must be part of a device group, you must create one or many device groups before you can connect devices and set up filters. You can group devices in terms of management if you want to treat them as a logical unit to manage, or you can group them by the type of filtering that they perform. For example, if you group devices by cross-reader filtering, then you create a group of related devices and then attach filters to that group.
The <DeviceGroups> section of the configuration file defines all the device groups in the system. All of the instances of devices and filters are defined within this element. The <DeviceGroups> element contains an array of <DeviceGroup> elements. Each <DeviceGroup> tag contains the following:
<Device>
One of many <Device> elements that can be defined in a device group. Each <Device> defines a device instance.
<EventCollectWaitTime>
The interval for the group to pull events out of the filtered window of events, in milliseconds.
<FilterInsts>
Defines the list of group filter instances
<IsDefault>
Set to false for all user groups
<Name>
The name of the device group
For more information on defining devices, refer to Section 1.5. For more information on creating filter instances, refer to Section 3.3.1.
Instance configurations include:
Instance Details
The name of the instance.
Instance Type
The type of the instance (device, filter instance, or current dispatcher) as well as a reference to the declaration of the component in the template section of edgeserver.xml. In Example 1-2, the <Extension> tag for the Itermec Device has the reference attribute set to 35 and refers to <Driver id="35">, the IntermecDevice driver defined in the <DriverList> element of edgeserver.xml.
Example 1-2 Extension Reference to a Driver
<Name>Intermec Device</Name> <DriverName>IntermecDevice</DriverName> <Extension Reference="35">/
Parameter Configurations
The parameters required by the instance. These parameters must also point to the declaration of the parameters for the component defined in the template section of edgeserver.xml.
The tag <ParameterInsts>, defines the parameters for an instance. The individual parameters are defined with the tag, <ParameterInst> (described in Example 1-3).
<ParameterInst> requires the following elements:
<Name>
The name of the parameter. The value must match the name attribute of the corresponding <Parameter> of the extension.
<ParameterMetaData>
The reference attribute must be set to the id of the corresponding parameter in the extension (which is defined within the <DispatcherList>, <DriverList>, or <FilterList> elements.)
<Value>
The value for the parameter for this instance.
The Oracle Sensor Edge Server starts by default when you start the Oracle Application Server Containers for J2EE instance (OC4J instance) and stops once you have stopped the OC4J instance. You can also start the Oracle Edge Sensor Server by running the runSensorEdgeServer.bat or runSensorEdgeServer.sh commands. If you modify the configuration file, then you must stop and restart the Oracle Sensor Edge Server. For information on starting and stopping the Oracle Sensor Edge Server after adding extensions, refer to Section 4.3.
|
Note: You must install JDK 1.4. or higher to run the Oracle Sensor Edge Server. |
To start the OC4J instance from a command line:
Start a command shell (on Windows, for example, use cmd.exe).
Navigate to ORACLE_HOME/j2ee/home.
Execute java -jar oc4j.jar to start the OC4J instance.
A message similar to the one illustrated in Example 1-4 displays if the Oracle Sensor Edge Server has been installed properly.
You can stop the Oracle Sensor Edge Server by using the OC4J administrative tools or you stop the OC4J instance itself from the command line. In either case, the Oracle Sensor Edge Server is notified and shuts down gracefully. To stop the OC4J instance from the command-line, send a kill signal to the OC4J instance. For example, on Windows, click Ctrl+C to kill the instance.
|
Tip: Refer to the Containers for J2EE User's Guide for information on other methods of starting or stopping an OC4J instance. |
In addition to starting the Oracle Sensor Edge Server by starting an OC4J instance, you can also start the Oracle Sensor Edge Server by running the following:
On Windows:
ORACLE_HOME\edge\runSensorEdgeServer.bat
On UNIX:
ORACLE_HOME/edge/runSensorEdgeServer.sh
If you do not provide the argument specifying the ORACLE_HOME, then the system prompts you with the following message:
Must provide the for this Sensor Edge Server.Usage: runSensorEdgeServer.bat ORACLE_HOMEORACLE_HOME
If you provided the ORACLE_HOME argument, then a message simular to the one described in Example 1-5 appears.
The <DispatcherList> element of the configuration file (described in Section 1.2.2) defines the dispatchers that have been uploaded to the Oracle Sensor Edge Server. For the Oracle Sensor Edge Server to use a dispatcher, you must create a dispatcher, an instance of an available dispatcher, by defining the <CurrentDispatcher> element (described in Section 1.4.1). An Oracle Sensor Edge Server can use only one dispatcher. By defining the elements within <CurrentDispatcher> you can direct the Oracle Sensor Edge Server to send event messages using Oracle Streams, Oracle's Java Message Service provider (OC4J JMS) remote Web Services or HTTP (to a client application).
To set the current dispatcher for the Oracle Sensor Edge Server:
Select from among the dispatchers defined within <DispatcherList>.
In <CurrentDispatcher>, change the element content of <DispatcherName> to the name of the dispatcher, which could be any one of the following:
Streams Dispatcher (Section 1.4.1.1)
JMS Dispatcher (Section 1.4.1.2)
HTTP Dispatcher (Section 1.4.1.3.
Web Services (Section 1.4.1.4)
NullDispatcher (Section 1.4.1.5).
Compare the definition of <Dispatcher> within <DispatcherList> to ensure that each <ParameterInst> within <CurrentDispatcher> corresponds with each <Parameter> defined within <Dispatcher>.
Save edgeserver.xml and restart the Oracle Sensor Edge Server. The server then loads the selected dispatcher upon startup.
Example 1-6 illustrates configuring the <CurrentDispatcher> elements for the Streams dispatcher.
Example 1-6 Configuring <CurrentDispatcher> in edgeserver.xml
<CurrentDispatcher id="76">
<DispatcherName>StreamsDispatcher</DispatcherName>
<Extension class="Dispatcher" reference="5"/>
<Name>StreamsDispatcher</Name>
<NeedReload>false</NeedReload>
<ParameterInsts id="77">
<ParameterInst id="78">
<Name>username</Name>
<ParameterMetaData reference="7"/>
<Value>edge</Value>
</ParameterInst>
<ParameterInst id="79">
<Name>password</Name>
<ParameterMetaData reference="8"/>
<Value>oracle</Value>
</ParameterInst>
<ParameterInst id="80">
<Name>url</Name>
<ParameterMetaData reference="9"/>
<Value>jdbc:oracle:thin:@(description=(address=(host=soclxs3db02)
(protocol=tcp)(port=9105))(connect_data=(sid=PRJ1)))</Value>
</ParameterInst>
</ParameterInsts>
</CurrentDispatcher>
Configuring the dispatcher as Oracle Streams and Advanced Queuing enables you to control how the dispatcher retrieves and distributes event messages. Unlike the OC4J JMS, 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 Oracle Streams dispatcher only supports UTF-8 encoding.
|
Tips:
|
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. For more informationon Oracle Sensor Edge Server Rule Set, refer to the Oracle Application Server Wireless Developer's Guide
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.
In addition to the these rule-based actions, the Rule Evaluation Job invokes applications by calling the Sensor Data Hub (SDH), which receives sensor data from the Oracle Sensor Edge Server or from other sources. The SDH includes the Sensor Data Archive, a set of archive tables that store all of the filtered sensor events in the system.
To configure the Streams dispatcher:
Within <CurrentDispatcher>, change the element content of <DispatcherName> to <StreamsDispatcher>.
Compare the attributes defined for the following connection information for the Streams staging area in the <ParameterInst> elements to those defined in the <Parameter> elements for the Streams Dispatcher:
url
The JDBC connection string to the database where the staging area resides. By default, this value is set to the OracleAS infrastructure database. Enter the URL to an application database providing optimal access and archiving of events and observations. The URL depends upon the driver type. For example, for a thin driver, enter
jdbc:oracle:thin@(description=(address=(host=<hostname>)<protocol=tcp)(port=<port>))(connect_data=(sid=<sid>)))
where <hostname> is the host name or IP of the database server, <port> is the port number for the listener (1521, by default) and <sid> is the service id of the instance.
username
The name of the user of the database where the staging area resides.
password
The password to the user of the database where the staging area resides.
Save the edgeserver.xml and restart the Oracle Sensor Edge Server. The server loads the Oracle Streams dispatcher upon startup.
|
Note: Applications requiring raw, unfiltered event data that has not been processed by the rules can connect to the staging area using either AQ notification or JMS. |
If you configure database streams as the event dispatcher method, you must perform the following post-installation steps:
Set up a database instance to run the Oracle Streams disptacher. This database instance holds the staging area for the Oracle Streams dispatcher, as well as its rules, queues, Sensor Data Archive (SDH), and other related data. You can use either the Standard or Enterprise Edition of the database as long as it is Version 9.2 or higher. Be sure to note the connect string and password. After you set up the database, you must set up the schema used by the Oracle Streams dispatcher.
|
Note: if the database instance is on a separate box, you must edit theORACLE_HOME/network/admin/tnsnames.ora file on the machine running the Oracle Sensor Edge Server or add the GDN to it.
|
Enter the database password.
Navigate to the SQL directory (such as ORACLE_HOME/edge/sql).
Use SQL*Plus to connect to the database (using the system account).
Run create_edg_user.sql to create a user permission.
Enter a password for the user. You can enter any password. Be sure to note the password.
Disconnect as system.
Reconnect as the user of the Oracle Sensor Edge Server using the password that you entered in Step 6.
Run edg_create_streams.sql.
Install the Sensor Data Hub (SDH) and then run edg_create_sdh.sql(as the EDGE user). The database includes a user called EDGE after you execute these scripts. All of the required schemas and data are created under that user. Background jobs start automatically.
OC4J JMS (OracleAS Containers for J2EE and Java Message Service), which is compatible with J2EE 1.3, is a Java Message Service based on Advanced Queuing (AQ) that provides guaranteed message delivery with auditing.
|
Note: In the current release, the OC4J JMS dispatcher configuration (that is, the JMS dispatcher) cannot send messages back to sensor devices. Only Oracle Streams supports this functionality. |
To enable event message dispatching using OC4J JMS, you must configure a JMS topic queue called edgeTopic to which the dispatcher posts new event messages. You must also specify a topic connection factory, edgeEventsConnectionFactory. To enable the Oracle Sensor Edge Server components to access this topic, you must configure the jms.xml file under the OC4J container. For more information on configuring the JMS queue, refer to Oracle Application Server Containers for J2EE Services Guide.
|
Note: Upon startup, the JMS dispatcher looks for theedgeTopic queue using the JNDI (Java Naming Directory Interface) service implemented by the OC4J container. If the dispatcher cannot locate edgeTopic, it returns an error and then exits.
|
To configure the jms.xml file under the OC4J container:
Note all of the OC4J JMS Server information, such as hostname, JMS username (typically admin), JMS password, and the RMI port information.
Navigate to ORACLE_HOME/j2ee/home/config.
Edit the jms.xml file by adding the following lines:
<topic-connection-factory host="<hostname>" location="jms/TopicConnectionFactory" password="<password>" port="<jmsport>" username="admin" /><topic name="jms/edgeTopic" location="jms/edgeTopic"> <description>The edge server event topic</description></topic>
Save jms.xml and then close it.
Start the Oracle Sensor Edge Server using the the userThreads option. For example: java -jar oc4j.jar -userThreads
To create a JMS dispatcher that enables the Oracle Sensor Edge Server to send event messages to the JMS topic queue, edgeTopic:
Within <CurrentDispatcher>, change the element content of <DispatcherName> to JMS Dispatcher.
Compare the <ParameterInst> elements with the <Parameter> attributes for the following:
provider
The URI of the OC4J instance where the edgeTopic queue is stored. This URI is used internally by OC4J ORMI to connect to the server. For example, enter ormi://oc4j.us.oracle.com.
username
The user name of the administrator of the OC4J instance where the edgeTopic queue is stored.
password
The password used by the administrator of the OC4J instance where the edgeTopic queue is stored.
ack
Set the acknowledgement mode to CLIENT_ACKNOWLEDGE or AUTO_ACKNOWLEDGE. The default mode is AUTO_ACKNOWLEDGE.
Save edgeserver.xml and restart the Oracle Sensor Edge Server. The server then loads the JMS Dispatcher upon startup.
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 Web Service dispatcher to distribute event messages through Web Services
Within <CurrentDispatcher>, change the element content of <DispatcherName> to WebService Dispatcher.
Compare the url attribute defined in <Parameter> elements for the WebService dispatcher with that defined in the <ParameterInst> element for the <CurrentDispatcher>. The url attribute must point to the EndPoint (port) of the Web Service. For example, enter http://localhost:8888/wsdl/mytest.wsdl.
The WSDL (Web Service Definition Language) document must contain the portType of EdgeClientCallback and the call, processEvent, as its child element. For more information about the message parameters of the WSDL and a sample of the WSDL document used for generating the Web Service stub, refer to the Oracle Application Server Wireless Developer's Guide.
Save edgeserver.xml and restart the Oracle Sensor Edge Server. The Oracle Sensor Edge Server then loads the WebService dispatcher upon startup.
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 set the HTTP dispatcher:
Within <CurrentDispatcher>, change the element content of <DispatcherName> to HTTP Dispatcher.
Compare the url attribute defined in <Parameter> elements for the HTTP Dispatcher with that defined in the <ParameterInst> element for the <CurrentDispatcher>.The value for this attribute is 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.
Save edgeserver.xml and restart the Oracle Sensor Edge Server. The server then loads the HTTP Dispatcher upon startup. For more information on the configuring the dispatcher to route events through HTTP, refer to the tutorial, Writing Sensor Based Applications Using JSP, on the Oracle Technology Network (http:/www.oracle.com/technology/).
Refer to the Oracle Application Server Wireless Developer's Guide for a description of the parameters posted by the Oracle Sensor Edge Server to the client application.
The Nulldispatcher 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.
To set the Nulldispatcher:
Within <CurrentDispatcher>, change the element content of <DispatcherName> to Nulldispatcher.
Save edgeserver.xml and restart the Oracle Sensor Edge Server. The Oracle Sensor Edge Server then loads the HTTP dispatcher upon startup.
To enable the Oracle Edge Sensor Server to use a driver for a reader or sensor, you must edit the <DeviceGroups> section of edgeserver.xml to create a device, an instance of the driver.
Locate the <DeviceGroup> to which to add the device. If needed, add a new <DeviceGroup> element. For more information on the children of the <DeviceGroup>, refer to Section 1.2.4.
Add a new <Device> section. (You can copy a <Device> section from an existing device to use as a template.)
Set the name of the device within the <Name> tag.
Set the element definition in the <DriverName> tag to the name of a driver listed in the <DriverList> section.
Within the <Extension> element, set the value of the reference attribute to that of the driver.
Set the <ParameterInsts> to match the attribute values set for the driver's <Parameters> element.
If needed, add a filter instance to this device by defining the <FilterInsts> section.
Save edgeserver.xml and restart the Oracle Sensor Edge Server to instantiate the device.
Example 1-7 illustrates configuring the Oracle Edge Sensor Server to use a device called stack 1, an instance of a driver called Edge Device Driver.
Example 1-7 Configuring a Device
<DeviceGroups>
<DeviceGroup>
<DeviceList>
<Device>
<Name>stack1</Name>
<DriverName>Edge Device Driver</DriverName>
<Extension reference="49"/>
<ParameterInsts>
<ParameterInst>
<Name>PortNo</Name>
<ParameterMetaData reference="51"/>
<Value>7878</Value>
</ParameterInst>
<ParameterInst>
<Name>IPAddress</Name>
<ParameterMetaData reference="52"/>
<Value>152.69.156.193</Value>
</ParameterInst>
</ParameterInsts>
<FilterInsts/>
</Device>
</DeviceList>
<EventCollectWaitTime>500</EventCollectWaitTime>
<FilterInsts id="108"/>
<IsDefault>true</IsDefault>
<IsSystem>true</IsSystem>
<Name>Unassigned</Name>
</DeviceGroup>
</DeviceGroups>
A filter instance is an instantiated object of a filter. Whenever a filter is applied to a device (or to a device group), a filter instance is created, enabling the device or device group to use the filter. Filter instances can be attached to either a specific device or to a device group. Some filters are written as group-level filters and can only be attached to a device group. Likewise, some filters are written only for device-level filtering and only function if they are attached to a specific device. Fore more information on creating filters and configuring edgeserver.xml to filter events at both the device group and device level, refer to Section 3.3.
To create a filter instance:
Within the <DeviceGroups>, locate the <Device> to which to add the filter instance.
Add a <FilterInst> element to the device's <FilterInsts> section.
For the <Extension> element, specify the name of the filter for the class attribute, and the id of the filter for the reference attribute.
Set the <ParameterInsts> to match the attribute values set for the filter's <Parameters> element.
Save edgeserver.xml and then restart the Oracle Sensor Edge Server.
Example 1-8 illustrates configuring a device to use a filter instance by defining the <FilterInsts> element. In this example, the PalletPassFilter has a <Sequence> value set a 1. The number specified within the <Sequence> tag determines the order in which filter instances are applied. For more information or setting the order of the filter instances, refer to Section 3.3.1.1.
Example 1-8 Configuring a Filter Instance for a Device
<FilterInsts>
<FilterInst>
<Sequence>1</Sequence>
<FilterName>PalletPassFilter</FilterName>
<Extension class="Filter" reference="50"/>
<ParameterInsts>
<ParameterInst>
<ParameterMetaData reference="52"/>
<Value>11</Value>
<Name>ExitEventThresholdTime</Name>
</ParameterInst>
<ParameterInst>
<ParameterMetaData reference="53"/>
<Value>12</Value>
<Name>EventCollectControlTime</Name>
</ParameterInst>
</ParameterInsts>
<NeedReload>false</NeedReload>
<Name>PalletPassFilter</Name>
</FilterInst>
</FilterInsts>
