Workflow And Status Tab

The Workflow And Status tab of the PDX Channel Configurator contains multiple parameters that define the elements required to build the interaction flow between STEP and PDX, this includes event queues, product status definitions, involved attributes and attribute groups, etc.

An event queue is used in the status communication between STEP and PDX. The intended use of this is that when a product passes through a vendor relevant workflow (e.g. 'New Product introduction' or 'Product Enrichment') appropriate events are triggers at workflow transitions. This makes it possible for a retailer to communicate the current status of the product to a vendor and also send messages to a vendor.

  • Event Queue: When a product proceeds through workflows in STEP, or the product is being moved by the retailer, a status update can be sent to PDX. This update is sent by creating an event on the status event queue, which is read by PDX.

    For this process to work correctly, ‘Queue Status’ must be set to ‘Read Events’, and ‘Consumer Read’ must be enabled.

    In a multimarket setup this event queue should be configured with all supplier facing contexts.

  • The content of the status update sent to PDX must contain the following information about the product:

  • STEP ID: This is displayed as the External Product ID on the product in PDX.

  • The ‘PDX ID Attribute’ attribute value: This is used as the key between STEP and PDX.

  • The PDX Status Attribute’ attribute value: This attribute contains the PDX status, that should be displayed to the vendor

  • STEP States Attribute attribute value: This is an attribute containing information about the progress of the product onboarding. The value will be shown as Workflow state on the product in PDX.

  • The Supplier Message Attribute attribute value: This attribute contains product onboarding-relevant information from the retailer. For example, the reason a retailer has returned the product for rework. The value given to this attribute will be added as a new entry in the product’s ‘Product history’ in PDX.

Reference the examples of PDX Status, Workflow State and Message to Supplier shown below:

The following images displays the parameters available within the Workflow And Status tab:

  • PDX Status Attribute: This parameter is to be configured with a LOV based attribute valid on product object type, that carries the product status being sent back to PDX to notify vendors. This attribute should be updated on state changes in the product onboarding or maintenance workflows, wherever PMDM needs to send product status back to PDX, notifying vendors if the product is rejected, or needs reworks, or is approved. Updates are sent to PDX via events on the Product Status Event Queue, described in detail below. For information about how to map these attribute values to valid PDX Statuses, refer to the 'Status Mapping' section defined later in this topic.

  • STEP States Attribute: This parameter is to be configured with a text attribute that is valid on product object type. This attribute is being used to carry the STEP Workflow state information sent back to PDX. This attribute should be updated on state changes in the product onboarding or maintenance workflows, wherever PMDM needs to send product status back to PDX, notifying vendors if the product is rejected, or needs reworks, or is approved.

  • Supplier Message Attribute: This parameter is to be configured with a text attribute valid on product object type. This attribute is being used to carry a notification message sent back PDX. This attribute should be updated on state changes in the product onboarding or maintenance workflow, wherever PMDM needs to send product status back to PDX, notifying vendors if the product is rejected, or needs reworks, or is approved.

  • Event queue: This parameter is to be configured with an event queue which is the integration method from STEP to PDX for sending product status updates. Whenever STEP needs to notify vendors about a product status change (together with messages), the product should have Product Status, STEP states and Supplier Message attributes set, and be published to this event queue. In a multimarket setup this event queue should be configured with all supplier facing contexts.

    The PDX side has an API call issued automatically every 1 minute, which fetches messages from the event queue, then consumes them accordingly. Setting product status related attributes and publishing to event queue is usually handled within a workflow in STEP.

Note: In a setup with multiple markets, the attributes defined in the PDX Status Attribute field, STEP States Attribute field, and Supplier Message Attribute field should have the dimension dependency set equal to the market dimension selected on the Channel Properties tab. The business logic responsible for updating these attributes should also ensure to provide market-specific values. This allows for market-specific status updates, workflow states, and supplier messages to be made available to suppliers.

