> Edgeflow Reference > Configuring and Using Edgeflows

Edgeflow Reference

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Configuring and Using Edgeflows

The following sections describe how to configure and use edgeflows:

 

Overview of RFID Edgeflow Technology

The ALE engine of WebLogic RFID Edge Server collects and filters data from RFID-labeled items moving through the supply chain. This process involves no business logic. However, data gathered during this process can be sent through local edge flows on the Edge Server, which apply business logic to the RFID data at the edge. Data that results from this workflow processing may be sent to the organization's enterprise data center or other destinations.

You construct edge flows to satisfy use cases. The edge flows are constructed from Edgeflow modules, which take input messages (event or programming cycle reports, or output from other modules), and emit edge flow messages according to embedded business logic.

Edge flows can be viewed as a series of actions triggered by a related event. For example, the observation of an EPC on an RFID-tagged case of consumer goods travelling down a conveyor belt could increment an LED counter, change a stack light to green, send an EPCIS event, or send a notification to another system.

Figure 2-1 shows edge flows in the context of EPC data.

Figure 2-1 Edgeflows in Context

Edgeflows in Context

Structure of Edgeflow Modules

Every edgeflow module has configuration parameters that determine the exact behavior of each module instance. For example, the External Sender module has parameters that let the user specify an XSLT file, destination URI(s), input data connections, and error output connections for a given instance of that module, as shown in Figure 2-2.

Figure 2-2 External Sender Module

External Sender Module

An edgeflow module instance can receive data from, and send data to, other module instances. It sends data to other module instances through output ports and receives data from other module instances through input ports.

A module can have multiple input ports and multiple output ports. The different ports are typically based on the different functions of the ports. For example, the Tag Accumulator module adds the tags it receives on its Add port to its internally-accumulated list and deletes the tags it receives on its Delete port from its internal list. Similarly, it sends the running list of tags on the Running Tag List output port and the final list of tags on the Final Tag List output port.

The input and output ports of edgeflow modules are typed, which means that they accept or send only specific data types defined by the port. For example, the Tag List Filter module accepts only ECReports in its input port and sends only Tag Lists through its tag list output port.

The structure of the edgeflow modules is illustrated in Figure 2-3.

Figure 2-3 Edgeflow Module Structure

Edgeflow Module Structure

Each module can contain the following:

The number of input and output ports is based on the function of the module. All ports are typed.

The WebLogic RFID Edge Server provides the edgeflow modules shown inTable 2-1.

Table 2-1 Available Edgeflow Modules
Aggregation Reconciler
Bar Code Decoder
Counter
Directional Filter
Directional Filter (Auto Configuration)
ECSpec Subscriber
EPC Cache Manager
EPCIS Aggregation Event Generator
EPCIS Manifest Query
EPCIS Object Event Generator
External Sender
HTTP Receiver (One Way)
HTTP Receiver (Request Response)
Numeric Display (EDI111 LED)
Preset Message (Dynamic)
Preset Message (Static)
Serial Number Replenisher (BEA Service)
Serial Number Replenisher (Static)
Stack Light
State Filter
Tag Accumulator
Tag Counter
Tag List Filter
Tag Verifier
Trigger Receiver
Wait For Time
Wait For Trigger
Write Tag
XML Generator
XML Parser
XML Transformer
   

 

Differences Between Legacy Workflow Modules and Edgeflow Modules

Prior to the version 3.0 release of the Edge Server, workflow modules were large single-focused components that addressed specific use cases. These modules included a Bidirectional Portal Module, an Observe Portal Module, and Numeric Display Module, Stack Light Module and Message Notifier Module helper modules

Starting with version 3.0 of the Edge Server, limited support is provided for the legacy modules. New legacy module instances cannot be created using the Admin Console and messaging between the legacy modules and the new edgeflow modules is not supported. For more information about the legacy modules, see Workflow Module Reference for Versions Prior to 3.0 .

The legacy modules are replaced by a number of small, reusable edgeflow modules that provide finer granularity functions and can be used as building blocks to satisfy use cases. The building blocks can be used to create simple or complex edgeflows and provide a flexibility that minimizes the need to write custom modules.

 

Prerequisites to Configuring Edgeflows

Before you configure an edgeflow, you may need to configure the ECSpec whose reports will provide input to the edgeflow. See Using the RFID Edge Server Administration Console for instructions on configuring an ECSpec.

You must also have a working installation of the WebLogic RFID Edge Server, including one or more hardware devices (stack lights, RFID devices, and LED displays).

