OIEP - Event-Based - Output Templates Flipper

An output template defines the data to be exported and connects it to the desired format. This enables you to use one output format for a specific object type, combined with a specific event type, and another output format for a different object type, combined with a different specific event type. Without an output template, even if events are triggered (based on the Event Triggering Definitions parameters), nothing is exported.

At least one output is required, but for event-based OIEPs, using multiple output templates can allow different messages to be generated based on the object type / event type combinations. Keep in mind that batching is restricted to a single template, so only use multiple templates when required. Refer to more information below under the Using Multiple OIEPs or Multiple Output Templates section.

Configuring an output template involves the following steps:

  • Configure the object types and event types
  • Specify the format
  • Configure preprocessor and post-processor, based on availability on your system

Important: For an event-based outbound integration endpoint, an output template must be created for each event trigger, otherwise the trigger will not output any data. For more information, refer to OIEP - Event-Based - Event Triggering Definitions Tab here.

Configure the Object Types and Event Types

The object type and event type selections determine the STEP data that will be exported. Different output templates (export configurations) can be used to export data based on the event type (core events or derived events) and the object type for which the event is generated.

Important: When exporting delete events, generally events are processed in the same order as they occurred. However, in some circumstances, the order is not reliable. For more information, refer to the Event-Based OIEP Order of Delete Events topic here.

  1. In System Setup, select the relevant OIEP > Configuration tab > Output Templates flipper > click the Add configuration link to display the 'Conditions for output template' dialog.

  1. In the 'Conditions for output template' dialog:
  • For the Object Types area at the top, click 'All object types' or 'Specify' to select the object type(s) using the Browse or Search options. Click the right arrow button () to move the object type to the right side of the dialog. To remove an object type, click the left arrow button ().
  • For the Event Types area at the bottom, select the event type. Core event types (create, modify, and delete) display on the left side and available derived event types display on the right side. Unlike core events, derived events must be created before they will display. For more information, refer to the Derived Events section of the System Setup documentation here.

When using the Mongo delivery method, specific settings are required to deliver delete events. For details, refer to the Delivering Delete Events section of the Mongo Delivery Method topic in this guide here.

For delete events in particular, the order of processing can vary based on the scenario. For details, refer to the Event-Based OIEP Order of Delete Events topic in this guide here.

Note: Selecting an object and event type defines the object types for export, but does not necessarily define the objects that are included in the actual message, since the format of the template may dictate that parent, child, or referenced objects are included. Additionally, the advanced settings for format determine if the selected objects, their children, or both should be considered for the export.

  1. Repeat the process until all required formats are displayed, keeping in mind the limitations of multiple output templates defined in the next section.

Note: Only one (1) output template is allowed for each Object type and Event type combination.

In the image below, all of the available system event types (create, modify, delete) were selected for each template created:

  1. If necessary, edit existing Object-Event type settings by clicking into the desired field to display an ellipsis button (). Click the ellipsis button () to display the 'Conditions for output template' dialog discussed above.

Using Multiple OIEPs or Multiple Output Templates

Generating output for multiple recipients can be accomplished in the following ways, which should be evaluated for best outcome.

Multiple OIEPs

  • Triggering events for event-based endpoints are global. For example, you may want a change in STEP name to trigger an event on some objects, but not others. This scenario requires a different configuration of triggers on multiple endpoints.
  • Delivery method is per endpoint, not per output format. If you need a different output to go to each external system, you must use multiple endpoints.
  • Messages generated via events and those generated via object selection cannot be combined in a single endpoint. Even when the format is the same, this scenario requires separate message generation and therefore requires separate endpoints.

Multiple Output Templates

Multiple output templates can be created to allow data output based on a combination of specific object types and event types.

Important: Be aware that events are processed sequentially and are added to batches, as allowed, by the required output templates. Each batch also involves overhead processing operations. Depending on the data being exported, multiple output templates can result in many batches with relatively few events in each. To optimize processing, it is better to have fewer large batches instead of many small ones.

Using multiple output templates prevents the same data from being exported across all chosen object types and event types. Multiple output templates also help to reduce data output, which increases performance both for STEP and for downstream systems. In addition, the use of multiple output templates should reduce the need for customizations.

