Difference between revisions of "Application Level Events (ALE) User's Guide"

From RifidiWiki

Jump to: navigation, search
(In Rifidi dashboard)
Line 124: Line 124:
 
==Validate==
 
==Validate==
  
=ALE Operations Basic Flow=
 
  
A few sample scenarios are illustrated below to demonstrate the use of the ALE interface messages.
 
<ol>
 
  <li>Define and Subscribe</li>
 
  <li>Define and Poll</li>
 
  <li>Immediate</li>
 
</ol>
 
 
==Scenario 1: Define and Subscribe==
 
 
The scenario specifies the ECSpec, it then subscribes to receive the resulting ECReports asynchronously.
 
 
<ol type="1">
 
  <li>Call the define method of the ALE interface.</li>
 
  <li>Call the subscribe method of the ALE interface, including an URI that identifies the Mqtt server (and topic name if you want to override the default 'ale' topic) as the destination for the ECReports. For example to publish to default topic (ale) type: tcp://localhost:1883 and if you want to subscribe to a different topic (myTopic) type: tcp://localhost:1883/myTopic</li>
 
  <li>Open a Mqtt client, for example MQTT.fx (http://mqttfx.jfx4ee.org/) and connect to Rifidi Mqtt Server, then subscribe to the topic name defined in subscribe operation.</li>
 
  <li>You should see the incoming messages according to what you defined in ECSpec.</li>
 
</ol>
 
 
==Scenario 2: Define and Poll==
 
 
The scenario shown illustrates an ALE client using the poll method of the ALE interface to synchronously obtain the EPC data it is interested in collecting.
 
 
<ol type="1">
 
<li>Call the define method of the ALE interface.</li>
 
<li>Calls the poll method of the ALE interface, naming the ECSpec previously defined in Step 1. During the duration of the event cycle the ALE client is blocked waiting for a response to the poll method.</li>
 
<li>An EPC which meets the filter conditions of the ECSpec is received during the event cycle. At the end of the event cycle, the ECReports is generated and returned to the ALE client as the response to the poll method.</li>
 
</ol>
 
 
==Scenario 3: Immediate==
 
 
The scenario shown illustrates an ALE client using the immediate method of the ALE interface to synchronously obtain the EPC data it is interested in collecting.
 
 
<ol type="1">
 
<li>Call the define method of the ALE interface.</li>
 
<li>Call the poll method of the ALE interface. This is very similar to the use of poll, except that when the client calls immediate it provides the ECSpec as part of the method call, as opposed to referring to a previously defined ECSpec. During the duration of the event cycle the ALE client is blocked waiting for a response to the immediate method.</li>
 
<li>An EPC which meets the filter conditions of the ECSpec is received during the event cycle. At the end of the event cycle, the ECReports is generated and returned to the ALE client as the response to the immediate method.</li>
 
</ol>
 
  
 
=ALELR Operations Basic Flow=
 
=ALELR Operations Basic Flow=
Line 227: Line 189:
 
[[File:xml_composite_reader.png]]
 
[[File:xml_composite_reader.png]]
  
<!-- init old version
+
=ALE Operations Basic Flow=
------------------------------------------------------------------------
+
 
 +
A few sample scenarios are illustrated below to demonstrate the use of the ALE interface messages.
 +
<ol>
 +
  <li>Define and Subscribe</li>
 +
  <li>Define and Poll</li>
 +
  <li>Immediate</li>
 +
</ol>
 +
 
 +
==Scenario 1: Define and Subscribe==
 +
 
 +
The scenario specifies the ECSpec, it then subscribes to receive the resulting ECReports asynchronously.
 +
 
 +
<ol type="1">
 +
  <li>Call the define method of the ALE interface.</li>
 +
  <li>Call the subscribe method of the ALE interface, including an URI that identifies the Mqtt server (and topic name if you want to override the default 'ale' topic) as the destination for the ECReports. For example to publish to default topic (ale) type: tcp://localhost:1883 and if you want to subscribe to a different topic (myTopic) type: tcp://localhost:1883/myTopic</li>
 +
  <li>Open a Mqtt client, for example MQTT.fx (http://mqttfx.jfx4ee.org/) and connect to Rifidi Mqtt Server, then subscribe to the topic name defined in subscribe operation.</li>
 +
  <li>You should see the incoming messages according to what you defined in ECSpec.</li>
 +
</ol>
 +
 
 +
==Scenario 2: Define and Poll==
 +
 
 +
The scenario shown illustrates an ALE client using the poll method of the ALE interface to synchronously obtain the EPC data it is interested in collecting.
 +
 
 +
<ol type="1">
 +
<li>Call the define method of the ALE interface.</li>
 +
<li>Calls the poll method of the ALE interface, naming the ECSpec previously defined in Step 1. During the duration of the event cycle the ALE client is blocked waiting for a response to the poll method.</li>
 +
<li>An EPC which meets the filter conditions of the ECSpec is received during the event cycle. At the end of the event cycle, the ECReports is generated and returned to the ALE client as the response to the poll method.</li>
 +
</ol>
 +
 
 +
==Scenario 3: Immediate==
 +
 
 +
The scenario shown illustrates an ALE client using the immediate method of the ALE interface to synchronously obtain the EPC data it is interested in collecting.
 +
 
 +
<ol type="1">
 +
<li>Call the define method of the ALE interface.</li>
 +
<li>Call the poll method of the ALE interface. This is very similar to the use of poll, except that when the client calls immediate it provides the ECSpec as part of the method call, as opposed to referring to a previously defined ECSpec. During the duration of the event cycle the ALE client is blocked waiting for a response to the immediate method.</li>
 +
<li>An EPC which meets the filter conditions of the ECSpec is received during the event cycle. At the end of the event cycle, the ECReports is generated and returned to the ALE client as the response to the immediate method.</li>
 +
</ol>
 +
 
 +
 
 
Here is an example of the basic flow for using ALE operations to get tag reads (current tags, addition and deletion) from a defined set of logical readzone(s) and the difference between using poll and immediate operations.
 
Here is an example of the basic flow for using ALE operations to get tag reads (current tags, addition and deletion) from a defined set of logical readzone(s) and the difference between using poll and immediate operations.
  
Line 383: Line 384:
 
</ol>
 
</ol>
  
-->
 
  
 
=ALE Implementation=
 
=ALE Implementation=

Revision as of 12:02, 29 March 2016

Note: Leverage similar approach to REST - below is just my thoughts - open to other ways to approach

Contents

Introduction

This section describes implementations of the EPCglobal ALE interface v1.0. The Application Level Events (ALE) specification describes an interface through which client applications may obtain filtered, consolidated EPC data from a variety of sources.

The ALE layer exists in a context including RFID readers, Users (administrative) and Client applications as shown below. Initially the administrators are responsible for installing and configuring the RFID environment. Once the environment is configured, EPC data (tag reads) are sent from the Readers to the ALE layer.

The processing done at this layer typically involves: (1) receiving EPCs from one or more data sources such as readers; (2) accumulating data over intervals of time, filtering to eliminate duplicate EPCs and EPCs that are not of interest, and counting and grouping EPCs to reduce the volume of data; and (3) reporting in various forms. The interface described herein, and the functionality it implies, is called “Application Level Events,” or ALE.

Configuration

#Port must be set
-Dorg.rifidi.ale.port=8112
#ALE and ALELR web services start by default but this can be changed 
-Dorg.rifidi.ale.enabled=true

How to Test ALE Operations

Set up testing

In order to deploy and use the ALE Test Client web application, follow the next steps:

  1. Install Java: Download and install Java JDK version 1.7
  2. Create JAVA_HOME variable: Define a system variable called JAVA_HOME pointing to jdk root folder, for example:
  3. Java home def.png

  4. Install apache tomcat: Download apache tomcat version 8 from http://tomcat.apache.org/download-80.cgi, for example:
  5. Download apache tomcat.png

  6. Extract the zip file and copy to a desired location, for example C:\apache-tomcat-8.0.30:
  7. Apache tomcat folder.png

  8. Change default port number: If you want to change default port number 8080 to any other custom value, go to /conf/server.xml and edit the file. For example if you want to change http port to 8081, change as shown below:
  9. Apache tomcat port.png

  10. Edit tomcat users file, in order for user to manage Tomcat web console and deploy applications: Go to /conf/tomcat-users.xml and edit the file to enable users with appropriate roles, depending on your security constraints. For example, enabling user tomcat with password tomcat with roles tomcat, manager-gui, admin-gui:
  11. Apache tomcat roles.png Note: If the server is started and you change this file, you should restart tomcat for changes to take effect.

  12. Start Tomcat Server: Open an OS command prompt and locate the bin folder under tomcat, and type startup.bat and hit Enter
  13. Apache tomcat start.png

  14. Download ALE web client War File, from http://fosstrak.github.io/fc/download.html From latest release choose Web-Based Client, and download the ZIP file:
  15. Ale war download.png

  16. Extract the zip file content and locate the WAR file
  17. Ale war zip.png

  18. Deploy War in tomcat: Go to localhost:8081 and you should see a similar page like this, then go to Manager App, as shown:
  19. Apache tomcat managerapp link.png

  20. Then you are asked to provide credentials to continue, type tomcat for user name, and tomcat for password, as configured previously
  21. Apache tomcat authentication.png

  22. If everything is going right, you should see the Tomcat Web Application Manager console:
  23. Apache tomcat app console.png

  24. Then go to War file to deploy section, and hit Choose file button:
  25. Apache tomcat choose file.png

  26. Then locate the War file to be deployed and hit Open:
  27. Apache tomcat open file.png

  28. Then hit the Deploy button:
  29. Apache tomcat deploy file.png

  30. Wait for a few seconds and you should see a success message saying OK, and below Applications section, see the new deployed application:
  31. Apache tomcat deployed file.png

  32. Finally, go to web client app pointing web browser to http://localhost:8081/fc-webclient-1.2.0/services/ALEWebClient.jsp And you should see the Ale Web Client app:
  33. Tomcat ale app.png

Execute

1. Start Rifidi server

Start the Rifidi server

2. Start Rifidi emulator

Start the Rifidi emulator, create an LLRP reader type, start it, and then create some Gen2 tags, and drag and drop some of them to emulated reader's antenna

3. Validate ALE and ALELR Web services are running

To validate ALE Web service, go to http://localhost:8112/aleservice?wsdl and you should see the web service definition

To validate ALELR Web service, go to http://localhost:8112/alelrservice?wsdl and you should see the web service definition

If you do not get web service response, make sure you have set required JVM arguments, as described in configuration steps

4. Open web client application

You can follow this guide in order to install the ALE web client ALE Web Client Setup

After successful deployment of ALE web client, point your web browser to http://localhost:8081/fc-webclient-1.2.0/services/ALEWebClient.jsp and you should see the web application to test ale and alelr web services:


Aleservice client.jpg

5. Call setEndPoint(String endPointName) for ALE

Call setEndPoint(String endPointName) for ALE: Clic on setEndPoint(String endPointName) link in left ALE panel, then type the url http://localhost:8112/aleservice as the endpoint attribute, then clic Invoke

Ale setendpoint.jpg

After this, verify the end point was appropriate set, by calling getEndPoint(), and you should see the endpoint address you set before:

Ale getendpoint.jpg

6. Call setEndPoint(String endPointName) for ALELR

Call setEndPoint(String endPointName) for ALELR: Click on setEndPoint(String endPointName) linl in left ALELR panel, then type the url http://localhost:8112/alelrservice as the endpoint attribute, then clic Invoke

Alelr setendpoint.jpg

After this, verify the end point was appropriate set, by calling getEndPoint(), and you should see the endpoint address you set before:

Alelr getendpoint.jpg

Validate

ALELR Operations Basic Flow

A few sample scenarios are illustrated below to demonstrate the use of the ALELR interface messages.

  1. Defining Logical Base Reader
  2. Defining Logical Composite Reader

Define a Logical Base Reader

Prior to these steps you need to set up the readers and readzones in Rifidi server. If you need all the antennas for a Reader to be included in collecting data, then create a Reader in Rifidi dashboard If you need just some specific antennas for a Reader to be included in collecting data, then create a Readzone in Rifidi dashboard

In Rifidi dashboard

  1. Create a Reader
  2. Create a session for reader and start the session
  3. Create a command to collect tag data, for example a LLRP-Configure command type
  4. Submit the command on session
  5. Then if optionally you need to create read zones:

  6. Create readzone defining associated reader and antennas

Note: Be careful in not naming a reader and a readzone with the same name, to avoid any reference issue in ALE. If this is the case, ALE will assume the reader instead of the readzone

Rifidi dashboard should look like this:

Defining ale readzone.png

In ALE client

  1. Call define method giving as readerName the same name that was assigned to a Reader (or a readzone) in Rifidi server.
  2. For example, if we want to use the Rifidi readzone we just created:

    Ale define readzone.png

    The XML content should look like:

    Ale define front door.png

Define a Logical Composite Reader

The readers that are going to be part of a composite reader must be first created as base readers, so you have to execute the steps to create a base reader prior to define composite readers.

In ALELR client

  1. Call define method. The readerName in this case may be any value.

For example if you want to create a composite reader with the name FrontDoorComp

Define composite reader.png

For example, if you have defined two base readers, called Front_Door_1 and Front_Door_2,then the XML file should look like:

Xml composite reader.png

ALE Operations Basic Flow

A few sample scenarios are illustrated below to demonstrate the use of the ALE interface messages.

  1. Define and Subscribe
  2. Define and Poll
  3. Immediate

Scenario 1: Define and Subscribe

The scenario specifies the ECSpec, it then subscribes to receive the resulting ECReports asynchronously.

  1. Call the define method of the ALE interface.
  2. Call the subscribe method of the ALE interface, including an URI that identifies the Mqtt server (and topic name if you want to override the default 'ale' topic) as the destination for the ECReports. For example to publish to default topic (ale) type: tcp://localhost:1883 and if you want to subscribe to a different topic (myTopic) type: tcp://localhost:1883/myTopic
  3. Open a Mqtt client, for example MQTT.fx (http://mqttfx.jfx4ee.org/) and connect to Rifidi Mqtt Server, then subscribe to the topic name defined in subscribe operation.
  4. You should see the incoming messages according to what you defined in ECSpec.

Scenario 2: Define and Poll

The scenario shown illustrates an ALE client using the poll method of the ALE interface to synchronously obtain the EPC data it is interested in collecting.

  1. Call the define method of the ALE interface.
  2. Calls the poll method of the ALE interface, naming the ECSpec previously defined in Step 1. During the duration of the event cycle the ALE client is blocked waiting for a response to the poll method.
  3. An EPC which meets the filter conditions of the ECSpec is received during the event cycle. At the end of the event cycle, the ECReports is generated and returned to the ALE client as the response to the poll method.

Scenario 3: Immediate

The scenario shown illustrates an ALE client using the immediate method of the ALE interface to synchronously obtain the EPC data it is interested in collecting.

  1. Call the define method of the ALE interface.
  2. Call the poll method of the ALE interface. This is very similar to the use of poll, except that when the client calls immediate it provides the ECSpec as part of the method call, as opposed to referring to a previously defined ECSpec. During the duration of the event cycle the ALE client is blocked waiting for a response to the immediate method.
  3. An EPC which meets the filter conditions of the ECSpec is received during the event cycle. At the end of the event cycle, the ECReports is generated and returned to the ALE client as the response to the immediate method.


Here is an example of the basic flow for using ALE operations to get tag reads (current tags, addition and deletion) from a defined set of logical readzone(s) and the difference between using poll and immediate operations.

Scenario 1x: Defining base reader

Defining base reader.png

call ALELR define method with parameters:

  • readerName: The name of logical reader to be used in Ale, not necessarily matching any reader id you have defined in Rifidi server.
  • specFilePath: The specification file that defines the reader to be associated with this logical reader, in XML format, looks like:

Alelr define xml file example.png

Scenario 2x: Defining composite reader

Scenario 1x: Immediate flow

1. Start the Edge Server

Create Rifidi reader(s), if not already created.

Rifidi readers.png

2. Setendpoint ale

http://localhost:8112/aleservice

3. Setendpoint alelr

http://localhost:8112/alelrservice

4. Call the AleLR Define method

5. Call the Ale Define method

6. Call Immediate method

Scenario 2x: Poll flow

Scenario 3x: Async (MQTT) flow

Scenario 1x: Current tags

  1. Define the ECSpecCurrent
  2. <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <ns2:ECSpec xmlns:ns2="urn:epcglobal:ale:xsd:1">
        <logicalReaders>
            <logicalReader>LLRP_1</logicalReader>
        </logicalReaders>
        <boundarySpec>
            <repeatPeriod unit="MS">15000</repeatPeriod>
            <duration unit="MS">10000</duration>
            <stableSetInterval unit="MS">0</stableSetInterval>
        </boundarySpec>
        <reportSpecs>
            <reportSpec>
                <reportSet set="CURRENT"/>
                <output includeRawHex="true" includeRawDecimal="true" includeEPC="true"/>
            </reportSpec>
        </reportSpecs>
    </ns2:ECSpec>
    
  3. Define a subscriber, which subscribes to ECSpecCurrent
  4. Put one Tag on the reader. Tag must appear in all Reports until Tag is removed from reader
  5. Remove Tag from the reader. Tag must not appear in any Report from now on

Scenario 2: Added tags

  1. Define the ECSpecAdditions
  2. <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <ns2:ECSpec xmlns:ns2="urn:epcglobal:ale:xsd:1">
        <logicalReaders>
            <logicalReader>LLRP_1</logicalReader>
        </logicalReaders>
        <boundarySpec>
            <repeatPeriod unit="MS">15000</repeatPeriod>
            <duration unit="MS">10000</duration>
            <stableSetInterval unit="MS">0</stableSetInterval>
        </boundarySpec>
        <reportSpecs>
            <reportSpec>
                <reportSet set="ADDITIONS"/>
                <output includeRawHex="true" includeRawDecimal="true" includeEPC="true"/>
            </reportSpec>
        </reportSpecs>
    </ns2:ECSpec>
    
  3. Define a subscriber, which subscribes to ECSpecAdditions
  4. Put one Tag on reader. Tag must only appear in the first following Report

Scenario 3: Deleted tags

  1. Define the ECSpecDeletions
  2. <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <ns2:ECSpec xmlns:ns2="urn:epcglobal:ale:xsd:1">
        <logicalReaders>
            <logicalReader>LLRP_1</logicalReader>
        </logicalReaders>
        <boundarySpec>
            <repeatPeriod unit="MS">15000</repeatPeriod>
            <duration unit="MS">10000</duration>
            <stableSetInterval unit="MS">0</stableSetInterval>
        </boundarySpec>
        <reportSpecs>
            <reportSpec>
                <reportSet set="DELETIONS"/>
                <output includeRawHex="true" includeRawDecimal="true" includeEPC="true"/>
            </reportSpec>
        </reportSpecs>
    </ns2:ECSpec>
    
  3. Define a subscriber, which subscribes to ECSpecDeletions
  4. Put one Tag on reader. Tag must not appear in the Report
  5. Remove Tag from reader. Tag must only appear in the first following Report

Scenario 4: Added and deleted tags

  1. Define the ECSpecAdditionsAndDeletions
  2. <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <ns2:ECSpec xmlns:ns2="urn:epcglobal:ale:xsd:1">
        <logicalReaders>
            <logicalReader>LLRP_1</logicalReader>
        </logicalReaders>
        <boundarySpec>
            <repeatPeriod unit="MS">15000</repeatPeriod>
            <duration unit="MS">10000</duration>
            <stableSetInterval unit="MS">0</stableSetInterval>
        </boundarySpec>
        <reportSpecs>
            <reportSpec reportName="Additions">
                <reportSet set="ADDITIONS"/>
                <output includeRawHex="true" includeRawDecimal="true" includeEPC="true"/>
            </reportSpec>
            <reportSpec reportName="Deletions">
                <reportSet set="DELETIONS"/>
                <output includeRawHex="true" includeRawDecimal="true" includeEPC="true"/>
            </reportSpec>
        </reportSpecs>
    </ns2:ECSpec>
    
  3. Define a subscriber, which subscribes to the mentioned ECSpec
  4. Put one Tag on reader. Tag must only appear in the first following Report
  5. Remove Tag from reader. Tag must only appear in the first following Report


ALE Implementation

The ALE clients are applications or services that process EPC tag information. Several methods are defined within the ALE interface which allow clients to specify the data they wish to receive and the conditions for the production of the reports containing the data. These methods are:

Note: for each operation example request/response/wsdl


Ale Operations

define(String specName, String specFilePath)

Creates a new ECSpec having the name specName, according to spec

undefine(String specName)

Removes the ECSpec named specName that was previously created by the define method

getECSpec(String specName)

Returns the ECSpec that was provided when the ECSpec named specName was created by the define method.

getECSpecNames()

Returns an unordered list of the names of all ECSpecs that are visible to the caller.

subscribe(String specName, String notificationURI)

Adds a subscriber having the specified notificationURI to the set of current subscribers of the ECSpec named specName. The notificationURI parameter both identifies a specific binding of the ALECallback interface and specifies addressing information meaningful to that binding.

unsubscribe(String specName, String notificationURI)

Removes a subscriber having the specified notificationURI from the set of current subscribers of the ECSpec named specName.

poll(String specName)

Requests an activation of the ECSpec named specName, returning the results from the next event cycle to complete. A poll call is like subscribing then unsubscribing immediately after one event cycle is generated (except that the results are returned from poll instead of being sent to a notificationURI).

After calling poll service, the expected response is an xml like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:ECReports specName="ReportGenerator_0_0" date="2016-01-17T21:36:40.966-05:00" ALEID="RIFIDI-ALE604974863" totalMilliseconds="9500" terminationCondition="DURATION" xmlns:ns2="urn:epcglobal:ale:wsdl:1" xmlns:ns3="urn:epcglobal:ale:xsd:1">
<reports>
<report reportName="Cycle_1">
<group>
<groupList>
<member><epc>300e34d6e51161826493ff7e</epc></member>
</groupList>
</group>
</report>
</reports>
</ns3:ECReports>

immediate(String specFilePath)

Creates an unnamed ECSpec according to spec, and immediately requests its activation. This is equivalent to defining an ECSpec, performing a single poll operation, and then undefining it.

After calling immediate service, the expected response is an xml like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:ECReports specName="ReportGenerator_0_0" date="2016-01-18T16:32:36.500-05:00" ALEID="RIFIDI-ALE-293181330" totalMilliseconds="9500" terminationCondition="DURATION" xmlns:ns2="urn:epcglobal:ale:xsd:1" xmlns:ns3="urn:epcglobal:ale:wsdl:1">
<reports>
<report reportName="Cycle_1">
<group>
<groupList>
<member><epc>300e34d6e51161826493ff7e</epc></member>
</groupList>
</group>
</report>
</reports>
</ns2:ECReports>

getSubscribers(String specName)

Returns an unordered, possibly empty list of the notification URIs corresponding to each of the current subscribers for the ECSpec named specName.

getStandardVersion()

Returns a string that identifies what version of the specification this implementation of the Reading API complies with.

getVendorVersion()

Returns a string that identifies what vendor extensions this implementation of the Reading API provides.

Error conditions

Methods of the ALE Reading API signal error conditions to the client by means of exceptions. The following exceptions are defined. All the exception types in the following table are extensions of a common ALEException base type, which contains one string element giving the reason for the exception.

SecurityException

The operation was not permitted due to an access control violation or other security concern.

DuplicateNameException

The specified ECSpec name already exists. Note that the existence of a CCSpec having the same name does not cause this exception; ECSpecs and CCSpecs are in different namespaces.

ECSpecValidationException

The specified ECSpec is invalid. The define and immediate methods of the ALE API SHALL raise an ECSpecValidationException if any of the following are true:

  • The specified specName is an empty string or is not accepted by the implementation
  • The logicalReaders parameter of ECSpec is null, omitted, is an empty list, or contains any logical reader names that are not known to the implementation.
  • The boundarySpec parameter of ECSpec is null or omitted.
  • The duration, stableSetInterval, or repeatPeriod parameter of ECBoundarySpec is negative.
  • The value of the startTrigger or stopTrigger parameter of ECBoundarySpec, or any element of the startTriggerList or stopTriggerList parameter of ECBoundarySpec does not conform to URI syntax as defined by [RFC2396], or is a URI that is not supported by the ALE implementation. Note that an empty string does not conform to URI syntax as defined by [RFC2396].
  • No stopping condition is specified in ECBoundarySpec; i.e., stopTrigger is omitted or null, stopTriggerList is empty, whenDataAvailable is false, and neither duration nor stableSetInterval nor any vendor extension stopping condition is specified.
  • The reportSpecs parameter of ECSpec is null, omitted, or empty.
  • Any ECReportSpec instance has a reportName that is an empty string or that is not accepted by the implementation.
  • Two ECReportSpec instances have identical values for their reportName fields.
  • Any member of includePatterns or excludePatterns within ECFilterSpec does not conform to the epc-tag format’s filter syntax
  • Two members of the fieldList parameter of any ECReportOutputSpec instance have the same name.
  • The fieldspec parameter of any ECFilterListMember instance is invalid.
  • The patList parameter of any ECFilterListMember instance is empty, null, or omitted, or any element of patList does not conform to the syntax rules for patterns implied by the specified fieldspec.
  • The fieldspec parameter of ECGroupSpec is invalid.
  • The fieldspec parameter of ECGroupSpec implies a datatype and format for which no grouping pattern syntax is defined.
  • Any grouping pattern within the patternList parameter of ECGroupSpec does not conform to the syntax for grouping patterns implied by the specified fieldspec.
  • Any two grouping patterns within the patternList parameter of ECGroupSpec are not disjoint, according to the definition of disjointedness defined by the datatype and format implied by the specified fieldspec.
  • Any member of the fieldList parameter within ECReportOutputSpec is an invalid fieldspec.
  • Any member of the primaryKeyFields parameter of ECSpec is not a known fieldname.
  • The implementation does not support the specified primaryKeyFields value of ECSpec with the specified logical readers. An implementation SHALL NOT, however, raise the exception if primaryKeyFields is omitted or its value is a list consisting of the single element epc.
  • For any ECReportOutputSpec instance, all five booleans includeEPC, includeTag, includeRawHex, includeRawDecimal, and includeCount are false, fieldList is empty or omitted, and there is no vendor extension to ECReportOutputSpec.
  • Any value of ECStatProfileName is not recognized, or is recognized but the 2693 specified statistics report is not supported.

InvalidURIException

The URI specified for a subscriber does not conform to URI syntax as specified in [RFC2396], does not name a binding of the ALECallback interface recognized by the implementation, or violates syntax or other rules imposed by a particular binding.

NoSuchNameException

The specified ECSpec name does not exist.

NoSuchSubscriberException

The specified subscriber does not exist.

DuplicateSubscriptionException

The specified ECSpec name and subscriber URI is identical to a previous subscription that was created and not yet unsubscribed.

ImplementationException

A generic exception raised by the implementation for reasons that are implementation-specific. This exception contains one additional element: a severity member whose values are either ERROR or SEVERE. ERROR indicates that the ALE implementation is left in the same state it had before the operation was attempted. SEVERE indicates that the ALE implementation is left in an indeterminate state.

ALELR Operations

define(String readerName, LRSpec spec)

Creates a new logical reader named name according to spec.

undefine(String readerName)

Removes the logical reader named name

update(String readerName, LRSpec spec)

Changes the definition of the logical reader named name to match the specification in the spec parameter. This is different than calling undefine followed by define, because update may be called even if there are defined ECSpecs, CCSpecs, or other logical readers that refer to this logical reader.

getLogicalReaderNames()

Returns an unordered list of the names of all logical readers that are visible to the caller. This list SHALL include both composite readers and base readers.

getLRSpec(String readerName)

Returns an LRSpec that describes the logical reader named name.

addReaders(String readerName, String[] readers)

Adds the specified logical readers to the list of component readers for the composite logical reader named name. This is equivalent to calling getLRSpec, modifying the LRSpec that is returned to include the specified logical readers in the reader list, and then calling update with the modified LRSpec.

setReaders(String readerName, String[] readers)

Changes the list of component readers for the composite logical reader named name to the specified list. This is equivalent to calling getLRSpec, modifying the LRSpec that is returned by replacing the reader list with the specified list of logical readers, and then calling update with the modified LRSpec.

removeReaders(String readerName, String[] readers)

Removes the specified logical readers from the list of component readers for the composite logical reader named name. Any reader name within readers that is not currently among the component readers of the specified logical reader is ignored. This is equivalent to calling getLRSpec, modifying the LRSpec that is returned by removing any references to logical readers in the specified reader list, and then calling update with the modified LRSpec.

setProperties(String readerName, LRProperty[] properties)

Changes properties for the logical reader named name to the specified list. This is equivalent to calling getLRSpec, modifying the properties in the LRSpec according to the table below, and then calling update with the modified LRSpec.

getPropertyValue(String readerName, String propertyName)

Returns the current value of the specified property for the specified reader, or null if the specified reader does not have a property with the specified name.

getStandardVersion()

Returns a string that identifies what version of the specification this implementation of the ALE Logical Reader API complies with.

getVendorVersion()

Returns a string that identifies what vendor extensions of the ALE Logical Reader API this implementation provides.

Example Rifidi App/Client

Personal tools