vending machines for schools pos interface architecture for the reimbursable school meals program
TRANSCRIPT
Vending Machines for Schools POS Interface Architecture
for the
Reimbursable School Meals Program
2iGuard – POS Interface Configuration, Version 6RSMP Equip Config Overview_V6.ppt
Information technology landscape
Vending Machine
6Vending Machine
6Vending Machine
6Vending Machine
6Vending Machine
6Vending Machine
6
Multiple iGuard™ LM520-FSCs:• Configured as Slave devices• Communicate Directly with SuperMaster™ to
Retrieve Student Fingerprint Templates for PINs Not Resident on the Individual Device
• Communicate Directly with iGuard™ API for POS Message Processing
iGuard™ LM-SM-5000: configured as the Master iGuard device
iGuard API
(using the API Server
Module & its Windows
Messaging Capabilities) POS System
Vending Machine
7
<VENDING_REQUEST>
<VENDING_RESPONSE>All iGuard Devices Are Connected to One Another and the API via Router to the In-School LAN
POS System Middleware
In-School Food Service Server
• Connected to other In-School Applications via Router& the In-school LAN
• Source of Student Admin Update Data
<DAILY_STUDENT_ADMIN_UPDATE (T.B.D.)> 1
Application Programs Running on the In-School Food Service Server
<VENDING_REQUEST>
<VENDING_RESPONSE>(i.e. – YES or NO, plus Any Essential Messages to Be
Displayed on The iGuard LCD)
In-School Student Information System Server
(1) Daily_Student_Admin_Update will likely be accomplished through a download from the POS System, since it already receives a daily update from the Student Information System Server; actual iGuard update process is still to be defined.
3iGuard – POS Interface Configuration, Version 6RSMP Equip Config Overview_V6.ppt
Interface communications sequence
Interface Communication Start• Student enters PIN and presents fingerprint to iGuard scanner mounted on
vending machine– iGuard authenticates identity of student using fingerprint template– iGuard retrieves student fingerprint template from SuperMaster™ for any PIN
entered at the machine that is not found in the local device
• iGuard sends a data structure to iGuard API via LAN and waits for response (i.e. – vending decision); agreed data structure will contain:
– PIN of authenticated student• Exact format of PIN to be specified for each POS System • Will likely be the normal POS PIN now used by student in a check-out line
– Any other data elements deemed essential & mandatory by the project team stakeholders
4iGuard – POS Interface Configuration, Version 6RSMP Equip Config Overview_V6.ppt
Interface communications sequence (continued)
• iGuard API receives iGuard data structure and sends to POS Middleware a <VEND_REQUEST> message containing {STUDENT_PIN} and waits for response
• POS Middleware receives <VEND_REQUEST> and relays to POS for processing
• POS System– Receives and processes <VEND_REQUEST> message & processes request from
student for reimbursable meal – Generates <VEND_RESPONSE> message (in an agreed data structure)
• Must contain {VEND_SALE} [This is a YES or NO decision on the sale of a reimbursable meal to the awaiting student] [Mandatory]
• May contain a {VEND_ RESPONSE_MSG} string constant for display in iGuard LCD to the awaiting student [Optional]
– Sends <VEND_RESPONSE> message to POS Middleware• POS Middleware receives <VEND_RESPONSE> message and relays to
iGuard API for processing
5iGuard – POS Interface Configuration, Version 6RSMP Equip Config Overview_V6.ppt
Interface communications sequence (continued)
• iGuard API receives <VEND_RESPONSE> from POS Middleware and relays to the awaiting iGuard
• The awaiting iGuard receives the incoming <VEND_RESPONSE> message and
– Interprets the {VEND_SALE} response & generates vending action command to the appropriate vending machine circuitry
– Displays any {VEND_ RESPONSE_MSG} message in iGuard LCD– Generates a <VEND_RESULT> message containing {MEAL_SERVED} and
sends to the POS Middleware for relay to POS System• {MEAL_SERVED} confirms delivery/non-delivery of a reimbursable meal to the
awaiting student [MANDATORY]• {NOT_SERVED_REASON_CODE} can be included if desired [OPTIONAL] • <VEND_RESULT> completes the audit trail for food service accounting
Interface Communication Complete
6iGuard – POS Interface Configuration, Version 6RSMP Equip Config Overview_V6.ppt
What is the simplest way to transfer these three messages between systems so that communications are independent of the specific POS System that controls food service operations in the school?
• We think it is through the use of the iGuard API and its Windows Messaging protocol…, but
• Is this the best overall technical solution?
Data element transfers required of the interface
iGuard API-to-POS1. <VEND_REQUEST> {STUDENT_PIN}
3. <VEND_RESULT> {MEAL_SERVED} including an optional {NOT_SERVED_REASON_CODE} when desired
POS-to-iGuard API2. <VEND_RESPONSE> {VEND_SALE}
including optional {VEND_ RESPONSE_MSG} when desired
7iGuard – POS Interface Configuration, Version 6RSMP Equip Config Overview_V6.ppt
Data element dictionary
Data Element Definition & Example1. {STUDENT_ID} Normal 4 or 5 digit POS PIN Code used by student at cafeteria line
check-out register [e.g. – 4552]
2. {VEND_SALE} A one-bit switch that authorizes or denies sale of a reimbursable school meal to the awaiting student [e.g. – 1 = YES; 0 = NO]
3. {VEND_ RESPONSE_MSG}
[Optional]
A string constant that can accompany {VEND_SALE} to convey a message to the awaiting student [e.g. – if VEND_SALE = 0, then {VEND_RESPONSE_MSG=“Declined, Please See Cashier”
4. {MEAL_SERVED} A one-bit switch that confirms:• Delivery of a reimbursable meal to the awaiting student, or• Non-delivery of a reimbursable meal to the awaiting student
[e.g. – 1 = DELIVERED; 0 = NOT DELIVERED]
5. {NOT_SRVD_RSN_CODE}
[Optional]
A string constant accompanying {MEAL_SERVED} that conveys to the POS a reason why the meal was not delivered. [e.g. – if VEND_SALE = 0, then {NOT_SRVD_RSN_CODE = 2} if reason for non-delivery was “Vending Machine Malfunction”. Acceptable values and definitions will be predefined.
8iGuard – POS Interface Configuration, Version 6RSMP Equip Config Overview_V6.ppt
Using iGuard API as a common vending interface
• Reasons to use the API (Pro’s)– It is already developed, tested & deployed with other interfaced
applications today – It uses standard Microsoft Windows messaging protocol to communicate – Through this API, we can provide any data structure needed by the
interfaced POS application– This API could serve as the standard interface point for use in
communications with any POS System [using a very small set of standard data elements]
• Reasons not to use the API (Con’s)– It makes the interface OS-dependent (i.e. – Microsoft Windows)– It does not contain as many robust features as would a standard TCP/IP
Client-Server application interface1 for managing• Dropped communications and the resulting missed messages• Reprocessing open / unresolved messages until they are satisfactorily
processed
1 As outlined in POS – iGuard™ Interface Specification, Version 2