Adlib API home page > Documentation > The API in detail

The API in detail

The client-side Adlib API (Application Programming Interface) is a function library implemented using a .NET HTTP handler, named wwwopac.ashx. This API is currently accessible through three different interfaces: a Windows file (which can be addressed via .NET programming languages like C#), a jQuery plugin, and Url requests. The Adlib API can be used to build your own (web) applications based on an Adlib SQL Server database or Adlib Oracle database. The service oriented architecture of this software – small building blocks instead of massive applications – offers the ideal foundation for it.

Axiell ALM Netherlands offers wwwopac.ashx, wwwopac.exe and adserver.exe as API components. In this reference documentation we’ll only discuss wwwopac.ashx, the main component.

The wwwopac.ashx is meant for client-side applications and web applications. This API component has been developed, with respect to wwwopac.exe (whilst keeping the calling mechanism compatible as much as possible), to allow for the following extra functionality:

  • better performance and scalability. The wwwopac.ashx is not a CGI extension like wwwopac.exe, it is a stateful .NET 2.0 http handler (uses IIS), and therefore it doesn’t need to be initialized again for every new query. The wwwopac.ashx is loaded into memory only once, as opposed to the wwwopac.exe, which is reloaded at each individual query. The advantage is obvious: faster response times. The downside is that the adlibweb.xml file and database info files are only loaded at application startup time. If you make modifications in your database .inf files then you will need to restart your application (for instance by recycling the application pool in which wwwopac.ashx runs.
    An Adlib search statement is converted by wwwopac.ashx to a single sql query, while wwwopac.exe would convert it to multiple sql statements. Moreover, the wwwopac.ashx interfaces directly to SQL Server or Oracle using these sql queries, and executes combined searches completely on the server, rather than combining partial searches on the client; this speeds up searching drastically. Also, all dataset checks and security checks are performed server side.
    With this API component there’s also no chance of memory leakage or resource leakage, because every instance of wwwopac is disposed of after use.
  • simplified configuration. In adlibweb.xml only three levels remain (a global one, a group and database level), and all settings are valid on all levels; further, in the names of the XML tags, camel notation is now consistently used, although pre-existing XML tags are still accepted in their original lower casing so that compatibility with the adlibweb.xml for the old wwwopac.exe is ensured. Click here for an example.
  • added functionality. The wwwopac.ashx offers access to more services, namely a data query service via the Adlib expert search language, the possibility to retrieve a list of pointer files, the option to write, remove or update records, to read, write or delete pointer files, the possibility to retrieve metadata from Adlib .inf files, functionality for image processing, and data validation.
  • an extended search language. Additional possibilities of Adlib SQL and Adlib Oracle databases allow for more search options – this means that wwwopac.ashx can only be applied to these types of database (Microsoft SQL Server 2005 and 2008 or Oracle 10g+). One addition is the option to search remote indexes via linked fields, even nested if desired. You can also search phonetically and use left, right or middle truncation. See further on in this documentation for a full overview.
    The wwwopac.exe parameters FLDx, OPRx, VALx, TRCx and BOOLx are no longer supported, and neither is dontkeepaspectratio. Use the search parameter instead, with a full Adlib search statement. The Adlib search statement is much more powerful than the old parameters. It is the responsibility of the user interface code to compose the Adlib search statement.
  • improved image handling. The wwwopac.ashx offers more image handling functionality* than wwwopac.exe. This functionality also improves the performance of Adlib in relation to image processing, especially for the retrieving and scaling of images for display in the Adlib Media Viewer or for thumbnail display on the brief display of a search result. The improved performance is accomplished by not resizing the images to be retrieved for every request, but by reducing or enlarging the image only when first requested, and then saving the result in a cache folder so that for a following identical request the next time a ready-made resized image can be retrieved. So the use of wwwopac.ashx for retrieving images is most useful if the images to which you link in your (museum) visual documentation records are pretty large files. For use in thumbnail displays, the image handler already scales those images on the server or retrieves earlier created thumbnails, which results in less data traffic on your network, it lightens the workload of the Adlib core software en also diminishes memory use of the work station enormously.
    You can also use this functionality to directly and safely store images linked to in a visual documentation record, in an Adlib SQL or Adlib Oracle database.
    A third advantage is that you can hide the path to linked images from users who are only allowed to view records: only the name of the image could still be visible.
    The wwwopac.ashx is not a standard part of a local Adlib system and won’t be installed automatically. However, the software can indeed become the basis of your Adlib web application, if that application runs on an Adlib SQL or Adlib Oracle database (although images may still be stored in the file system). When using wwwopac.ashx, you are of course free to decide whether or not to apply the new image handling possibilities.
    * Note that during the development phase of this functionality, there was talk of separate software named Image Handler which could have been used alongside wwwopac; however, the relevant functionality is now only available as part of wwwopac.ashx.
  • multiple interface styles. These include: REST (send a URL and receive XML), DLL (managed C# and VB).
    • Below schema illustrates the possibilities in the anatomy of a (web) application implementing the Adlib API.