VCSI: STEPXML Splitter Post-processor in OIEP

Use of the STEPXML Splitter is determined by the grouping option selected:

  • For the Change Package Git Delivery method, the STEPXML Splitter is integrated into the delivery method, so the STEPXML Splitter post-processor must not be added to the OIEP.

    For change packages, all exports use the Flattened hierarchy split mode and export definitions as comments. The user can decide to also export business rules converted to an editable format on the delivery method dialog, which replaces the STEPXML files that include comments with editable .JS files for business rules.

  • For a collection used to group changes and an Advanced STEPXML template configured for various configurations that do not include the Change Package object, the STEPXML Splitter is required on the OIEP with ‘Git Delivery’.

The STEPXML Splitter post-processor can take any STEPXML file produced by the STEP Exporter processing engine as input and splits the file into multiple valid STEPXML files and/or editable business rule format files that are then passed to the configured delivery method. Generally, the splitter produces one file per STEP object and further normalizes the content so that elements for which the sequence has no significance in STEP are output in the same order every time. Non-object configurations (e.g., derived events) and system settings are output in a single file.

Splitting and normalizing makes it easier to compare configurations outside of STEP in a VCS like Git. Further, it makes it easy to selectively choose specific configuration items to be imported on another system.

The STEPXML Splitter post-processor has the configuration options explained below.

Split mode

Split mode defaults to ‘Flattened’ but also allows 'Hierarchical'. The parameter affects how to represent STEP objects in the produced split files when they are typically exported in a nested structure.

To illustrate the difference, in the example shown below, the following classification hierarchy is being exported:

In both modes, one file will be created per classification object.

In Flattened mode, upper levels are omitted, and each file contains exactly one 'Classification' element with parent identifier information, as shown below.

(…)
<Classifications>
<Classification ID=‘stibo.IMConfigFolder’ UserTypeID=‘ImportConfigurationsRoot’ ParentID=‘ConfigurationsRoot’>
<Name>Import Configurations</Name>
<MetaData>  
  <Value AttributeID=‘Purpose’ QualifierID=‘en-US’>Storage for import configurations</Value>
</MetaData>
</Classification>
</Classifications>
(…)

In Hierarchical mode, each of the leaf classifications (e.g., Import Configurations) is nested inside the element representing the 'Configurations' classification, which is stripped of all but ID, object type ID, and parent ID information, as shown below.

(…)
<Classifications>
<Classification ID=‘ConfigurationsRoot’ UserTypeID=‘ConfigurationsRoot’ ParentID=‘Classification 1 root’>
<Classification ID=‘stibo.IMConfigFolder’ UserTypeID=‘ImportConfigurationsRoot’> 
<Name>Import Configurations</Name>
<MetaData>
  <Value AttributeID=‘Purpose’ QualifierID=‘en-US’>Storage for import configurations</Value>
</MetaData>
</Classification>
</Classification>
</Classifications>
(…)

Generally, it is recommended to use the default 'Flattened' mode while the 'Hierarchical' mode should only be used if the full hierarchy path must be present in each file.

Note: The 'Hierarchical' example from above can be imported on a system where the classification with ID 'ConfigurationsRoot' is not present as it will be created during import. Importing the 'Flattened' example on such a system, however, results in an error.

Convert business rules to editable format

This option determines how business rules (conditions, actions, functions, and libraries) are exported.

  • If set to No, the business rules are exported as STEPXML files.

  • If set to Yes, the rules are exported in the editable *.JS format described in this topic.

    When exporting editable business rules, set this option to 'Yes.' The business rules in the STEPXML that are fed to the post-processor are converted to the editable format and represented in a single *.JS file instead of being represented in a STEPXML file. For details, refer to the VCSI: Editable Business Rules Format topic.