Asset Publisher Processing Plugin Parameters and Triggers

The Asset Publisher event processor plugin can be configured to publish asset content to a specific location.

Deleted objects (objects in the recycle bin) are ignored during processing.

To access the 'Configure Processing Plugin' parameters, the Asset Publisher processor must be selected within the Select Processor parameter during the wizard step 'Configure Event Processor.'

The Parameters and Event Triggers sections below contain important information on settings that should be considered when creating an event processor using this processing plugin.

Prerequisites

This section of documentation describes configuration steps for this specific processor, but that is only one part of configuring an event processor. For the full set of instructions on configuring an event processor, refer to the Event Processors topic.

Additionally, if image conversion is required as part of the asset push, the image conversion configuration must be completed prior to the asset push configuration, so that the conversion can be selected as part of the configuration. Refer to the Image Conversion Configuration topic for more information here.

Parameters

Each of the relevant parameters for the Event Processor Wizard 'Configure Processing Plugin' step are described below. Any additional wizard parameters with importance for this plugin are also included in this topic.

Note: You can hover over the parameter value fields within the wizard to access descriptive tool tip text.

Conversions - These are the image conversions to publish. Click the plus button () in the parameter to add a row within the field. Click the ellipsis button () to display the Conversion Configuration dialog.

The Conversion Configuration dialog has the following parameters:

  • Name - add the mandatory name of the conversion; it must be unique within an Asset Publisher configuration.

  • Image Conversion - select the mandatory image conversion to be used. If the asset format, size, or image color settings need to be converted when pushed to the target system, select the relevant conversion configuration from the list. The <source> option is default and will produce no conversions. The dropdown list contains the conversions that are available in the system. Configurations that have (conversion) appended to their names are custom conversions and can be changed and/or edited. Those without (conversion) appended are standard conversions and cannot be changed and/or edited.

  • Storage Template- specify the mandatory path and file name to store the conversion on blob (binary large object) storage. The following variables / macros are available:

  • $assetID$ - ID of the asset being published

  • $assetNAME$ - NAME of the asset being published

  • $IDpath$ - Two path levels constructed from the last four (4) characters of the asset ID; use when folder structure for assets is needed

  • $attribute:attributeID$ - Value of the description attribute of the asset is being published

  • $contentdimensionpointsID$ - ID(s) of the dimension point(s) for which the asset is being published

  • $extension$ - The original extension for the asset. Will not include leading dot (.)

  • $autodetected-extension$ - The extension produced by the asset conversion. Should only be used for the rate case where the conversion can produce files with different extensions. If a conversion always produces the same extension, the information should be hardcoded instead. Will not include leading dot (.)

  • Note: For the Storage Template file path, similar to Asset Push, the system makes letters lowercase and replaces characters that are illegal in a Windows file system with '_'. Illegal Windows characters are: \ / : * ? < > | For example, if assetid is 'ABC<> and the storage template is '$IDpath$/$assetID$.jpg', then it resolves to the storage path 'bc/__/ABC__.jpg'.

Validation is done when saving the configuration. You can choose to fix the issue (if one exists) at that point or save the configuration as-is and update later.

  • Condition - if specified, this optional condition must evaluate to be true for the given asset to be published by this conversion.

    You can bind asset content to restrict that asset conversion only be done on, for example, specific MIME types by using the 'Current Asset Content Object' bind as described in the Other Binds topic in the Resource Materials documentation here.

    To restrict conversion only on assets in specific classifications, define a condition in the triggering condition on the queue (where it will be the asset itself that can be bound in the condition as opposed to asset-content).

    Important: The following constraints are checked when the event processor is processing events. If the constraints are not fulfilled, the event processor stops and fails.

  • Path Attribute - The Path Attribute is only mandatory when used for DaaS configuration and when the 'Handle Delete Events' parameter (defined below) is set to 'Yes.' Otherwise, it is used to store the actual published path of this asset (from the storage template). Refer to the Publishing to Data as a Service topic in the Data as a Service documentation here. Configure the attribute as follows:

    • Single-valued, description attribute

    • Externally maintained

    • Must have same dimension-dependencies as asset content

    • Must be valid for an object type used in triggering-object-types of event processor and the path attribute must not be used in any other enabled Asset Publisher event processor

  • Version Attribute: This mandatory attribute is used to store the version of the published asset. The value is stored on the asset. Configure the attribute as follows:

    • Single-valued, description attribute

    • Externally maintained

    • Must have same dimension-dependencies as asset content

    • Must be valid for an object type used in triggering-object-types of event processor and the path attribute must not be used in any other enabled Asset Publisher event processor

  • Status Attribute: If specified, this optional attribute is used to store the status of the publish operation. The value is stored on the asset. Configure the attribute as follows:

    • Single-valued, description attribute

    • Externally maintained

    • Must have same dimension-dependencies as asset content

    • Must be valid for an object type used in triggering-object-types of event processor and the path attribute must not be used in any other enabled Asset Publisher event processor

