SharePoint 2013 and Windows Azure Media Services

One of the cool new kids on the block for Windows Azure is Media Services. Windows Azure Media Services (WAMS) is currently in Beta, and as I dig in more I personally feel there’s a ton of potential here—especially when it comes to SharePoint. For those that don’t know what WAMS is all about, it’s a slick set of services and APIs within the Azure platform that enable you to do things like upload videos, encode into new file formats/codecs, save to BLOB storage, set permissions for consumption, stream BLOBs with global cache, and so on. Here’s the thing: you can do this all through a set of cloud-based APIs, which when compared to previous media management workflows and processes buys you quite a bit. Using WAMS, you can not only optimize your multimedia processing and management, but you can build some pretty darn compelling apps in the process. 

Windows Azure Media Services

You can see below the different services that will be available from within WAMS. There’s quite a bit here—and not only for SharePoint, but for more general media management and consumption as well.

So, why should you give a rip, right? Well, what’s interesting is that there’s been a relative constant when it comes to the adoption of SharePoint: in many organizations it’s being used as a multimedia learning platform (or even a corporate communications platform). That is, the document libraries, lists and ability to manage sites and media within those sites give you the ability to build out multimedia solutions that are built on SharePoint. It’s just easy to integrate multimedia with the ability to manage sites, documents, and permissions against those artifacts. However, what’s been tricky has been the ability to process and manage the multimedia that sits behind those solutions. Think creating and projecting a WMV format across 3-4 different other codecs; think having a common streaming point where we can assess permissions using the native SharePoint security authentication; and think about having a set of services and APIs that can now allow you to not only publish to SharePoint, but also project cross-device.

Some interesting scenarios that bring these two technologies together are:

1. Organizational Web sites
2. Learning solutions built on SharePoint
3. Corporate communications
4. Digital marketing campaigns in SharePoint FIS
5. Multimedia publishing platform
6. Social networking/community web sites
7. …

In short, there’s lots of potential here.

WAMS & SharePoint

Now for readers of this blog, you know I’ve focused a lot on the Azure and SharePoint kick; albeit I’ve focused a lot on SharePoint 2010. However, with the veil lifting on what SharePoint 2013 has to offer, all of a sudden not only is the integration of SharePoint and Windows Azure native, but it also is very compelling (and know that I’ll be focusing some energy on this moving forward). For example, for those of you who are in the SharePoint community, I’m sure you’re now up to speed on the fact that the future direction for SharePoint app development is the cloud; it’s the guidepost for future app design and deployment and is somewhat of a shift from what we’ve come to understand in SharePoint 2010. That is, within SharePoint 2013, there exist a couple of ways to build and deploy apps within a cloud-hosted app model: the first is the autohosted app; and the second is the provider-hosted app. The autohosted app model is an inclusive cloud model, where you build an app where configuration information lives in SharePoint and the core server-side code lives in Windows Azure (but through deployment they are registered and live as one). The provider-hosted app model is much more flexible. You can deploy code to any web platform, including Windows Azure, and then register that app with SharePoint.

So, the question becomes how we begin to mesh this interesting world of WAMS with the (new and existing) world of SharePoint—thus, the integration of media and SharePoint. To help illustrate, let’s walk through an example. And in this walkthrough, we’ll do two things:

1. Build out an HTML5 cloud-based app that leverages a video streamed from Azure Media Services; and

2. Create a simple SharePoint 2013 “Client App” that surfaces the media within SharePoint.

Yes, there is an assumption here about managing and consuming media from WAMS. What about the upload? What about the transcode? What about the management of media? Well, it’s all here. Using the SDK and How-to’s, you can build yourself a handy-dandy app that moves your apps into your Azure account and then makes them available for use within other solutions or platforms like SharePoint. And it’s within these how-to’s and the SDK that you’ll hopefully begin to see the power of WAMS.  But this is a blog, and we must scopeth that which we delivereth. Thus, the assumption with this walkthrough is that you’ve followed the aforementioned tutorials and have created a WMV, uploaded and encoded it as a MP4, and have then saved it to Blob storage so you can stream it from Azure. So, we start from a video that is ready to be streamed from WAMS, e.g. https://myvidsite.cloudapp.net/home/default.html.

Building an HTML-based Media App

You can create a Windows Azure app using the .NET 4.0 framework and all the latest and greatest Azure tools/SDK (v. 1.7). To do this:

• Open Visual Studio 2012.
• Click File, New Project.
• Select Cloud and then select Windows Azure Cloud Service.
• Provide a name for the project and click OK.

• When prompted, select the ASP.NET MVC 4 Web Role, and then edit the name of your role to make it more intuitive.
• Click OK.

• At this point, Visual Studio creates the project structure and default code spit for you.