If your edgeflow sends EPCIS events to the RFID Enterprise Server, you will also need a working installation of the WebLogic RFID Enterprise Server.

 

Configuring Edgeflows

You configure edgeflows by configuring edgeflow modules and connecting them together, using the RFID Edge Server Administration Console. Edgeflow modules are connected to one another by referring to the name of the module and the name of the input port that is receiving output from another module.

Consider the example shown in Figure 2-4. The B to A Tag List output of this Directional Filter (Auto Configuration) module is sent to the Tag List input port of the interior-door-observeB2A EPCIS Object Event Generator module.

Figure 2-4 Connecting Edgeflow Modules

Connecting Edgeflow Modules

Creating an Edgeflow Module: Main Steps

To define an edgeflow module:

  1. Start the RFID Edge Server Administration Console if it is not already running.
  2. Select the Edgeflow Modules node under the Site and Edge Server you are working with.
  3. Choose the type of operation to perform:
    1. To define a new module, click New.
    2. To create a copy of an existing module, select the module and click Clone.
  4. Give the module you are creating a unique Module Name.
  5. Choose the Module Type from the drop-down list.
  6. Configure the edgeflow module by filling in values for the fields according to the information provided in Edge Flow Module Reference.
  7. Click OK to save your changes.

Defining an Edgeflow: Main Steps

To define an edgeflow:

  1. Start the RFID Edge Server Administration Console if it is not already running.
  2. Check that notification drivers are set up for all types of notifications you will be using.

    3. These drivers are defined in the RFID_EDGE_HOME/etc/edge.props file, where RFID_EDGE_HOME is the directory where you installed the RFID Edge Server software.

  3. Configure any RFID devices you will be using.

    4. For testing purposes, as an RFID device, you can configure the Reader Simulator software included with the RFID Edge Server.

    For more information on RFID device configuration, see the RFID Reader Reference and any manufacturer documentation provided with your hardware.

  4. Create the ECSpecs and associated ECReports required by this edgeflow.

    5. For more information on creating ECSpecs, see Using the RFID Edge Server Administration Console.

  5. Define edgeflow modules as described in steps 1-7, in Creating an Edgeflow Module: Main Steps.
  6. Create edge flow subscriptions for ECSpecs, as necessary.
    1. Select EdgeFlow Module for the Type field.
    2. The Module field should contain <edgeflow module name>:port-name. For example, door-taglist:Start.
  7. When you click Subscribe, the ECSpec will send ECReports to the edgeflow destination you specified.

    8. Active subscriptions allow you to test that the edgeflow is functioning correctly, and that the Edge Server is sending messages to the configured locations and devices.

  8. Test the edgeflow by simulating a tag observation using the Reader Simulator, or by holding a tag near the antennas on your RFID reader.

    9. You should see evidence of edgeflow activity (Edgeflow messages arriving at notification destinations and delivery of ECReports).

 

Edgeflow Examples

The RFID Edge Server 3.0 software provides a number of sample edgeflows, available in the RFID_EDGE_HOME/samples/EdgeFlows directory. Each of the edgeflow samples can be imported into a RFID Edge Server 3.0 system and modified to meet specific customer needs.

Table 2-2 Sample Edgeflows
ShippingReceivingDoor
Demonstrates a simple observe use case, where EPCIS object events are generated.
StoreInteriorDoor
Demonstrates determining the direction in which tags are moving and generating related events.
PalletBuildingStation
Demonstrates a pallet building use case, in which EPCIS Aggregation events are generated.
SmartShelf
Demonstrates a smart shelf use case.
TagCommisioning
Demonstrates a tag printing use case.
PalletReconciliation
Demonstrates how to use edgeflow modules to perform a pallet reconciliation; that is, shipment reconcilliation against a manifest.

Use the following steps to import the sample edgeflows:

  1. Start the following components:
    1. Ensure that your RFID hardware is connected and powered on or start the Reader Simulator.
    2. Start the Edge Server.
    3. Start the Administration Console
    4. Start the Reader Simulator
  2. In the Administration Console, import the edgeflow example of you choice:
    Select File > Import
    EDGE_SERVER_HOME\samples\EdgeFlows\ExampleDirectory\ExampleName.xml

This imports the ECSspec (if applicable), the edgeflow modules, and starts the edgeflow. You can view or modify the module configurations through the Administration Console.

The following sections describe the sample edgeflows. You can load each of the edgeflow samples and use the Administration Console to view the configuration properties of each module.

