1 . SCSB API's consumed by LAS

Note: All are RESTful services

2. LAS API’s consumed by SCSB

Hearbeat API
Request API
Item status check
Permanent Withdrawal - Direct
Permanent Withdrawal - Indirect

1 . ITEM STATUS CHECK

Scsb uses LAS item status check api to check the status of item in LAS and process accordingly for any requests such as Retrieval, Recall or EDD. The api is also used in Refile process and status reconciliation process. Whenever there is a need to check the status of an item in LAS this api is called.

LAS will accept JSON-encoded REST GET calls to retrieve the status of an item. Given a barcode, the itemStatus API will return the item’s owner and a string describing the item’s status in the LAS system.

Request format for item status

{ "itemStatus":
 [ 
   { "itemBarCode": "string" } 
   , { "itemBarCode": "string" }  ...
  ] 
}

Response format for item status

{ "dsitem":
 { "prods:hasChanges": boolean,      # IGNORE
   "prods:before":{ JSON data }      # IGNORE
   "ttitem": [
     { "itemBarcode":"string",
        "itemStatus":"string",
        "CustomerCode":"string"
     }  
     , { "itemBarcode":"string",
          "itemStatus":"string",
          "CustomerCode":"string"
      }  ...
   ],
 }
}

Sample items status call

curl -G -g -o - http://$HOST/lasapi/rest/lasapiSvc/itemStatus --data-urlencode \
'filter={ "itemStatus": [ 
  { "itemBarCode": "AR00035602" }
 ] }'

Field Descriptions for itemStatus api call

JSON field	Description / Typical usage	Data Type	Field width
itemBarcode	Item barcode	alphanum	20
CustomerCode	LAS Owner code	alphanum	3
itemStatus	Item Status	String	40

GFA’s PWD and PWI api’s are used during deaccessioning an item.

When an item to be deaccessioned is available in SCSB database then PWD api is called otherwise PWI api is called to perform deaccession.

2 . PERMANENT WITHDRAWAL - DIRECT

LAS will accept JSON-encoded REST calls to permanently retrieve items from ReCAP. The required fields are the owner code (CustomerCode), the item barcode (itemBarcode) and the stop code (destination).

Request format for permanent retrieval item - direct

{ "dsitem":
   { "ttitem": [
     {
       // required fields
       "CustomerCode": "string"
       "itemBarcode": "string"
       "destination": "string"

       "requestorName": "string"
       // or at least one of
       "requestorFirstName": "string"
       "requestorMiddleName": "string"
       "requestorLastName": "string"
     }
     , { "CustomerCode": "string" ... } ...
   ] } // end of ttitem array   
}

Response format for permanent retrieval item - direct

{ "dsitem":
  { "ttitem": [
    {
      // required fields
      "CustomerCode": "string"
      "itemBarcode": "string"
      "destination": "string"

      "requestorName": "string"
      // or at least one of
      "requestorFirstName": "string"
      "requestorMiddleName": "string"
      "requestorLastName": "string"
      “errorCode”: “string”
      “errorNote”: “string”
    }
     , { "CustomerCode": "string" ... } ...
  ] } // end}

The CustomerCode and destination fields must either match the owner and stop codes in the LAS system.
The owner code is used only for verification purposes. It is compared to the code stored in the LAS system, and an error is returned if it does not match
LAS does not separately store the first, middle, and last names of the requestor. If the requestor is blank or missing, it will be constructed from the requestorFirstName, requestorMiddleName, and requestorLastName. If the requestor field contains data, the other three fields are ignored.

Error codes for permanentlyRetrieveItem

errorCode	errorNote	Description
itemNotOnFile		Item barcode not found in LAS
wrongCustCode	CustomerCode: XX	The supplied customer code does not match the one stored in LAS. The correct code is returned in the errorNote.
itemWithdrawn	item status, if available. Otherwise, the message "Status unknown - possible reaccession" is returned.	The item has been permanently withdrawn from LAS.
missingReqData	Comma-delimited list of required fields that were not supplied. If requestor data is missing, the field “requestor” is reported.	One or more required fields were empty
InternalErr	The nature of the error that occurred.	LAS consistency error. These should never occur – but best practice requires they be tested for

Sample permanent retrieval - direct call

curl -i -X POST -H "Content-Type:application/json" \
  http://$HOST/lasapi/rest/lasapiSvc/permanentlyRetrieveItem \
  $HOST/permanentlyRetrieveItem -d \
  '{ "dsitem":{ "ttitem": [ 
     { "CustomerCode":"AR", "itemBarcode":"AR00000612", "destination":"AR",
       "requestor":"requestorName" },
] }'

