Introduction

Intershop Commerce Management provides two mechanisms for distributing products across channels: product sharing and product syndication.

• Product Sharing

  With product sharing, sales or partner organizations can distribute large numbers of master products to sales channels ("outbound product sharing"). The products are not copied to the target channels but remain in the parent organization's master repository.

  Generally, all deriving channels share the master data, regardless of their hierarchy. Channels can, however, choose to activate all or only a selected set of the shared master products ("inbound product sharing").

  Channels that share master products can still add new products or change attributes of a master product by overriding the entire product. When changing a master product attribute, a new channel product is created with a reference to the master product (which serves as a look-up fallback). Note, however, that shared product variations, bundles and retail sets cannot be modified.

  Intershop recommends to use product sharing for distributing large numbers of products, assuming only little changes to the data in the channels.

• Product Syndication

  With product syndication, sales channels can derive master products from parent sales or partner organizations. In a mass data operation, the master products are actually copied to the channel repositories.

  Product syndication requires the mapping of attributes (standard product attributes, catalog assignments, prices, etc.) of the original source product into attributes of a target product (offer). Specific rules control how attributes of the original (source) product are mapped into attributes of the target product. Upon syndicating, hence, attributes can be changed.

  Intershop recommends to use product syndication for distributing products across channels if the product data is expected to be changed in the channels.

Which product distribution mechanism to apply depends on the intended business scenario, with particular respect to the number of products and their attributes, the channel structure, the expected channel-specific data changes, etc. In the context of a sizing estimation, for example, Intershop can evaluate this question and, consequently, recommend either sharing or syndication.

This document introduces product sharing concepts.

References

• Cookbook – Product Sharing
• Concept - Product Syndication and Synchronization
• Concept - Shared Products Changes (valid to 7.6)
• Job - Update Rule Based Sharing Groups in Reference - Intershop 7.6 Jobs.

Glossary

This glossary describes the main terminology used in this document:

Architecture Overview

The figure below represents the overview of the product sharing architecture in combination with the product syndication alternative:

Product sharing always starts in the master repository or partner channel repository. You have to choose the channels the products are shared with. Product syndication, in contrast, is always defined inside the channel you want to fill with products.

The red arrows pointing upwards illustrate syndication. The green arrows pointing downwards illustrate sharing. For example the products in the master repository of the Partner organization 1 are copied (syndicated) from the main sales organization. The partner organization may define its own local products, too. The products in the sales channel repository of Partner organization 2 are shared from various places – from the master repository of the partner organization as well as from the repositories in the main sales organization.

Overview of Product Sharing

1. Configuration of sharing groups/channels with selection of target repositories (channels)
   • Affected tables: PRODUCTSET, PRODUCTSET_AV, PRODUCTSETASSIGNMENT, PRODUCTSETDOMAINASSIGNMENT;
   • PRODUCT table is not touched;
   • DERIVEDPRODUCT table is not touched;
   • Products are visible in the target channels.
2. Product is changed in a target channel
   
   • PRODUCT table is not touched;
   • DERIVEDPRODUCT table is touched and the change is stored here;
   • Base product do not have this change as PRODUCT table is not touched.
3. Product is changed in the master repository
   
   • PRODUCT table is touched and the change is stored here (or the product assignments);
   • DERIVEDPRODUCT table is not touched;
   • In the target channel this change is automatically visible if it is not overwritten (changed) in the channel;
   • In the target channel this change is not visible if the same change was earlier done in the target channel (there is an entry in DERIVEDPRODUCT table).
4. Product is removed from sharing group
   
   • PRODUCT table is not touched;
   • DERIVEDPRODUCT table is touched - entry for this product is removed (if any);
   • PRODUCTSETASSIGNMENT table is changed - entry for this product is removed;
   • In the target channel this product is no longer available.