Note: The first example, Example: Simple Observe Edgeflow, uses screen shots to provide some context about how edgeflow modules connect via the user interface. Having established this context, subsequent examples do not require or include the screen shots.

Example: Simple Observe Edgeflow

This example (shipping-receiving-door.xml) creates an edgeflow that reads tags, creates an OBSERVE Object Event for each tag, and sends the event to the Edge Server console. This example represents a shipping or receiving door that reads all tags and reports OBSERVE events for the tags that pass through.

The example uses the reader simulator and reports events to the Edge Server console. In a production environment, the reader simulator would be replaced by a real reader and the events would be reported to an external system using JMS or HTTP.

A diagram of this edgeflow is shown in Figure 2-5.

Figure 2-5 Example Observe Portal

Example Observe Portal

The following sequence summarizes the functions of each component of this edgeflow:

  1. An ECSpec (door-ecspec) is configured to always read from antenna 1 (ConnecTerra1) of the reader simulator. This ECSpec has one ECReport, report_0, which contains an EPC List.
  2. A subscription to the door-ecspec ECSpec is made by the door-taglist Tag List Filter module, as shown in Figure 2-6. The Tag List Filter module extracts tag information from the EPC List in an ECReport and creates a tag list.
    3. Figure 2-6 Tag List Filter Subscription to door-ecspec

Tag List Filter Subscription to door-ecspec

  1. The Tag List Filter module extracts the tag information from the ECReports created by the ECSpec, and sends the resulting tag list to the door-observe EPCIS Object Event Generator module, as shown in Figure 2-7.
    2. Figure 2-7 Tag List Filter Module Sends Output to EPCIS Object Event Generator

Tag List Filter Module Sends Output to EPCIS Object Event Generator

  1. The EPCIS Object Event Generator module (door-observe) creates an OBSERVE object event for each tag it receives and sends the object event (in an EPCIS Document) to the External Sender module, as shown in Figure 2-8.
    2. Figure 2-8 EPCIS Object Event Generator Sends Output to External Sender

EPCIS Object Event Generator Sends Output to External Sender

  1. The External Sender module (door-sender) receives the EPCIS Document, converts it to its XML representation, and sends it to the Edge Server console, as shown in Figure 2-9.
    2. Figure 2-9 External Sender Sends OBSERVE Event to the Edge Server Console

External Sender Sends OBSERVE Event to the Edge Server Console

The destination URI for the External Sender module is defined as: console:SHIPPING-RECEIVING-DOOR.

You could instead configure this destination URI to use HTTP to send the events, using the following format: http://<host>:<port>/module/<modulename>:<portname>.

EXAMPLE: Pallet Building Edgeflow

This sample (pallet-building-station) demonstrates a pallet building use case. In the example, the EPCs that are read during the process are accumulated to create and EPCIS Aggregation event for the pallet.

The aggregation event is created when no tags are detected for 10 seconds (the Tag Accumulator module is configured to accumulate for 10 seconds).

The aggregation event is then sent to a specified destination. In this example, the event is sent to the Edge Server console. Any errors that occur during this process are also sent to the Edge Server console.

A diagram of this example is shown in Figure 2-10.

Figure 2-10 Example Pallet Building Station

Example Pallet Building Station

The following sequence summarizes the function of each component of the Pallet Building station example:

  1. An ECSpec (pallet-station-ecspec) is configured to always read from antenna 1 (ConnecTerra1) of the reader simulator. This ECSpec has one ECReport, report_0, which contains an EPC List and a Tag List.
  2. A Tag List Filter module (pallet-station-taglist) subscribes to the ECSpec, takes the ECReports produced by the ECSpec, extracts the tag information, and sends it to the Add port of a Tag Accumulator module.
  3. The Tag Accumulator module (pallet-station-accumulator) accumulates the tags until it detects that no tags have been read for a 10-second period. This 10-second time period is configured by a value of 10000 milliseconds in the Stable Set field.

    4. After the 10 seconds have passed, the Final Tag List is sent to an EPCIS Aggregation Event Generator module Tag List input.

  4. The EPCIS Aggregation Event Generator module (pallet-station-aggregator) identifies EPCs that contain the pattern urn:epc:pat:gid-64-i:10.70.* as being a parent. All other tags are used as child tags.

    5. An aggregation ADD event is generated from the Tag List input and sent to an External Sender module. If an error occurs during this process, an error message is sent to an additional External Sender module.

  5. An External Sender module (pallet-station-sender) sends the generated aggregation to the Edge Server console via the Destination URIs configuration field.
  6. An External Sender module (pallet-station-error-sender) sends any errors that occurred to the Edge Server console via the Destination URIs configuration field.

