Data Exchange Enhancements and Changes

Summary

The following enhancements and changes have been made as part of the 2025.2 update:

  • Users can now override the Kafka Streaming Receiver's 'Consumer Group ID'. Previously, this value was auto-generated using the STEP system name and the ID of the inbound integration endpoint (IIEP). Additionally, the Execution Report data is improved so that it no longer reports unnecessary 'Unknown configuration parameter' messages. Refer to the Kafka Streaming Receiver topic in the Data Exchange documentation.

  • Inbound integration endpoints (IIEPs) using the Amazon SQS receiver method no longer report extraneous messages about connecting to and disconnecting from the SQS provider in the Execution Report. Five individual lines have been replaced with 'Connecting and Disconnecting to step.0.log.' For information on the receiver method, refer to the Amazon SQS Receiver topic in the Data Exchange documentation.

These enhancements and changes have also been made as part of the 2025.2 update and are described in the Details section that follows:

  • REST API V2 improvements in this update support uploading messages through an enabled and scheduled IIEP, without invoking the IIEP. Also, customers can have extended control over integration endpoints (IEPs), event processors (EPs), and gateway integration endpoints (GIEPs), including the ability to set and/or get metadata attribute values and activate / deactivate a processor. And, the schema for background processes in REST API V2 now allows the execution time of background processes to be retrieved in milliseconds.

  • The LZ4 compression / decompression parameters have been removed from the Kafka Delivery method and the Kafka Receiver method. These parameters caused issues with the automatic compression and decompression provided by Kafka.

  • For outbound integration endpoints (OIEPs) using the Context Splitter post-processor, administrators can now modify the file name template and the characters used for the file name delimiter. This improvement ensures that the file names generated can be compatible with downstream systems.

  • PDX integration elements have been renamed to clarify their intended use and simplify configuration.

  • PIES Importer now provides control over retaining or replacing existing Price List data containers during import.

  • AutoCare now supports latest Description Codes and improved error reporting for Description Code issues during PIES import.

  • PIES Importer now Supports MaintenanceType='C' , enabling partial updates to existing PIES Items.

Details

REST API V2 improvements

REST API V2 now supports uploading messages through an enabled and scheduled IIEP, without invoking the IIEP, using the new POST /inbound-integration-endpoints​/{id}​/upload operation.

REST API V2 also now allows extended control over integration endpoints (IEPs), event processors (EPs), and gateway integration endpoints (GIEPs). The following new and/or improved HTTP operations are available for IEPs (inbound-integration-endpoints and outbound-integration-endpoints), EP (event-processors), and GIEPs (gateway-integration-endpoints) object types:

  • New PATCH/{object type}/{id} - allows setting metadata attribute values for the specified ID, for example name, description, and other attributes that are valid on the object type.

  • Improved POST/{IEP object type}/{id}/enable - activates the specified ID for an IEP, now with the option to resume related 'suspended' background processes.

  • Improved POST/{IEP object type}/{id}/disable - deactivates the specified ID for an IEP, now with the option to suspend related 'waiting' background processes.

  • Improved GET/{object type}/{id} - allows getting metadata attribute values for the specified ID, previously only name and description were available.

  • Finally, the schema for background processes in REST API V2 has been extended, allowing the execution time of background processes to be retrieved in milliseconds. Previously, the execution time could only be measured in seconds. This improvement provides greater accuracy for scenarios that require more precise timing.

For details, refer to the 'REST API V2' section of the Technical Documentation accessible at [system]/sdk or from the Resources section of the system's Start Page.

Removal of LZ4 compression / decompression parameters

Previously, the 'Compress Message Content' parameter on the Kafka Delivery method and the 'Decompress Message Content' parameter on the Kafka Receiver method allowed selection of 'LZ4'. However, these options caused confusion because they do not control the Kafka framework 'compression.type' setting. Instead, LZ4 compression / decompression is activated within STEP and messages using these options were not automatically decompressed / compressed on the consumer / producer side. For this reason, the options have been removed.

