inRiver model design considerations

  • Litium 7
The InRiver model tool allows a wide variety of design options. Some of these options are restricted or discouraged by InRiver standard best practices (as explained in InRiver wiki). Also, some of the features supported by InRiver V are not compatible with or not supported by Litium. However, a project may choose to go beyond standard InRiver recommendations and might model features that are not currently supported by the Litium InRiver Connector, in which case the connector need to be changed by the implementation project.

Architectural Differences

These are limitations arising due to architectural differences between InRiver 6 and Litium. They are hard to work-around. Therefore it is recommended to avoid these during the modelling phase of InRiver model.

  1. Use InRiver recommended best practice "Product-Item-Resource" model.This is equivalent in Litium to BaseProduct - Variant - Media Files. This model makes it mandatory that InRiver Products are always Base Products in Litium, and InRiver Items are always Variant in Litium Studio.
  2. In Litium Studio, same variant cannot be part of two base products. In InRiver, avoid connecting the same Item to multiple Products via Product-Item links.
  3. InRiver Channel entity and properties are not transfered to Litium. The Litium equivalent of InRiver channel is the installation instance.
  4. The first level of InRiver ChannelNodes directly under an InRiver Channel are transfered as Litium Assortments.
  5. One InRiver Model: Only one InRiver instance per Litium instance (However, there can be multiple Litium Instances for a single InRiver instance). If two InRiver models (from two InRiver servers) are connected to same Litium instance, there will be entity Id conflicts.
  6. Multi-valued CVLs: Litium does not have an equivalent representation of multi-valued CVLs. Consider using multiple single-valued CVL fields instead.
  7. inRiver does not allow spaces in the CVL key, whilst Litium allow it. If you already have a Litium solution with spaces in multivalue/Default value keys, you need to rename them first.
  8. Sort order of Litium Assortments: Sort order of Litium Assortments (immediate children ChannelNodes of InRiver Channel) cannot be changed. It will always be alphabetical order.
  9. ArticleNumber should not be changed, once a Litium article is created. The ECommerce module creates orders which has the article number and changing the article number of an article may result in incorrect ECommerce order data. Therefore, once created, article number should not change. Consider using a Mandatory, Unique, ReadOnly (Integration code has to set it, not the Rich Client user), String property for the article number.
  10. When "inRiver connect" service is not running: The studio connector will not receive events from inRiver, which means important updates will be missed. In particular, if an entity is removed from the inRiver channel, that change will not be reflected in Litium Studio and the corresponding Litium entities (categories, base products and variants) will continue to be published in the public website.

Default entity and link types

This section explains the InRiver EntityType Ids and Linktype Ids used by the connector and describes their default behaviour when importing to Litium.
When modelling your InRiver solution, it is better to use these Ids whenever possible and stick to the behaviour as explained in this article. All names are standard best practice recomendations of InRiver Product-Item-Resource model.
 

Important! : Though Litium InRiver connector does not have hard-coded names, InRiver RichClient and other tools and components may have specific naming requirements. Therefore, it is highly recomended to use the names proposed by InRiver wiki documentation for common entities.

Entity Type Ids

  • Channel
  • ChannelNode
  • Product
  • Item
  • Resource
  • Specification

Link Type Ids

  • ChannelChannelNode
  • ChannelNodeChannelNode
  • ChannelNodeItem
  • ChannelNodeProduct
  • ChannelNodeResource
  • ItemProduct
  • ItemResource
  • ItemSpecification
  • ProductItem
  • ProductProduct
  • ProductResource
  • SpecificationResource

Behaviour of default entity types when importing to Litium Studio

  • Channel: Represents the Litium instance. There can be only one channel per connector instance. Each seperate Litium solution need a seperate channel, and a Litium InRiver connector instance.
  • ChannelNode: Channel nodes directly under a Channel become Litium Assortments. All other nodes become Litium Categories.
  • Product: Litium base product.
  • Item: Litium variant. 
  • Resource: A file in Litium Media.
  • Specification: No equivalent entity in Litium, imported as property fields to the connected entity.
     

Behaviour of default link types when importing to Litium Studio

  • ChannelChannelNode: The target ChannelNode becomes a Litium Assortment.
  • ChannelNodeChannelNode: A Litium Category (parent) and a Litium Category (child)
  • ChannelNodeItem: A Litium Category (InRiver ChannelNode) and a Litium Variant (InRiver Item) published as a base product under that category.
  • ChannelNodeProduct: A Litium Studio Product Group(InRiver ChannelNode) and a Litium Studio VariantGroup(InRiver Product) published as a product under that product group.
  • ChannelNodeResource: A Litium Studio Media Archive resource (InRiver Resource entity File field) linked to the Litium Studio Product Group.
  • ItemProduct: Directional relationship between the Litium Studio Product (InRiver Item should have a ChannelNode parent and inRiver product should also have a different ChannelNode parent).
  • ItemResource: A Litium Studio Media Archive resource (InRiver Resource entity File field) linked to the Litium Studio article (variant).
  • ItemSpecification: Specifications fields become Litium Studio variant group fields in article template.
  • ProductItem: Litium Studio Variant Group (InRiver product) and Litium Studio Variant (InRiver Item)
  • ProductProduct: A Bi-directional relationship between two Litium Studio Products.
  • ProductResource: A Litium Studio Media Archive resource (InRiver Resource entity File field) linked to the Litium Studio variant group.
  • SpecificationResource: Not implemented.
  • ProductSpecification: Not implemented.

Behaviour when an entity is removed from inRiver channel

  • Channel Node: Product groups, products and assortments in Litium Studio corresponding to the channel node is removed. Articles will be delinked from Variant Groups. Variant Groups, Articles and Resources are not deleted, but will remain in unpublished state.
  • Product: The corresponding product in Litium Studio is deleted. The variant group is not deleted. If inRiver product is added to the multiple inRiver channel nodes, its only the product that correspond to the deleted link that will be deleted.
  • Item: The corresponding Litium Studio article is removed from the variant group. The article itself is not deleted.
  • Resource: The corresponding Litium Studio image/resource is removed from the entity property. The resource/image is not deleted from the Litium Studio Media Archive.

Features for future releases

Following features are not avialble in the current version but they may be available in a future version. In the meantime the connector can be modified by the implementation project to support these features by extending/modifying the source code.

  1. Multiple article templates
  2. Multiple product group templates.
  3. Multiple outbound specifications.
  4. Specifications for resources. 
  5. Specification inheritance.
  6. Product Sets.
  7. Article structure.
  8. Deleting articles/resource files when deleted in inRiver.

     
Updated   2020-06-10