At this point, I removed a bunch of the default project goo—such as the ASPX pages, App_Data folder, etc. You’ll note that I added a set of supplement libraries/resources for my HTML video player, e.g. a CSS folder with a playerframework.min.css file (and debug file), a JS file added to the Scripts folder called playerframework.min.js (and again a debug file), and then focused on the heart of the Azure app by creating the default.html page—which will load the BLOB from Azure (or WAMS). (You could probably trim even more if you wanted from the default project, but I chose to stop here.)

• To hit the default.html page when you’re debugging, right-click and select Set as Start Page.
• Within the default.html page, add code that resembles the following snippet of code. (What will vary in your code will be the bolded URI that points to your video.)

<html xmlns="https://www.w3.org/1999/xhtml">
<head runat="server">
<title>HTML5 Video Player</title>
<link rel="stylesheet" href="../CSS/playerframework.min.css"/>
<script type="text/javascript" src="../Scripts/playerframework.min.js"></script>
</head>
<body>
<form id="form1" runat="server">
<div>
<video id="myVideo" class="pf-video" width="480" height="320" controls="controls">
<source src=https://myblobstore.blob.core.windows.net/html/BigBuckBunnyMP4.mp4?sr=c&si=new&sig=5CxDGrmtYndAm8bhdwITw7tlABlZFTxtsL%2BfR051Ngg%3D
type='video/mp4;
codecs="avc1.42E01E, mp4a.40.2"' />
</video>
<script type="text/javascript">
var myPlayer = new PlayerFramework.Player("myVideo");
</script>
</div>
</form>
</body>
</html>

