Direct publishing to web pages

Excuse the lack of info on my part and the (likely) ignorance of MediaBin terms...

I've been working on a project to upload existing images in a SQL database to MediaBin, modify custom metadata, and retrieve the assets to a file share which will be the root of a web subdomain. I've built a loader app which which makes calls to the MediaBin web service, and then stores a generated URL in a database for other apps to consume. I'm trying to determine if this is the right approach, or of we're using the MediaBin product in it's most efficient way, or if we could call it directly from our web pages.

We've been generating a GUID filename, dropping images from our database out to a landing zone with the generated filename, then calling the InsertAsset_UNC to upload them to the correct container. After modifying the metadata for the newly inserted asset via a call to ReviseAssetMetadata, we call the RetrieveAsJPEG_UNC method, specifying the target share name, size etc.

This seems to be very wasteful of resources, needing to have the asset in both the MediaBin database, and in the website file share - our client applications are retrieving the image URL from the (non MediaBin) database, then specifying the URL as the src property of img elements on our web pages.

When we were buying in to the product, we were under the impression that the MediaBin service would provide an asset directly to our web pages at the required resolution etc - from a quick look round the web, it seems it is possible to integrate the product with different CMS packages, but from what I can see, the images need to be pulled from MediaBin as part of the laying out of those pages. We have many applications where we need an image displayed on dynamically generated pages - our initial belief was that the service would provide this at the time the client apps page is served, however our current implementation is dependent on the image being deployed previously to the web root folder. Have we got the implementation completely wrong - is the product capable of real-time serving of images, which would remove the need for our website file share??

Thanks

John

Find more posts tagged with

Comments

Rick Poulin

Have we got the implementation completely wrong - is the product capable of real-time serving of images, which would remove the need for our website file share??

It's capable, yes.. it's probably not the best approach though. The image transformation is the most computationally expensive part of the process, so you typically only want to do this only once. Otherwise, you're exposing your DAMS to performance degradation from the web.

For many reasons, the Autonomy product stack typically separates the authoring portion from the runtime portion with a thick solid line in the diagram. MediaBin's primary purpose is to *manage* the assets, not to render them. As such, the typical model is for MediaBin to publish rendered assets out to web server(s).

Your process seems a bit awkward, in that you seem to be hardwiring your "publishing" process to an ingestion tool. I get that this is probably part of a content migration process, but you haven't spoken to your final state solution.

If that's what you're having trouble picturing, here's the typical scenario. MediaBin used to have a "Deployment Agent" module back in v4.6. This may or may not be part of MB's workflow engine in v8.x, I'm not sure. But your content authors in MediaBin should be trained such that when they make changes to an asset, they kick off a workflow (possibly with some kind of approval process) which ends up deploying rendered copies and optionally metadata, to front-end runtime servers.

All that to say, your content ingestion sounds fine, but the extraction shouldn't be the responsibility of your ingestion app (at least not in the long run). You should look at building a publishing process in MediaBin instead, which could update your webserver file share (or wherever your docroot happens to be) and your DB as well. By doing so, your runtime scaling strategy should be much more obvious and straightforward.

jwi39

Rick

Many thanks for your reply - I'm involved in the side of house which developed and maintains an application where our customer facing agents can add and update content which should appear on their public web pages. They're built dynamically using data provided by a webservice, which includes binary image info. Our architectural direction was to move away from storing the assets in our database, and load them into MediaBin instead, resize them there (as part of the upload process) and dump them out to the web share - all to be done via the interactions with the MediaBin webservice rather than interactively via the UI.

My only interaction with Mediabin has been thru the webservice (I've never actually seen the UI in anything but screenshots on the web!) but it does seem to support image selection as part of the authoring process. As our pages are built on the fly (for approx 15k agents) we don't really have content authors creating each page (and thus selecting the required photo size), everything from our agent info database is merged to the aspx page at runtime. With our new solution, we were going to provide the image URL for the web share as part of the data feed, rather than taking the binary data and turning it into an image on the fly.

In any case, everything's come to a bit of a crunch as our Marketing department are trying to identify if the solution being provided will actually meet their needs - perhaps like many IT projects, they didn't know what they wanted until they got what they asked for, then realized they needed something entirely different!!

John

Rick Poulin

In any case, everything's come to a bit of a crunch as our Marketing department are trying to identify if the solution being provided will actually meet their needs - perhaps like many IT projects, they didn't know what they wanted until they got what they asked for, then realized they needed something entirely different!!

It certainly sounds like you're not using MediaBin for much. Given your use case, it sounds like you were looking for a better runtime repository rather than a full digital asset management product.

I have to wonder what was wrong with your DB model, and why you moved away from it. There's libraries to do image resizing directly in your ingestion app, so what was MB supposed to add to the equation for you?