When setting up an inRiver iPMC environment for a customer, one of the things we are importing a lot of into inRiver iPMC is images. Lots of images.

A traditional way of importing images, revolves around a "hot folder", often on an FTP server. Here product managers dump images with filenames in specific patterns. Then a scheduled job (in the form of a scheduled extension) to inRiver iPMC would run every 15 minutes, connect to the folder, download the images and import them into iPMC.

In this blog post, you will see a different approach using serverless integration in Microsoft Azure.

Inbound extensions

As part of iPMC, inRiver introduced two extension types, Inbound Data Extension and Inbound File Extension. They both look very much like a Restful WebAPI and indeed the interfaces we can implement contains Add, Update and Delete methods. The first accepts a string of data, the latter accepts a byte array of file data.

Compared to the hot folder design, this looks quite reversed. Now the inRiver platform is not pulling files, the files are being pushed to the platform. To utilize this, other systems would have to make an integration in order to push images to inRiver iPMC.

Using Azure Logic Apps

So, what if the customer really does want to have a hot folder?

For some product managers that folder just fits neatly into their ways of working. They might already be using Dropbox, OneDrive, Adobe Creative Cloud for other purposes. Maybe even using Azure Blob Storage or an SFTP server. So, let’s not remove that from them.

Some time ago, I got the idea that connecting different storage types with an inbound extension could be made serverless. I found that Microsoft Azure provides a serverless platform, called Azure Logic Apps. With this platform, business logic flows can be set up using drag and drop components (no code is needed).

This has a couple of advantages:

• Loose coupling, as neither source or destination system is dependent on each other.
• It is really cheap. Right now, the price per execution is around $0.000025.
• The inbound extension can be made generic and be reused for different set-ups.

And some disadvantages, as well:

• It still has a price.
• Importing one image at a time is not as optimized as batch loading many images can be.

A demonstration

For this demonstration, I assume that a generic Inbound File Extension is already in place in iPMC.

Also, for my demonstration a Logic App will be connecting to a OneDrive folder, although loads of other source integrations come out-of-the-box.

This is my image import flow:

1. A file is dropped in a OneDrive folder, which will trigger the flow.
2. The file must be either a JPEG or PNG file. If it is not, ignore it and exit the flow.
3. Upload the file to the Inbound File Extension in InRiver iPMC.
4. Delete the file from the OneDrive folder.

Unfortunately, the way the inbound data extension expects an uploaded file, was not supported out-of-the-box by Azure Logic App. Therefore, if you look closely at the the screenshot, you will notice that I had to make up a multipart MIME request in order to post my files to the inbound data extension.