The SaaS application scenario is built around Contoso Real Estate Listing Management where real estate agents can register and create an account on the SaaS system and manage their property listings. The intent of the demo is to show the pattern/architecture for a scalable Web application built on Windows Azure Web Sites and then what a great opportunity one has to land the SaaS data into the context of Office and SharePoint. These simply become additional views/web pages that you hang off the SaaS application. You can surmise from this demo, that essentially any SaaS or line-of-business (LOB) application could nicely be extended with “companion apps” too. In this case, we had two primary use cases for the real estate agent users of the SaaS application.

1. For real estate agent users that only have the Office clients and not Office 365 Business (Medium or Enterprise).
2. For real estate agencies that have Office 365 Business, hence SharePoint Online that supports apps for SharePoint is a part of their service offering. Here we also wanted to have SSO between the Office 365 tenancy and the SaaS application.

Here is the session recording: (if the viewer does not fully display, you can view here.)

You can view/download the slide deck here:

Enjoy!

If you have already installed some apps from the Store on office.com into your Office 2013 clients, then you will have noticed that the app for Office only interacts with the document at the point where the user has placed the insertion point in the document, or has selected text, etc. Essentially, the app requires user actions for the app to interact with the document. This is great for apps where you want the user to be in control of the where and when in the document authoring experience. But what about line-of-business or other cases where you want to present the user with a preformatted document with “known” locations within the document that you want to manage/interact with programmatically?

A great example of this is the Bing financial portfolio template. Open Excel 2013 and type “bing” in the search bar to search for the Bing template. Then click on the template and choose Create. When the document loads, take whatever steps necessary to enable the app and you’ll see that the app is essentially pre-loaded in association with the document and can interact with the document by updating stock data even without some user interaction. Also if you search for a stock in the app that is not in the pre-loaded table in the document, you can choose to add it to the table by clicking the Add button. Notice that it adds it to the bottom of the table without you needing to have a location pre-selected where to add the row. This is because the app “knows” locations in the document that it can interact with. This is quite powerful and certainly something that you as a developer should be aware of how to do this. It may provide some neat opportunities for your apps for Office. So let’s get after it.

A Word app for Office with Content Controls

So we don’t reinvent the wheel here and so that we use a code sample that is available to all, the MSDN team has provided a sample app that will serve as a great starting point for us. Open the Apps for Office: Binding to and validating content controls in Word 2013 code sample landing page. Confirm that you have all the prerequisites in place, download the code sample and open it in Visual Studio.

