Synchronize Video Platform Resources from inRiver to Episerver Commerce
inRiver is one of the leading Product Information Management systems out there. Having a solid integration with Episerver Commerce makes it even more appealing for any company looking for an extension to their Episerver powered technical eco-system.
We’ve done a great share of inRiver implementations over the years and are, as always, utilizing all cool aspects of the technical platforms we work with. This blog post will introduce you to one of them. Similar to Episerver, inRiver has a very flexible marketing model, which easily enables you to shape and define data-entities according to your business. One use of that flexibility is the fact that you can easily support various kinds of assets – e.g. images, documents and YouTube hosted videos – as resources related to your other marketing entities. Working through the definition of these entities are simple, hence not covered by this blog post (hint: use wiki.inriver.com for assistance). The focus of this post has instead shifted towards the actual synchronization of these different kinds of resources to Episerver Commerce.
Matching inRiver resources against the Episerver Content Model
inRiver pushes resources to Episerver through a Web Api, which are being exposed by the inRiver connector you’re adding to your Episerver project. When a new resource is received, the inRiver Connector uses a few steps to locate the content type within Episerver suitable to accommodate the resource passed over:
- Based on the ResourceFileId characteristic associated to the inRiver resource, the connector derives the file extension (e.g. .jpg or .pdf)
- If either the ResourceFileId doesn’t exist, or is empty, which it would be if it’s not a physical file (e.g. a Youtube Video), the value “url” is used as file extension
- With respect to the extension, e.g. .jpg or “url”, the connector uses Episerver’s ContentMediaResolver to locate all MediaData content types as per the default extension-driven algorithm
- First MediaData content type matching the extension, e.g. .jpg or “url”, which depends on the actual resource being synchronized, the connector picks the first match implementing IInRiverResource
- If no MediaData content type, implementing the interface and matching the extension, were found, inRiver’s own InRiverGenericMedia is used as fallback.
As you can see, for traditional blob-driven resource types such as images and documents, the inRiver connector will automatically work with your existing MediaData content types as long as they implement IInRiverResource – your implementation can be empty. For videos stored through your favorite hosting platform, such as YouTube, it though requires a few more easy steps for it to work seamlessly.
Ensuring your hosted resources, like YouTube videos, are pulled to the right Episerver content type
First off, second bullet in the list above is essential to highlight. Since your YouTube videos in inRiver never gets uploaded to the inRiver system, they won’t ever have a ResourceFileId characteristic mapping back to any valid file extension. As a result of this, the connector will use the value “url” during it’s MediaData content type lookup.
To ensure your inRiver originated YouTube videos are mapped to an independent Media Data content type in Episerver, you will therefore first have to declare a dedicated class inheriting from MediaData*
Note the MediaDescriptor annotation states “url” and the class implements IInRiverResource.
* If you’re not already familiar with Episerver’s Content Model and how resources are mapped through the MediaDescriptor, please go to Episerver’s documentation here.
Pass along the embed link to your external video
For the example of a YouTube video, it’s recommended to extend your Resource entity type within your inRiver marketing model with a characteristic named “ResourceEmbedLink”. The purpose of that characteristic is to hold the link to a given video on YouTube – e.g. https://www.youtube.com/embed/_D0ZQPqeJkk.
As part of the inRiver connector’s resource import routine, the implemented method HandleMetaData, as part of above InRiverVideoMediaType, is called to enable you to populate additional properties during the synchronization. If you extend previous snippet according to below, you’ll be able to map the value of “ResourceEmbedLink” back to your content type.
Note the implementation of HandleMetaData along with the new property called EmbedLink.
As with any other Episerver content types, you can easily extend your presentation layer with a controller responsible of rendering. If we stick with the YouTube example, your view would rely on a dynamic YouTube embed script, where the dynamic part is driven by your EmbedLink property.
<iframe width="560" height="315" src="@Model.EmbedLink" frameborder="0" allowfullscreen></iframe>
Understanding these essentials of the inRiver and Episerver Commerce synchronization of course applies to more than simple YouTube videos. Have it in mind when you’re working with any form of external resources and/or asset meta attributes and you’ll be done in no time.