|
Oracle® Application Server Wireless Administrator's Guide
10g Release 2 (10.1.2) B13820-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Wireless Administrator's Guide
10g Release 2 (10.1.2) B13820-02 |
|
|
Previous |
Next |
This chapter, through the following sections, describes how to use the Sensor Services tool.
Section 4.6, "Managing the Devices of an Edge Server Process"
Section 4.8, "Managing the Edge Dispatchers for an Oracle Sensor Edge Server Process"
The Oracle Sensor Edge Server enables enterprises to incorporate information from sensors into their I.T. infrastructure and business applications by receiving event data from sensor devices or applications and then normalizing this data by putting it in a common data format and stripping it of extraneous information using filters. The event data, which is now a normalized event message, is then sent to edge clients using a dispatcher. Depending on the configuration of the Oracle Sensor Edge Server's dispatcher, an Oracle Sensor Edge Server client receives event messages through database streams, JMS (Java Message Service), Web Services, or HTTP. The payload of the message is always an event.
The Sensor Services tab (Figure 4-1) enables you to manage how an Oracle Sensor Edge Server process receives, filters, and dispatches data.
For more information on Oracle Sensor Edge Server processes, see Section 3.6.1, "Managing and Configuring the Web-Based Applications".
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 sent back by the client has 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 4-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 4-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.
The Sensor Services tool includes the following tabs, which enable you to enhance or change the capabilities of the Oracle Sensor Edge Server processes by adding extensions (custom-built drivers, filters and dispatchers) to the repository and administer the Oracle Sensor Edge Server processes themselves.
Edge Servers
The Edge Servers tab (Figure 4-1), which opens by default when you access the Sensor Services tool, includes a table that lists the Oracle Sensor Edge Server processes. (Users granted the System Manager role create and configure these processes as well as start and stop them.) From this screen, you can view the current status (running or stopped) of an Oracle Sensor Edge Server processes, the Oracle Sensor Edge Server group to which it belongs and the node information for the process, the Oracle Home and Oracle Host of the process. The Oracle Home and Oracle Host values displayed for a process enable you to locate the installation of the Oracle Sensor Edge Server and distinguish between multiple instances of the Oracle Sensor Edge Server running on the same Oracle Host. Multiple Oracle Sensor Edge Server instances can be installed inside different Oracle Homes, but can run on the same Oracle Host.
|
Note: The Oracle Home and Host Name values only appear in the integrated mode. |
For more information on configuring the Oracle Sensor Edge Server processes, see Section 3.6.1, "Managing and Configuring the Web-Based Applications".
From this table, you assign devices to (or delete devices from) a selected Oracle Sensor Edge Server process by clicking the Manage Edge Devices button. Using the functions accessed through this button, you can also edit the properties of a device, such as the filters (that is, the instances of a filter object) that it uses. Likewise, clicking the Manage Edge Device Groups button enables you to add device groups (the logical groupings of Oracle Sensor Edge Server devices), to a selected Oracle Sensor Edge Server process, manage the device membership of the group, manage the filter assigned to the group, or delete the device group from the Oracle Sensor Edge Server process. The Manage Edge Dispatchers button enables you to assign a single dispatcher to a selected Oracle Sensor Edge Server process.
|
Note: If you modify the assignments of devices, device groups, or edge dispatchers of an Oracle Sensor Edge Server process, or modify the devices, device groups, or dispatchers themselves, then you must use the System Manager to stop and restart the Oracle Sensor Edge Server process to which these components belong, so that any changes can take effect. For more information on starting and stopping a standalone instance, see Section 3.6.2.1, "Creating a Standalone Process". |
Drivers
From the Drivers tab, you can add the drivers used by the devices belonging to an Edge Server process by uploading an Extension Archive file (a JAR file containing all of the class files as well as other related files of the driver) to the repository. For information on creating and managing drivers, see Section 4.3. See the Oracle Application Server Wireless Developer's Guide for more information on creating the Extension Archive file. The drivers are not executed. For the Oracle Sensor Edge Server to use a driver, you must create an instance of that driver called a device.
Filters
Similarly, the Filters tab also enables you to add a filter by uploading an Extension Archive file (a JAR file containing all of the class files as well as other related files of the filter) to the repository. These filters, which strain out unneeded event data, become available to Edge Server devices when you assign a filter to a device. Once a filter is assigned to a device, a filter instance (an object of the filter) is created. For information on creating and managing filters Section 4.4. See the Oracle Application Server Wireless Developer's Guide for more information on creating the Extension Archive File.
Dispatchers
Using the Dispatchers tab, you add a dispatcher, an object that forwards event data from the Oracle Sensor Edge Server, by uploading an Extension Archive file (a JAR file containing all of the class files as well as other related files of the dispatcher) to the repository. For an Oracle Sensor Edge Server process to have dispatcher functions, you must assign a dispatcher to a process. When you assign a dispatcher to an Oracle Sensor Edge Server process, you create an edge dispatcher (an instance of a dispatcher). For more information on creating and managing dispatchers, see Section 4.5. See the Oracle Application Server Wireless Developer's Guide for more information on creating the Extension Archive File.
|
Note: The drivers, filters, or dispatchers are available to all Oracle Sensor Edge Server processes in the repository after you upload them to the repository. |
After you log in to the OracleAS Wireless Tools, you select the Sensor Services Tool by clicking the Sensor Services tab.
|
Note: You must be granted either the Super-user or Oracle Sensor Edge Server Manager roles to access the Sensor Services tool. |
Drivers enable communication between a device and the Oracle Sensor Edge Server.
The driver browsing screen enables you to create, edit and delete drivers. The screen includes a list (Table 4-2) that organizes the drivers available for creating devices as follows:
Table 4-2 Elements of the Driver Browsing Screen
| Element | Description |
|---|---|
|
Name |
The name of the driver. |
|
Class Name |
The name of the driver implementation class. |
|
Version |
The version of the driver implementation. |
|
Description |
A description of the driver. |
|
Created Date |
The date that the driver was created. |
To add a driver, first click Create. The Create New Driver screen appears. Using the Import button, locate and then upload the driver's Extension Archive file to the repository. The Extension Archive file is a JAR file containing all of the class files and native binaries of the driver, as well as its properties files or static data files. In addition, the Extension Archive includes the Extension Archive Descriptor file, an XML file containing instructions for the Oracle Sensor Edge Server on loading and managing the driver.
Once the driver's Extension Archive file has been uploaded, the parameters specific to the uploaded file appear. (Unless the Extension Archive Descriptor file has been modified, the driver parameters are read-only.) Click Finish to complete the driver. The driver, which then appears in the browsing screen, can be used to create a device for the Oracle Sensor Edge Server process (described in Section 4.6).
|
Note: After you create a device, you must stop and restart the Oracle Sensor Edge Server process using the System Manager. For more information on starting and stopping a standalone instance, see Section 3.6.2.1, "Creating a Standalone Process". |
For information on the packaging an Extension Archive and the Device Management API, see the Oracle Application Server Wireless Developer's Guide
To delete a driver from the repository, first select a driver from the list and then click Delete. Deleting a driver also results in the deletion of the devices and filters using that driver.
OracleAS Wireless provides the following drivers out of the box:
EdgeSimulator (Section 4.3.3.1)
Version: 10.1.2
Alien (Section 4.3.3.2)
Model: 9RE-001
SDK Version: Alien SDK Version 2.1.0
Intermec (Section 4.3.3.3)
Models: Penn Reader, Delaware Reader, PCMCIA Reader
SDK Version: COM API Version 2.0
Patlite (Section 4.3.3.4)
Model: New PHE-3FB PC-Controlled Light
Protocol: PHE-3FB System Control Protocol
|
Note: The Intermec and Lightstack Device Controllers are available for download from Oracle Technology Network (http://www.oracle.com/technology/). |
The Simulator (the EdgeSimulator 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 EdgeSimulator 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 4-3) 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).
To configure the Simulator, enter the name of the input file, an XML file that tells the simulator how to generate the 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 4-1 illustrates the syntax for generating two events, pausing, generating two more events, and then looping 20 times:
Example 4-1 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. Section 4.3.3.1.1 illustrates how to instruct the Simulator to wait for half a second between each event and three seconds between loops:
Example 4-2 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 4-3) control the event's fields.
Table 4-3 Event Elements for the Simulator
| Event Field | Value |
|---|---|
|
|
The number value that corresponds to the type of event. Table 4-1 describes the values of the |
|
|
The number value for the subtype. For example, the subtype value in Example 4-3 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 4-3, the value of 1 turns on the device. Refer to the Oracle Application Server Wireless Developer's Guide for more information on Instruction Events. |
|
|
The text value of this field identifies a tag (that is, a read or target) to an event instruction. In Example 4-3, one of the |
|
|
The tag data. This is an optional field. |
|
|
The name of the device or application that generates the event. The |
Example 4-3 illustrates an input file which includes two groups of events: the first one runs only once and the second runs 20 times.
Example 4-3 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 AlienDevice driver supports all of the Alien Technology RFID readers. The ALR series of readers has been tested for this release of the Oracle Sensor Edge Server. Configuring the AlienDevice driver includes:
Finding the IP Address of the Alien RFID reader using the discoverer included in the RFID Gateway demo software provided by Alien Technology (Section 4.3.3.2.1).
Connecting the Alien RFID reader to a Web browser (Section 4.3.3.2.2).
Connecting the Alien RFID reader to the Oracle Edge Server by creating a device using the AlienDevice driver (Section 4.3.3.2.3).
By default, the Alien RFID reader uses DHCP (Dynamic Host Configuration Protocol) to get its IP address upon connection to the network. To discover the IP address without a DCHP server, use the RFID Gateway Demo software, available as part of the Nanoscanner Development Kit Releases, as follows:
Install the RFID Gateway Demo software.
Run the setup.exe (on the Alien Technology CD).
Select Install RFID Gateway Demo Software and follow the installation instructions. A folder called Alien RFID Gateway appears in the Programs folder of the Start menu.
When the RFID Gateway Demo Software is installed, use it to discover the IP address as follows:
Start the Alien RFID software by selecting Alien RFID Gateway (located in the Alien RFID Gateway folder of the Start menu). Upon startup, the Alien RFID Gateway software scans the serial ports of the computer and the network and displays a list of the Alien RFID readers and their IP addresses in the window that appears. For example, a reader might be listed as Alien RFID Reader@144.25.171.209.
Get the IP address of the Alien RFID Reader from the list. Using this address, you can configure the Alien RFID reader to the Web browser.
Because the Alien reader has a built-in Web Server, you can connect it to a Web browser by pointing the browser to the IP address of the Alien device, such as http://144.25.171.209. When prompted, enter a user name and password. Because the default settings should be correct, you can then create a device from the RFID reader, which is an instance of the device. For more information on creating devices, see Section 4.6.
To connect the Alien RFID reader to the Oracle Edge server, create a device for the Alien RFID reader:
Enter the name of the device. This is a mandatory parameter.
If needed, select an edge device group for this device from the Group list.
Select AlienDevice from the Driver list and then click Go. The parameters specific to the Alien Device driver appear.
Set IPAddress to 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.
Enter the port number used to communicate with the device (23 is the default).
Set the Username.
Set the Password.
Set the AntennaSeqIDList to the list of identifiers for each antenna.
Set AntennaMappedDeviceNameList to the list of mapped device names associated with each antenna.
Click Finish to complete the device.
Restart the Oracle Sensor Edge Server to receive events.
The IntermecDevice driver supports all of the RFID readers by Intermec, including the OEM Reader (Microwave, UHF), the PC Reader (PCMCIA), and the Fixed Reader (Serial or Ethernet). Other Intermec readers that support the Intellitag IDK also work with the IntermecDevice driver. For more information, refer to
Requirements
The IntermecDevice requires the following components, which are bundled and shipped with the Intermec 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
Oracle Sensor Edge Server Device Controller
The Oracle Sensor Edge Server Device Controller (the Device Controller) communicates with the local IDK API and exposes a network protocol that enables the Oracle Edge Server to communicate with the IDK.
IntermecDevice Driver
The IntermecDevice driver is the counterpart to the Device Controller, as it communicates with the Device Controller to drive the underlying devices.
The Oracle Sensor Edge Server can run on the same server as the Device Controller and the IDK, or on a separate server. Because the Intermec hardware exposes a Windows 32- based API, you must run the Oracle Sensor Edge Server on a Windows box or dedicate another Windows machine to only the Device Controller and the IDK.
Configuration Steps
Configuring the IntermecDevice driver involves the following tasks:
Installing the IDK (Section 4.3.3.3.1).
Registering Serial and PCMCIA readers (Section 4.3.3.3.2).
Configuring the Intermec readers (Section 4.3.3.3.3).
Using the Intermec tools to test the Intermec readers (Section 4.3.3.3.4).
Installing the Device Controller (Section 4.3.3.3.5).
Starting the Device Controller for the Intermec reader (Section 4.3.3.3.6).
Creating a device using the IntermecDevice driver to enable communication between the Oracle Sensor Edge Server and the Device Controller for the Intermec reader (Section 4.3.3.3.7).
To install the IDK and tools:
Connect the RFID reader to either a serial port, the PCMCIA slot of a PC, or a network segment. Connect a serial reader with a null modem (2/3 swap) cable. For more information, refer to the Intermec documentation.
Extract the content of the compressed file to a temporary directory, such as (c:\temp):ORACLE_HOME\edge\lib\IDK_Beta_4.0.1.tgz. (You can also download the latest version of the IDK from Intermec's Web site)
Install the IDK by running the install at C:\temp\setup.exe.
At the installer's first page, select Next.
In the Agreements page, read the license agreement and select Yes or No. Selecting No prevents you from proceeding.
On the next page, enter your name, the company name, and then select Anyone who uses this computer. Click Next.
Select a directory for the IDK. Use the default, if possible.
Select Typical for the setup type and then click Next.
Click Next to install the IDK and programs to the PC.
You must register devices for the Serial and PCMCIA readers. The following steps to register these devices to do not apply to Ethernet readers.
To register devices:
From the Start menu, select Intellitag IDK and then Device Registry Application.
Select the Register Readers tab. Be sure that the reader is connected.
Select an existing reader from the Select Reader drop-down list or enter the name of a new reader in the New Reader Name field and then click Register New Reader.
In the Port Name field, enter the name of the port that you use to connect to the reader.
Accept the default settings (unless you have changed the device).
Once you register a reader, you next configure it by editing the rfconfig.ini file. Open the rfconfig.ini file from the Start menu, select IntelliTag IDK and then rfconfig.ini. The file, which opens in Notepad is formatted as a standard Windows INI file. Each section of the file represents a new reader configuration, as illustrated by the [Reader_One] section in Example 4-4.
Example 4-4 rfconfig.ini
[Reader_One] RFID_SWTT_FILE_NAME=C:\Program Files\Intermec\Intellitag IDK\swtt.ini RFID_ATTR_TYPE=IT500 UAP Reader IT500_PORT_TYPE=TCPIP IT500_PORT_NUMBER=6543 IT500_CONNECT_TRIES=1 IT500_PORT_NAME=192.168.200.47 IT500_DEBUG_FILE_NAME="c:\IT500_Reader.log" IT500_ANTENNA_TRIES=5 IT500_ANTENNAS=1 2 0 0 0 0 0 0 IT500_READ_TRIES=5 IT500_WRITE_TRIES=5 IT500_INTERR_DEBUG=0 IT500_READER_DEBUG=0 dll_name=C:\Program Files\Intermec\Intellitag IDK\it500.dll IT500_IDENTIFY_TRIES=1 IT500_INITIALIZATION_TRIES=1 IT500_SIM_TAGS=5 IT500_IDENTIFY_READ_END_ADDR=17 IT500_HARDWARE_TYPE_CHECK=0 IT500_AUTOID_TIMEOUT=20
Although you can rename [Reader One]to any name, note this name for future reference. Modify (or verify) the following settings for the rfconfig.ini file:
IT500_PORT_TYPE
This parameter tells the API the type of connection to use, such as TCPIP for a network reader or ral for a serial or PCMCIA reader.
IT500_PORT_NAME
If it is a serial or PCMCIA reader, this parameter sets the name of the reader, that you registered (see Section 4.3.3.3.2). For network readers, this is the hostname or IP address of the reader.
IT500_PORT_NUMBER
This parameter specifies the TCP/IP port used to connect to the reader. The default setting is 6543. This parameter should only be defined for a network reader.
IT500_ANTENNAS
This is a mask for the antennae that are active and connected to the reader. The first digit corresponds to the first antenna. For example, if you have Antennas 1 and 3 connected to the reader and Antenna 1 is the first antenna, then set the parameter to IT500_ANTENNAS=1 0 3 0 0 0 0 0. For four antennae connected consecutively, set this parameter to T500_ANTENNAS=1 2 3 4 0 0 0 0.
Save the Notepad file and then close it after you complete the configuration.
To test the reader using Intermec tools:
From the Programs folder of the Start menu, click Intellitag IDK and then RF Tag Map.
Click Select to select a reader configuration. A dialog box appears listing the configurations defined in the rfconfig.ini file.
Select a reader configuration and then click Select. The Open button is activated.
Click the Open button to connect to the device
If then reader is connected properly, then the buttons in the Tag Map section are enabled.
Click Start to start the reader.
Wave the sample tags in front of the antenna. The tag ID and payload should be read and appear on the screen.
Install the Device Controller by extracting the
ORACLE_HOME\edge\controller\deviceController.zip file into the C:\ directory. This extracts the Device Controller files into the C:\controller directory.
To start the device controller:
Start a command-line console (cmd.exe)
Navigate to the C:\deviceController directory and then run the following command:
startIntermec.bat <ReaderName> <Port>
where <ReaderName> is the is the configuration name of the reader in the rfconfig.ini file and <Port> is the port on which the IntermecDevice driver listens so that it can communicate with this Device Controller.
For example, to start the Device Controller for the reader called Penn_A at port 6666, run the following command:
startIntermec.bat Penn_A 6666
After the Device Controller for the reader starts, create a device from the IntermecDevice driver that enables the Oracle Sensor Edge Server to communicate to the reader through this Device Controller.
You must create a device, an instance of the IntermecDriver driver, to enable the Oracle Sensor Edge Server to communicate with the Device Controller. To create a device:
Enter the name of the device. This is a mandatory parameter.
If needed, select an edge device group for this device from the Group drop-down list.
Select IntermecDevice from the Driver drop-down list and then click Go. The parameters specific to the IntermecDevice driver appear.
Set IPAddress to the hostname or IP address of the machine running the Device Controller. If it runs on the same machine as the Edge Server, enter 127.0.0.1.
Set PortNo to the port number used to start the Device Controller (6666 is the default).
Set the AntennaSeqIDList to the list of identifiers for each antenna.
Set AntennaMappedDeviceNameList to the list of mapped device names associated with each antenna.
Click Finish to complete the device.
Restart the Oracle Sensor Edge Server to receive events.
Unlike the RFID readers or other sensors, the Patlite series of lightstacks and trees 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.
Configuring the Patlite driver involves the following tasks:
Installing the Patlite hardware (Section 4.3.3.4.1).
Configuring the Device Controller for the Patlite device (Section 4.3.3.4.2).
Starting the Device Controller for the Patlite device (Section 4.3.3.4.3).
Configuring the Oracle Sensor Edge Server to communicate with the Device Controller for the Patlite device by creating a device instance (Section 4.3.3.4.4).
Supported Patlite Devices
Patlite's products include those that support both Serial and Ethernet connection. The current version of the Patlite driver in this release supports the Serial connection only.
To connect the Patlite device, you must have the following hardware:
A free RS232C communication port
A Female/Female, nine-pin RS232 cable with a straight-through pin type (such as a modem cable).
To set up the hardware:
Connect the lightstack to a power supply.
Connect one end of the serial cable to the lightstack.
Connect the other end of the serial cable to the serial port.
After you install the Device Controller (as described in Section 4.3.3.3.5), edit the deviceController/config/dcconfig.xml file as follows:
Change the comName parameter to the com port that you are using.
If the default port is currently in use on the local machine, change the value for lcPort to an available TCP/IP port number.
In Example 4-5, the dcconfig.xml file uses COM3 as the value for comName and the default port of 7878 for the lcPort parameter.
To start the device controller:
Navigate to deviceController/deploy/win.
Run startLight.bat. A message similar Example 4-6 appears.
Example 4-6 Status Message for the Patlite Device Controller
C:\deviceController\deploy\win>startlight Local ip is: 144.25.168.146 Establishing the listener at port: [7878] ... Waiting for connections...
After the Device Controller starts, you can enable communication between the Oracle Sensor Edge Server and the Device Controller for the Patlite device by creating a device from the Patlite Device driver.
You must create a device, an instance of the Patlite Device driver, to enable the Oracle Sensor Edge Server to communicate with the Device Controller. To create a device:
Enter the name of the device. This is a mandatory parameter. For example, enter Light1.
If needed, select an edge device group for this device from the Group drop-down list.
Select EdgeDevice from the Driver drop-down list and then click Go. The parameters specific to the driver appear.
Select Invoke Method.
Set IPAddress to the hostname or IP address of the machine running the Device Controller.
Set PortNo to the TCP/IP port number set in the dcconfig.ini file (7878 is the default).
Click Finish to complete the device.
Restart the Oracle Sensor Edge Server to run this device.
A filter is a class that strains out unwanted events or translates higher level events from groups or events or specific conditions. An event is a message that is sent from either a sensor device or an application that signals that a state has changed. The Oracle Sensor Edge Server, which receives the data from these sensor devices or applications, normalizes the contents of these event messages by putting them in a common data format and then applies filters to strip them of extraneous information or unwanted events.
Filters 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. The filter object implements three levels of filtering:
Pre-Device Filtering
Pre-device filtering provides filtering against a batch of pass-in events before they are routed to the Oracle Sensor Edge Server device.
Post-Device Filtering
Post-device filtering provides any filtering against the events before they are merged up to a device group.
Device Group Filtering
Device group filtering provides filtering against events before they are delivered to an edge client.
|
Note: Pre- and post-device filters apply only to devices; device group filtering applies only to device groups. |
Applying Filters to Devices and Device Groups
A filter instance, which is an object of a filter, enables device groups and devices to use filters. Whenever a filter is applied to a device (or to a device group), a filter instance of that filter is created. For more information on device- and device-group filters, see Table 4-7.
The filter browsing screen enables you to create, edit and delete filters. The screen includes a list (described in Table 4-4) that organizes the filters available to the devices and device groups.
Table 4-4 Elements of the Filter Browsing Screen
| Element | Description |
|---|---|
|
Name |
The name of the filter. |
|
Class Name |
The name of the filter implementation class. |
|
Version |
The version of the filter implementation. |
|
Description |
A description of the filter. |
|
Created Date |
The date the filter was created. |
The Oracle Sensor Edge Server enables you add filters that provide pre-device and post-device filtering.
|
Note: Only the filters that you create enable pre- and post-device filtering. For more information on developing filters, refer to the Oracle Application Server Wireless Developer's Guide. |
To create a filter, first click Create. The Create New Filter screen appears. Using the Import button, locate and then upload the filter's Extension Archive file to the repository. The Extension Archive file is a JAR file containing all of the class files and native binaries of the filter, as well as its properties files or static data files. In addition, the Extension Archive includes the Extension Archive Descriptor file, an XML file containing instructions for the Oracle Sensor Edge Server on loading and managing the filter.
Once the filter's Extension Archive file has been uploaded, the parameters specific to the uploaded file appear. (Unless the Extension Archive Descriptor file has been modified, the filter's parameters are read-only.) Click Finish to complete the filter. The filter, which then appears in the browsing screen, is available to devices and device groups. For more information on applying a filter to a device, see Section 4.6.
Dispatchers forward events from the Oracle Sensor Edge Server to either a dispatching layer or directly to an application.
The dispatcher browsing screen, which you access by selecting the Dispatchers tab, enables you to create and delete dispatchers. The following sections describe these functions:
The Dispatchers browsing screen includes a list (described inTable 4-4) that organizes the dispatchers available to the Oracle Sensor Edge Server processes.
Table 4-5 Elements of the Dispatcher Browsing Screen
| Element | Description |
|---|---|
|
Name |
The name of the dispatcher. |
|
Class Name |
The name of the dispatcher implementation class. |
|
Version |
The version of the dispatcher implementation. |
|
Description |
A description of the dispatcher. |
|
Created Date |
The date the dispatcher was created. |
To set a dispatcher, first click Create. The Create New Dispatcher screen appears. Using the Import button, locate and then upload the dispatcher's Extension Archive file to the repository. The Extension Archive file is a JAR file containing all of the class files and native binaries of the dispatcher, as well as its properties files or static data files. In addition, the Extension Archive includes the Extension Archive Descriptor file, an XML file containing instructions for the Oracle Sensor Edge Server on loading and managing the dispatcher.
Once the filter's Extension Archive file has been uploaded, the parameters specific to the uploaded file appear. (Unless the Extension Archive Descriptor file has been modified, the filter's parameters are read-only.) Click Finish to complete the dispatcher. The dispatcher, which then appears in the browsing screen, is among the dispatchers available when you create an edge dispatcher for an Oracle Sensor Edge Server process. For more information on creating an edge dispatcher, see Section 4.8.2.
|
Note: The readme of Edge Developer's Kit, available from the Oracle Technology Network (http://www.oracle.com/technology/), explains how to format dispatchers so that the Oracle Sensor Edge Server can automatically populate parameters from the uploaded JAR file.
|
An edge device is an end point of a sensor- based architecture, such as a Radio-Frequency Identification (RFID) reader, a dry contact, an laser diode, carousel, scale, robotic picker, or indication devices such as light sticks or message boards. Sensors are hardware or software end points that make observations of certain changes in state. While this is usually a physical change, such as a laser diode detecting that something has blocked the line of its beam, it can also a software observation of a change occurring within software, such as when a monitor daemon running on an edge controller exits. Sensors also observe defects in software.
The Manage Edge Devices button on the Edge Server List table enables you to add a device to a selected Edge Server process, delete a device from an Oracle Sensor Edge Server process, or edit the properties of a device. You can also start or stop a device. The following sections describe these tasks.
Section 4.6.1, "Adding a Device to an Oracle Sensor Edge Server Process"
Section 4.6.2, "Managing the Filter Instances for a Device or Device Group"
Section 4.6.5, "Deleting Filter Instances from Devices and Device Groups"
By selecting and an Oracle Sensor Edge Server process and then by clicking the Manage Edge Devices button, you access the Edge Devices tab, which includes a table listing of the devices assigned to the selected process (Figure 4-2). Table 4-6 describes the elements of this list.
Table 4-6 The Devices Table
| Element | Description |
|---|---|
|
Name |
The name of the device. |
|
Object ID |
The Object ID of the device that is stored in the repository. |
|
Status |
Whether the device is running (indicated by an upward pointing arrow), or stopped (indicated by an downward pointing arrow). |
|
Current State |
The current state of the device. |
|
Group Filter |
A check mark indicates that this device belongs to a device group that is associated with a filter instance that strains out unwanted events |
|
Device Filter |
A check mark indicates that this device is associated with a filter instance. |
|
Driver |
The type of driver used by this device. |
|
Group |
The name of the device group to which this device belongs. |
This table also includes buttons that enable you to delete a selected device from an Oracle Sensor Edge Server process, edit the properties of a device, manage the filter instances assigned to a device, as well as buttons to start and stop a selected device. The screen also includes the Create button, which enables you to add a device to the selected Oracle Sensor Edge Server process.
To add a device, first select an Oracle Sensor Edge Server process from the Edge Server List (Figure 4-1) and then click Create. The Create New Device screen appears, enabling you to add a device to the selected Oracle Sensor Edge Server process by defining the following values:
Enter the name of the device. This is a mandatory parameter.
If needed, select an edge device group for this device from the Group drop-down list.
From the Driver drop-down list, select the driver type for this edge device and then click Go. The parameters specific to selected edge driver appear.
Define the parameters of the driver as needed. For more information on drivers, see Section 4.3.1, "Adding a Driver".
Click Finish to complete the device. Click Cancel to clear all values and return to the device management screen.
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. The Filter Control button, located in the tables listing the available devices or device groups associated with an Oracle Sensor Edge Server process, enables you to add, edit, delete, or arrange filter instances.
Although you can develop your own filters and then upload them (see Section 4.4.1), OracleAS Wireless includes a set of filters out of the box (described in Table 4-7).
Table 4-7 The Pre-Seeded Filters of the Oracle Sensor Edge Server
| Filter Name | Function | Applied to Device Group? (Supports Group-Level Filtering) | Applied to Devices? (Supports Device-Level Filtering) |
|---|---|---|---|
|
Check Tag ID Filter |
A diagnostic tool that checks if a device is reading tags during a specified interval. See Section 4.6.3.1 |
No |
Yes |
|
Cross-Reader Redundant Filter |
Blocks redundant events that are sent from the devices of a device group. See Section 4.6.3.2 |
Yes |
No |
|
Debug Filter |
Tracks events passing through the system and then writes these events to a log file. See Section 4.6.3.3 |
No |
Yes |
|
Pass Filter |
Notifies applications that a tag has passed through a device's gateway or range or transmission. This filter also blocks events, so that only one event, rather than duplicate events, are generated when a tag is detected by a device. See Section 4.6.3.4 |
No |
Yes |
|
Shelf Filter |
Signals that an item has entered, or exited the field or gateway of a device reader. See Section 4.6.3.5 |
No |
Yes |
|
Pallet Pass-Thru Filter |
Enables you to see all of the tag IDs for items held in a container or on a pallet. See Section 4.6.3.6 |
No |
Yes |
|
Pallet Shelf Filter |
Sends events that signal new containers or pallets entering or exiting the field or gateway of a device reader See Section 4.6.3.7 |
No |
Yes |
Adding a filter instance to a device enables pre-device filtering and post-device filtering of events. For a device group, a filter instance provides device group filtering. For more information on device- and device group-level filtering see Section 4.4.
To add a filter instance to a device, select a device from the browsing screen and then click Filter Control. The Filter Control screen appears, displaying the list for the selected device or device group in the Applied Filter Instances pane (Figure 4-3).
Select a filter from the Filter drop-down list and then click Add. The parameters specific to the selected filter appear. Define the values as needed and then click Finish to create a instance of the filter for the selected device or device group. The filter instance appears in the Applied Filter Instances pane (Figure 4-3), where it can then be deleted, edited, or sorted.
Figure 4-4 Defining the Values of a Filter
The order of filter instances affects the efficacy of the data filtering. For example, if a device or device group is assigned a group filter, which groups IDs into an array of events and treats them as one item and a tag filter the filters out the events for a specific tag, TagXYZ, then applying the group filter before the tag filter results in the Oracle Sensor Edge Server receiving events grouped into chunks based on when they were detected, but only after the tag filter has strained out the events for TagXYZ. Reversing the order of the filters (that is, putting the group filter before the tag filter) would prevent the tag filter from filtering out anything, because it would see only the group events and not those for TagXYZ.
You can arrange the filter instances by selecting a filter instance and then moving it up or down using the arrow keys. To set the filter sequence, click Finish.
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 driver, 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 4-8 describes the parameters (and associated values) of the Check Tag ID filter.
Table 4-8 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 4-9 describes the signature of the generated event. Refer to Section 4.1.1 for more information on the Event type.
Table 4-9 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. |
|
|
The message type, Note: Applications should subscribe to this message type for notifications of when devices fail. |
|
|
|
|
|
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 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.
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. Refer to Section 4.1.1 for more information on the Event type.
Table 4-10 describes the signature of the pass through event.
Table 4-10 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. |
|
|
|
|
|
|
|
|
The ID of the tag. |
|
|
The data payload of the tag. |
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 (described in Table 4-11) when the device first detects the tag. See Section 4.1.1 for more information on the Event type.
Table 4-11 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. |
|
|
|
|
|
|
|
|
The ID of the tag. |
|
|
The data payload of the tag. |
OUT FIELD Event
The Shelf Filter generates this event (described in Table 4-12) when the interval defined for the Exit Event Threshold Time parameter elapses. See Section 4.1.1 for more information on the Event type.
Table 4-12 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. |
|
|
|
|
|
|
|
|
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 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 4-13). Refer to Section 4.1.1 for more information on the Event type.
Table 4-13 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. |
|
|
|
|
|
|
|
|
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 4-14):
Table 4-14 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. |
|
|
|
|
|
|
|
|
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 4-15):
Table 4-15 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. |
|
|
|
|
|
|
|
|
A comma-separated list of Tag IDs. |
|
|
A comma-separated list of datum. |
To edit a filter instance, select the filter instance from the Applied Filter Instance pane and then click Edit. The parameters for the filter instance appear. Modify the values as needed and then click Apply to commit the changes.
To delete a filter instance from a device or from a device group, select the filter instance from the Filter Instances pane and then click Delete.
A device group is a logical grouping of devices. An Oracle Sensor Edge Server can have one or many device groups instantiated. Each device group is responsible for all of the devices (and their filters) included within it. Before you connect devices and filters to an Oracle Sensor Edge Server, you must first create device groups. The Manage Device Groups button on the Edge Server List table enables you to add a device group to a selected Oracle Sensor Edge Server process, delete a device group from an Oracle Sensor Edge Server process, or edit the properties of a device group (such as managing the device membership of the group). The following sections describe these tasks.
Section 4.7.3, "Deleting a Device Group from an Oracle Sensor Edge Server Process"
Section 4.7.4, "Managing the Filter Instances for a Device Group"
Figure 4-5 The Edge Device Groups Browsing Screen
By selecting and an Oracle Sensor Edge Server process and then clicking the Manage Edge Device Groups button, you access the Edge Device Groups browsing screen, which includes a table that lists the device groups assigned to the selected process (Figure 4-5). Table 4-16 describes the elements of this list.
Table 4-16 The Device Groups Table
| Element | Description |
|---|---|
|
Name |
The name of the device group. |
|
Object ID |
The Object ID of the device group that is stored in the repository. |
|
Status |
Whether the devices belonging to the device group are running (indicated by an upward pointing arrow), or stopped (indicated by an downward pointing arrow). |
|
Group Filter |
A check mark indicates that this device group is associated with a group filter instance. |
|
Device Filter |
A check mark indicates that this devices belonging to this group are associated with filter instances. |
|
Driver |
The type of drivers used by the devices belonging to this group. |
This table also includes buttons that enable you to delete a selected device group from an Oracle Sensor Edge Server process, edit the properties of a device group, and manage the filter instances assigned to a device group. The screen also includes the Create button, which enables you to add a device group to the selected Oracle Sensor Edge Server process.
To create a device group, first select an Oracle Sensor Edge Server process and then click Create. The Create New Edge Device Group screen appears. Enter a name for the device group and then add devices to this device group by moving a device (or devices) from the Available Devices pane to the Selected Devices pane. Click Finish to complete the device group and add it to the selected Oracle Sensor Edge Server process.
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 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. For more information, see Section 4.6.2, "Managing the Filter Instances for a Device or Device Group".
|
Note: You must stop and restart the Oracle Sensor Edge Server process using the System Manager after you create, edit or delete a device group. For more information on starting and stopping a standalone instance, see Section 3.6.2.1, "Creating a Standalone Process". |
Selecting a device group and then clicking the Edit button enables you to change the name or the device membership of a device group. Clicking Apply commits any changes made to the device group. Clicking Cancel sets the device group back to its previous state.
To delete a device group from an Oracle Sensor Edge Server process, select the device group and then click Delete.
See Section 4.6.2, "Managing the Filter Instances for a Device or Device Group".
For an Oracle Sensor Edge Server process to use a dispatcher, you must assign an edge dispatcher to the process. An Oracle Sensor Edge Server process can use only one edge dispatcher. This edge dispatcher is noted as "Current".
Figure 4-6 The Edge Dispatcher Browsing Screen
To access the functions to create and manage edge dispatchers for a selected Oracle Sensor Edge Server process, first select the Oracle Sensor Edge Server process and then click the Manage Edge Dispatchers button. The Edge Dispatchers browsing screen appears, which includes a table that lists the available edge dispatchers (Figure 4-6). Table 4-17 describes the elements of this list.
Table 4-17 Elements of the Edge Dispatcher Browsing Screen
| Element | Description |
|---|---|
|
Name |
The name of the edge dispatcher. |
|
Current |
A check mark notes that the Oracle Sensor Edge Server process currently uses this edge dispatcher to forward events. An Oracle Sensor Edge Server process can use only one edge dispatcher. |
|
Dispatcher |
The name of the dispatcher used to create this edge dispatcher. |
|
Class Name |
The name of the dispatcher implementation class. |
|
Version |
The version of the dispatcher implementation. |
|
Description |
A description of the dispatcher. |
|
Date Last Modified |
The last time the edge dispatcher was updated. |
The following sections describe the tasks enabled from the edge dispatcher browsing screen:
Section 4.8.1, "Setting the Current Edge Dispatcher Used by the Oracle Sensor Edge Server Process"
Section 4.8.2, "Setting an Edge Dispatcher for an Oracle Sensor Edge Server Process"
Section 4.8.4, "Deleting an Edge Dispatcher from an Oracle Sensor Edge Server Process"
An Oracle Sensor Edge Server process can use only one edge dispatcher at a time. To set the edge dispatcher for the Oracle Sensor Edge Server process, select an edge dispatcher and then click Set Current. Even if you have only one dispatcher configured for an Oracle Sensor Edge Server process, it can only be used by the dispatcher process if you set it as current; otherwise, the dispatcher will not be used. After you assign a dispatcher as current, the Oracle Sensor Edge Server process using it must be stopped and then restarted. For more information on starting and stopping a standalone process, see Section 3.6.2.1, "Creating a Standalone Process".
|
Note: If you modify the assignments of devices, device groups, or dispatchers of an Oracle Sensor Edge Server process, or modify the properties of the devices, device groups or dispatchers used by a process, then you must stop and restart the Oracle Sensor Edge Server process to which these components belong. For more information on starting and stopping a standalone process, see Section 3.6.2.1, "Creating a Standalone Process" |
To set the edge dispatcher for an Oracle Sensor Edge Server process, click Create. The Create New Edge Dispatcher screen appears, in which you enter a name for the edge dispatcher, select the dispatcher used for this instance and then define the values for the parameters specific to the selected dispatcher. Clicking Finish completes the edge dispatcher.
You can select an edge dispatcher process to send event messages using Oracle Streams, Oracle's Java Message Service provider (OC4J JMS) remote Web Services or to a client application using HTTP.
Configuring the edge dispatcher to use Oracle Streams and Advanced Queuing enables you to control how the edge 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 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. For more information on Oracle Sensor Edge Server Rule Set, refer to the Oracle Application Server Wireless Developer's Guide
In addition to these rule-based actions, the Rules 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:
|
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. |
To configure the Streams dispatcher, select Streams and the define the following information connection information for the Streams staging area:
The JDBC connection string to the database where the staging area resides. By default, this value is set to the IAS 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.
The name of the user of the database where the staging area resides.
The password to the user of the database where the staging area resides.
Select Use Customer Database to configure the Oracle Sensor Edge Server processes to send event messages through an external database.
|
Note: If you configure database streams as the event dispatcher method, you must perform the following post-installation steps:
|
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 Oracle Application Server Wireless 10g Release 2 (10.1.2.02), the OC4J JMS dispatcher configuration (that is, the JMS dispatcher) cannot send messages back to sensor devices. Only the database stream dispatcher configuration 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. In addition, you specify edgeEventsConnectionFactory as the connection factory. To enable the Oracle Sensor Edge Server components to access this topic, you must configure the jms.xml file under the OC4J container. Refer to the Oracle Application Server Containers for J2EE Services Guide for more information on configuring the JMS queue.
|
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 create a JMS dispatcher that enables the Oracle Sensor Edge Server processes to send event messages to the JMS topic queue, edgeTopic:
Define the following values:
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.
The user name of the administrator of the OC4J instance where the edgeTopic queue is stored.
The password used by the administrator of the OC4J instance where the edgeTopic queue is stored.
Set the acknowledgement mode to CLIENT_ACKNOWLEDGE or AUTO_ACKNOWLEDGE. The default mode is AUTO_ACKNOWLEDGE.
Set enterprise_mode to true.
Perform the following steps for each middle tier that uses the JMS dispatcher:
Add the oc4j.jar and edgeclient.jar libraries to the classpath section of opmn.xml, located in the ORACLE_HOME/opmn/conf/directory by adding the following lines under the process type with the ID of "edgeserver_server"::
<environment> <variable id="CLASSPATH" value="$ORACLE_HOME/j2ee/home/oc4j.jar" append="true"/> <variable id="CLASSPATH" value="$ORACLE_HOME/wireless/lib/edgeclient.jar" append="true"/> <environment>
|
Note: The value for ORACLE_HOME depends on the location of an OracleAS Wireless middle tier. |
Copy edgeclient.jar to ORACLE_HOME\wireless\lib\. The edgeclient.jar is available from the Oracle Technology Network (http://www.oracle.com/technology/products/iaswe/edge_server/).
Stop and then restart the OracleAS Wireless middle tier.
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, select Web Services and then define the parameters for this dispatcher type by entering 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 separately to the client. Because the Oracle Sensor Edge Server performs these posts sequentially, if one post is blocked, then all following posts are also blocked. Select HTTP to configure the HTTP dispatcher and then 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.
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.
Click OK to complete the dispatcher configuration. Ensure that the selected dispatcher method functions after you complete this configuration. 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/)
By selecting an edge dispatcher and then clicking Edit, you access the Edit Edge Dispatcher page, which enables you to change the name of the edge dispatcher and modify the values of its parameters. You cannot select another dispatcher. Clicking Apply commits any changes made to the edge dispatcher. Clicking Cancel sets the edge dispatcher's name and parameter values back to their previous state.
