Axiell WebAPI home page > Documentation > Release notes for WebAPI

Release notes for WebAPI

Release notes

Bug fixes

  • OAI would return the same set of data for all resumptiontokens. This was fixed in
  • The WebAPI no longer retrieved nested, merged-in fields from a linked database. Fixed in
  • The new generic media plugin generated an error when retrieving video content via getcontent. This was fixed in version
  • When trying to insert/update records using grouped XML via the WebAPI, while the group name associated with a repeating set of fields matches the name of one of the fields in the group, the WebAPI was generating two alternative occurrences of that field and split the data across them. Fixed in
  • Previously, if a record contained an invalid tag it could not be retrieved by the WebAPI or an OAI request. An OAI harvest would even stop on such a record. This was fixed in now, for records with errors a log entry is added and an empty record is listed in the OAI response.
  • OAI performance for the listrecords command was not as good as it could be. The fix in gives a substantial performance improvement for this request.
  • The adlibweb.xml <xmlType>raw</xmlType> setting didn't output raw xml when using OAI: always grouped XML was generated. Fixed in
  • OAI responses didn't quite validate to the OAI-PMH validator. Fixed in
  • When a record contained undefined tags, it could not be retrieved via the WebAPI or OAI. OAI ouput would even stop on encountering such a record. The fix makes sure that for records with errors a log entry is added and that an empty record is listed in the OAI response. Fixed in
  • OAI Error code handling was incorrect or unclear in some situations, namely for unknown resumptionTokens, a wrong verb and retrieving a specific identifier. Fixed in version
  • In a Full Text indexed database, a "when" search gave an error because an index from the old index structure was searched. Fixed in
  • In a Full Text indexed database, an "autocomplete" which references a long text field failed because an index from the old index structure was searched. Fixed in
  • A scan in a Full Text indexed database used the old index tables people_name or thesau_term instead of the new full text index table. Fixed in version
  • The op="" attribute in a <field> element, as introduced in was ignored when the field used indirection. Fixed in
  • Some facets queries failed when the facet referenced a linked field because the query included domain = '' in the where clause when the domain field was actually stored as NULL. Fixed in
  • WebAPI command=getcontent gave a "cannot load file or assembly 'Magick.NET-Q16-AnyCPU, Version=" error. Fixed in version
  • Posting data with a non-unique term and a flexible domain that was assigned to only one of those terms, failed incorrectly with an error message that multiple linked records were possible so no link could be made. Note that if multiple records for the same term do contain the same domain and this term and domain are posted for a write action, then the same error will be generated, but correctly so this time because the WebAPI cannot make a choice between records which have the same term and the same domain. Fixed in
  • A WebAPI search in a Full Text indexed database, using the contains operator, returned a SQL error: Invalid column name 'strippedterm'. This was fixed in WebAPI version
  • An OAI from date search did not match the modification date in a database with indexed links: records from before the specified date were returned too. Fixed in version
  • An insertrecord call for a record with a link to an existing record, inserted the record all right but tried to create a new linked record instead of making the link to the existing other record. This was fixed in
  • Multilingual fields were excluded from the output, if one multilingual value was empty. This was fixed in version
  • When searching with the contains operator on two or more words in a Full Text enabled database, the words were treated as a phrase (words in that particular order) instead of independent words in any random order. This was fixed in version

New functionality

New generic Media Server plugin

From, a new generic Media Server plugin has been implemented that is capable of passing through requests to different external media storage/retrieval services, using the mapping of the arguments passed to the getcontent command to a service URL. Assumptions for this to function:

  • The external service URL supports the HEAD request which is used to determine the content type of the requested media.
  • The requested media is returned by the external service as a byte stream.

Configuration of this new plugin is done like this:

<imageServerConfiguration name="generic">
    <ImagePlugin type="Axiell.GenericService.Plugin.GenericPlugin, Axiell.GenericService.Plugin">

The ServiceUrl element holds the external service URL with the place holder elements between % characters. In the example above, the %value% place holder means that the incoming WebAPI getcontentrequest has a value= argument, and the value of that argument is placed in the ServiceUrl. All arguments passed in are accessible and can be used to form the new value of the ServiceUrl to be called, so from the following getcontent call:

the following placeholders can be used (also listed are the values referenced by the placeholders)

Placeholder - Value

%command% - getcontent

%server% - azure

%value% - IMG_6936.JPG

%height% - 200

%width% - 200

Any custom argument you add to the getcontent call can also be used. So something like:

gives you the option to use a %source% placeholder in your ServiceUrl which will then be replaced with the value Axiell before calling the URL.

If an access token for the external service is needed you can specify that in the AccessToken node in the plugin configuration section and that will then be used as a Bearer token on the request to the external service.

Support for the HEAD request for the Axiell WebAPI has been added too. You can do a HEAD request with the getcontent call which will only return the header info with the content type and not the image itself: the body will be empty. With a normal GET request you will also get the media itself.

New basic POST plugin

To be able to POST basic requests to an ingest/storage service and return the response back to the caller, a new plugin is introduced. The plugin takes the request message from a specific configured field in a specific record from a specific configured database and will POST the raw contents to the URL configured for the plugin and relays the response back to the caller. In version of the WebAPI this proxy handler option has been added. The configuration in adlibweb.xml is like this:

 <proxyServerConfiguration name="myproxy">
    <ProxyPlugin type="Adlib.InternetService2.Proxy.GenericProxy">
      <token>some access token</token>

and can be called with a string formatted like:

...wwwopac.ashx?proxy=<proxy server definition>&value=<record priref>

The required settings in the configuration are:

  • database - the name of the database containing the records storing the payload value
  • field - the English field name or tag where the payload to be sent is stored
  • url - the end-point to POST the payload to
  • token - an access token
  • mimetype - the type of content (application/json or text/xml)

The proxy doesn’t need a command parameter. The result of the URL call is returned to the caller of the API. The configured mime-type is used for both the POST to the external URL and the content type of the API response.

All search syntax options implemented for Full Text indexed databases

Previously there was no way to differentiate contains any from contains all: a contains search would always be a contains any search. And a contains all type of search was not available for q searches either. In WebAPI version this has been solved. The operators containsall (short version: $), containsany (short version: _) and containsphrase (short version: ~) have been implemented. So with the following sample data:
- record 1 containing ti = buster keaton
- record 2 containing ti = diane keaton

You can do the following searches:

title containsany “keaton buster”
title _ “keaton buster“
would return both records as they both have keaton in the title.

title containsall “keaton buster”
title $ “keaton buster“
would return record 1 as that has both buster and keaton

title containsphrase “keaton buster”
title ~ “keaton buster“
wouldn't return any record because neither contains this phrase.

Moreover, in the <searchfields> section in adlibweb.xml, you can now specify per search field which operator to use if you perform a q search with the WebAPI. You do that by including an op="" attribute in a <field> element. The following operators are supported here:

= (also the default if the op attribute is not used)
>, >=, < and <=
containsall or $
containsany or _
containsphrase or ~

For example:

<field op=”containsall”>title</field>
<field op="containsall">description</field>
<field op="=">object_number</field>
    <field op="containsall">term.word</field>

OAI performance improvement

The SQL query to harvest each new set of records (after a resumption token) has been optimized, leading to an OAI performance improvement.

JP2 (jpeg 2000) support added

Since jpeg 2000 support in browsers is limited to Safari, only download (without display in the browser) of the jp2 file type is now fully supported by the Axiell WebAPI and up, while for display the file must be converted to a normal jpeg file by adding the &imageformat=jpeg parameter to the WebAPI getcontent call. The size of the downloaded image is determined by either the maxWidth and maxHeight setting in the image server configuration (set them to 0 for retrieving an unscaled file) or (if no explicit settings for width and height were made) by the default maximum dimensions used by the WebAPI.

New Azure Blob Storage media plugin

From WebAPI version, an Axiell.AzureBlobStorage.Plugin.dll plugin for the Axiell WebAPI is available to allow the ingest and retrieval of files in and from Microsoft Azure Blob Storage. Please see the full topic for more information.