RFDDTAG - EF Endpoint

Binding Function	RFDDTAG
Binding ID	EF_ENDPOINT_POST
Binding Description	Posts Read Events to EF Endpoint for Processing
Purpose	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
Logic	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
Restrictions
Comments	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	URI set to RFDDTAG
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

	IMOVE Rules
	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.

Action

XML Schema

HTTP Post

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

<EventBindingID>EF_ENDPOINT_POST</EventBindingID>

<Tags>

</Tag>

<ObjectType>ASSET</ObjectType>

</Tag>

<ObjectType>PRODUCT</ObjectType>

</Tag>

<ObjectType>ASSET</ObjectType>

</Tag>

</Tags>

</ImoveTagNotification>

** Unmapped Tag

** Asset Object

** Product Object

** Zone value being passed in Antenna tag

Shown below are the configuration Style Sheets

Group

XSL Stylesheets

imove-taglist.xsl

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

<xsl:transform version="1.0" exclude-result-prefixes="rdml" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:rdml="http://www.lansa.com/2000/XML/Function" xmlns:xalan="http://xml.apache.org/xslt">

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

<xsl:template match="/">

<Tags>

<rdml:fragment name="TAGLISTDETAILS" />

</Tags>

</ImoveTagNotification>

</xsl:template>

</xsl:transform>

imove-taglist-details.xsl

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

<xsl:template match="/">

<Tag>

</Tag>

</xsl:template>

</xsl:transform>

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