For example, consider an event-based OIEP that is configured so that when a change is made to a 'Product Category' object, the export should not include child objects, but when a change is made to a 'Product Family' object, the export should include child products. This can be achieved by configuring multiple XML output templates, and by selecting the specific object and event type.

Limitations of Multiple Output Templates

  • Output files are only delivered to one destination, regardless of the number of output templates.
  • Output templates encompassing all object types are only available if all object types are chosen when making the configuration. This prevents excess output from the endpoints.
  • Batching occurs per template type.
  • Different output formats cannot be defined for the same object type. Common setup is to avoid combining different output formats (e.g., STEPXML and CSV) in the same endpoint.

Configure the Format

The format selection determines how the STEP data is formatted (XML or tabular).

  1. Click into the format column to display the ellipsis button (). Click the ellipsis button () to display the 'Select format' dialog.

  1. In the Select format window, on the Format tab, select the desired format from the dropdown. The options are the same as in the Export Manager, based on your system licenses. Use the following links for additional information:

  1. When available, specify how to map data to the export format, including the elements identified in the image below: object super type dropdown, data source, mapping target, and mapping rules.

For more information about the object super type dropdown, refer to the Export Manager - Select Objects topic here. For more information about the other elements, refer to the Export Manager - Map Data topic here.

Note: The Mapping tab is enabled when the format selected requires mapping. Selected formats, including STEPXML and Advanced STEPXML, are automatically mapped so the Mapping tab is disabled.

  1. On the Advanced tab, a number of advanced export options can be specified.

  • Tag conversion: Converts tags to match the selected output format. This setting is optional.
  • If this box is left unchecked, any formatting tags that are included in attribute values will not be converted in the outbound message. For example, if an attribute value contains bold text (which must be made bold with a STEP Style Tag, e.g., <bold>/</bold>), this tag will not be converted to its corresponding HTML output format (e.g., <B>/</B>) in the export. For more information on STEP Tags, refer to the Tags topic in System Setup documentation here.

  • Locale conversion from context: Converts numbers into the numeric format that corresponds to the selected locale. By default, this option is not checked. Note: If Smartsheets are used for format, this must remain unchecked.
  • Resolve Inline References: Resolves inline references when they are exported. This box is checked by default, along with the option 'Export Inherited Inline References.'
  • If unchecked, inline references will be exported with the inline reference tagging instead of the actual content pulled in by the inline reference. For example, if an attribute called 'Product Number' has an inline reference to pull in the STEP ID of the object (e.g., 12345), the attribute value will not contain 12345. Instead, it will contain tagging similar to the following:

    <ref attrid="" equalsign="=" includeattrname="false" resolveto="objid" separator=";"/>

    This setting would be valid if the user planned to re-import the file at a later time and not overwrite the inline reference with a static value. For more information on inline references, refer to Inline References in Attribute Values in the Getting Started documentation here.

  • Include Calculated Attribute Values: Resolves calculated attribute values when they are exported. By default, this option is checked. If not checked, calculated attribute values are exported with empty values, unless the Force Calculation option has been set. The Force Calculation option on the Transformations dialog is available when mapping a calculated attribute using a transformation. For more information, refer to Outbound Map Data - Transform here.

The value template is exported for each selected context, including a qualifier ID, which makes it possible to import the same data back into STEP. For information about calculated attribute values, refer to the Calculated Attributes topic in System Setup documentation here.

Important: If many complex calculated attribute values (traversing hierarchies and/or references) are used, consider if they should be exported, since they can impact performance. If required, consider scheduling for non-peak times. Simple calculations are not detrimental to an export, regardless of the quantity.

  • Select version used to resolve tables: This setting is only available if the format is STEPXML and 'Include Tables' is set to Yes. A publication version should be selected if the tables contain content relevant to a particular publication (such as column or row types that are only valid for certain publication types) or a publication version (such as commercial data). If a publication version is not selected, the version last used in STEP Workbench is used. For more information, refer to the Exporting Resolved Tables topic in the Tables documentation here.
  • Only Export Selected Objects: Specifies that only objects from the output template are exported. No children are exported. This setting is unchecked by default and is only available if 'Only Export Leaf Objects' is unchecked. This setting does not apply to STEPXML.
  • Only Export Leaf Objects: Specifies that only the leaf objects (lowest level of the export object for both events and selected objects) of the selected top hierarchy are included in the export. Selected objects and triggering objects are only included if they have no children. This setting applies to the CSV or Excel format.