Note: During the status transmission from STEP to PDX, inheritance will not be considered. Market-specific statuses must be explicitly set for the market they are intended for.

Maintenance

When PDX is adopted by retailers as the primary product onboarding tool for bringing products into a STEP instance, the retailer has likely migrated supplier-provided product records into STEP from a different tool. In this scenario, the supplier-provided products in the retailer’s STEP system are now out of sync with the same products in the supplier’s system. This can present challenges when retailers and suppliers move forward together with PDX. The purpose of the ’Maintenance’ functionality is to enable retailers to continue to receive product data from suppliers for new and existing products and enable suppliers to maintain those products after the retailer transitions to the PDX platform.

Note: 'Maintenance' is not intended to establish a continuous two-way data synchronization between PDX and STEP, but rather to push existing products from STEP to suppliers in PDX during the initial onboarding of the supplier to PDX.

The parameters available within this canvas are mainly relevant to the Maintenance set up.

The Maintenance functionality gives retailers the ability to push existing products from STEP into the relevant channel in PDX, in effect sending them back to the supplier. In that PDX channel, the products will be processed as so-called ‘Retrieved products’ for the supplier in question. Next, the supplier can reclaim the products and maintain them as they would any other.

When retrieved products enter PDX, two things happen:

  • The products will be created in the PDX channel for the relevant supplier

  • The products will appear in the master data area in PDX

The product’s ID in PDX, as well as the attribute values the retailer wants to be viewable in the channel and in master data, can be configured in STEP. The product data shared in this way can be used by the supplier to recognize the incoming product and match it to the supplier's existing product record.

A product that enters PDX in this way will be marked as a ‘retrieved product’ and will enter the PDX onboarding process in the workflow state named, 'Made available for maintenance in <name of channel>’, as shown in the screenshot below.

Pushing product to PDX in Maintenance

In the Maintenance process, products are pushed from retailers to suppliers by generating events on a dedicated event queue.

Note: If many events are generated at once, PDX may require additional time (up to 24 hours or more) to consume and distribute all events.

If packaging information is managed by vendors, the event queue should be extended to automatically include any packaging objects in the messages made available to PDX. This means that when a product is pushed to PDX, the parent packaging hierarchy will also be pushed to PDX. This can be done using business actions.

Another useful business rule to make is a business action that can generate events on e.g. a collection of products. This might be done, for example, on all products for a specific supplier.

Note: Before a product can be sent to PDX the product must reference a supplier and have a Maintenance ID (attribute is configured below).

The event generation business rule above should be extended, so that it checks these requirements. Then, if the validation for a product failed, no event is generated, and the process can move to the next product.

For a channel with Maintenance enabled, a given supplier can only be authenticated under one PDX Client login. This means that if the same supplier attempts to add the channel in another PDX client, they will get the following error message: 'This vendor has already been added to this channel. Please configure another Vendor Identifier and try again.'

To enable the PDX maintenance flow, the following parameters are required:

  • Event Queue Maintenance: This parameter is to be configured with an event queue which is the integration method from STEP to PDX for sending existing products to PDX as described above.

    In a channel configured with multiple languages, the event queue should be configured with enough contexts to cover all supplier-facing languages.

  • Include in Maintenance: This parameter is to be configured with an attribute group. Attributes and asset references that should be added to the product in the PDX channel and stored in the retrieved layer should be linked into this attribute group.

    Attributes used in this attribute group can have language as the dimension dependency in STEP, but cannot have other dimension dependencies in STEP

  • Promote to Master Data: This parameter is to be configured with an attribute group. Attributes to 'promote' to master data, i.e., Attributes that will be visible in master data in PDX should be linked into the attribute group.

    Attributes used in this attribute group cannot vary by language or market.

  • Maintenance ID Attribute: This parameter is to be configured with an attribute. As mentioned above, the product ID used in PDX can be configured from STEP. The STEP attribute (the Maintenance ID) for storing this ID must be configured for this parameter. It should be valid for the Product Object Type and all packaging object types (if relevant). It cannot vary by any dimensions in STEP.

    By default, this product ID will be used in PDX to match retailer’s retrieved products with their corresponding product in the supplier’s master data. This matching occurs when suppliers upload updates to their products via Excel sheet import or an integration using the external API.

    This attribute should be IDs like GTIN or some supplier product identifier. The values should make it possible for a supplier to first recognize the product and then deploy PDX’s ‘Match-based import’ and mapping capabilities to maintain the product.

  • Maintenance ID Attribute on Reference: This parameter contains a metadata attribute. This is relevant if packaging objects are added to the maintenance queue. It can be used to help build an automated process that adds packaging objects to the maintenance queue (as recommended above). The metadata attribute must be valid on the packaging reference types. It should be a calculated attribute that on a given packaging reference include the Maintenance ID of the parent. This makes it possible for a business rule to deduce the next member in a packaging hierarchy to add to the maintenance queue.