5. Sharing group is deleted/channel assignment removed/share nothing
   
   • PRODUCT table is not touched;
   • DERIVEDPRODUCT table is touched - all entries for this sharing group/channel are removed (if any);
   • PRODUCTSETASSIGNMENT table is changed in case of sharing group - all entries for this sharing group are removed;
   • PRODUCTSETDOMAINASSIGNMENT table is changed in case of removing channel assignment - entry for this channel is removed for this sharing group;
   • In the target channel no shared products are available anymore.

Overview of Product Syndication

1. Configuration of product syndication mapping rules
   
   • Affected tables: PRODUCTDATADECLARATION, PRODUCTDATADECLARATI_AV, PRODUCTDATADECLARATIONLIST, PRODUCTDATAMAPPINGRULE, PRODUCTDATAMAPPINGRU_AV, PRODUCTDATAMAPPINGRULESET;
   • PRODUCT table is not touched at this point;
   • There are still no products syndicated to this channel.
2. Start syndication by search/browse with selection of source repository
   
   • PRODUCT table grows with the number of selected products - the products are copied in different domain (the channel repository domain);
   • Products are visible in the current channel.
3. Product is changed in the target channel
   
   • PRODUCT table is changed - entry for channel repository domain is changed;
   • Base product don't have this change as PRODUCT table is not touched for the source (master) repository.
4. Product is changed in the master (source) repository
   
   • PRODUCT table is changed - entry for source (master) repository domain is changed;
   • Channel (syndicated) product don't have this change as PRODUCT table is not touched for the target channel;
   • In the target channel this change is not visible until the synchronization process is performed;
   • In the target channel changes between source and target repository are tracked and can be reviewed before starting synchronization process;
   • Performing the synchronization process copies the changes from the source to the target product repository - PRODUCT table is changed for channel repository domain;
   • After synchronization process is completed the changes applied on the source product are also seen on the target product side.
5. Product is removed from source repository
   
   • PRODUCT table is changed - entry for source (master) repository domain is deleted;
   • Channel (syndicated) product is not deleted as PRODUCT table is not touched for the target channel;
   • In the target channel this removal is not visible until the synchronization process is performed;
   • In the target channel changes between source and target repository are tracked and can be reviewed before starting synchronization process;
   • Performing the synchronization process removes the product entry from target product repository - PRODUCT table is changed (entry removed) for channel repository domain;
   • In the target channel this product is no longer available.
6. Disable/remove product syndication
   
   • Remove/delete all syndicated products from the target channel.

Differences Between Product Sharing and Product Syndication

Product Sharing

Advantages

• Supports hundreds of channels accessing the same data
• Reduces the amount of redundant product data in the database
  No redundant data is created when products need to be shared. If the product changes in the target repository, only the delta of the two products is persisted.
• Supports overwriting the attributes of a product
  If a product is changed in the source repository, the change is propagated to the target repositories immediately unless it has been overridden in one of the targets.
• Reduces the number of long running batch processes
  There is no need for synchronization as it is done in the product syndication.
• Usually improves the search performance of database queries
• Reduces the costs of migration
• Straightforward, very fast process
• Allows to create filters for the shared products in the target repository (also known as inbound sharing)

Restrictions / Disadvantages

• Sharing between master repositories is currently not supported.
• Sharing between sales channels is currently not supported.
• Changes to products that are shared to other repositories are immediately visible in all target channels. This restriction applies when customizations are required in the projects.
• The links (or the contained products) in the shared variation masters and product bundles cannot be changed in the target repositories. The same applies to the product-category assignments and product links that were shared from another repository.
• Mapping rules or selecting only a subset of product attributes is not supported. All product attributes get shared. It is not possible to leave some of them out.

Product Syndication

Advantages

• The copy process can be adjusted so that only a part of the product data is taken into account. This is achieved by the usage of mapping rules. Mapping rules may be quite advanced and certain data may be modified during the process.
• The newly created products are independent and behave like local products of the channel or the organization. If you change a product attribute inside the master repository, it is not changed within the channel.
  Changes in the source repositories can be approved before propagation to other repositories. This is done by the synchronization mechanism.
