Reminder…

First – a short reminder. This is how Excel Services REST works when trying to access a range:

https://server/_vti_bin/ExcelRest.aspx/doclib/File.xlsx/Model/Ranges('sheet1!A1')?$format=html

This will give back an HTML fragment representing the range. Now, what if sheet1 had a space in it? Say it was called Sheet 1?

Handling spaces in sheet names

The standard way of handling spaces in sheet names is to surround them in single quotes. And herein lies the problem – we already use single quotes to specify the range. The solution is to escape them (not URL escape – that will not help us). So here's what this looks like:

https://server/_vti_bin/ExcelRest.aspx/doclib/File.xlsx/Model/Ranges('''sheet 1''!A1')?$format=html

This may be a little unclear. Here's what's inside the braces:

<single quote-1><single quote-2><single quote-3>sheet<space>1<single quote-4><single quote-5>!A1<single quote-6>

1 – Denotes the beginning of the range name.

2,3 – the first single-quote in 'Sheet 1' encoded by doubling it.

4,5 – the second single quote in Sheet 1' encoded by doubling it.

6 – The end of the range name.

But wait.. It gets even uglier

What if the sheet name has a single quote in it? Say: Sheet '1 (that's Sheet<space><single quote>1). In Excel, this would be represented in this fashion:

See the double-single-quote in there? It's because Excel faces the same issue as we did in the previous example – it needs to escape the character. But what does that look like in REST?

https://server/_vti_bin/ExcelRest.aspx/doclib/File.xlsx/Model/Ranges('''sheet ''''1''!A1')?$format=html

Yeah. That's four single quotes in there…

<sq-1><sq-2><sq-3>sheet<space><sq-4><sq-5><sq-6><sq-7>1<sq-8><sq-9>!A1<sq-10>

1 – Denotes the beginning of the range name.

2,3 – the first single-quote in 'Sheet ''1' encoded by doubling it.

4,5 – the second single quote character in 'Sheet ''1' encoded by doubling it.

6, 7 – the third single quote character in 'Sheet ''1' encoded by doubling it.

8, 9 – the fourth single quote character in 'Sheet ''1' encoded by doubling it.

10 – The end of the range name.

Embedding Excel Web App in your own web page or blog

One of the interesting bits is that you can change the settings of what is shown by the viewer – whether it should show a specific item (range/chart etc) or if it should scroll to a specific location in the workbook etc. These options are pretty simple, but I thought it would be usful to create a simple helper that will let you pick the features you want and will build the customization string for you:

All you have to do, is fill the orange cells and copy the appropriate string to your IFRAME embed code. Enjoy!

Enjoy!

Well.. Not really “nice” as much as an “eye sore” – the HTML was pretty awful. I elicited the help of one of our PMs (Manpratap Suri) to make the application look and behave like somebody a sane person would want to use. Once installed, the first step is to select the workbook you want the embed code for:

The “Publish to web” option will show up, allowing the user to automatically navigate to the application page. Once clicked, the user is immediately dropped the application page:

There are five parts to this screen – at the top, there’s a huge “Publish to the web” title that should probably be made smaller. Then, below that, there are four elements you can choose from – charts, tables, PivotTables or ranges. To the left, below that, there’s a list of the available items (three items in the example above) and to the right is a preview image. Below the preview image, there are the available embed options – URL, HTML, Raw Data and DHTML.

The user can now easily navigate between the type of elements the workbook exposes and between the actual elements exposed and easily pick what they want to use in their site.

Clicking on “Tables” for example, will give the list of tables in the workbook:

The interesting part though is the “Embed” code at the bottom. There are four options:

* URL – this is the direct URL to the entity. Pasting this in the browser address box will directly navigate to the entity.

* HTML – this is the HTML that represents the element. For charts, this is an <img> tag with the appropriate link (which means it will be refreshed every time the page containing it is loaded). For ranges/PivotTables and Tables, this is the actual HTML for the object (which means that it is “static” – it will not change).

* DHTML – Only works for Ranges/PivotTables/Tables – this is is a piece of script and HTML that can be embedded – it will return the HTML for the requested element. Because this is brought in via AJAX every time the page loads, the data will always be current.

* Raw Data – Only works for Ranges/PivotTables/Tables – this is the link to the raw data (values) of the requested element.

In the next post, I am going to show how to use the various Embed options in SharePoint.

(Download link is right below this line - where it says "Attachments:")

ExGadget.gadget

