updatepointerfile

For more information about saved searches, see the Axiell Collections online Help.

Syntax

command=updatepointerfile&<parameter>=<value>&...

• database (String) name of the database table on which to perform the updatepointerfile function. The name of this database table must have been specified in the adlibweb.xml file.
• data (String) the saved search (aka pointer file) to write: data constitutes the data in the form of XML which must be written back to the database. Use the POST method and software of your own making to send pointer file data to the web server.
  Posted data may contain a hit list; if not, the provided search is executed before the hit list is written. (The hit list is the repeated <hit> node.)
  To update an existing saved search, use the assigned number of the relevant pointer file. The entire saved search will be overwritten, not just the XML tags you submit, so make sure you submit all metadata which the saved search should contain, even if it was already present in the saved search. Use getpointerfile to learn how the XML to be written back should look like: you can leave out empty XML tags and the diagnostics part.
  Include the writeAllowed setting in adlibweb.xml, otherwise saved searches can’t be written to the database.
  The user who wants to write a saved search to the database, must have write access in Axiell Collections. Make sure that the write process runs under the right identity.

  Note: the Axiell WebAPI can write saved searches in two different XML formats: the default format and the 'structured' format, although you must NOT specify this format explicitly. The WebAPI automatically detects which format you are trying to write. These formats have the following characteristics:

  • The root element is named adlibXML.
  • The saved search is contained in a record element within a child element from the root with the name recordList.
  • The saved search metadata is contained within the record element and may comprise the title of the saved search, the owner (the name of the user who created the saved search), a repeated hit element containing the record numbers from this saved search, and possibly some SDI information and an accesslist with user names and associated access rights. If you also want to write custom metadata with the saved search, then you'll have to format your saved search xml in the structured type. In this format, the repeated hit element in the saved search metadata must be replaced by a hitlist element containing repeated record elements in which the priref attribute indicates the record number. The hitlist/record node may then contain any xml you wish, allowing you to add custom metadata about the saved search. Custom metadata can only be added via the WebAPI, not via the creation of saved searches in Collections applications. Click here for more information about the structured XML type for saved searches.
• output (String) [optional] output format to be returned. Values for output can be either json or xml (xml is the default, so you don't need to specify that explicitly). However, the output format produced by jQuery applications is always JSON, so you don't need to specify the output type there either.
  Read more about JSON output here.
• callback (String) [optional] returns JSON output wrapped in brackets with your callback function name, for AJAX requests: <callback function name>( <JSON output> ); You don't need to specify output=json, because the output format is JSON by default.