1. Once loaded, click on the CorporateBio project and make sure that the Start Action property is set to CorporateBio.docx.
2. Press F5 to start debugging. Word will load the document but notice that you need to Insert the Corporate Bio app from the Apps for Office ribbon dropdown. This means that the app for Office and the document are not “coupled”. In other words the app and the document are independent from each other, the only thing is that the when the app opens, it can locate “known” locations on the document.
3. These “known” locations are in the form of content controls. Click on one of the content controls in the document. Notice that it has a name. The name is what the JavaScript method .addFromNamedItemAsync("EmployeeName", …) uses to bind to this known location in the document. You can see this in the $(document).ready(function () in the CorporateBio.js file. 
4. To add content controls to the document you need to enable the Developer tab in Word. Click File, Options, Customize Ribbon, and in the right-hand column under Main Tabs, check the Developer tab so that it will activate.
5. Return to the document and click anywhere within the document. Click the Developer tab, in the Controls group, click the Aa (the Rich Text Content Control is the only one the apps for Office JSOM can interact with).
6. Click on your newly inserted content control so it’s highlighted and click the Properties button in the Controls group. Notice that the title is empty by default, however, this is the property that the JSOM will bind to as a named item. Enter a Title of your choice, “TestTitle”, etc. and click OK and you’ll see that your content control is now named. The point here is that this is how the other three content controls on the page were created and named.
7. As noted above, when you pressed F5 and the document opened, you needed to insert the app so let’s now fix that and “couple/associate” that app with the document. Simply click Save. Now, close the document to stop debugging and then click F5 again. Notice that the app and document open together now.

The anatomy of the .docx file with an app for Office

1. Now let’s take a look inside the .docx file to see how this is all recorded in the OOXML. To do so you can copy the CorporateBio.docx file out of the project into another location if you like or just take my word for it as I step through this.
2. Once the file is in a new location, change its extension from .docx to .zip.
3. Right-click the .zip file and choose to extract all.
4. When the file is extracted, open the word folder, webextensions folder, and open the webextension1.xml file in any xml viewer.
   
5. There are a couple things to note here:
1. Notice that the attribute storeType is “Registry” and the store is “developer”. These two attributes point to where the Office client needs to look for the manifest file for the app that is associated with this document. Because this document was saved while the app was running in Visual Studio, these are the settings that get saved within the document. Since our document will not always be opened within a Visual Studio context, we’ll come back to this below and show how to get these attributes set to another location for the manifest.
2. Notice the bindings and binding elements. The id attribute is of interest here. See that it’s not the name of the content control that is in the document, but it’s the optional parameter name of the binding, e.g. { id: 'nameBinding' }, that we passed in to .addFromNamedItemAsync in the CorporateBio.js. This is just to show that the binding ids are recorded here in the OOXML.  

Getting the coupled/associated app for Office and Manifest file in sync

1. Ok, so now let’s say you’re done testing your coupled/associated app for Office and document and you’re ready to make it available within your enterprise. For this example we’ll just make it available using a network share to host the manifest file. If you need guidance on how to setup a network share for apps for Office manifest files see that section in my previous post for a step-by-step.
2. At this point you could also publish the CorporateBioWeb out to Windows Azure Web Sites if you like to lock in an absolute URL for the app, but that’s optional. Again, you can see this post for steps on how to do that. But to keep things straightforward, we’re simply going to use the URL for the app running in IIS Express.
3. In the Solution Explorer click on the CorporateBioWeb project and confirm that it’ SSL Enabled property is set to True. (If you needed to click it to True, you should run your app one more time so IIS Express will have your app running under https too.) Then copy the SSL URL value.
   
4. In the Solution Explorer under the CorporateBioManifest node, double-click the CorporateBio.xml file to open the manifest file. Replace the ~remoteAppUrl/ with your https://localhost:yourport/ you just copied.
   
5. Save the manifest file changes.
6. Now to work some “manual” magic for how to get things all wired up for use outside of Visual Studio.
7. In the Solution Explorer, right-click on the CorporateBio project and choose, Open Folder in File Explorer.
1. Open the CorporateBioManifest folder, copy the CorporateBio.xml file and save it in the network share folder you setup for manifest files.
8. Since the CorporateBio.docx file within the Visual Studio project is now wired up to point to the Registry for its manifest file we can’t use that document outside of Visual Studio, if you do, you will get the following error when the app loads in Word.
   
9. Therefore, you’ll need to get a fresh copy of the CorporateBio.docx file that is in the sample .zip folder. Open the original .zip folder and copy the CorporateBio.docx file to a location of choice. (Note: if you copied the file directly out of the .zip, then right-click the .docx file, choose properties, and click the Unblock button.)
10. Double-click the CorporateBio.docx file, click the Insert tab, drop-down the Apps for Office and select See all…
11. In the Apps for Office dialog, click on the SHARED FOLDER and you should see the Corporate Bio app, if not click the Refresh button. Once you see the app click on it and then click the Insert button.
12. If you see an exclamation point icon warning click on it. And then click the Start button to load the app. (see the step 9 note to fix this)
13. Once the app loads, click File, Save As and provide a name. You can save this as either a Word Document .docx or a Word Template .dotx file. either will have the app coupled/associated with the document.
    
14. And how does the OOXML look now? The storeType is “Filesystem” and the store is you file share location.
    

An Excel app for Office with Named Ranges

So that’s great for Word, but what if I want to do the same this for Excel? Well, since the JavaScript Object Model for Office works across both Word and Excel let’s tweak the manifest and wire this up in Excel without needing to go into Visual Studio at all.

Update the app manifest to for Excel

1. Navigate to your network share location for the manifest files and open CorporateBio.xml in any text editor.
2. In the Capabilities node, add <Capability Name="Workbook" /> and save the file. (Note: you might want to increase the version number in the manifest file so the Office clients will load the updated manifest since the previous one may be cached by the clients.)
   
3. Now open Excel and a new blank workbook.
1. In the first column, enter in each cell: Name:, Position: and About Me:.
   
2. Click on cell B1, then in the upper textbox where you see B1, replace it with the name “EmployeeName” and press the ENTER key. After you type in the value you must press the ENTER key for Excel to retain it. You can confirm Excel knows this named range by clicking the B1 cell. EmployeeName should be showing.
   
3. Repeat the above step for cells B2 and B3, providing the names “EmployeePosition” and “EmployeeAboutMe” respectively.
4. Now, choose Insert app for Office and select Corporate Bio. Once it loads Save As an Excel Workbook .xlsx or an Excel Template .xltx.
5. Wow, that was easy!! The only thing to note here is that the Validate data logic may need to be updated since the code sample was hard-coded to only compare against the default literal values within content controls to see if the data had changed and Excel cells do not have the default text.
   

Summary

In this post you used a MSDN code sample that does data binding to content controls within Word. You worked this forward to see how the app can be coupled/associated with a document. Then the OOXML was exposed to help provide understanding that the end result for the document you want to distribute, must have the known location for its manifest file saved within the document. This known location can be a network share, a corporate catalog on an on-premises SharePoint 2013 site or in Office 365 SharePoint Online, or in the Store on office.com. So, essentially the document you want to distribute with the coupled/associated app, must have been saved while accessing the manifest end-point that the users of the document will have access to.

Documents and templates with apps already in them is a great way to provide user experiences where you have done all the complex setup and you have predetermined locations within the document where you can programmatically push and retrieve information at will. New opportunities abound!

Enjoy!

Secondly, Windows Azure Web Sites, as you’ll see, can be managed for the most part, just like you would a typical Web site on IIS. Therefore you do not need the Windows Azure SDK loaded on your dev machine as if you were developing for Windows Azure Cloud Services (although you certainly could build your app for Office on Cloud Services, but that would be another post), so again, it’s the friction free way to get rolling. If you want your app for Office to consume other Windows Azure based services then you would need the Windows Azure SDK, but using Web Sites alone you do not need it.

Prerequisites:

To develop apps for Office you do not necessarily need an Office 365 Developer Site, but you do need to make sure that you have the Office 2013 clients (or you can get these from your MSDN or TechNet subscription) installed on a machine you want to test with. If you use Visual Studio to develop with, you’ll need Visual Studio 2012 Pro or above and the Microsoft Office Developer Tools for Visual Studio 2012 – Preview 2. Once VS 2012 is installed, run the Microsoft Web Platform Installer on your developer machine and search for “Office” you’ll find the above Office/SharePoint tools for building apps to download/install.

Resources for Building Apps for Office:

dev.office.com is your friend for resources on building apps for Office and SharePoint.

Setup a Windows Azure Account:

1. Navigate to windowsazure.com, click on Free Trial. Click through the subsequent pages to create your account.
   
2. Once your account is created login to manage.windowsazure.com if you’re not already logged in.
3. Click on + New to see the WEB SITE Preview menu item, click it and then click QUICK CREATE. (If the WEB SITE menu item is greyed out for you, click on it and follow the link to the right to sign up for the preview program. After you’ve completed the sign up and the service says it’s active you can return to this page.) Enter a name in the URL for your app for Office, this will be verified to be globally unique and available for use by the green checkmark. Select a REGION that is appropriate for you and click CREATE WEB SITE.
   
4. It takes a few seconds for your web site to be provisioned. Once it’s Running click on your app’s Name to enter the dashboard for the web site.
   
5. From the dashboard page, do some exploring by clicking on each of the tabbed items to see the various items you have for managing your new web site. 
    
6. Click on the Dashboard tab and notice the quick glance section on the right. First, right-click on the SITE URL and select to open in a new window or tab. You’ll see the splash page confirming that your site was successfully created. In the browser, change the URL from HTTP to HTTPS, press enter, and you’ll see that your site also supports HTTPS needed for apps for Office. So your site is ready.
   
7. Also, notice that there are a number of other helpful links such as setting up TFS and GIT publishing and FTP is available too. For use with Visual Studio in this post, click the Download publish profile link and save this to a location on your development machine. You’ll use this file later.
   
8. That’s it, for setting up the Windows Azure Web Site, now you just need to build the app for Office and publish it here.

Setup a Network Share for the App for Office Manifest file:

1. To remove any dependency on a SharePoint on-premises or Office 365 SharePoint Online as a location for the app for Office to be uploaded, you’ll setup a network share on your developer machine for the manifest file. Open File Explorer on your developer machine and create a folder named AppManifests in the root of the C drive. (note: the folder can be named anything and be located on any drive, this is just a suggested name and location.)
2. Once the folder is created, right-click on the folder and set the sharing with Everyone.

Configure Office Clients to Trust the Network Share for Manifest Files:

1. Open Word 2013 (or any of the clients that support apps for Office) and open a New document. Click the File tab. From the left navigation bar click Options.
   
2. In the Word Options dialog, click Trust Center and Trust Center Settings…
   
3. In the Trust Center dialog, click Trusted App Catalogs and enter in the Catalog Url text box, \\YourMachineNameHere\AppManifests\, and click Add catalog. When the catalog is added, be sure to check the Show in Menu check box. Then click OK. You’ll be prompted that you need to restart Word, but simply close out any open dialogs and Exit Word for now.
   
4. Ok, now your Web Site, network share and Office clients are ready for your app for Office.

Create App for Office:

1. Open Visual Studio 2012 as administrator. Select New Project… In the New Project dialog click on Apps under Office/SharePoint, click App for Office 2013, provide a Name and Location, and click OK.
   
2. In the Create app for Office dialog, leave the default Task Pane app selected and click Finish.
3. Since this post is about how to simply deploy an app for Office to Windows Azure Web Sites so you can see the pattern for doing this, you will make no changes to this base web app, you will simply publish it. Right-click on the web project and select Publish…
   
4. In the Publish Web dialog, click Import… and navigate to the location where you saved the “publish profile” above.
   
5. Click Next on subsequent screens until you see the Start Preview button, it’s not necessary that you click this but it’s interesting to see the files that will be deployed. You will notice in subsequent deployments that you do, only those elements that have changed will be uploaded. On the first time all items get uploaded of course and this button shows the individual items. Once the upload items are determined, click Publish.
   
6. When the publish completes, a browser will open for your web site. Append to the end of the URL, /Pages/YourVS-AppName.html and press enter to see your deployed app. Your URL should look something like, https://appforofficetest1.azurewebsites.net/Pages/OfficeApp3.html.  Since you do not have a default page setup for the site (which you can in the management portal for this Web Site) you need to add the path to your deployed page.  Your deployed page should look like the following. But of course you’re not in the context of Office so things appear to not work – but the app for Office is deployed.
   
7. Change the URL to HTTPS, press enter, and copy/paste it into Notepad or somewhere for use later.
8. Now, back to Visual Studio.
   

Deploy the App for Office Manifest file to the File Share:

1. Since apps for Office are essentially a manifest file that the Office clients can access and the manifest file simply contains the URL for your web site, all you will do here is save a copy of the manifest file in your network share and update the SourceLocation element in the manifest with the full HTTPS URL for your Windows Azure Web Site.
2. In Visual Studio, right-click on your app for Office “folder” (not “project”) and select Open Folder in File Explorer.
   
3. In File Explorer, right-click your app for Office XML file and select Copy.
   
4. Open another File Explorer and open your AppManifests folder and Paste your app for Office manifest.
5. Open your newly pasted app for Office manifest file in Notepad or any text editor and locate where you saved a copy of your full HTTPS URL in an above step. Copy the URL and paste it into the SourceLocation element in your manifest file. The element should look something like the following, then Save and Close the edited manifest file.
   
6. Ok, almost there!

Test your App for Office:

1. Open Excel 2013 and open a blank workbook.
2. Click the Insert tab, click on Apps for Office, from the drop-down select See all…
   
3. Click the SHARED FOLDER tab to see the apps for Office manifests available in your network share. Select your app for Office and click Insert.
   
4. Your app for Office hosted on a Windows Azure Web Site, in a Microsoft Data Center, in the Region you chose is displayed in Excel – how cool is that for friction free? Click on any cell in Excel and press the Set data button and then click into any other cell, enter some data, exit the cell and then reselect it, and click Get data.
   

As you can see (and you had a couple configuration steps here for the network share and Office that only need to be done once) it is really a simple process to spin up a Windows Azure Web Site for hosting an app for Office. Essentially you build your web application (it can be written in any language that is supported on IIS and the Office JavaScript Object Model), publish it to Windows Azure Web Sites using a number of methods from TFS, Git, Web Deploy, or FTP, and wire up Office to access your manifest file on a network share (or SharePoint on-premises, or SharePoint Online in Office 365) and you’re set.

This post is meant to only provide an introduction to simply show the pattern for using Windows Azure Web Sites as a backend for apps for Office. But for next steps you would need to think about whether your app for Office needs to support multi-tenancy. If so, you may need to couple a Windows Azure SQL Database with your Web Site. Here again, you should check back on the windowsazure.com site and click on the pricing tab to run some numbers along with what will it mean when you hit the maximum instances/capacity on your free site and need to start moving into the pay-as-you-scale-out dynamic. But, in any case, Windows Azure Web Sites are a super option to start with where the risks and costs have a very low barrier for entry.

So start building your Apps for Office on Windows Azure Web Sites today!

Enjoy!

The all new cloud app extensibility model for Office and SharePoint 2013 enables building a whole new class of productivity solutions for Office and SharePoint. And the new Store on office.com for Office and SharePoint provides the venue for these apps to be delivered to Office, SharePoint on-premises and Office 365 SharePoint Online users worldwide.

In these DevCamps, developers will learn the concepts of the new cloud app model and how to use it. Topics for building apps for SharePoint range from how to read/write to SharePoint as a service using its rich APIs whether the JavaScript/managed code object model or via REST/OData, how events that happen on SharePoint can drive actions in your app, to using SharePoint search via the APIs.

Topics for apps for Office include how to build task pane, content and mail apps that render in the Office client applications, use the Office JavaScript object model to interact with documents and mail items, and how to deploy apps for Office as standalone solutions or part of an app for SharePoint.

Other topics will cover how to think about elasticity, scalability and reliability of your backend services. Here we’ll call out a friction-free path with Windows Azure Web Sites and some of the other Windows Azure technologies. But being true to the cloud app model, the backend services can run on any platform, so in the end, this is always your call. And of course the steps for getting your app into the Store on office.com will be discussed too.

We have great instructors on board, each with a deep background in development so you can expect a rich 2-days of content and hands-on.

<Updated 1/2/2013>

Meet the instructors:

</Updated 1/2/2013>

So, review the schedule and register to attend at a location that works for you and begin thinking about building an app for Office and/or SharePoint.

We’ll look forward to seeing you at one of these events.

Enjoy!

I am thrilled to announce the all new series “Inside apps for Office and SharePoint” on Channel 9. For your viewing pleasure, we have a three-part inaugural video set to kick off the series. This video set introduces you to the whole new concept of building apps for Office and SharePoint 2013 using the standard web technologies that you know and love. As will hold true with additional videos in the future, we’ve interviewed those that are building the products so you will hear first-hand from the experts.

It’s truly an exciting time for those that want to develop a whole new class of productivity solutions on Office and SharePoint 2013. And once developed, your apps can be submitted/published to the Office Store (now in Beta) on Office.com. Since apps for Office and SharePoint are available from the store to multiple millions of Office users and hundreds of thousands of Office 365 users – all I can say is, WOW!! So take a look at these videos and get started building apps for Office and SharePoint. Everything you need to get rolling is available at this single URL, dev.office.com, and be sure to follow the Apps for Office and SharePoint blog.

You can view the videos here, but be sure to set a favorite for the Inside apps for Office and SharePoint series landing page.

Thanks to all the Microsoft program managers and colleagues for your help in getting this series launched and to Laura Foy for hosting this initial three-part set of videos.

Introducing Developing Apps for Office and SharePoint, Part 1: Overview

Introducing Developing Apps for Office and SharePoint, Part 2: Developer Platform Drill-down

Introducing Developing Apps for Office and SharePoint, Part 3: Tools – Access, Visual Studio 2012, and “Napa”

Enjoy!

In the days and weeks ahead there is going to be soooooo much great stuff to talk about for developers with lot’s of excellent resources coming available. I’ll be discussing a number of these with various drill-down topics here as the next Office unfolds. But for now the best place to get started is the Apps for Office and SharePoint Blog. In the first post Ludo introduces you to the new Office cloud app model – Great Stuff!! A whole new world for building business productivity solutions with the new Office has just opened up for discovery.

So get started by downloading the new Office Customer Preview and follow Ludo’s next-steps guidance…

Enjoy!

Enjoy!

The bottom line is that SPO BCS can connect up to any Windows Communication Foundation (WCF) or SOAP-based web service. Whereas the on-premises BCS can connect directly to a SQL database, .NET Assembly and WCF service, the SPO BCS version can only connect to the WCF/SOAP-based web services. The only other caveat for SPO BCS is that the user’s authenticated identity cannot pass directly through to the backend web service. The service itself must be username/password protected and the username/password will be set in the SPO Secure Store (SSS). Think of this as a “Trusted Subsystem Model” where there is a single service account that is used to authenticate to the backend system, not a specific user’s credentials/identity. Therefore, if the user must be known to the backend LoB system, you’ll need to pass some sort of a the user’s unique identifier (e.g. employee-id, GUID, etc.) as a parameter to the backend so it can do logging, filtering, permissions setting, etc. for the specific user. Other than this, the SPO BCS is wired up in the identical way as you would the on-premises version.

The hands-on-lab (HOL) steps you through the process of creating a WCF service that simply front-ends the Northwind database that is publically available via an OData feed at, https://services.odata.org/Northwind/Northwind.svc/. (https://www.odata.org has a number of data sources you could tap into – just follow the “ecosystem” and “producers” links.) The HOL includes the following:

Exercise 1:
In this exercise you’ll build your WCF service that fronts the Northwind OData service that contains a couple methods to retrieve data from the Customers table. You’ll then deploy your service to your Windows Azure account and test to make sure the endpoint is working. (Note: you do not need to host your service on Windows Azure. The steps in this exercise show how to do that, but you can host your SOAP-based web service on any server as long as it has a publicly accessible endpoint that SPO BCS can hit.) For the HOL you will not secure the web service with a username/password because to use security in the SPO SSS you would need to have the web service secured with a certificate that is issued by a Certificate Authority (CA) like VeriSign, Go Daddy, or others. BCS will not connect to a web service that is protected with a self-signed certificate – therefore, to keep this simple and free, the HOL web service is not secured. But for your production LoB web service you should purchase a certificate issued by your favorite CA.  

Exercise 2:
Here you will use your SPO administrator portal to set permission on the Metadata Store and then use SharePoint Designer 2010 to create the External Content Type from the web services and then create an External List from that.

Exercise 3:
In this final exercise everything comes together to show how to build out both no-code and code-based solutions now that the valued LoB data is available in SPO. First, you’ll see how to surface the data in web parts that filter the data directly in the URL. Secondly, you’ll add External Columns to a document library so that these columns can be surfaced in a Word document. This document can then become the default document for the document library so this exercise shows how to wire up this type of solution. Lastly, this exercise shows how to consume the External List data programmatically via a Word add-in. The main requirement here is that the add-in must prompt the user for their O365 credentials for the add-in to authenticate to O365 and access the External List. The HOL provides the guidance around this and sample code for both the starter solution and a completed solution.

Please download the HOL from here:

And don’t forget, once your External Lists are available in SPO, they are accessible via the web browser on your devices. For instance, these can come in really handy for your sales personnel in the field that may need to get quick directions to their customer’s site. They simply navigate to the SPO site and to the External List, drill into the customer they want, click on the Searchable Address link and then they can get their turn-by-turn directions – and a solution like this is done without any code once the External List is available!

Enjoy!

Update 7/12/2012: for a deeper presentation on an end-to-end solution using O365 SharePoint Online BCS, an Excel client add-in, a Windows Phone 7 app, a Windows SQL Azure database and a Windows Azure web service, see this post.

Enjoy!

Enjoy!