• If you syndicate the products, there will be no problems in creating variations or bundles in the syndicated channel.

Restrictions / Disadvantages

• Product data is doubled for each copied product, resulting in the production of a lot of redundant data.
  The total size of the product repositories explodes which has a negative impact on the performance and resource requirements of the system. This especially needs to be considered if the system maintains many channels that distribute the same products, many products or both. Using syndication makes product tables grow with the number of channels.
• The process of initially syndicating and later synchronizing many products is slow and requires substantial resources. The more products and channels are in the system, the slower the process.
• After the product has been syndicated, the newly created product has its own lifecycle and can be changed independently. However, if a change needs to be propagated through all channels (e.g., a changed product description in the source repository) a special background process has to be started. This process is called product synchronization and it requires both resources and administration.
• If a product has been changed in both the source and the target repositories, the synchronization process will override the local changes in the target repository.
• Users that have the right to browse the channel repositories may have access to the master repository. This contradicts the general IS7 data flow.

Choosing Between Syndication and Sharing

A technically justified limitation is that syndication and sharing cannot be used together for distributing product data to the same target repository. Only one of the two approaches should be chosen.

A simple rule of thumb is that sharing should be used whenever it is possible. This is the preferred way to distribute products across channels simply because it is much more resource effective. Nevertheless, there are certain situations in which syndication might be preferred. This section complements the previous and gives hints when and what to use.

Syndication is preferred when:

• The products are managed decentralized in several repositories.
• The syndicated products are heavily changed in the target repositories. Most of them are meant to have channel-specific properties that override the properties of the source products. However, if the product changed in both the source and the target repository, the synchronization batch process will override the changes in the target repository with these in the source.
• Modifications of the syndicated products are always necessary and mapping rules are the right tool to implement these changes.
• The products in the source repositories do not change often and only occasional synchronization is necessary.
• The products in the target repositories need to be independent of these in the source.

Sharing is preferred when:

• The products are managed centrally.
• There are lots of products and channels.
• The system must scale well when new channels and products are added.
• The products in the target repositories are the same or differ slightly from these in the source repositories.
• Products are modified primarily in the source repository and changes need to be propagated to the target repositories immediately.

Outbound Product Sharing

Outbound product sharing is the process of selection of the target channels and the products to be shared with these channels performed at the source (master, partner channel) repository. The sharing direction is from the source repository to several target repositories. This process shares selected (or all) products of the source domain with the channels selected as target domains.

The following main tasks are involved in the outbound product sharing mechanism:

1. Select channels with which to share product data.
2. Assign the data set to be shared.
3. Create sharing groups to pre-defined data sets.

The picture below shows the workflow of outbound product sharing:

Channel Assignments

Sales or partner organizations select the channels with which they intend to share product data. Generally, the assigned channels are intended to just reuse the original master product data.

They can, however, still add new products or apply some channel-specific changes to master products (except for shared product variations,bundles and retail sets).

An un-assignment of a channel with which the product data is shared removes the shared products from the channel.

Nevertheless, modifications applied to the shared products are maintained, i.e., re-establishing the sharing relation with the same products automatically restores previous modifications.

Product Data Assignments

For every sharing relation, i.e., for every assigned channel, the parent organization defines the scope of products to be shared. The available options are: nothing, all, or by sharing group.

Sharing Groups

The sharing group provides capabilities to assign target channels and to select products to be shared into the added target channels based on:

• rule-based (automatic) product selection
• manual product selection

The picture below represents the user interactions that are possible to be done in the context of creating and maintaining sharing groups and their channel and product assignments.

The Intershop Commerce Management application offers the capability to select between rule-based product selection by manufacturer/category and manual (search/browse) selection of products.

Rule-based Product Selection

The rule-based selection uses manufacturer/manufacturer alias and/or category assignment as rules for product selection, i.e., products which have manufacturer X as attribute will be assigned to the sharing group, products which have category ABC as category assignment will be assigned to the sharing group.