Example: Directionality

This sample (store-interior-door.xml) demonstrates a use case where tags, and the direction they are moving while passing through a door, are detected. For the detected tags, an EPCIS event is generated, and includes the detected direction of a tag while passing through a doorway. The EPCIS event is sent to external destinations.

Figure 2-11 shows a diagram of this example.

Figure 2-11 Directionality Example

Directionality Example

The following sequence summarizes the function of each component of the Directionality edgeflow:

  1. The examples does not require that the user explicitly create an ECSpec.

    2. Instead, the Directional Filter (Auto Configuration) module (interior-door-directionality) creates an ECSpec for the read points (configured via the A-side and B-side logical reader names) and subscribes itself to receive notifications of EPC sightings. Logical reader names are required to be configured for each point .

    Specifically, it configures two ECSpecs (interior-door-directionality-DirectionalityPointA and interior-door-DirectionalityPointB) that read from antenna 1 (ConnecTerra1) and antenna 2 (ConnecTerra) of the reader simulator, respectively.

    Consider the antenna locations to be the two sides of the door.

  2. The Directional Filter (Auto Configuration) module then uses the ECReports produced by the ECSpecs to determine tag direction. The following ECReports are generated:
    • Add report for point A
    • Delete report for point A
    • Add report for point B
    • Delete report for point A
  3. The Directional Filter (Auto Configuration) module has two tag lists output ports: one for tags moving from point A to point B and one for tags moving from point B to point A.

    4. The tag lists are sent to two EPCIS Object Event Generator modules: interior-door-observeA2B:Tag List and interior-door-observeB2A:Tag List

  4. The EPCIS Object Event Generator module (interior-door-observeA2B) creates OBSERVE object events for tags that are read moving from point A to Point B. These events are sent to an External Sender module, interior-door-senderA2B:Input as EPCIS documents.
  5. An EPCIS Object Event Generator module (interior-door-observeB2A) creates OBSERVE object events for tags that are read moving from point B to point A. These events are sent to an External Sender module, interior-door-senderB2A:Input as EPCIS documents in XML format.
  6. External Sender modules (interior-door-senderA2B) and (interior-door-senderB2A) send the Object events to two different ports of the Edge Server console based on their direction, console:TO-SALES-FLOOR or console:TO-STORE-ROOM.

Example: Pallet Reconciliation

This example (pallet-reconcilliation.xml) demonstrates a pallet reconciliation use case that includes sending HTTP messages between edgeflow modules and external systems.

There are two components of this example: the edge server edgeflow component that you import via pallet-reconcilliation.xml, and a target Web container component that generates and returns a manifest.

For the Web container component, the example includes Java code, XML files, and .JSP files to create a manifest in response to a request. The example is already built, but includes a build file in case you want to make changes and rebuild.

Note: Your modules would typically request the manifest from an external system. However, to keep the example simple it assumes that the supplied web client on localhost is used to get the manifest.

The directions for running this portion of the example are provided in Configuring the External System to Generate the Manifest.

Figure 2-12 provides a diagram of this example.

Figure 2-12 Pallet Reconciliation

Pallet Reconciliation

The following sequence summarizes the function of each component of the Pallet Reconciliation example:

  1. An ECSpec (reconciliation-ecspec) reads tags added at Antenna 1 of the Reader Simulator.
  2. A subscription to the ECSpec is made by a Tag List Filter module (reconciliation-aggregationTagListBuilder). This module takes the ECReports produced by the ECSpec, extracts the tag information and sends it to the Tag List input port of an EPCIS Aggregation Event Generator module.
  3. An Aggregation Event Generator module (reconciliation-aggregationEventGenerator) creates an aggregation for the tags. The parent tag is defined as urn:epc:id:gid:10.10.1 and EPCs that match urn:epc:pat:gid-64-i:*.*.[2-7] are defined as children in the aggregation. An aggregation event is generated and sent to an Aggregation Reconciler module. If an error occurs during processing, the error is sent to an External Sender module.
  4. An Aggregation Reconciler module (reconciliation-reconciler) receives the aggregation from the aggregation generator and sends to an External Sender to request a manifest for the aggregation. The manifest is received on the Aggregation Reconciler module Manifest input port.

    5. The acceptable match is 100 percent and extra children are allowed.

    The Aggregation Reconciler module uses five external sender modules to send the results of the reconciliation to different ports on the Administration Server Console:

    reconciliation-result-parentMatched-sender:Input sends the result of reconciliation (boolean indicating success or failure).

    reconciliation-result-childrenMatched-sender:Input sends the result of reconciliation (boolean indicating success or failure).

    reconciliation-result-missing-sender:Input sends a manifest identifying any missing entries.

    reconciliation-result-extra-sender:Input sends a manifest identifying extra entries.

    reconciliation-result-error-sender:Input sends an error report.

  5. The External Sender module (reconciliation-aggregationEventExternalSender) receives the aggregation on its input port (reconciliation-aggregationEventExternalSender:Input), and sends the aggregation to the external system (localhost is used in the example for simplicity) as an HTTP message.

    6. The External Sender also sends console notification so that the Edge Server console displays the aggregation event sent.

