SIP messages supported
OLIB SIP Server supports these SIP messages
|Request message||Response message|
|09 (Checkin) [i.e. return]||10 (Checkin Response)|
|11 (Checkout) [i.e. issue]||12 (Checkout Response)|
|15+ (Add Hold) [i.e. add reservation. NB – titleno must be supplied, not copyno or copy barcode]||16 (Add Hold Response)|
|15- (Delete Hold) [i.e. cancel reservation. NB – titleno must be supplied, not copyno or copy barcode]||16 (Delete Hold Response)|
|17 (Item Information)||18 (Item Information Response)|
|23 (Patron Status)||24 (Patron Status Response)|
|29 (Renew)||30 (Renew Response)|
|37 (Fee Paid)|
|63 (Patron Information)||64 (Patron Information Response)|
|65 (Renew All)||66 (Renew All Response)|
|93 (Login)||94 (Login Response)|
|97 (Request ACS Resend)|
|99 (SC Status)||98 (ACS Status)|
SIP messages not supported
OLIB SIP Server does not support the following SIP messages:
01 (Block Patron)
15* (Modify Hold)
19 (Item Status Update)
25 (Patron Enable)
35 (End Patron Session)
Circulation transactions are generally driven by the logged In Location in OLIB Web. The equivalent in SIP is the AO field. Every message that a SIP Client can send to a SIP Server includes an AO field. In an OLIB system, this must contain the key ID of the location which is regarded as the Logged in Location for that SIP Client. It must be defined by the SIP Client. The OLIB SIP Server cannot define it for the SIP Client. If the SIP Client does not provide a valid location key ID in the AO field in any request messages that it sends to the OLIB SIP Server, the OLIB SIP Server will default the logged in Location for that transaction to ‘XXXXX’.
The logged in Location is used to determine such things as holidays, closed periods, etc (relevant when calculating return dates for an issue transaction, for example). So it is important that the SIP Client supplies a valid location key ID in the AO field in all requests that it sends to the OLIB SIP Server.
It is also important that the' XXXXX' location in OLIB (Default Location for NCIP and SIP circ transactions) is configured appropriately so that any requests that are sent from a SIP Client with nothing in the AO field are processed correctly.
99 (SC Status)
The following is a typical SC Status message:
The OLIB SIP Server returns the following ACS Status message:
The BX field indicates which SIP messages are supported. In character position order:
- Patron Status Request (23)
- Checkout (11)
- Checkin (09)
- Block Patron (01)
- SC/ACS Status (99)
- Request SC/ACS Resend (97)
- Login (93)
- Patron Information (63)
- End Patron Session (35)
- Fee Paid (37)
- Item Information (17)
- Item Status Update (19)
- Patron Enable (25)
- Hold (15)
- Renew (29)
- Renew All (65)
Note that the location key ID in the AO field is taken from the system default location as defined in OLIB Defaults. It is up to the SIP Client whether it uses this information.
23 (Patron Status)
The following is a typical Patron Status message:
The OLIB SIP Server returns the following Patron Status Response message:
24 00020101014 120240|BHGBP|BLY|CQY|AAJSMITH|AESmith, John|BV15.00|AY0AZE4FD
63 (Patron Information)
The following is a typical Patron Information message:
The block "__Y_______" is the summary field. Each character is set to either Y or blank (represented in the above example by an underscore). Setting a character to Y indicates that the ACS should return additional information about the user. In the above example, the 3rd character is set to Y, which indicates that the ACS should return the items that the user currently has on loan in the AU field in the Patron Information Response message.
The OLIB SIP Server returns the following Patron Information Response message:
64 00020160809 122347000100020002 0000AOMAIN|AA180|AESmith, John|BLY|BV6.00|BEjohn.email@example.com|AY0AZDD39
Note that the AO field in the Patron Information Response message will contain whatever the SIP Client passed to the SIP Server in the AO field in the Patron Information request message.
Patron Information may include the Patron email address in the BE field, depending on OLIB Defaults configuration.
If OLIB Defaults> Circulation Defaults> Include Email In BE (SIP) is null or Yes, the User email address will be included.
11 (Checkout) [i.e. issuing]
The following is a typical Checkout message:
11NN20101005 08062920101021 030629AOMAIN|AAJSMITH|AB111111|AC|
The OLIB SIP Server returns the following Checkout Response message:
121NUY20101014 121215AOMAIN|AH20101104 120000|AAJSMITH|AB111111|AJMarmalade and jam making for dummies|BV1.30|AF|AY0AZDC91
Note that the BV field indicates whether a charge has been raised against the user’s account for this issue transaction
09 (Checkin) [i.e. returning]
The following is a typical Checkin message:
09N20100930 09384820100930 093848AP|AOMAIN|AB111111|AC|
The OLIB SIP Server returns the following Checkin Response message:
101YUN20110217 075306AOMAIN|AB111111|AQ|AJThe 7 pillars of wisdom|AAJSMITH|CK001|AY0AZE777
The following is a typical Renew message:
29YN20110217 07542120110224 075421AOMAIN|AAJSMITH|AB111111|
The OLIB 8.1 SIP Server returns the following Renew Response message:
301YUY20110217 075421AO|AAJSMITH|AB111111|AJThe 7 pillars of wisdom|AH20110310 000000|CK001|AY0AZE44D
Note that the ok field and the renewal ok field both indicate that the renewal was carried out. The new return date is supplied in the AH field.
15+ (Add Hold) [i.e. reserve]
The following is a typical Add Hold message:
The AJ field must contain the record number (i.e. the title number) of the item being reserved. A title reservation will be placed. Copy reservations are not supported in the OLIB 8.1 SIP Server.
The OLIB SIP Server returns the following Hold Response message:
161N20110217 075711AO|AAJSMITH|AB|AJThe 7 pillars of wisdom|BR1|AY0AZEA91
The reservation is placed as either a confirmed or unconfirmed reservation depending on whether the Submit Res. As Active field is set to Yes in the user’s location record.
15- (Delete Hold) [i.e. cancel reserve]
The following is a typical Delete Hold message:
The AJ field must contain the record number (i.e. the title number) of the item whose reservation is being cancelled.
The OLIB SIP Server returns the following Hold Response message:
The following is a typical Login message:
Note that, although the CO field (login password) is included (because it is a required field), it must never be set to anything. The OLIB 8.1 SIP Server does not include decryption facilities, so the password cannot be included in the CO field in an encrypted form. But if it is included in plain text, it will be written to the OLIB SIP Server log file and will therefore be clearly visible. This is unacceptable to OLIB customers. Thus, the password must never be included in the CO field in a Login request message.
The OLIB SIP Server returns the following Login Response message if the login is successful (i.e. if there is a user record in the database with a value in the barcode field that matches the value included in the CN field in the Login request message):
Please note that, in the OLIB SIP Server, the Login Response message will always indicate that the login is successful, irrespective of whether the barcode supplied in the Login request message’s CO field matches a barcode in OLIB. Thus, it is recommended that the Login service is not used with the OLIB SIP Server.
Barcode and other identifiers for the user
As soon as you enter the User's Barcode, OLIB displays that user's details, e.g. Address, Balance, Loan Items. You can then issue items to the user.
You can also use other IDs from the User record:
- Alternative Barcode
All of these IDs can be entered into the Issue/Returns/Renewals screen in the User field. OLIB then displays the User details, with the User's Barcode in the User field. It is then possible to issue items to that user. This feature allows you to use other IDs in your organisation, e.g. a student services number, to issue items to students.
Similarly, in SIP, when the user identifier that is stored in any of the above fields is supplied in the AA field of a SIP Patron Status request or a SIP Patron Information request, the correct user record is returned in the response message.
When a user identifier is supplied in the AA field of a SIP Checkout request, the item is issued to the correct user.
A record is written to the crossfield_user_auth_log table each time the new cross-field user authentication function is called.