How Blending Rules Affect Import

When you import the same item from multiple spoke systems, specific attributes of the item might have different values, depending on the spoke system.

To control which attribute value is imported into production, you can define blending rules, which are applied during import, and which determine which spoke system's attribute value to import, based on the blending priority that you define in the blending rules.

During the import process, blending rules use the spoke system item relationships on a production item to identify the spoke system product records to be blended with imported data. Blending rules are applied at the item level, in a specified order of preference among the spoke systems. When the import is uploaded to production, blended values overwrite the item attribute values in production.

Blending rules aren't applied to product data for new items, since there is no existing data to be blended with new data. The spoke system item relationship used by blending rules to relate a spoke system item to a production item isn't created until an item is imported into production.

Blending rules are applied in the following business events:

When an existing spoke system provides updates to product data that was imported earlier.
When a new spoke system provides data for an existing item.

Blending rules operate during import if:

Existing spoke system cross-references are found in the production database.
New spoke system cross-references are established as a result of matching with a production item containing spoke system cross-references with other spoke systems.

You can choose to apply blending rules to attributes in the following ways:

All attributes in one or more attribute groups. (This is the most common case.)
All attributes associated with one or more item classes.
One or more attributes from a single attribute group.

For blending to work, you can upload data to the staging area using these means:

Product Hub Portal
Product Uploads REST Service (using import maps)

This REST service lets you insert and edit the product data in the staging area.
Data uploaded by other means (such as FBDI, ADFdi, Item Batch Maintenance Service) won't be available for blending because this data is uploaded directly to an item batch.

You can create blending rules for these spoke systems, to be applied when data is being imported from the staging area into Product Hub:

Supplier
Data Pool
Internal

After blending is completed, the blended item record overwrites production data for the item.

General Principles of Blending

General principles guiding the application of blending rules include:

Blending rules run only if any of the spoke systems mentioned in the blending rule has provided data into the supplier stage. If the higher priority spoke system hasn't provided any data, then whatever is provided by the lower priority or other spoke systems (spoke systems not mentioned in the blending rules) will be imported.
If a blending rule is written on an attribute then that rule will run only if that attribute is part of import. The attribute can be part of import because values are provided for that attribute in import.
If a blending rule is written on an attribute group then that rule will fire only if any of the attributes of that attribute group are part of import. The attributes can be part of import because values are provided for those attributes.
If a blending rule is written on an item class then that rule will run only if items of that item class or its child item classes are being imported.
No updates will occur to the items staged in the Staging area of Product Hub Interface. Product Hub stores its data in the Staging area of Product Hub Interface. Blending happens only within the import batch. Blended data is then imported to production.
If more than one rule exists on the same attribute, then the first rule in the master blending rule set will be run.
Products in statuses Rejected or Draft don't get into the batch, so they don't have cross-references, and so they aren't considered for blending.
Blending rules defined for an item class which is at a higher level of the item class hierarchy will be inherited to child item classes.

Blending and Synchronization

By selecting or deselecting the Ignore Null check box when you create individual blending rules, you can choose whether to enable the synchronization of null attribute values from the staging area, to the batch interface area, and then to the production area.

By default, the Ignore Null check box in a blending rule is selected. If you leave it selected, then null values are ignored during import. Blending is performed, but synchronization of null attribute values isn't. This scenario is called blending-only.
If you deselect the Ignore Null check box in a blending rule, then null values being imported replace the corresponding values that exist for the attribute in production. This scenario is called blending-plus-synchronization.
The Ignore Null check box can be deselected only if the blending rule is written at attribute group level.
If an attribute group is a multi-row extensible flexfield, then synchronization causes the missing rows in the uploaded product data to be removed from the flexfield in production.
If an attribute group is used in a single-row extensible flexfield, then the attributes with null values in the uploaded product data are also replaced with nulls in the flexfield in production.
Blending-plus-synchronization is only supported for item-level extensible flexfields (single-row, multi-row, and translatable extensible flexfields) for items of all organizations being imported from Data Pool, Supplier and Internal spoke systems.
Blending-plus-synchronization is supported for items of master organizations and child organizations.