Now there’s a couple of things of interest here. The first is that we’re using HTML5 and the <video> tag to load and play our Azure-hosted video. (If you’re looking for a good primer on the video tag, check this blog-post out.) The second is that you can see that we’re not only referencing the MP4 file (https://myblobstore.blob.core.windows.net/html/BigBuckBunnyMP4.mp4) but we’ve also got some strange GUID thingy (sr=c&si=new&sig=5CxDGrmtYndAm8bhdwITw7tlABlZFTxtsL%2BfR051Ngg%3D) at the end of the URL: this is the access signature that you create programmatically using the WAMS API—or you can use the Cloud Storage Explorer to do some of this manually (also known as an Access Policy ID). This indicates the level of access you can set for consumers for a specific video asset. For example, if you click on an MP4 asset in your Cloud Explorer view, and then click Security, you’ll have the ability to manually set the shared access permissions options.

If you then click the Shared Access Signatures tab, you’ll be able to leverage a Shared Access Policy that you’ve created for your BLOB, and you can click the Generate Signature button, which creates a full BLOB URL for your video. You can then Copy to Clipboard and then paste in a browser to load the video and stream from Azure. (As per this post, ensure you have the correct MIME type; else, this will cause a failure for your video to load properly.)

You can see that when you click the Shared Access Policies tab you can create new policies with specific access rights and start and expiration times—all of which are enforced against your video BLOB.

While not complete, the below excerpt from the WAMS SDK gives you a sense for how you can do some of the above programmatically:

static String GetAssetSasUrl(IAsset asset, TimeSpan accessPolicyTimeout)

{

IAccessPolicy readPolicy = _context.AccessPolicies.Create("My Test Policy", accessPolicyTimeout, AccessPermissions.Read);

ILocator locator = _context.Locators.CreateSasLocator(asset, readPolicy, DateTime.UtcNow.AddMinutes(-5));

…

var theOutputFile = from f in asset.Files

where f.Name.EndsWith(".mp4")

select f;

IFileInfo theFile = theOutputFile.FirstOrDefault();

string fileName = theFile.Name;

var uriBuilder = new UriBuilder(locator.Path);

uriBuilder.Path += "/" + fileName;

…

return uriBuilder.Uri.AbsoluteUri;

}

• When you’re done adding the HTML and required resources, hit F5 to debug. You should see something similar to the below: your video being streamed from WAMS within your HTML5 video player.

• The next step is to publish your app to Windows Azure. To do this, right-click your Cloud project and select Publish. Then, publish the application to your Windows Azure subscription/account. This will then make the app accessible from the wider Web, hosted on Windows Azure.

• Once you’ve published your HTML5 video player app that consumes the video being streamed from WAMS, you are now ready to move onto the next step: creating a simple SharePoint 2013 app that surfaces the Azure app.

Integrating the Azure App with SharePoint 2013

In the first exercise, you created and deployed an HTML5-based video player that was hosted on Windows Azure and leveraged the core WAMS features to upload, transcode, store, and stream a video (although this WAMS-specific functionality was a pointer to the SDK). Where you should have left off was having a deployed app where the HTML5-based video loaded for you from Windows Azure. In essence, a URL not unlike the following: https://myvidsite.cloudapp.net/home/default.html. Now, you’ll use the new SharePoint 2013 app model to integrate the Azure app to SharePoint. You’ll use the autohosted Client App template to do this. (Note: to get started with Office 2013 development, visit the MSDN Developer page.)

• Open Visual Studio 2012, and click File, New Project.
• Select Office/SharePoint, and then select Apps and App for SharePoint 2013.
• Provide a name and click OK.

• In the next dialog in the wizard, select the SharePoint site you’ll be deploying the app to, and then select Autohosted in the drop-down list.

• Visual Studio will create a project comprising two parts: one part configuration and another part web app code. Delete the “..Web” part of the project.
• Right-click the project, and then select Add and then New Item. Select “Client Web Part (Host Web),” provide a name for the new Client Web Part and click Add. You can see below, I added one called “MyAzureVidPlayer” to the project.

• Now you’ll want to copy the URL to the Azure video player page and configure two parts of the project.
• First, open the Elements.xml file and amend the Content element, as per the bolded XML code within the snippet below.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="https://schemas.microsoft.com/sharepoint/">
<ClientWebPart Name="MyAzureVidPlayer" Title="MyAzureVidPlayer Title" Description="MyAzureVidPlayer Description" DefaultWidth="300" DefaultHeight="200">
<Content Type="html" Src=" https://myvidsite.cloudapp.net/home/default.html " />

  </ClientWebPart>
</Elements>

• Second, right-click the AppManifest.xml file and click View Code. Amend the XML file as per the bolded code so it looks like the below:

<?xml version="1.0" encoding="utf-8" ?>
<App xmlns="https://schemas.microsoft.com/sharepoint/2012/app/manifest"
     Name="MyFirstAzureVidPlayer"
ProductID="{70e24eec-9734-4b8d-b084-5851ff7be7c4}"
Version="1.0.0.0"
SharePointMinVersion="15.0.0.0">
<Properties>
<Title>MyFirstAzureVidPlayer</Title>
<StartPage> https://myvidsite.cloudapp.net/home/default.html </StartPage>
</Properties>

  <AppPrincipal>
<AutoDeployedWebApplication/>
</AppPrincipal>

  <AppPrerequisites>
<AppPrerequisite Type="AutoProvisioning" ID="RemoteWebHost" />
</AppPrerequisites>
<AppPermissionRequests><AppPermissionRequest Scope=" https://sharepoint/content/sitecollection/web" Right="Read" /></AppPermissionRequests></App>

• Now you can hit F6 to build, and then right-click the project and select Publish. Publishing the app will build an autohosted cloud app that you can deploy to your SharePoint site. When the project is done building, copy the auto-opened Windows Explorer path for use in the next step.
• Now, navigate to your SharePoint site. In this case, I’m using SharePoint Online, so I clicked Apps in Testing and then selected new app to deploy, which enables me to upload the .app I just built (you can now click Browse and paste in the folder path from the previous step).
• Once you’ve uploaded the .app, click Deploy and then hit the Trust It button to trust the app. This deploys the Azure app to SharePoint but integrates them natively using the new SharePoint 2013 (autohosted) cloud model.
• To get your app onto a page, click Page, Edit, Insert, and then select App Part and then choose the app part you just deployed. And voila, your WAMS video player app (hosted in Azure) now shows up as an integrated app in SharePoint.

Congratulations! You’ve now build your first WAMS and SharePoint 2013 integrated app using the new cloud app model.

Final Thoughts

In this blog-post, I showed you separately how to create the Azure app and how to create the SharePoint app; although, breaking them apart wasn’t for naught. Hopefully, you now can see that while there may be separate pieces to the cloud puzzle, they are increasingly coming together as a united front—whether it be through concerted templates/functionality or by integrating Azure and SharePoint natively. (Note that by using the Provider hosted template in SharePoint 2013, you’ll be able to pull the above exercise together within one Visual Studio deployment.) And what’s interesting is that while here we talked about Windows Azure and WAMS, it’s about the wider web being your play-ground; it’s about being able to not only create a great Azure media app, but also integrate a great HTML5 or PhP app with SharePoint as well. But, WAMS is hugely compelling; especially from the process and workflow perspective. Again, within this blog I pointed to the SDK as an example of this, which makes the after-integration of WAMS and SharePoint look easy—which is where I focused.

I encourage you to play around with the WAMS SDK. When thinking about SharePoint, there are some interesting integrations you can accomplish with both 2010 and 2013. Expect to see more here.

Happy coding.

Steve
@redmondhockey

Comments

• Anonymous
  August 08, 2012
  Great Article! Very Informative. (www.sharepointinnovations.com)