Tech Blog

Creating Form Options from Alma APIs

Most data-manipulation applications have some requirement to limit a form field’s value to a controlled list of options. In this case, it’s beneficial to have a way to obtain the acceptable values in order to provide a user interface which offers a select box, radio buttons, or check boxes.

In our example, we’re building a form to update electronic collections. The Update Electronic Collection API accepts an electronic collection object, which is described in this documentation. In this post, we review two ways of obtaining such options in Alma- via code tables and other APIs. We’ll build an Angular service which can be used from a Cloud App, but the approach is equally valid for other development stacks.  Our service will retrieve the options for all relevant fields via these two methods, and the values will be used in the accompanying component HTML form.

Code tables

When a field accepts the values from a code table, the documentation indicates such as shown below:

Our options service calls the Retrieve Code Table API for each code table required for our form (following the guidelines in this blog post). Then for each response, we map the rows into list of code/description pairs, sort the list by description, and save the results to a local variable.

forkJoin(
  /* Code tables */
  this.codes.map(key=>this.restService.call<CodeTable>(`/conf/code-tables/${key}`))
)
.pipe(
  tap(results => {
    this._options = new Options();
    results.forEach(table => 
      this._options[camelCase(table.name)] = 
        table.row.map(r=>({code: r.code, desc: r.description}))
        .sort(sort('desc'))
    )
  })

 

Other APIs

Some fields take the value of another object in the system. These cases are indicated in the documentation, such as the following:

We want to create a generic way to process these “other” APIs and retrieve the options to display to our users. Our options service defines an interface which includes the API’s URL, the name of the field to be used for the code, and a function which returns the description to be displayed. The below example shows the configuration for fields based on integration profiles and licenses.

interface OtherApi { 
  [key: string]: { 
    uri: string, 
    code: string, 
    desc: (obj: any) => string 
  }
};

  private otherApis: OtherApi = {
    Proxies: {
      uri: '/conf/integration-profiles?type=PROXY_DEFINITION',
      code: 'code',
      desc: (i: IntegrationProfile) => i.code.concat(i.description ? ` (${i.description})` : '')
    },
    Licenses: {
      uri: '/acq/licenses',
      code: 'code',
      desc: (i: License) => i.name
    }
  }

Then we proceed to call each API and map the results to a list of code/description pairs using the code field and description function defined in the interface. We also make use of the default pagination parameters that the Alma APIs support in order to automatically retrieve all of the values recursively. Then we sort the list by description, and save the results to the same local variable along with the code table-based results.

The end result of our service is an option list for each code table/API. We can then use the relevant option list to populate the radio buttons or select box in our user interface, as shown in the screen shot below:

The code for the options service is available in this Github repository. Hope it’s helpful for those who have this use case, whether you’re working on a Cloud App or a traditional app.

Leave a Reply