Documentation Center

IBackgroundTaskHandler - BATCHSTATUSUPDATE

Updates metadata fields of document objects with the provided language card IDs and uses plugins to export document objects to the specified location.

Input data

The input data XML:

eventdata
Input data root element.
  • Required: yes
lngcardids
The element text defines the language card IDs to export. The element text should contain at least one language card ID.
  • Required: yes
ishfields

Object metadata fields container. The fields container can have one or more ishfield elements.

  • Required: yes
foldername
The element text can include a folder name; if you specify a folder name, it is prepended to a system-generated timestamp to create a unique export folder name. You only need to specify this input if you want to update the metadata AND export successfully updated items.
  • Required: no
This XML example shows the typical input data:
<eventdata>
    <lngcardids>147094, 145246, 160350, 144730, 161038, 161046, 161054, 161062, 161070, 161078,...</lngcardids>
    <ishfields><ishfield name="FSTATUS" level="lng" ishvaluetype="element">VSTATUSINTRANSLATION</ishfield></ishfields>
    <foldername>ExportTranslation-MicroFocus Vega.2</foldername>
</eventdata>			

Background task configuration

The list below describes the configurable parameters:

batchsize
Maximum number of items allowed to process by one batch. If there are more items to process they will be split between different batches.
  • Required: yes
  • Default value: n/a
  • Allowed values: Any integer number greater then 0 and less or equal then 2 147 483 647.
  • Example: 500
exportEventType
The handler name of the export event that is trigered after the update to export the successfully updated objects.
  • Required: no
  • Default value: n/a
  • Allowed values: Any export event type.
  • Example: PUBLICATIONEXPORT
retrywaittime
Objects might be locked when the batch is executed so it is useful to wait and perform a second attempt to update them. This parameter defines how long a job should wait before it tries again.
  • Required: no
  • Default value: 00:01:00 (1 minute)
  • Allowed values: Any time span in format HH:MM:SS
  • Example: 01:00:00 (1 hour), 00:00:30 (30 seconds).

Default background task configuration example

The following configuration handles the BatchStatusUpdate background task:

<handler eventType="BATCHSTATUSUPDATE">
  <scheduler executeSynchronously="false" />
  <authorization type="authenticationContext" />
  <execution timeout="01:00:00" recoveryGracePeriod="00:10:00" isolationLevel="None" useSingleThreadApartment="false" />
  <activator>
    <net name="BatchMetadataUpdate">
      <parameters>
        <parameter name="batchsize">500</parameter>
        <parameter name="exporteventtype">PUBLICATIONEXPORT</parameter>
        <parameter name="retrywaittime">00:01:00</parameter>
      </parameters>
    </net>
  </activator>
  <errorHandler maximumRetries="0" />
</handler>

Flow

  1. Read configuration parameters
  2. Read event data.
  3. Write a record indicating the start of the event and the initial progress status to the Event Monitor.
  4. Divide the language card identifier into number of batches according to the batchsize configuration parameter.
  5. For each batch:
    1. Write a record to the Event Monitor indicating how many objects are to be processed.
    2. Update the metadata fields for all objects in the current batch.
    3. Write a record to the Event Monitor with the details about the total number of objects that are updated, failed and waiting for retry and how many objects were processed in total.
  6. If there are items waiting for retry because they were locked at the time of execution:
    1. Wait a timeout specified in the retrywaittime configuration parameter.
    2. Retry metadata update for all unprocessed items in the same way they are processed normally (see above).
  7. Write a record in Event Monitor indicating the total number of processed objects and how many of them were updated and how many failed.
  8. Write a record in the event monitor indicating the completion of the event handler.
  9. If the foldername event data parameter and the exporteventtype configuration parameter were correctly provided, the new event handler is triggered to export the successfully updated objects. Otherwise, a warning record is written to the Event Monitor.