Collaboration and Enterprise Content Management
Enterprise content management can be a big pain point for organizations that do not properly plan ahead for file sharing. One Entrance client had an interesting problem that the software consulting team was asked to fix. Every year they must interview hundreds of students, each of which has a profile and a set of documents (recommendation letters, transcripts, etc.- you probably have fond memories of that stuff). These documents are really only viewed a few times, but when they are, they’re viewed by a lot of interviewers trying to prepare for the interview at the same time. The documents aren’t huge, and we aren’t talking about giant documents, but the client also doesn’t pay for a lot of hardware and bandwidth. In past years, serving up these documents has been a mess, without interviewers struggling to connect and download documents in time. After this crunch period during the interview cycle, the documents never need to be accessed again, and can just be archived away.Azure and the Cloud
Enter the cloud. After some research into the options, Azure looked like a great solution. They could store and host the documents there, and delete everything after the interview cycle. The client would just need to pay for the storage for a brief period. I’ve looked at hosting VMs and remembered
that it can get pricey. But when we ran the numbers for Blob storage, for the data volume and bandwidth the client would require, they would end up paying less than $10 a month. Great!
There are various types of storage options, but the team decided on Blob storage. This lets you store and retrieve arbitrary binary data. Under your Azure account, you can create any number of “catalogs” which contain any number of blobs. The metadata on a blob is very limited- essentially name and content type.
Azure provides a RESTful API and a .NET client API for manipulating your data. The .NET API is quite straightforward.
Azure and Enterprise Content Management
The only mildly complex thing about Azure is access control. You have a few options: 1. Restrict access to the Azure account. This might be fine if we wanted to retrieve the documents on the server and then stream them back to the client, but this doesn’t solve any of our problems. 2. Open access to everyone, and just restrict ability to list the container contents. This is security by obscurity, and inadequate. 3. Create a shared access signature. This allows you to give users temporary access to a specific container or blob. The server creates an access policy in Azure, and uses it to generate a shared access signature. This is a token that is appended to the URL for the Blob. The client can use that URL for the amount of time specified in the policy. We used option 3. We create containers for each student that contain all of the student’s documents. When an interviewer needs to browse the scholar’s documents, we create a temporary policy allowing them to access the student’s container for an hour.Troubleshooting Azure
At first we were troubled by the fact that a user with access to a nominee’s documents could forward the URL to anyone- nothing ties the client user to the access policy. Upon reflection, I realized that they could just as easily forward the downloaded document, so we haven’t given up anything by using this scheme. Just because nothing is simple, there were a few gotchas to trip up the beginner.- Containers have to be named in all lowercase letters or numbers. Hyphens are allowed, but must be followed by a letter or number. Camel case is not allowed. The errors caused by this are not intuitive.
- If you get the latest Azure Blob Client code from Nuget, it will not work with the emulator in the latest Azure SDK. You need to get version 2.X instead of 3.x. Apparently there will be an update to the SDK in Spring 2014 to address this.
The post Enterprise Content Management: Azure Blob Storage appeared first on Entrance Software.