Tech Blog

Discovery-Optimized APIs: Display Logic Rules

In a previous blog post, we explained the rationale behind offering discovery-optimized APIs. In a recent Alma release, additional support has been added to take display logic rules into consideration when calculating request options for a title. Check out “Discovery-Optimized APIs: Requests and Request Options” for an introduction to the request options API.

In this post we show how to use the display logic rules option in our Blacklight reference application.

First, let’s define a display logic rule in Alma to hide the general electronic service offering “general help” on a resource if the user is defined as Staff.

Now I call the request options API without the new parameter:

And I receive an array of 6 request options, among them the general electronic service we noted above.

  "request_option": [
    { ... },
    { ... },
    { ... },
      "type": {
        "value": "GES",
        "desc": "General Electronic Services"
      "request_url": "",
      "general_electronic_service_details": {
        "code": "LIBR",
        "name": "Request Assistance for this Resource!",
        "description": null,
        "public_name": "Request Assistance for this Resource!",
        "avail_for_physical": true,
        "avail_for_electronic": true
    { ... },
    { ... }

Now when I run the API again with the new consider_dlf=true parameter, I receive an array with only 5 entries, without the specified GES.

Discovery implementation

Now I can make a small change to my application to include the new parameter when retrieving the request options. The result is that my request drop down box contains only the options as calculated by the display logic rules:

So now if you have an application which allows users to place requests, you can still manage you logic in Alma and expose only the relevant request options according to the specified user.

Leave a Reply