For integration endpoints (IEPs) that need to use the legacy STEP LZ4 compression, the following properties can be set in the Self-Service UI on the environment's 'Configuration properties' tab:

  • Outbound integration endpoints (OIEPs): Kafka.Delivery.Dynamic.ExtraDriverOptions

  • Inbound integration endpoints (IIEPs): Kafka.Receiver.Dynamic.ExtraDriverOptions

For more information, refer to the Kafka Delivery Method topic and the Kafka Receiver topic, both in the Data Exchange documentation.

OIEP Context Splitter post-processor editable file name template

The Context Splitter post-processor divides the export file generated by an outbound integration endpoint (OIEP) into individual files based on the contexts on which the data is dependent. Previously, the file name template could not be edited and used '##' as the file name delimiter, which sometimes caused issues with downstream systems. With this update, the file name template parameter is included in the post-processor dialog and can be edited by the user.

For details on this new parameter, refer to the OIEP - Event-Based - Output Templates Section topic or the OIEP - Select Objects - Output Templates Section topic, both in the Data Exchange documentation.

Renamed PDX integration elements

With the improvements to Product Data Exchange (PDX) outbound integration endpoint (OIEP) and inbound integration endpoint (IIEP) elements over previous updates, the names of some elements have become confusing by including variations of the name. To clarify the expected selection for each element, the names have been updated, and the recommended options are now all named 'PDX', as indicated below.

  • In the IIEP 'Receiver Method' section, the previous 'Product Data Exchange' option is now named 'PDX'. This is the recommended receiver method for PDX.

  • In the OIEP 'Output Template' section, the 'Pre-processor' dropdown:

    • the previous 'Product Data Exchange Outbound Pre-processor' option is now named 'PDX pre-processor (deprecated)'.

    • the previous 'PDX Pre-processor 2' is now named 'PDX pre-processor'. This is the recommended pre-processor for PDX.

  • In the OIEP 'Delivery Method' section:

    • the previous 'Product Data Exchange' option is now named 'PDX (deprecated)'.

    • the previous 'Product Data Exchange 2' option is now named 'PDX'. This is the recommended delivery method for PDX.

OIEP options that include '(deprecated)' in the name will be removed in a future update. Customers using these options are advised to edit their OIEPs to use the newer options and ensure continued successful processing.

For more information, refer to the PDX Delivery Method topic, the OIEP - Event-Based - Output Templates Section topic, the OIEP - Event-Based - Pre- and Post-processing Section topic, and the PDX Receiver topic, all in the Data Exchange documentation.

Improved Price List data container handling in AutoCare PIES import

The Product MDM for Automotive solution now offers a more consistent and reliable approach to managing Price List data containers during PIES Item imports.

A new parameter, PIES Price List Data Containers Import Handling, has been added to the [PIESToStepXMLConvertService] conversion service. It allows the user to control how existing data containers are handled during import:

For existing implementations where PIES Items with Price List data containers already exist in the system, the user should carefully consider the chosen option in the PIES Price List Data Containers Import Handling parameter before proceeding with the import:

  • Selecting Delete_Price_List_Data_Containers deletes old data containers and replaces them with new ones (with new IDs).

  • Selecting Never_Delete_Price_List_Data_Containers retains old data containers, adds new ones with new IDs.

For more information on this new parameter, refer to the Conversion State topic in the Solution Enablement: Product MDM for Automotive documentation.

AutoCare solution updated to support latest Description Codes

The AutoCare component within the PMDM for Automotive solution now supports the most recent Description Codes provided by AutoCare.

Additionally, the error report generated by the BGP during a PIES file import has been improved to provide more detailed and explanatory messages for errors related to Description Code.

Support for MaintenanceType='C' in PIES Importer

The PIES Importer in the PMDM for Automotive solution has been enhanced to support MaintenanceType='C' at the PIES Item level in PIES import files. While MaintenanceType='A' was already supported, the addition of MaintenanceType='C' now enables the importer to process changed PIES Items. This enhancement allows partial updates to existing items to be calculated and applied during the Delta Calculation state.