Configuring the External System to Generate the Manifest

The Web container portion of this example is already built and you do not generally need to rebuild it. However, if you make changes and need to rebuild, the build file is located in samples\EdgeFlows\PalletReconciliation\manifestGenerator\build.bat .

Use the following steps to run this example:

  1. Deploy the application to your Web container. For example, you can copy the entire manifestGenerator directory to the WebApps directory of Apache Tomcat and then deploy the manifestGenerator application.
  2. The default URL target is: http://localhost:8080/manifestGenerator/eventReceiver.

    3. If the context path for the application is not http://localhost:8080/manifestGenerator, then you must change the destination URIs field in the reconciliation-aggregationEventExternalSender module.

  3. Start a browser window pointing to the sample context, which is http://localhost:8080/manifestGenerator unless you have changed it.
  4. Using the Edge Server Administration Console, Select ECSpec > reconciliation-ecspec > Suspend.
  5. Start the Reader Simulator and select all tags on Antenna 1.
  6. Return to the ECSpec pane, select reconciliation-ecspec > Unsuspend. Wait a few moments and then select Suspend. This creates a notification with tags selected on Antenna 1.
  7. On the Edge Server console, you will see the Aggregation Event Sent to Manifest Generator message, such as the following:
    8. <!-- AggregationEventSentToManifestGeneratorClient -->
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <ns7:EPCISDocument xmlns:ns4="http://www.bea.com/ns/rfid/enterprise/epcis-captur
    e/xsd/2.0/" xmlns:ns7="urn:epcglobal:epcis:xsd:1" xmlns:ns3="urn:epcglobal:epcis
    -query:xsd:1" xmlns:ns5="http://www.bea.com/ns/rfid/enterprise/epcis-masterdata/
    xsd/2.0" xmlns:ns2="http://www.unece.org/cefact/namespaces/StandardBusinessDocum
    entHeader" xmlns:ns6="urn:epcglobal:epcis-masterdata:xsd:1">
        <EPCISBody>
            <EventList>
                <AggregationEvent>
                    <eventTime>2007-07-24T13:59:42.725-04:00</eventTime>
                    <parentID>urn:epc:id:gid:10.10.1</parentID>
                    <childEPCs>
                        <epc>urn:epc:id:gid:10.40.4</epc>
                        <epc>urn:epc:id:gid:10.20.2</epc>
                        <epc>urn:epc:id:gid:10.50.5</epc>
                        <epc>urn:epc:id:gid:10.70.7</epc>
                        <epc>urn:epc:id:gid:10.60.6</epc>
                        <epc>urn:epc:id:gid:10.30.3</epc>
                    </childEPCs>
                    <action>OBSERVE</action>
                    <bizStep></bizStep>
                    <disposition></disposition>
                    <readPoint>
                        <id></id>
                    </readPoint>
                    <bizLocation>
                        <id></id>
                    </bizLocation>
                    <bizTransactionList/>
                </AggregationEvent>
            </EventList>
        </EPCISBody>
    </ns7:EPCISDocument>
  8. On the browser window, the page displays notification of a new aggregation event arrival and a generated manifest. A sample browser window is shown in Figure 2-13.
    9. Figure 2-13 Browser Window Displaying Generated Manifest

Browser Window Displaying Generated Manifest

  1. You can edit the manifest and click the Send button to send it to the Aggregation Reconciler (reconciliation-reconciler). The manifest for the aggregation is sent as an HTTP message to the manifest input port of the module. Results are produced based on the manifest being used to reconcile the aggregation.
  2. You should see results of the send in the status area of the Web browser page and on the Edge Server console. A sample Web browser page is shown in Figure 2-14.
    3. Figure 2-14 Browser Window Confirming Send Status

