updaterecord

To update (edit and save) an existing record via de Axiell WebAPI, you have to know the record number (priref) or some other unique identifier of the record you want to update. Prirefs or other identifiers can be obtained by searching for the desired records first, in any of the different ways described elsewhere in this documentation. Prirefs are used by default: if you don't have prirefs at your disposal, use the updatetag parameter with a specified tag to indicate what other unique identifier field to use to look up an existing record to update. If you provide neither, the WebAPI will try to create a new record which might lead to duplicate-key error messages.
Although not a strict requirement, it is probably safest to lock the record before editing it, so that no-one else can edit the record simultaneously. After updating or writing a record it will be unlocked automatically. Only if you decide not to update a locked record, you'll have to unlock it explicitly. Any field locks (possibly applied in Adlib, not Collections) in the existing record will be respected, so you can't overwrite locked field contents.
The writing of records resolves links and it manages reverse links, but internal links are not yet dealt with. However, non-preferred terms in validated fields are automatically replaced by their preferred terms. Moreover relations between records can automatically be deleted when updating a record, but linked field data in the updated record will be deleted only when the link reference field value gets set to empty.
Further, linked fields in your database may have write-back fields defined for them, which means that in a catalogue record the user can edit or enter information in merged-in fields belonging to a linked record, to be stored with the linked record when the catalogue record is saved. Data you write to such merged-in fields will be written back to the relevant linked record if for the linked field the appropriate write-back fields have been specified.

Syntax

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

• database (String) name of the database configuration on which to perform the updaterecord function. The name of this database table must have been specified in the adlibweb.xml file.
• updatetag (String) in case the uploaded data doesn't contain record numbers of the records to update, you must use the updatetag parameter with the tag of some other uniquely indexed field as the parameter value, which field values are actually included in the uploaded data. Failing to include a priref or other unique identifier in the uploaded data, will cause the WebAPI to try and create new records instead of updating existing ones, which may result in duplicate-key error messages.
• data (String) the record(s) to write; data constitutes the data in the form of adlibXML which must be written back to the database. Use the POST method in software of your own making to send record data to the web server.
  Include the writeAllowed setting in adlibweb.xml, otherwise records can’t be written to the database.
  The user who wants to update a record in the database, must have write access in the Axiell Collections application (which access rights can be set up via Axiell Designer). Further make sure that the write process runs under the right identity (which is determined by the setup of the WebAPI application in IIS).
  All fields that are referenced in any way for writing data really must have been defined in the data dictionary of the database tables used by the Axiell application; this includes link reference tags. By default, you can't write to fields which are not specified in the data dictionary, because of security reasons. The data dictionary consists of all the database, dataset, field and index specifications collected in the .inf database table configuration files of an Axiell application. These .inf files can be viewed and edited using Axiell Designer.
  Submit an existing priref so that the written record will be merged with an existing record. This means that only the provided fields will be written to the existing record; other fields in the existing record will keep the value they already had. The record priref can be included as a separate node in the record XML if it is a field in the target .inf, but in grouped XML it's also an attribute of the <record> node and providing the priref as an attribute of this node is preferred (since it is a property of the record).
  If you write data in which a validated field contains a non-preferred term, then this value will automatically be replaced by the correct preferred term. The returned record XML will contain the preferred term. If there is more than one preferred term (when there are homonyms) then an exception is thrown and the record is not updated.
  When you POST grouped XML data to the wwwopac.ashx while one or more of the application fields are multilingual, then be sure to structure your XML accordingly. The required source XML format is identical to the search result XML format and it is mandatory for multilingual fields to use the lang attribute to specify the data language of the field to write to. The WebAPI will check the data dictionary (.inf file) of the relevant database to find out if fields are multilingual or not. The XML format for an existing record with record number 4783, writing to a multilingual title field (in field group Title) must be structured similarly to the following:
  <adlibXML><recordList><record priref="4783"><Title><title><value lang=’en-GB’>Test title English</value><value lang=’nl-NL’>Test titel Dutch</value></title><Title></record></recordList></adlibXML>
  while for a monolingual title field you would structure the XML like:
  <adlibXML><recordList><record priref="4783"><Title><title>Test title</title><Title></record></recordList></adlibXML>
  
• xmltype (String) [optional] type of xml to be written ('grouped' or 'unstructured')
• 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.
• language (String) [optional] the default data language for monolingual data inserted into a multilingua field. A default data language parameter is available for the insertrecord and updaterecord commands, to allow the client or user to POST monolingual record XML while specifying the default data language for any multilingual target fields once through the URL. This has the advantage that a lang attribute doesn't need to be added to fields in monolingual XML source data that is targeted for a multilingual field. So the client doesn't need to be to be aware of any multilingual fields in the target database and may POST its monolingual source data without lang attributes: the WebAPI will use the language parameter (with an ISO 639-1-ISO 3166-1 language code like nl-NL or en-GB for example) to determine which lang attribute must be added automatically to any monolingual value when it is written to a multilingual field. Of course, if you're sure there exists no multilingual target fields, then you don't need to use this parameter.
  (If you were to leave out the lang attribute in the XML body AND you do not provide the language parameter while writing the data to multilingual fields, an error will be reported in the XML diagnostic section.)