Integrating inriver: An overview

This overview article gives you the basics for integrating and adapting inriver to your needs.

Integrating primarily refers to onboarding and offboarding content. However, you can also create automation, for example by listening to events and triggering actions.

inriver provides many ways to manually manage your product content from within the application itself. If you want to learn more, this section in inriver Community is a good starting point.

Hosted vs remote execution

inriver offers multiple options for integrating and adapting inriver, both hosted and remote.

Hosted solutions are deployed as extensions. They run in the inriver cloud service, using the inriver Connect service.

Remote solutions are hosted and execute outside of the inriver cloud service.

The choice between hosted or remote execution might be a partner or customer preference based on tech stack. The general recommendation is to choose a hosted execution, as performance is better in the cloud due to lower latency.    

Framework or API

There are three main ways of automating inriver integrations that are used to send and receive data, as well as to customize workflows and to manipulate data in your user interfaces.

• REST API - Traditional technology-agnostic REST API. If possible this is preferred over the Remoting API for remote solutions, but may not offer the necessary functionality. Read more in this article.
• Remoting API - API with more functionality than the REST API.  Requires C# programming. Required for use with hosted solutions but can be used in remote solutions, although REST is recommended for remote solutions where possible.
• inriver Integration Framework (IIF) for outbound integrations - Returns data using a common Integration Model instead of the customer's unique Elastic Data Model. Ideal for building adapters, assisting with headless eCommerce, exporting to storefronts, and for larger customer integrations. Writing extensions using the IIF requires C# programming, but the IIF Connect API offers some functions over HTTP. Read more in this article.

There is also the xConnect API which the Content Store is built upon. However, this is not really an option as the REST API provides much more flexibility. As the Content Store capability evolves, this API will be deprecated. 

Selecting the right method

The best approach to use varies from customer to customer, and maybe even from integration to integration. There are many factors that need to be taken into consideration including but not limited to the size and skill of your development team and the tools and systems that you use.

The choice of tools might also differ depending on your needs and where you are in the PIM process. 

Examples

Below is a list of example scenarios you might run into:

• You want to send product information to an external system? The Integration Framework would most likely be a better solution than the REST API.
• You're a partner working on an adapter to be used for several different customers? The Integration Framework is the recommended solution.
• You need to customize a workflow for one specific customer? This is usually done with some kind of extension depending on the specific requirements.
• Need to build a hosted inriver extension? Use the Remoting API or Integration Framework depending on your requirements and/or preferences.
• Need to build a remote solution? Use the REST API if it contains the functionality you require, if not then use the RemoteManager in the Remoting API.
• Want to build an adapter to export product data to an eCommerce system? Integration Framework is preferred but a Remoting API solution might also be possible. If you plan to use the adapter for several different customer/environments you get a lot of benefits by using the Integration Framework. 
• You want to aggregate product data for use in headless eCommerce? Integration Framework is preferred but a Remoting API solution might also be possible. Note however that if you use a Remoting-only approach, you need to account for customer-specific Elastic Data Models.
• You need to validate a business rule and if it fails, prevent an entity from being saved in inriver? Write a ServerExtension using the Remoting API.
• Your development team does not work with C#/Microsoft tech stack? REST API or IIF Connect API.
• You want to use inriver Integration Framework but do not have C# programmers on staff? Look to use the IIF Connect API.
• You need to compute a field and it is OK to populate it asynchronously? Write a Listener Extension using the Remoting API.

Basically, you can use the table below to assist you in the decision-making.

The PIM process

The PIM process can be divided into four phases:

• Content Onboarding
• Content Creation
• Content Distribution
• Content Evaluation

Content onboarding

When onboarding content, incoming data is provided by inbound integrations or by manual tools provided by the inriver platform.

To facilitate content onboarding, inriver provides tools such as Supplier Onboarding, Contribute, and the Excel Import and Export functionalities. You can also upload content manually and in bulk, for example images.

If you want to automate your incoming data feeds, you can add the pre-built Import Adapter to your license. You can also create custom integrations using the REST API or Remoting API.  Hosted solutions are recommended for managing larger quantities of data.

Content creation

When creating and/or improving content and content workflows, you can use tools provided by the inriver platform or automate the interaction with inriver by using different types of extensions. 

To facilitate content creation, inriver provides tools such as mass update, completeness, in-context editing, tasks, and other workflow-related tools.

Two other tools are application templates and HTML templates that can be used for content creation as well as for onboarding or distribution.

If you want to automate the management of data or workflows, you can use pre-built adapters such as the Adobe AEM Assets Integration for DAM functionality. You can also create custom integrations using the REST API (or Remoting API). Listeners are for example used to identify when events are triggered. Read more in this article.

Content distribution

When distributing data, you can use tools provided by the inriver platform or automate the interaction with inriver by using different types of extensions. 

To facilitate content distribution, inriver provides tools such as Excel Export, inriver Print and inriver Content Store.  

When automating content distribution, there are two tools you can use, inriver Syndicate and inriver Plan & Release.

inriver Syndicate is primarily pushing data to marketplaces where you can customize the integration depending on the requirements of the endpoint.  

inriver Plan & Release allows classification of content in a catalog and category format and is typically used with e-commerce systems or inriver Print. You can find several of the inriver standard adapters which leverage Plan & Release here. 

If you want to automate the distribution and publishing of data from inriver without using the pre-built options, you can use the Integration Framework to create custom integrations through Plan & Release. If you want to create an integration based on Syndicate, you can use the REST API or Remoting API.

Technically, the implementations vary due to the way data is managed internally and delivered to the different extension interfaces. Read more about different extensions in this article.

Content evaluation

This is an important step in the PIM process, but not an integration point to build extensions to at this time.

Further reading

Inriver integration terminology