Status Mapping

The parameters available within this canvas are mainly relevant to the mapping of values of the PDX Status Attribute and the status in PDX.

  • PDX Success Attribute Mapping: This parameter is to be populated with a value ID of a valid value of the PDX Status Attribute. Products with PDX Status Attribute equal to this value will appear with PDX Status equal to Accepted.

  • PDX Rejected Attribute Mapping: This parameter is to be populated with a value ID of a valid value of the PDX Status Attribute. Products with PDX Status Attribute equal to this value will appear with PDX Status equal to Rejected.

  • PDX Returned Attribute Mapping: This parameter is to be populated with a value ID of a valid value of the PDX Status Attribute. Products with PDX Status Attribute equal to this value will appear with PDX Status equal to Returned.

  • PDX Sent Attribute Mapping: This parameter is to be populated with a value ID of a valid value of the PDX Status Attribute. Products will PDX Status Attribute equal to this value will appear with PDX Status equal to Submitted.

Event Queue Product Message Templates

The paragraphs below contain instructions on how to configure the Product Message Templates of the status and maintenance event queues mentioned in the previous section of this document.

Status update

As part of the setup of the status update sent to PDX, a dedicated event queue must be created and configured.

Below is an example of a Product Message Template:

<?xml version="1.0" encoding="UTF-8"?>
<STEP-ProductInformation ResolveInlineRefs="false" FollowOverrideSubProducts="false" ExportDerivedAttrs="true">
<Products ExportSize="Minimum">
    <Product IncludeParent="false">
        <Values>
           <Value AttributeID="TEST.PDX.AT.pdxid" />
            <Value AttributeID="TEST.PDX.AT.MessagesToSupplier" />
            <Value AttributeID="TEST.PDX.AT.WorkflowStates" />
            <Value AttributeID="TEST.PDX.AT.WorkflowEvent" />
        </Values>
    </Product>
</Products>
</STEP-ProductInformation

In the example above:

  • TEST.PDX.AT.pdxid is the attribute configured as PDX ID Attribute on the Channel Properties Tab

  • TEST.PDX.AT.WorkflowEvent, TEST.PDX.AT.WorkflowStates and TEST.PDX.AT.MessagesToSupplier are the attributes configured as PDX Status Attribute, STEP States Attribute, and Supplier Message Attribute on the Workflow And Status Tab

In a multimarket setup this event queue should be configured with all supplier facing contexts.

Maintenance

As part of the setup of the maintenance functionality, a dedicated event queue must be created and configured. Below is an example of a Product Message Template:

If the parameter Family Object Type on the Supplier Data Definition Tab is empty:

<?xml version="1.0" encoding="UTF-8"?>
<STEP-ProductInformation ResolveInlineRefs="false" FollowOverrideSubProducts="false" ExportDerivedAttrs="true">
    <Assets ExportSize="Referenced">
        <Asset>
            <AssetContent ExportType="REST">
                <ImageConversionConfiguration ID="Source"/>
            </AssetContent>
        </Asset>
    </Assets>
    <Classifications ExportSize="Referenced">
        <FilterUserType ID="SuppliersProducts"/>
        <Classification/>
    </Classifications>
    <Products ExportSize="Minimum">
        <Product IncludeParent="false">
            <Name/>
            <ClassificationReference type="SupplierLink"/>
            <ProductCrossReference/>
            <AssetCrossReference/>
            <DataContainers/>
            <Values>
            	<Value AttributeID="TEST.PDX.AT.pdxid" />
            	<Value AttributeID="TEST.PDX.AT.MessagesToSupplier" />
            	<Value AttributeID="TEST.PDX.AT.WorkflowStates" />
            	<Value AttributeID="TEST.PDX.AT.WorkflowEvent" />
              <Value AttributeID="TEST.MaintenanceID" />
              <Value AttributeID="TEST.SentToPDX" />
              <Value AttributeID="TEST.MasterProductID" />
              <Value AttributeID="MaintenanceMatchingKeys" />
            </Values>
        </Product>
    </Products>
</STEP-ProductInformation>

In the example above:

  • SuppliersProducts is the object type configured as Supplier Products Classification Object Type on the Supplier Classification Tab

  • SupplierLink is the reference type configured as Supplier Products Reference Type on the Supplier Classification Tab

  • TEST.PDX.AT.pdxid is the attribute configured as PDX ID Attribute on the Channel Properties Tab

  • TEST.PDX.AT.WorkflowEvent, TEST.PDX.AT.WorkflowStates and TEST.PDX.AT.MessagesToSupplier are the attribute configured as PDX Status Attribute, STEP States Attribute, Supplier Message Attribute on the Workflow And Status Tab

  • TEST.MaintenanceID is the attribute configured as Maintenance ID Attribute on the Workflow And Status Tab

  • TEST.SentToPDX is the attribute group configured as Include in Maintenance on the Workflow And Status Tab

  • MaintenanceMatchingKeys is the attribute group configured as Promote to Master Data on the Workflow And Status Tab

  • TEST.MasterProductID is the attribute configured as Family ID Attribute on the Supplier Data Definition Tab

If the parameter Family Object Type on the Supplier Data Definition Tab is not empty, then the generated XML should include information on parent products

<?xml version="1.0" encoding="UTF-8"?>
<STEP-ProductInformation ResolveInlineRefs="false" FollowOverrideSubProducts="false" ExportDerivedAttrs="true">
    <Assets ExportSize="Referenced">
        <Asset>
            <AssetContent ExportType="REST">
                <ImageConversionConfiguration ID="Source"/>
            </AssetContent>
        </Asset>
    </Assets>
    <Classifications ExportSize="Referenced">
        <FilterUserType ID="SuppliersProducts"/>
        <Classification/>
    </Classifications>
    <Products ExportSize="Minimum">
        <Product IncludeParent="true">
            <Name/>
            <ClassificationReference type="SupplierLink"/>
            <ProductCrossReference/>
            <AssetCrossReference/>
            <DataContainers/>
            <Values>
            	<Value AttributeID="TEST.PDX.AT.pdxid" />
            	<Value AttributeID="TEST.PDX.AT.MessagesToSupplier" />
            	<Value AttributeID="TEST.PDX.AT.WorkflowStates" />
            	<Value AttributeID="TEST.PDX.AT.WorkflowEvent" />
              <Value AttributeID="TEST.MaintenanceID" />
              <Value AttributeID="TEST.SentToPDX" />
              <Value AttributeID="TEST.MasterProductID" />
              <Value AttributeID="MaintenanceMatchingKeys" />
            </Values>
        </Product>
    </Products>
</STEP-ProductInformation>

In a channel configured with multiple languages, the event queue should be configured with enough contexts to cover all supplier-facing languages.