Note: The Path attribute is mandatory when $assetNAME$ and $attribute:attributeID$ macros are used.

Notification Event Queues - Click the plus button () in the parameter to add a row within the field. Click the ellipsis button () to display the Select Processor for Events dialog. Select the processor using standard Browse / Search Node Picker functionality.

Storage Provider - Storage provider for which converted images are pushed. Options in the dropdown are available when a Gateway Integration Endpoint is created and configured. For specific information on how to set up Gateway Integration Endpoints for the Asset Publisher functionality, refer to the following topics located in the Data Exchange documentation:

  • Configuring a Gateway Integration Endpoint - Amazon S3 Blob Storage (here)
  • Configuring a Gateway Integration Endpoint - Google Cloud Storage (here)
  • Configuring a Gateway Integration Endpoint - Microsoft Azure Blob Storage (here)

Extended Logging - Set to 'Yes' to enable extended logging in the execution report of the event processor. This logs information for each upload taking place. The default setting is 'No.'

Publish Inherited Content - This option is available on systems where asset content is dimension dependent and the content depends on a single dimension. By default, asset content is only published for the dimension points to which it is local. Use this option to export content for specific dimension points that the content can be inherited to.

Handle Delete Events - Set this parameter to 'Yes' to perform ongoing cleanup of the blob storage. To process delete events, you must also select a 'Path Attribute' and set the 'Storage Template' within the Conversion Configuration dialog (defined above). With this configuration, the blob storage is managed by attempting to delete the blob / binary identified in delete events based on the current configuration. A 'best effort' approach is used for deletions based on the Storage Template of the current configuration. If the published asset cannot be found because the Storage Template has been modified since publishing, the published asset is not deleted.

By default, the 'No' setting indicates that binaries are not deleted from the blob storage based on delete events.

Event Triggers

For the event processor to take effect, it must be configured to only listen for changes on asset type objects housed within the same previously selected classification folder.

By default, events are triggered on the Approved workspace. Derived event functionality is available for triggering events prior to approval, as defined in the Derived Events topic in the System Setup documentation.

The recommended setup of the triggering definition of the Asset Publisher event processor includes:

  1. In the Triggering Object Types flipper, click the Add Object Type link to display the Select Object Types dialog.
  2. Select one or more asset object types that will be monitored for changes. When business rules are not required in the Event Filter and Generate Event fields, multiple object types can be selected within the same Triggering Object Types row.

Important: You must select at least one asset type for Triggering Object Types, or nothing will be processed by the event processor.

  1. Click the OK button to add the selection to the Triggering Object Types table.
  2. In the Triggering Attributes flipper, add the attribute ‘asset.uploaded.’
  3. In the Miscellaneous Triggers flipper, uncheck all the checkboxes.

When the event processor runs, the configuration is validated. The attributes set for path and version should have the same dimension dependencies as asset content. Upon validation, if anything is wrong, the event processor stops. You will then need to reconfigure and run again.

Below is an example of an event processor that processed successfully. It processed two (2) assets and uploaded three (3) blobs.

Continuing the example above, there are three blobs in blob storage:

Return to the asset(s) published for the updates for the path, status, and version. Your results will depend on your own setup and upload time.

Republishing Assets

To republish assets that were, for example, deleted from blob storage, resized, or had the path changed, etc., run a bulk update using the Clear Value operation to clear the value for a specific attribute. Or, run more than one Clear Value operation to clear the value for multiple attributes. For details, refer to the Attribute Values: Clear Value Operations topic in the Bulk Updates documentation here.

Send a republish event for the asset(s) and then invoke the event processor again to republish the assets to blob storage.