Navigation: Filtering & Collection > Event Bindings > Available Bindings > Internal Bindings >

RFDDTAG - EF Endpoint

Still need help? Create a Support Ticket with Stratum Support

Send comments on this topic.

← Previous Next →


Binding Function



Binding ID



Binding Description

Posts Read Events to EF Endpoint for Processing



This is a universal binding that enables enhanced functionality within the TagNet Extension Framework (as listed below in Post EF logic). This leverages the variable RFDDTAG URI to send an event payload to an endpoint that performs the business logic using a number of custom supplied XSL style sheets to format the data into XML.


Note that this Binding can be used whether the Reader is Server managed or via the SRC



Collects whatever tags are seen during a read event cycle from a given portal and performs the following logic:

Prior to sending to EF

Supports full GPIO script as a result of standard MATCH / NOMATCH/ NOTAG variables.

Processes IMOVE rules is so specified in Binding properties and automatically transfers inventory from location A to Location B. Sends out email if IMOVE has [EMAIL] keyword anywhere in description. Note: SRC read events use their actual read event time as the Inventory transaction time and not when the transaction is processed (server time). This is to account for different time zones of where the SRC may be relative to TagNet Server time zone as well as transmit latency between SRC location and server.

Triggers Camera support if so configured in the Physical Reader profile

Supports all Filter keywords (including *RSSI, *PRODTYPE, *ANTENNA)

Supports Binding Email Exceptions. Email notification is sent when an error is encountered.

Sends out Tag Event data as listed below via an HTTP post to the EF defined endpoint. The box below shows the generated XML.

Tag Event attributes (Binding ID, Location ID, Schedule timestamp, Event Cycle, etc.)

Tag attributes (TagID, Object Type, Physical reader, Seq, timestamp, Antenna, RSSI)

Logic within EF after receiving payload

Processes IMOVE rules (if configured here) and pushes to the EF browser based Event Viewer

Processes Zone based directionality logic if Zone passed in payload (as opposed to antenna ID) or Reader/Antenna makes a match in the Zone file. See further logic details below

Processes Departmental substitution logic when *ANY  (from location) and *SOURCE (to Location) specified in the IMOVE Rule. This if for customers that introduce a level in the inventory location matrix that implies asset ownership regardless of what physical location the asset is moved to. For example: if a matrix is setup as Facility.Building.Dept.Room.Location and the tag is moved, the Dept value (Level3) will be moved to the same (level3) of the target location. Refer to Inventory Movement Rules for further examples.

Enables an unmapped tag that is seen at a read point to be mapped and put into inventory. Configure in Imove API Settings

Enables certain object fields to be updated during an IMOVE rule. Configure in Imove API Settings

Enables Event Group logging to occur for directional zone based logic. Configure in Imove API Settings

Enables specialized 'Hold State' logic evoked after a successful IMOVE transaction. Configure in Imove API Settings





 This binding can be tested with the EF Dynamic Tag Event test utility

Files Updated

RFDLOCIN, RFDLOCIH (Insert), RFDTAGVS (tag last seen by Location/Reader/Ant), RFDTAGPR (tag last seen globally),  TagHoldState (if feature enabled)

Program Name


Binding Setup

Binding Properties

Email Notification

The email address to send binding specific alerts. Note: This overrides the default SMTP Recipient value under System Settings


UDA Grouping

UDA's at both the Asset instance level and Tag Inventory level instance can be included in the Dynamic XML by grouping them in a UDA Group Name


Dwell Time

Dwell time prevents the tag from being included when seen again at the same read point until dwell time expires.  Refer to the the Binding Change for detailed explanations of this directive. NOTE: If using Zone based logic - Dwell time at binding level should not be used here if as this is controlled at the Zone level



Refer to the the Binding Change for detailed explanations of each directive. NOTE: These directives are ignored here as the EF manages IMOVE rules as well as event visualization via its Browser based event viewer.


Data Layout & Style Sheets

This section specifies the content type (XML today with JSON in future), the Data layout, and the style sheet names that have been edited to included your specific attributes. Note that these style sheets are for the individual tag transaction payloads as denoted by the *TAGLIST Data Layout selection.

The Style Sheets to support this binding need to be copied out of \TagNet Extension Framework\EF Web\custom-xsl folder into a user defined folder (e.g. Custom-xsl) as they will be overwritten upon subsequent updates to TagNet. The folder path for the modified style sheets would then be TagNet\Integrator\JSMInstance\Custom-xsl



The below XML is sent to the EF Endpoint listener.



XML Schema



<?xml version="1.0" encoding="UTF-8"?>

<ImoveTagNotification xmlns:xalan="">







    <Tag xmlns:xalan="">










<Tag xmlns:xalan="">