According to the selected manufacturers and categories the product set assignments are made. A job Update Rule Based Sharing Groups is created in domain SLDSystem that will update the assignments regularly.

Manufacturer Alias

Manufacturer aliases provide a comfortable way to group sharing products based on the respective manufacturer.

Using aliases, organizations can specify new manufacturer names intended to represent one or more actual manufacturers. This eases the handling of multiple manufacturers that, based on their offering, could be grouped, or, e.g., manufacturers that appear in more than one spelling.

Manufacturers assigned to a manufacturer alias cannot longer individually be retrieved in sharing groups but only with their common alias name.

Мanual Product Selection

The manual selection of products or the assignment of products via Search/Browse is done in two ways: select desired products directly or select a desired category with products (currently the selection of products by category is not supported by DBInit but the same functionality is supported by DBInit for rule-based product selection).

Assign By Search opens the product list view, displaying all products in the repository that are currently not assigned to the sharing group. The simple search or advanced search is used to find the products you intend to add to the sharing group.

Assign by Browse opens the list of available catalogs. To browse specific catalog categories, select the radio button for the catalog and click Next.Click the category names to view the sub-categories until you have found the intended category or product list.

Channel Assignment

At the Channels tab of the sharing group a channels can be assigned.

Basically, multiple channels can be assigned to one sharing group and multiple sharing groups can be assigned to one channel.

Differences Between Deleting and Disabling a Sharing Group

If a product sharing group is deleted or unshared, the according product assignments are removed. All data in DERIVEDPRODUCT, DERIVEDPRODUCTCOSTPRICE and DERIVEDPRODUCTLISTPRICE is cleared.

If a product sharing group is disabled, all product assignments are kept. They are just not visible in the Commerce Management application and/or the storefront. All data in DERIVEDPRODUCT, DERIVEDPRODUCTCOSTPRICE and DERIVEDPRODUCTLISTPRICE is preserved.

Product List and Product Sharing Tab

The product list view and product detail view contain further information about product sharing. The product list view of a repository that shares products to other channels contains an additional status icon if the product is shared to another repository.

The Sharing tab of the product detail view shows all channels sharing this product and related information.

Inbound Product Sharing

Inbound product sharing is the process of selecting certain products shared from another (source) repository to be activated for current channel (which is the target domain of the sharing relation). By default, the inbound product sharing accepts/selects all shared products as active/visible in the current channel. Additionally, specific products is possible to be selected for activation. In this case, only the activated products by this inbound product set are visible in the channel. The sharing direction is from the target repository to the source repository. This mechanism activates selected (or all) products of the source domain for the current channel.

The following main tasks are involved in the inbound product sharing mechanism:

1. Select to share/activate all or selected products.
2. Maintain lists of active and inactive products.

The picture below shows the workflow of inbound product sharing:

Inbound Sharing Administration

The inbound product sharing gives the receiver of shared products the ability to select all or a set of incoming products for further usage.

Activate all shared products option - assigns all shared master products to the channel repository.

Activate selected shared products option - displays the list of all available shared master products that are currently inactive, and below the list of currently active products. You can either browse through the list or perform a search to narrow the choice.

Product List and Product Changes Tab

The product list view of the target channel shows appropriate status icons if the product was shared from another repository.

The Changes tab of the product detail view shows current differences between the shared product and the base product.

As mentioned above the contained products in the shared variation masters and product bundles may not be changed in the target repositories. It is also impossible to change on the target channels the product-category assignments and product links that were shared from another repository. The assignments and the links are visible but read-only.

These restrictions does not apply for the locally created assignments and links.

Sharing Procedure

The sharing procedure consists of the following high level steps:

1. Get the product (manually, import, replication, etc.)
2. Share the product by assigning it to a proper group and an available channel, or share the entire repository (outbound product sharing)
   • Sharing is configured in the Master or Partner Channel Repositories.
   • Channel Requirements: must not be a Partner Channel and no syndicated products in the target channel.
   • Products can be explicitly assigned by a sharing group or implicitly through a channel assignment.
   • The explicit relationship can be set up from both: Channel => Sharing Group, Sharing Group => Channel.
   • Multiple sharing groups can be assigned to one channel.
   • Multiple channels can be assigned to one sharing group.
3. Make channel specific changes in the target channel - change attributes, prices, life-cycle information, ...
   • Attribute changes in the master repository become effective immediately in case of these attributes are not overwritten in the target channel.
   • Overwritten attributes are visualized in the Changes tab in the detail product view of target channel. The changes on product relations (categories, links, attachments, ...) are not shown in this tab. They are not shown at all because only new assignments is possible to be defined at the shared product side and preserving the shared ones. So no changes could be detected on one product relation between the base product and the derived (shared) product.

Product Sets

The term Sharing Group is used in the UI and it is the synonym of a Product Set. Product sets are defined for a given domain. They are extensible objects. We distinguish three types of product sets:

• The all products product set. Each domain, which can share products to other domains can define exactly one all products product set. The flag all is set for this product set. Target channels assigned to this product set will share all products of the source domain.
• The no products product set. Each domain, which can share products to other domains can define exactly one share nothing product set. The flag nothing is set for this product set. The product set has no product set assignments. Target domains assigned to this product set will share no products of the source domain. This product set was introduced for easier administration in the Commerce Management application. It is used to build a sharing relation if someone decides to share products to a target channel later. Currently no products are shared, but it will be impossible to syndicate products to that target channel (syndication and sharing at the same time is not allowed for the same channel).
• The ruleBased product set.The ruleBased flag defines how products are selected. If ruleBased is used then a rule-based product selection is made, or an explicit selection.

There are two other important boolean attributes that are defined in the interface ProductSet:

• The inbound product set. It is defined for a target channel and allows filtering of all incoming shared products. The inbound flag is set when Activate selected shared products option is applied.
• The active product set.The active flag is indicating if the product set is enabled (active) or disabled (inactive).

The following class diagram shows the ProductSet and related classes:

Product Sharing Helper

The class com.intershop.beehive.xcs.internal.productset.ProductSharingHelper can be used to determine if a domain shares products from another repository. The product sharing helper has three important methods:

• isEnabled: Returns true if the domain shares products from other domains
• getDomains: Returns a collection of domains which products are entirely visible in the given domain
  This includes the given domain itself and all domains of product sets where the flag for all is set.
• getProductSets: Returns all product sets with explicit product assignments (no all products product sets)

The product sharing helper also implements the interface com.intershop.beehive.core.capi.query.processor.QueryParameterHandler. This makes it possible to use the product sharing helper in query files as a pre-processing rule in queries. The following code shows an according usage.

<query>
<parameters>   
	<parameter name="Domain" type="com.intershop.beehive.core.capi.domain.Domain"
optional="false"/>    
</parameters>
<processor name="OracleSQL">
    <processor-preprocessing output="Sharing" input="Domain"
processing="ProductSharingHelper"/>
</processor>
<template type="countedobjects">
	SELECT
		productid,
		count(productid) over() as ROWCOUNT
	FROM
		deletedproduct 
    WHERE
    <template-if condition="Sharing:Enabled">   
	domainid IN (<template-loop alias="Domain" iterator="Sharing:Domains">
<loop-statement><template-variable value="Domain:UUID"/></loop-statement><loop-separator>,</loop-separator></template-loop>)  
	<if-else/>
	domainid = <template-variable value="Domain:UUID"/> 
	</template-if>
</template>
</query>

A usage in Java sources looks as follows:

ProductSharingHelper sharing = new ProductSharingHelper(domain);
if (sharing.isEnabled()) {
    // do something
}

A pipelet com.intershop.beehive.xcs.pipelet.productset.CreateProductSharingHelper needs to be executed if a check for shared products for a given domain is needed in a pipeline. Sample usage can be seen below:

Derived Product

A derived product in a business or consumer channel holds all changes made to this product if it was shared from a master repository or partner channel repository.

The class DerivedProductPO holds channel specific changes of products, i.e., if a product has been changed in the channel in a way that specific attributes of ProductPO are getting a new value or any custom attribute is added or changed then a new instance of DerivedProductPO is created that holds these changes. The primary key of the class consists of the ID of the base product and the domain ID of the channel where the product was derived.

On the picture above ProductPO derives from the abstract class XMLExtensibleObjectPO implementing the interface ExtensibleObject, but providing another database design. While, the DerivedProductPO derives from ORMObject, because of its special primary key.

A transient class that implements the interface Product performs all lookups using the required fallbacks. The implementation class is named ProductViewImpl:

ProductViewImpl uses the following fallback when getting a product (the searches must perform the same fallback in database queries):

1. Get the derived product or only a single attribute from the derived product.
2. If no derived product is defined or the attribute does not exist use the base product.

ProductViewProvider

All product queries need to return instances of the product view instead of plain products. That means all related queries require changes accordingly. The query framework will get a new result mapping type named “provider” which allows passing the provider name that is responsible to create the product view. The provider that returns product view instances is named ProductViewProvider.

The ProductViewProvider requires the UUID and the domain UUID. It is registered like any other provider instance and can change in custom projects. For more information about how to register and replace an existing provider implementation refer to Concept - Dependency Injection and ObjectGraphs and the corresponding cookbooks.

Queries

All query files that search products use the sub-query GetSharedProductsByAdvancedSearch.query. This implements the lookup of shared products by domains or product sets. There are a couple of other places in the Java code where a similar sub-select is used. The related queries need an additional filter condition, which checks if all products are part of the inbound set if there exists one. See the second EXISTS clause of the following query:

WHERE
(
    (
        p.domainid IN (<SharingDomains>)
        OR EXISTS 
        (
            SELECT 1
            FROM
                productsetassignment psa
            JOIN
                productset ps ON (psa.productsetuuid=ps.uuid)
            WHERE
                p.uuid=psa.productUUID
            AND
                p.domainid=ps.domainid
            AND
                psa.productsetuuid IN (<OutboundProductSetIDs>)
        )
    )
    AND
    (
        EXISTS 
        (
            SELECT 1
            FROM
                productsetassignment psa
            WHERE
                p.uuid=psa.productUUID
            AND
                psa.productsetuuid = <InboundProductSetID>
        )
        OR
        (
            p.domainid = <ProductDomainID>
        )
    )
)

Jobs - Update Rule Based Sharing Groups

The job Update Rule Based Sharing Groups is used to refresh the assignments for rule based product sets. It is scheduled in SLDSystem domain and gets all rule based sharing groups and updates the product assignments based on the updated rules.

The main properties of this job are documented, e.g., here: Reference - Intershop 7.6 Jobs.

Optimization and Extendibility

Optimization

• Overwrite product queries to improve query performance.
• Overwrite following queries to globally optimize context indexes:
  • database/GeneralContextIndex
  • database/LocalizedXMLAttributeContextIndex
  • database/XMLAttributeContextIndex

• Configure local context index queries to optimize particular context indexes:
  • intershop.cartridges.ctx_table.<table>=<query>
• Write own SortingAttributeProviders to optimize sorting in queries.
• Use Direct Custom Attributes.

Extendibility

• Exchange the ProductViewImpl by configuring an own provider in:
  resources/<cartridge>/objectgraph/objectgraph.properties: global.overrideModules=com.customer.application.intershop.extensions.MyCartridgeOverrideModule
  and bind ProductViewProvider to your own provider implementation.
• Write jobs maintaining product assignments of sharing groups.
  • Example: assign products by interpreting flag attributes
• Implement own sharing mechanisms by replacing the ProductViewImpl and overwriting according queries.