The Requests feature of SirsiDynix Symphony allows Library users to communicate their needs or requests to the library by sending a particular type of request through e-Library, in person, or through Web Services. Each request can be associated with a particular user, item, or both, depending on its request type. If the request is associated with a user, the WorkFlows wizards can be used to reply to the user. For more information about Requests, see the Requests chapter of the WorkFlows online help.
In order to use Web Services to work with Requests, you need to understand the entire workflow of the available operations.
1. | First, use the lookupRequestListPolicyList operation to find the policyIDs of the different Request List policies that are available. For example, STAFF and PUBLIC. |
This is important because each Request List has a defined set of requests that can be made. So, if I want to build an interface that asks a patron to select the kind of request they want to make, then I need to use the appropriate Request List (PUBLIC in this case).
2. | Use the getRequestListPolicy operation to get the list of all the requestTypes that are available for a specified Request List policyID (see step 1). This requestType becomes an ID for subsequent requests, so we'll need to store it. |
Note: The lookupRequestTypePolicyList operation retrieves a list of all the possible requestTypes. You can use the policyDescription that is returned here for displaying a choice for the user. Therefore, you would cross-reference the requestType of GetRequestListPolicyResponse with the policyID of LookupRequestTypePolicyListResponse.
3. | You use the previous two steps to display a list of request options to a user. After the user selects one of the options, we need to call getRequestTypePolicy using the selected requestType as the policyID of the operation's request. From the information returned, we need to know the value of requestTextRequired so that we know if the Request the user will be making requires a VED (view, edit, delete). The value may be MANDATORY (a VED is required), OPTIONAL (a VED can be supplied if wanted), or NEVER (any VED data supplied will be ignored). |
Note: The other data returned in this operation are important, but can be retrieved through other operations.
4. | Now we need to determine the fields to display to the user. To do this, use the lookupRequestTemplate operation. |
This returns information about whether a userID or catalogKey are required for the Request (if they are, therefore, we must make sure to get that information and include one or both as part of the Request). This operation also returns the default status of the request. You can specify this or another appropriate value (you can get a list of available status values using lookupRequestStatusPolicyList).
The operation also returns a requestEntryInfo (RequestEntryTemplateInfo type) for each field to display to the user in the request form. The entryDescription can be used as the field label. If allowedEditCreate is false, then you should only display the data (rather than let the user change it). Use the required element to help determine which fields the user must supply values for and which you might want to provide validation for. The dataType, minimumSize, and maximumSize elements are also important for validation purposes.
The entryID and absoluteEntryNumber values will be used in the createRequestRequest, so save those with each field as well.
5. | After the user supplies values for the fields on the request form, the next operation to call is createRequest. This operation requires the sessionToken from an authenticated user who has staff level or higher privileges. Therefore, you must first call loginUser for someone other than the patron. Perhaps you want to use a shared staff account or a Web Services-specific staff account to do this. |
As part of CreateRequestRequest, make sure to include values from any required fields. For example, the userID or call number or VED data.
If the request is successful, the system returns the requestKey of the request.
6. | Using the requestKey, you can call lookupRequest to display the information that the system received. |
You can also use lookupRequests to get a list of all the requests submitted by the specified user.
This is a basic workflow for using the requests feature. However, there are some other operations and options available in the service that you may want to take advantage of depending on your library and the configuration of the ILS.
© 2009-2012 SirsiDynix