Browser Window Confirming Send Status

  1. Sample reconciliation output displayed on the Edge Server console is shown in Listing 2-1.
    2. Listing 2-1 Sample Edge Server Reconciliation Output 
    <!-- ReconciliationResult-ParentMatched -->
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <ns4:PrimitiveType xsi:type="xs:boolean" xmlns:ns4="http://www.bea.com/ns/rfid/e
    dgeflow/xsd/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns3
    ="urn:epcglobal:ale:xsd:1" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns2
    ="http://schemas.connecterra.com/EPCglobal-extensions/ale">true</ns4:PrimitiveTy
    pe>
    <!-- ReconciliationResult-ChildrenMatched -->
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <ns4:PrimitiveType xsi:type="xs:boolean" xmlns:ns4="http://www.bea.com/ns/rfid/e
    dgeflow/xsd/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns3
    ="urn:epcglobal:ale:xsd:1" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns2
    ="http://schemas.connecterra.com/EPCglobal-extensions/ale">true</ns4:PrimitiveTy
    pe>
    <!-- ReconciliationResult-Extra -->
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <ns4:Manifest xmlns:ns4="http://www.bea.com/ns/rfid/edgeflow/xsd/1.0" xmlns:ns3=
    "urn:epcglobal:ale:xsd:1" xmlns:ns2="http://schemas.connecterra.com/EPCglobal-ex
    tensions/ale">
        <children/>
    </ns4:Manifest>
    <!-- ReconciliationResult-Missing -->
    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <ns4:Manifest xmlns:ns4="http://www.bea.com/ns/rfid/edgeflow/xsd/1.0" xmlns:ns3=
    "urn:epcglobal:ale:xsd:1" xmlns:ns2="http://schemas.connecterra.com/EPCglobal-ex
    tensions/ale">
        <children/>
    </ns4:Manifest>
Note: The reconciliation-reconciler module waits indefinitely for manifest messages for every aggregation event. If you cannot send a manifest to this module, you may need to reset the module using the Administration Console: Select reconciliation-reconciler > Configure > OK. This will reset the module and return it to the normal ready state.

Example: Tag Commissioning

This sample demonstrates how to configure printing-related modules to print EPCs, based on bar code input.

As part of this sample, a GUI (invoked via the run.bat file) is provided to allow users to send bar code data to the printing modules. When bar code data is sent to the modules, an EPC is printed to the selected EPC field of Antenna 1 of the Reader Simulator.

Figure 2-15
Browser Window Confirming Send Status
Tag Commissioning

The following sequence summarizes the function of each component of the Tag Commissioning example:

  1. An HTTP Receiver (Request Response) module (tag-commissioning-http), accepts barcode input from the user and sends it to a Bar Code Decoder module.

    2. To run this example, the bar code GUI (invoked via run.bat), which is shown in Figure 2-16, sends the bar code you specify. The status area displays the response.

    You must enter a bar code that conforms to one of the supported formats.

    Figure 2-16 Print Sample Console Bar Code GUI

Print Sample Console Bar Code GUI

  1. The Bar Code Decoder module (tag-commissioning-barcode) converts the bar code to an EPC pattern required by the printer modules and sends it to a Write Tag module. For bar codes that already contain a serial number reference (SSCC) the EPC ID is generated. Otherwise, the EPC ID pattern is generated.
  2. The Write Tag module (tag-commissioning-write) contacts an EPC Cache Manager (tag-commissioning-cachemgr:PCSpec Request) to create an edge side cache, creates a PCSpec for the item type, and prints an EPC from the created cache.
    1. The EPC Cache Manager module (tag-commissioning-cachemgr) creates and replenishes the cache by contacting a Serial Number Replenisher (Static) module.
    2. The Serial Number Range (Static) module (tag-commissioning-static-replenish) supplies EPCs for the configured range to the EPC Cache Manager module.
  3. Returning to the Write Tag module (tag-commissioning-write) module, it sends a PCWriteReport to the input port of a Tag List Filter module. The Tag List Filter module extracts tag information from the PCWriteReports and creates a tag list.
  4. The Tag List Filter module (tag-commissioning-taglist) provides the tag list to the Tag List input of an EPCIS Object Event Generator module.
  5. The EPCIS Object Event Generator module (tag-commissioning-event-generator) sends Object Events (the response) to the HTTP Receiver module.

  Back to Top       Previous  Next