Note: Uncheck both ‘Only Export Selected Objects’ and ‘Only Export Leaf Objects’ if all objects (both for triggering events and object selection) and their children should be included in the export.

For more information, refer to Export Manager - Advanced documentation here.

Configure the Pre-processor and Post-processor

Preprocessor and postprocessor options are available depending on your system configuration.

Pre-processor

  • Business Action Pre-Processor can be applied on event-based OIEPs before exporting events from a batch in an event queue. Applying the preprocessor means a node can be added to a current batch, or an event can be removed from the current batch before a message is created for an export. You can configure a preprocessor for each of the output templates. For more information, refer to OIEP - Pre-Processor - Business Action here.

    A Triggering Object Type event filter or Generate Event option can be used in place of a preprocessor. For more information, refer to the OIEP - Event-Based - Event Triggering Definitions Tab documentation here.

PDX Outbound Pre-Processor can be used to handle change events on reference assets, and forwards this information to the PDX product. For more information, refer to the Exporting Metadata Attributes of an Asset to PDX topic in the Data Integration documentation here.

Post-processor

Standard post-processing options should be evaluated if multiple contexts are included in the output. You can configure a post-processor for each of the output templates. The Triggering Object Type generate event option can be used in place of a post-processor. For more information, refer to the OIEP - Event-Based - Event Triggering Definitions Tab documentation here.

  1. Click into the Post-Processor column to display the ellipsis button (). Click the ellipsis button () to display the 'Select Post Processor' dialog.

  1. In the Configure Post-processor, select from the following options:
  • No post-processing exports files using the standard export functionality.

  • Context splitter generates an export file for each configured context. Each exported file will only contain context specific data. For more information, refer to the OIEP - Post-Processor - Context Splitter topic here.

    For the Copy inherited product values parameter, select Yes to copy and save inherited product values to the child product; or select No to use inherited product values in the export, but leave the child product unmodified.

    When using Excel or CSV format, and multiple contexts are configured for export, you must select Context Splitter, or a single context will be included in the export.

  • Copy Context Dependent Values and References to export context-dependent values and references and add the corresponding ContextID attribute to the value or reference in question. The endpoint generates one file containing values and references for each context specified. For more information, refer to the OIEP Post-Processor - Copy Context Dependent Values and References section here.

    For the Copy inherited product values parameter, select Yes to copy and save inherited product values to the child product; or select No to use inherited product values in the export, but leave the child product unmodified.

    If you use the Copy Context Dependent Values and References post-processor to add ContextIDs to a cross-context export (exporting data for selected contexts), the downstream system can use the <ContextID> tag to identify specific contexts. Additionally, this facilitates re-importing the exported data into the correct contexts in STEP after processing by a third-party service or application.

  • Chained Post Processor as defined in the OIEP - Post-Processor - Chained Post Processor topic here.

  • Generic STEPXML Splitter splits up STEPXML messages to multiple STEPXML valid fragments containing one single node per STEPXML file.

  • STEPXML Splitter produces one file per STEP object as defined in the 'STEPXML Splitter' Post-processor Plugin for OIEP section of the Integration Endpoint Plugins for VCS Integrations topic in the Configuration Management documentation here.

  • Transformation by XSLT transforms data via an XSLT stylesheet before exporting. Under the XSLT-Stylesheet parameter, click the ellipsis button () and browse or search for the stylesheet to use for the transformation. For more information, refer to OIEP - Post-Processor - Transformation by XSLT section of the Data Exchange documentation here.

  • GDSN to MDM Post Processor handles an exported STEPXML file that may include many packaging hierarchies and many objects within each packaging hierarchy. The post-processor will split these files up by STEP context and by trade item before applying transformations. The transformed files will have a hash code generated and compared to a previous hash code to verify if there have been changes. Optional business actions can also be executed to affect workflows or other purposes. For more information, consult your Stibo Systems account manager or partner manager.

    Note: This post processor is only available when running the GDSN to Receiver component.