SIP2: Protocol for self-checkout (UXPROD-1001)

[SIP2-9] SIP2: FOLIO Status - Startup and shutdown of SC Created: 19/Nov/18  Updated: 25/Jun/19  Resolved: 09/Apr/19

Status: Closed
Project: sip2
Components: None
Affects versions: None
Fix versions: 1.0.0
Parent: SIP2: Protocol for self-checkout

Type: Story Priority: P3
Reporter: Hkaplanian Assignee: Martin Tran
Resolution: Done Votes: 0
Labels: q1-2019-spillover
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Attachments: PDF File sip2_developers_guide.pdf    
Issue links:
Defines
defines UXPROD-1002 SIP2: Protocol for self-checkout - in... Closed
Gantt End to Start
has to be done before SIP2-44 SIP2: Setup test environment for exch... Closed
Sprint: 3Ms-SIP2-61, 3Ms-SIP2-60
Story Points: 5
Tester Assignee: Magda Zacharska
Epic Link: SIP2: Protocol for self-checkout

 Description   

FOLIO must send this message in response to a SC Status message.
Do health check of the Folio modules that will be used.
For this user story we assume that most the values are hardcoded.

Senario 1
1. Library staff starts up self-checkout system
2. Self-checkout system sends SC Status (99) message
3. FOLIO sends Status (98) message

Senario 2
1. Library staff shuts down self-checkout system
2. Self-checkout system sends SC Status (99) message
3. FOLIO sends Status (98) message



 Comments   
Comment by Magda Zacharska [ 18/Mar/19 ]

The self checkout station will send status message to FOLIO:
99<status code><max print width><protocol version>

status code: It is a status of the self checkout unit. 1-char, fixed-length, required field. Allowed values: 0 (OK) or 1 (out of paper) or 2 (about to shut down)
max print width: This is the maximum number of characters that the unit can print. 3-char, fixed-length required field
protocol version: 4-char, fixed-length required field: x.xx

In the response FOLIO will return following message:
98<on-line status><checkin ok><checkout ok><ACS renewal policy><status update ok><off-line ok><timeout period><retries allowed><date / time sync><protocol version><institution id><library name><supported messages ><terminal location><screen message><print line>

on-line status: 1-char, fixed-length required field: Y or N.
checkin ok: 1-char, fixed-length required field: Y or N. A Y indicates that the SC is allowed to check in items
checkout ok: 1-char, fixed-length required field: Y or N. A Y indicates that the SC is allowed to check out items
ACS renewal policy: This is FOLIO renewal policy 1-char, fixed-length required field: Y or N. A Y indicates that the SC is allowed by FOLIO to process patron renewal requests as a policy
status update ok: 1-char, fixed-length required field: Y or N. FOLIO policy for the SC. A Y indicates that patron status updating by the SC is allowed, e.g., a patron’s card status can be changed to blocked
off-line ok: 1-char, fixed-length required field: Y or N. This field should be Y if the ACS supports the off-line operation feature of the SC. The ACS must also support no block charge requests from the SC when it comes back on-line.
timeout period: 3-char, fixed-length required field. This timeout period until a transaction is aborted should be a number expressed in tenths of a second. 000 indicates that the ACS is not on-line. 999 indicates that the time-out is unknown
retries allowed: 3-char, fixed-length required field. Indicates the number of retries that are allowed for a specific transaction. 999 indicates that the retry number is unknown
date / time sync: 18-char, fixed-length required field: YYYYMMDDZZZZHHMMSS May be used to synchronize clocks. The date and time should be expressed according to the ANSI standard X3.30 for date and X3.43 for time. 000000000000000000 indicates a unsupported function. When possible local time is the preferred format.
protocol version: 4-char, fixed-length required field: x.xx
institution id: variable-length required field, the library's institution Id. Field Code: AO
library name: variable-length optional field, library's name. Filed Code: AM
supported messages: variable-length required field. This field is used to notify the SC about which messages FOLIO supports. Field Code: BX

Position Message
0 Patron Status Request
1 Checkout
2 Checkin
3 Block Patron
4 SC/ACS Status
5 Request SC/ACS Resend
6 Login
7 Patron Information
8 End Patron Session
9 Fee Paid
10 Item Information
11 Item Status Update
12 Patron Enable
13 Hold
14 Renew
15 Renew All

terminal location: variable-length optional field. FOLIO could put the SC’s location in this field. Field Code: AN
screen message: variable-length optional field. Provided a way for the ACS to display messages on the SC screen. They are never required. When used, there can be one or more of these fields, which are then displayed on consecutive lines of the screen. If they are too long, then the trailing portion of the field will be left out. The message can contain holds, fines, disabled card, library branch. Field Code: AF
print line: variable-length optional field. Provides a way for the ACS to print messages on the SC printer. They are never required. When used, there can be one or more of these fields, which are then printed on consecutive lines of the printer. Field Code: AG

Comment by Matt Reno [ 03/Apr/19 ]

Just a note here, we can't respond to SC status until a login message is placed. Scenario 1 and 2 should probably be updated to include "1a. SC sends a login message." For scenario 2, it is possible that the SC is currently logged in when the shutdown is initiated, but login is still a prerequisite for SC status to be accepted.

Comment by Magda Zacharska [ 03/Apr/19 ]

I think what you describe is covered by SIP2-11 Closed user story. This user story assumes that login message is not required. We're still awaiting the response from Chalmers if their SC are configured to use Login message.

According to the 3M Developer Manual (attaching to this user story) the login message is not required. SC might be configured to send certain character strings and wait for a certain character strings from ACS. At least this is how I understand the communication between SC and ASC

Comment by Matt Reno [ 04/Apr/19 ]

From a protocol perspective, that is true. But from a practical standpoint we cannot accept SC status without a login first in a multi-tenant setup. With Chalmers, sure they are the only one, but this wouldn't work when another tenant is on the system. Though, I think there are bigger issues here with respect to multi-tenant support.

Comment by Magda Zacharska [ 04/Apr/19 ]

Let's discuss the best approach and prioritize the work.

Comment by patty.wanninger [ 04/Apr/19 ]

Magda Zacharska, this ticket is marked "In-reveiw," but we (the manual testing team) have no way to test it. Can you assign yourself as tester?

Comment by Martin Tran [ 08/Apr/19 ]

4/8 - Developer's notes:

  • Laid out basic request handling structures
  • Provided a temporary hard-coded configuration for ACS status. Values will need to be finalized
  • Used Freemarker template to generate SIP responses
  • At this moment doesn't do anything with the request. Maybe in the future we could save the SCStatus request's pertinent information, such as max print width to properly trim/format the messages, and respond dynamically to protocol version.
Comment by Martin Tran [ 09/Apr/19 ]
  • Laid out basic request handling structures
  • Provided a temporary hard-coded configuration for ACS status. Values will need to be finalized
  • Used Freemarker template to generate SIP responses
  • At this moment doesn't do anything with the request. Maybe in the future we could save the SCStatus request's pertinent information, such as max print width to properly trim/format the messages, and respond dynamically to protocol version.
Generated at Fri Feb 09 00:14:51 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.