Fast-forward to Beta 1, and our user testing showed that people got really confused by this mode – they expected the changes they typed in to be saved back into SharePoint. We took a close look at the scenario and a decision was taken to disable this sort of “read-only editing” to avoid the confusion. Now, the mode still exists and is easily accessible when using a web-part (you simply need to go to the web-part properties and check the “Allow typing” option there. But what of the full-screen viewer (the one the user lands in when they click “view in browser” or “edit in browser” on the drop down menu)?

Well, it turns out we also allow this mode in there – if you tack on “&allowtyping=1” at the end of the URL, you will actually go back into scratch-pad mode and the user will be able to make modifications to the workbook in the grid, in the cells.

This is what it looks like:

Two things – in the URL box – you will see that I added the “&allowtyping=1” parameter:

You will also notice the small warning that comes up at the top of the grid, warning the user that changes made to the workbook will not be saved:

If you have any questions, feel free to comment. If you have sample workbooks that use charts based on dynamic ranges you can share, please send them to me, I will try to find some time to make sure they work.

After asking around, here’s a method that works pretty damn well:

1. Add a new library (right-click Libraries in explorer and click “New”).

2. Add the Favorites folder to the library

That’s it. Because libraries appear first in the start-menu, you will now see your favorites apprear in the start menu.

https://tsdlt2/_vti_bin/ExcelRest.aspx/Docs/Bugs.xlsx/Model/Ranges('Sheet1!A1|Z100')

This will return the Sheet1!A1:Z100 range.

As for why we had to do this.. IIS does not like colons in the path portion of a URL – any colon in the Path causes IIS to not allow the request to go through. Now, there’s a workaround to that by tweaking some registry key, but we did not want admins to do it nor did we want to do this automatically, so we decided to use the pipe symbol instead.

In this post, I will show the real power behind this pattern of generating files on the fly and feeding them to Excel Services. Instead of just using the data from the document library (the list of word documents), what if we enabled user input?

If you recall, the URL I used in the previous post was this:

https://tsdlt2/_layouts/WorkbookGeneratorSample/SpecStatus.aspx

And that produced the following chart:

But what if I only wanted people from my team – say only Chris Stich and Greg Lindhorst?

Here’s the URL I can pass in:

https://tsdlt2/_layouts/WorkbookGeneratorSample/SpecStatus.aspx?pm=Chris+Stich&pm=Greg+Lindhorst

In this case, the ASPX code will know how to look at the query-string and figure out what names I am interested in. Here’s the result:

The way this works is very easy. Zayed’s original code would look through the entire list of documents in the SharePoint document library and generate a chart out of all of them. I added code, essentially, in three places. First, when loading the page, I figure out what names need to appear:

Then, when deciding on whether or not to add rows to the workbook, I make sure we only add the rows if the PMs are on the URL (or if there’s nothing on the URL (note that most of the code is in Zeyad’s original post – I am just showing what I modified here):

The highlighted area is the one that was added – it simply looking at the names that were passed in as URL parameters, and if the name currently being procesed (pmName) is not one of them, it ignores the set of documents and does not add the row to Excel.

Finally, Zayed’s FixChartData() method had to be tweaked to make sure the chart has the correct amount of elements:

And that’s about it! All in all, we added about 12 lines of code to the original code developed by Zeyad and we have a solution that allows us to target exactly which PMs we want to look at.

In the posts to come, I will show more tricks and uses for this idea of generating Excel workbooks on the fly.

When I saw this post, I decided to ‘one up’ it and give my spin on it, and by that introduce one of the less known new features in Excel Services on SharePoint 2010 – the ability to point Excel Services at any URL that returns a workbook – not specifically ones that are extensioned as such. More on the general case in a later post. This post will show how we can take Zeyad’s solution and turn it into a dynamic solution.

To summarize Zeyad’s solution – the idea is to have a chart in Excel represent how many “open issues” a list of specs have for each PM in the team, furthermore broken out by what stage the document is in. The owner of the document is deduced from document properties and the amount of “open issues” is deduced from looking at the Word file and searching for a specific style applied to paragraphs (we have a special style for marking opened issues). If you read Zeyad’s great post, you will see the work done there – essentially, you have a web-part where you click on an “Update” button and that generates the new workbook (with the updated chart) and saves it into SharePoint. Here’s a screen-shot I pilfered from Zeyad’s post:

You can see the little buttons above the chart – you click the left one to cause the chart to get regenerated and then on the right one to cause the chart on the page to display.

Here’s what my solution looks like (I have less specs in my library, so my graph is less impressive):

Note the missing “Update” button. So how does the workbook get updated? To understand that, it’s important to see what the URL is that the EWA is looking at:

As you can see, the workbook URL is pointing to an aspx page. “That’s tom-foolery!” I can hear you crying. Not quite. Here’s the code in the ASPX page:

The call to GenerateWorkbookStream() is essentially the method called btnSubmit_Click() in Zeyad's post with very little change – instead of saving the binary stream back into SharePoint, GenerateWorkbookStream() returns the byte array to the caller.

What we do with that byte array is write it as the response to the ASPX page (that’s where we make the call to ctx.Response.OutputStream.Write()). The other important parts are the headers we set and the call to Response.End()  which finishes the call and returns the result to the caller.

The other two lines are where we set the header for the response. First, we set the content-type to be that long string which is the content type of an OpenXML Spreadsheet file. The second one we set is the “LAST-MODIFIED” which is required for Excel Services to process the file (the file would not be loaded if this header is not set).

That’s it – the rest of the code is pretty much the same. Here’s a diagram of what happens:

When I told Zeyad I was going to post about this, we talked a bit about the solution, and he pointed out that, much better than my solution or his, it would have been nice to have a workflow that actually updated the workbook whenever a word document was updated in the doc lib. That way, we only regenerate the workbook when we need. The next post I will make will show how the dynamic workbook solution can do so much more.