While data is being imported from item batch to production, synchronization of attribute data is performed, as part of blending rules. The attribute synchronization logic is:

Synchronization only occurs if the Ignore Null check box in a blending rule is deselected.
Synchronization occurs at two locations:
- First, while uploading the data to the staging area
- Second, while importing the data into Product Hub through the item import process
If synchronization is enabled for an attribute group (the Ignore Null check box is deselected) then:
- While inserting data into the staging area, values that are missing in the incoming feed delete the corresponding existing values in the staging area.
- While importing data into production, attribute values that exist in production but not in the batch are deleted from production.
If an attribute group named in a blending rule is a multi-row extensible flexfield, and Ignore Null is deselected, then, while inserting the data into the staging area, values of the attributes of this attribute group will be deleted in the staging area for which the values are missing in the data file being uploaded. This attribute synchronization in the staging area is only supported through the PROCESS operation of the Product Uploads REST Service. Then, while importing the data from an item batch to Product Hub, the data in the batch is compared with the production data. For all extensible flexfield rows in production that aren't in the data being imported, these rows are deleted in production after import. New rows being imported that don't exist in production will be added to production after import, and rows having updates will be updated in production after import. Note that for updating multi-row extensible flexfield attributes, unique row identifiers should be provided in the incoming feed.
If an attribute group named in a blending rule is a single-row extensible flexfield, and Ignore Null is deselected, then all the attributes of that attribute group that have no values in the batch are given null values in production after import.
Attribute groups for which Ignore Null is deselected in a blending rule are considered as being owned by the higher priority spoke system. This is termed attribute group ownership. Here's an example of attribute group ownership:
- In a blending rule, spoke system item relationship SpokeA has priority 1 (higher), and SpokeB has priority 2 (lower). The blending rule is associated with attribute group AG_One.
- Import case A (attribute group ownership not in effect): For SpokeA, Ignore Null is selected, so attribute synchronization isn't in effect.
  - In the staging area, SpokeA doesn't provide data for some attributes of attribute group AG_One. The data in the staging area is then imported into Product Hub.
  - SpokeB then provides the data for the same item in Staging for which SpokeA had provided the data but SpokeB provides data for all the attributes of attribute group AG_One. While importing this data from SpokeB, only those attribute values are imported which weren't provided by SpokeA because the Ignore Null check box was selected for SpokeA in the blending rule.
  - If SpokeA had provided values for all of the attributes of attribute group AG_One, then data of SpokeB for attribute group AG_One wouldn't have been imported.
- Import case B (attribute group ownership in effect): For SpokeA, Ignore Null is deselected, so attribute synchronization is in effect. Because it has higher priority in the blending rule, and because Ignore Null is deselected, SpokeA is considered the owner of attribute group AG_One.
  - In the staging area, SpokeA doesn't provide data for some attributes of attribute group AG_One. The data in the staging area is then imported into Product Hub. (This is the same as import case A.)
  - Data from SpokeB for attribute group AG_One isn't imported to production, because SpokeB isn't the owner of attribute group AG_One. The null values provided by SpokeA for some of the attributes are retained in production and aren't overwritten by the values from SpokeB.
  - Without attribute group ownership being in effect, the attribute values from SpokeB for which SpokeA had not provided the values would be imported.

Restrictions and Validations

Restrictions and validations on blending rules include:

Synchronization of attribute values isn't performed for seeded operational item attributes.
Blending rules apply only for the item entity, not for the item revision or supplier entities.
Blending rules may be set up on any attributes of an item.
Blending rule sets can't be composite rule sets.
Blending rules defined at the higher levels of an item class hierarchy are inherited by child item classes.
Spoke systems categorized as internal systems, data pool, or supplier are available as source systems for use in blending rules. The predefined Product Information Management Data Hub spoke system isn't available as a source system for use in blending rules.
Data uploaded by means other than those identified here (such as Product Hub Portal and Product Uploads REST Service) isn't available for blending because this data is uploaded directly to an item batch. Examples of other means are: FBDI, ADFdi, and Item Batch Maintenance Service.
Rule set impact analysis isn't available for blending rule sets.