Field Descriptions for permanentlyRetrieveItem

JSON field	Description / Typical usage	Data Type	Field width
CustomerCode	Owner code	alphanum	3
itemBarcode	Item barcode	alphanum	20
destination	Delivery stop	alphanum	8
requestor	Item requestor	string	70
requestorFirstName	First name of requestor	string	28
requestorLastName	Last name of requestor	string	28
requestorMiddleName	Middle name of requestor	string	16
errorCode	Error code (output only)	alphanum	16
errorNote	Additional detail (output only)	string	60

3 . PERMANENT WITHDRAWAL - INDIRECT

LAS will accept JSON-encoded REST calls to mark retrieve items as permanently withdrawn from ReCAP. The required fields are the owner code (CustomerCode) and the item barcode (itemBarcode).

Request format for permanent retrieval indirect

{ "dsitem":
  { "ttitem": [
    {
      // required fields
      "CustomerCode": "string"
      "itemBarcode": "string"
    }
    , { "CustomerCode": "string" ... } ...
  ] } // end of ttitem array   
}

Response format for permanent retrieval indirect

{ "dsitem":
  { "ttitem": [
    {
      // required fields
      "CustomerCode": "string"
      "itemBarcode": "string"
      “errorCode”: “string”
      “errorNote”: “string”
    }
    , { "CustomerCode": "string" ... } ...
  ] } // end of ttitem array   
}

The CustomerCode field must either match the owner code in the LAS system, or must be mappable to it. The current documentation assumes that the actual LAS codes will be used.
The owner code is uttsed only for verification purposes. It is compared to the code stored in the LAS system.

Error codes for permanentlyRetrieveItemIndirect

errorCode	errorNote	Description
itemNotOnFile		Item barcode not found in LAS
wrongCustCode	CustomerCode: XX	The supplied customer code does not match the one stored in LAS. The correct code is returned in the errorNote.
itemWithdrawn	Item status, if available. Otherwise, the message "Status unknown - possible reaccession" is returned. (This should never happen).	The item has been permanently withdrawn from LAS.
missingReqData	Comma-delimited list of required fields that were not supplied. If requestor data is missing, the field “requestor” is reported.	One or more required fields were empty
itemNotOut	Item status	Item is not “OUT” according to LAS, and therefore cannot be indirectly withdrawn.
InternalErr	The nature of the error that occurred.	LAS consistency error. These should never occur – but best practice requires they be tested for

Sample permanent retrieval indirect call

curl -i -X POST -H "Content-Type:application/json" \
  http://$HOST/lasapi/rest/lasapiSvc/permanentlyRetrieveItemIndirect \
  $HOST/permanentlyRetrieveItem -d \
  '{ "dsitem":{ "ttitem": [ 
     { "CustomerCode":"AR", "itemBarcode":"AR00051608" }
] }'

Field Descriptions for permanentlyRetrieveItemIndirect

JSON field	Description / Typical usage	Data Type	Field width
CustomerCode	Owner code	alphanum	3
itemBarcode	Item barcode	alphanum	20
errorCode	Error code (output only)	alphanum	16
errorNote	Additional detail (output only)	String	60

NOTES: Use of Color

In field description tables, three colors are used:

JSON field	Description / Typical usage	Data Type	Field width
Green	Required input fields	alphanum	3
White	Optional input fields	alphanum	20
Blue	Output only	alphanum	16

Unless otherwise indicated, input fields are also output fields.
Some fields (such as the requestor first, middle and last name) are only conditionally required. The notes associated with each call explains any such exceptional conditions