<Tag xmlns:xalan="">










<Tag xmlns:xalan="">





















** Unmapped Tag









** Asset Object









** Product Object













** Zone value being passed in Antenna tag


Shown below are the configuration Style Sheets



XSL Stylesheets


<?xml version="1.0" encoding="UTF-8"?>


<xsl:transform version="1.0" exclude-result-prefixes="rdml" xmlns:xsl="" xmlns:rdml="" xmlns:xalan="">


<xsl:output method="xml" omit-xml-declaration="no" indent="yes" xalan:indent-amount="2"/>


<xsl:template match="/">




  <EventBindingID><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDREQBND']/@value"/></EventBindingID>

  <LocationID><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDREQLOC']/@value"/></LocationID>

  <ScheduleDate><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDREQDAT']/@value"/></ScheduleDate>

  <ScheduleTime><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDREQTIM']/@value"/></ScheduleTime>

  <EventCycle><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDREQCYC']/@value"/></EventCycle>



    <rdml:fragment name="TAGLISTDETAILS" />









<xsl:transform version="1.0" exclude-result-prefixes="rdml" xmlns:xsl="" xmlns:rdml="" xmlns:xalan="">


<xsl:output method="xml" omit-xml-declaration="yes" indent="yes" xalan:indent-amount="4"/>


<xsl:template match="/">



  <TagID><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDPLTGHX']/@value"/></TagID>

  <ObjectType><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDTGOBJT']/@value"/></ObjectType>

  <ReaderID><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDPLRDID']/@value"/></ReaderID>

  <SequenceNumber><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDPLTGSQ']/@value"/></SequenceNumber>

  <TagLogDate><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDPLTGDT']/@value"/></TagLogDate>

  <TagLogTime><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDPLTGTM']/@value"/></TagLogTime>

  <Antenna><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDPLTANT']/@value"/></Antenna>

  <RSSI><xsl:value-of select="/rdml:function/rdml:fields/rdml:field[@name='RFDPLRSSI']/@value"/></RSSI>







Zone Based logic enabled in this binding


When a read event is logged at a given antenna, the parent ZONE is determined and any further read events by any antenna included in that zone will be ignored for the dwell period. This is done to ignore stray 'bounce back' reads when traveling through a doorway.

Zone read point relationships are maintained in the TagNet Zone Maintenance however for this binding the RSSI values are not used and can be left blank.

Dwell is controlled at the Zone level, this is declared via a bracketed [value] in the Zone description

A custom 'last seen' table (EF.ImoveLastSeen) is used to maintain the last read Zone registered for each TagID.

As the tagged object moves from one side of the doorway threshold to the other (e.g. leaving or entering room), the read zone on the opposite side will register the tag and thus its dwell time begins.

It is important to note that if tagged object doubles back in the direction it came from before the dwell period ends, then it will be be ignored and the IMOVE transaction will be missed. Thus it is important to consider the dwell period carefully, too long and it will miss double-backs... too short and there is a chance that a stray tag read could move it back from where it came from.

NET Change is only at the antenna level thus if enabled will only work partially. This will reduce tag event logging considerably however it will disallow tags from doubling back on certain conditions. Additionally this needs to be implemented at the Zone level.

Shown below is a pictorial representing this logic, from a physical perspective the below items need to be considered:

Pure Readability - (RFID 101) is the read zone strong enough to see the tags regardless of directionality?

Bounce Back - when traveling through doorway A--> B and 'A' sees tag after its dwell expires and 'B' does not have time to self-correct (its dwell is active) as it continues on and leaves doorway.

Read Ahead - self correcting if passing in the direction of the read zone, however if rogue bounce when traveling by (e.g. door open) then will not self-correct.

Ensure you don't have conflicts with your Rules; if you have multiple Zones pointing to the same reader, the logic will pick the first occurrence alphabetically and that will be sent to the EF for processing. The EF IMOVE logic will then query back to the IMOVE rules table and pick the first occurrence matching the [From Location + Logical reader/Physical reader/antenna] or [From Location + Read Zone]. The first one will be picked up alphabetically by IMOVE rule name.

Is this the right directional binding logic for your use case? This logic is designed when deploying multiple zones whereas each read point in the zone (such as inside perimeter of a room) could be managed by different readers thus at a choke point doorway in this example, Zone A can be managed from Reader 1 and Zone B can be managed from Reader 2. So in this case you don't have the advantage of the strongest antenna wins because read points are spread over multiple physical readers. If you have a single reader managing all read points on both sides of the choke point, then this binding is not best suited for your application. Refer to section on implementing directional logic.


The below is an abstract schematic (top view) of a given doorway and representative antennas & read zones




Copyright © 2024 Stratum Global, Inc.