Monday, March 31, 2014

Debugging Workflows In SharePoint 2013 Online using Azure

This is just so cool… You’re now able to debug workflows in SharePoint 2013 online by using your Azure account. Just this past weekend we (Composable Systems) hosted the Azure bootcamp here in Louisville, KY and I gave a dev talk on Service Bus. As it turns out, you can use one of your service bus namespaces to help you develop SharePoint 2013 workflows as well as remote events. Very timely indeed.

I’m building a SharePoint 2013 App for our largest client, Microsoft. This one is specifically for the Bing division, which they’ll use internally. I’m using Visual Studio 2013, SharePoint Online through our Office 365 subscription and a SharePoint App template. We’ll eventually deploy this to their internal SharePoint App store.

The first thing you need to do is go into the Azure portal and create a namespace under the Service Bus category, or choose an existing one you’ve already created. I just created a new one. No other configuration was needed here.


Once the namespace is setup, you’ll need to copy the connection string from the connection settings button near the bottom of the screen.


I just copied the ACS connection string.

Next, open the SharePoint App project properties in Visual Studio.


Now that is setup, I can do a couple of things. I can write details out to the console and I can set breakpoints. Wait… write to the console? Yep. When you press play to deploy/run your app, VS.NET starts a console that listens to that Service Bus.

So in this case, I added a WriteLine activity to my workflow (this comes from the Primitives section of the toolbox).


This will show up in my console when running the app. Here’s what that looks like.


And the breakpoint experience is really neat. When it breaks, you can explore all your local variables. Very handy.


Tuesday, March 4, 2014

The Future of InfoPath Forms

Probably one of the most important topics to Composable Systems, and myself personally, at the SharePoint Conference (2014) is the future of InfoPath Forms. InfoPath is supposedly gone as a product… That means in about 10 years, we’ll have to deal with migrating our forms to some other tool or set of tools.

Relax. That’s 10 years. InfoPath is going to be supported in its current form and will still be part of the next version(s) of SharePoint. Forms hosted in SharePoint will still work. The app will work on the desktop as well. So we’ll have time to migrate to a new solution, but we shouldn’t wait too long to re-think our forms. Having said all that, the future is still not too clear. At the SharePoint Conference today, Microsoft said that they’re very much in flux here and are looking for help from the community to guide this. They said there’s a lot of work going on here within Microsoft, but there’s nothing ready to ship anytime soon. So there was no big announcement. It’s not what I wanted to hear, but at least they’re transparent in their position here.

Despite this, the team gave a good classification of the different types of options/tools available to deal with this. Here are the items they covered. Some things are available today, others are coming in the future.

Excel Surveys

This has already shipped with SharePoint. It’s often overlooked and most people haven’t even heard of this. This is actually a great solution for simple surveys and forms. There is a simple designer to add as many questions, of varying type, to the form. These simply become columns in Excel. And you get to share the survey URL for people to fill out. When results come in, they go directly to the spreadsheet – and in real-time. To create one, just choose new “Excel Survey” from within a document library.

List Forms

This is new stuff. It wasn’t really a product announcement as in replacing InfoPath, but it did put a nicer experience on top of a list. These are MS Access-based forms that sit on top of a list. Before we go too far here, this is just the form part of MS Access and is entirely web-based. It’s based on HTML5 and is initiated using the ribbon while editing a list – there is a new “design form” button that sits right next to the InfoPath button. It’s a fast and flexible design surface which allows drag/drop support of labels and fields. You can re-size and re-position. It’s just form elements for the current list though. You essentially create a new view. It’s not as comprehensive as I would have hoped. This will ship in SharePoint online within the next 3-6 months.

Structured Documents

This is another scenario where Word documents are used as high-fidelity documents which gives users a more WYSIWYG experience. These are fillable word documents where the form fields can be edited and/or filled out. It meets the need of an online as well as offline scenario. These most closely resemble the InfoPath forms, but are not nearly as complex. They’re just for filling out and capturing data. Also, the data is kept in the Word document, so it makes for a good archival story. This functionality is about a year off.

App Forms

These are the most complex forms. These are based on MS Access online which allows for a relational and fully transactional database behind the scenes. By the way, the new MS Access online databases are based on SQL Azure. So it’s going to be scalable, capable and reliable. This is currently shipping in the online version.

So, this is sort of like the Shuttle program being shut down without a real clear path to get to the space station. Not what I wanted to hear – I really wanted a cool HTML5 based application that did what InfoPath did, but without all the strings attached. I guess we’ll wait and see on this – we’ll keep you up to date on this. We’ll also deal with this on a case-by-case basis. Sometimes using InfoPath, sometimes creating our own HTML5 forms.

Saturday, August 1, 2009

Odd Error When Retrieving Items from an SPView

When attempting to retrieve items from an SPView programmatically, you cannot reference fields by name or by their ID.  Note, I’m using MOSS 2007 with SP2.  So here’s the code that causes the issue (and resulted in over 3 hours of wasted time)…

Guid listId = new Guid(...);
Guid viewId = new Guid(...);

SPList list = SPContext.Current.Web.Lists[listId];
SPView view = list.Views[viewId];

SPListItemCollection filteredItems = list.GetItems(view);

foreach (SPListItem item in filteredItems)
Response.Write(item["Title"]); // THIS FAILS

And you’ll see this error:

Exception has been thrown by the target of an invocation. ---> System.ArgumentException: Value does not fall within the expected range. at Microsoft.SharePoint.SPFieldMap.GetColumnNumber(String strFieldName) at Microsoft.SharePoint.SPListItemCollection.GetRawValue(String fieldname, Int32 iIndex) …

Thankfully, the SPView object exposes a Query property which is a string that contains the CAML that filters list items.  Using this property, you can just create your own SPQuery object and retrieve the items from the list.  The following code has this modification.

Guid listId = new Guid(...);
Guid viewId = new Guid(...);

SPList list = SPContext.Current.Web.Lists[listId];
SPView view = list.Views[viewId];

SPQuery query = new SPQuery();
query.Query = view.Query; // GET THE QUERY PROPERTY FROM THE VIEW

SPListItemCollection filteredItems = list.GetItems(query);

foreach (SPListItem item in filteredItems)

Hopefully, this saves you some time.

Tuesday, June 30, 2009

Document Library Icons Missing

Here’s something to keep in mind as you provision document libraries inside SharePoint.  You can provision document libraries through both the web (site) and site (site collection) scoped features.  The way you would do this is through use of the ListInstance element similar to the following:

Id="Expenses" Title="Expenses" OnQuickLaunch="False" RootWebOnly="true"
Description="Contains expense documents."
TemplateType="101" Url="Expenses">

Unfortunately, when provisioning document library instances from site collection features the icons appear to be missing.  In the object model, which you can’t change after the fact, the ImageUrl property is empty.  If you look at the “View all site content” link, you’ll see what I’m talking about.

image_2_3B6F10A9.png (501×191)

This is just something to be aware of.  It may not be a show-stopper, but it’s an inconvenience to your users.  I’d recommend provisioning your lists as site features (at the Web scope).  It may mean more features to manage, however.

Thursday, June 11, 2009

Keep Site Definition IDs Unique

This recently bit me.  I had two different site definitions.  They had two different webtemp xml files, of course.

Here’s the first one:

<?xml version="1.0" encoding="utf-8" ?>

<Templates xmlns:ows="Microsoft SharePoint" >
  <Template Name="STORESITEDEF" ID="10010">


The second looked like this

<?xml version="1.0" encoding="utf-8" ?>

<Templates xmlns:ows="Microsoft SharePoint" >
  <Template Name="MARKETSITEDEF" ID="10010">


When I went to create my site, I kept getting this error:

The template you have chosen is invalid or cannot be found...

I incorrectly assumed that the ID was only relevant within a given site definition – why this wasn’t a GUID, I don’t know.  Anyway, I changed one of my IDs to be different and after an IISRESET all is well.

Tuesday, June 2, 2009

Always Capitalize (all-caps) Boolean Values in CAML

So here I was, late at night, banging my head against the desk trying to figure out why my a custom field’s custom property wasn’t hiding when I clearly stated Hidden=”true”.  As it turns out, you need to specify the uppercase value for that boolean or it simply won’t work.  There’s no error; it just doesn’t hide.  Here’s a snippet of code where this bit me while developing a custom column using the ProperySchema section to allow additional settings to be used for the field.

Field Name="TypeName">CustomColumn</Field>
Field Name="ParentType">Note</Field>
Field Name="TypeDisplayName">My Custom Column</Field>
Field Name="TypeShortDescription">My Custom Column</Field>
Field Name="UserCreatable">TRUE</Field>
Field Name="ShowOnListCreate">TRUE</Field>
Field Name="ShowOnSurveyCreate">TRUE</Field>
Field Name="ShowOnDocumentLibraryCreate">TRUE</Field>
Field Name="ShowOnColumnTemplateCreate">FALSE</Field>
Field Name="FieldTypeClass">ACME.SharePoint.Blah.CustomField,
ACME.SharePoint.Columns, Version=1.0.0...</Field>
Field Name="MySetting"
DisplayName="My Setting:"

As you can see Hidden is set to “TRUE.”  “true” simply does not work.

What’s funny is that the WSS.XSD gives you intellisense in VS.NET (in most areas) for the following options for boolean fields: true, false, True, False, TRUE, FALSE.  Ok.  Why?

This was just one case where my choice of case caused an issue.  What about everywhere else?  So proceeded to tell my colleagues, including Bryan Phillips, about this oddity with hiding properties of custom fields.  He said that he always uses uppercase.  Not only for custom columns, but for everything.  I’ve typically used lowercase since it seemed to be close to my c# practices.  However, from now on, I’m going to capitalize my boolean values.

Wednesday, May 13, 2009

Understanding SharePoint Lists and Content Types

This post discusses lists and content types in SharePoint.  It’s an overview of the concepts from a developer’s perspective.

Before getting into content types, it’s important to do a brief review of Lists.  Central to SharePoint is the concept of a list, which is often compared to a database table.  If you spend any amount of time with lists you’ll quickly see the similarities.  Like database tables, lists have columns and rows.  You can query them, modify them, sort them and even index them.  And both lists and database tables also have a variety of column types for things like text, numbers, dates... Conceptually, they’re equals.

So why use lists in SharePoint?  Well, there are a number of features above and beyond what you can do with simple database tables.  Here are some of the main benefits:

  • User Interface: A SharePoint list provides not only the storage, but the user interface for working with the data.
  • Item Security: Lists support row-level security and security trimming.
  • Versioning: You can store multiple versions of data.
  • Ease of Use: Lists can easily be modified from within the browser.  End users can make these changes without a developer.
  • Content Types: Lists support content types.
  • There’s more, but I don’t have all day :)

User Interface

When you create a list in SharePoint, you get (for free) the user interface for working with the data in the list.  You get a new form, edit form, display form and a variety of views to display the data in a listing format.  As you add new columns the user interface changes and users can easily enter that information.  Compare this to a database table.  If you’re an end-user, you need to call a developer to modify the forms as fields change in the database.  A real pain and definitely not worth anyone’s time, in my opinion.

Item Security

You can lock down one row of data in a SharePoint list.  This not only prevents access to that one item, but it also prevents unauthorized users from actually seeing data in the list.  Even when you query the object model and retrieve items (rows) from a list, your results have unauthorized records trimmed out automatically.  That’s really cool.  Try doing that in a database.  It’s a lot more work.


When you modify data in a SharePoint list, you have the option to enable versioning.  This will keep track of all changes for all columns in the list.  This feature also allows you to revert back to previous versions.  This is difficult to achieve in a database table solution.

Ease of Use

End users no longer have to bother the developer when they want to create a list to store something.  On their own, and with proper permissions, users can create and modify new lists.  Since all the forms are already done and up to date, users can essentially build a “web application” that has the functionality that used to take weeks to do in plain-old ASP.NET.  What?!!!  You mean that I can no longer charge my clients to build tables and the simple CRUD forms used to input/edit data?  That’s right.  All the out-of-the-box capabilities of SharePoint has essentially raised the bar regarding client expectations.  Clients expect it done now and can they actually do it themselves.  However ... do not despair.  There’s still plenty of software development to be done for your SharePoint users: workflows, web parts, custom jobs, custom forms...  Clients are never satisfied for long and, for a developer, this is a good thing.

Content Types

Let’s spend the remainder of this post on Content Types.  A content type is essentially a set of columns that can be used over and over in multiple lists.

Before we get too deep, you need to understand that columns can live on their own.  In a SharePoint site, there’s a special list of “Site Columns” that are already created and can be used in multiple lists.  For instance, there are standard columns like Author, Address, Spouse, and many more.  These are listed in the Site Column Gallery.  This is found on the Site Settings screen.

image_10_2D47FEB8.png (155×175)

And when you look at the Site Column Gallery, you’ll see a list of columns that Microsoft provides.  You can add your own, too.

image_8_2D47FEB8.png (529×409)

So Site Columns live in the Site Column Gallery.  They have all the settings required for each column.  For choices, these are things like the actual choices that need to be selected.  For others, it might be whether or not they’re required.

You can add one or more columns to a list when you go into the list settings screen of the list.  Here’s a simple Projects list where we want to add some site columns.  As you can see, it can be a real time-saver compared to creating new columns on the list each time.

image_12_2D47FEB8.png (514×264)

Next choose to add from existing site columns.

image_14_5B355170.png (640×259)

Then choose some columns to add.  Pretty easy.

image_16_5B355170.png (640×394)

So now we have a list with new columns no big deal.  But where do Content types come into this.  Well, just as we can add columns to a list, we can add columns to a Content Type.  Let’s create a Project content type and show how we can use that on two different lists (one for internal projects and one for external projects).

There’s another gallery that we need to introduce.  This is the Content Type Gallery.  Look under Site Settings and you’ll see this.

image_18_5B355170.png (170×182)

From here, we can see all of the built-in content types.  Open the Contacts content type and look around.

image_20_5B355170.png (640×451)

Notice how the Columns appear here just like they did in our list settings screen.  Although the content type doesn’t really store any data, it does define the structure of the data.  Let’s create a new content type for our projects.  Go back to the Content Type Gallery and click Create.

image_22_5B355170.png (285×111)

Next, give the content type a title and choose “Item” as the parent content type.  This is found under the “List Content Types” category.  I’ll talk more about the parent content type shortly. 

image_24_5B355170.png (640×395)

Once you’ve done this, you’ll be sent to the content type settings screen for your new content type.  From here, you can add new columns as necessary.  Notice that you already have a Title column.  This is because we chose the Item content type as it’s parent.  Item is the top-most content type for all items in SharePoint.  Every content type you create must use Item as a parent or some child of Item.  This is a really powerful concept that essentially lets you “inherit” the columns from a parent type.  It’s really just that simple.  We inherit from Item and we automatically get a Title fields.  If we inherited from Contact, we would get all the fields of Contact.  Let’s add some of our own fields for our project structure.

image_26_5B355170.png (279×165)

Note that you can create new site columns on the fly, but we’ll just choose from the existing site columns.  It’s quicker.  Add some columns that make sense for projects.

image_28_5B355170.png (503×280)

Now, let’s create a couple of custom lists: Internal Projects and Client Projects.  From the Create page, choose Custom List.

image_30_5B355170.png (172×157)

So now, we have three lists.  The one I originally started with where I added my own columns and the two we just created.  So we have two distinct lists to contain our internal and client projects now.  Let’s enable content types for each and then choose our “Project” content type.  Here are the steps for the Internal Projects list.  First, go to the settings for the list and choose Advanced Settings:

image_34_5B355170.png (578×333)

Next, choose to enable content types.

image_36_5B355170.png (640×72)

This gives us the ability to add new content types.  It also shows a new section in the list settings page that displays the content types that are in play.

image_38_5B355170.png (640×454)

Notice the new section.  Also notice that one content type is already in play.  Content types are always in play in SharePoint lists and document libraries.  Allowing management of content types simply let’s us see and work with them.

Next, add our Project content type.  Choose “Add from Existing Content Types” and choose project.

image_40_5B355170.png (640×314)

Save your changes and now, let’s see the list.  Click on the New button drop-down.

image_42_5B355170.png (306×165)

You can create new Item (that only has a Title) and a new Project that contains a new project form with all the fields we selected for our content type.  Here are the two forms.

image_44_5B355170.png (640×255)

So regardless of whether or not you’re in the Internal projects list or the Client Projects list, you’ll have the same form, but the data is stored in two different lists.  This concept doesn’t even exist in a typical database.  Try playing around with this.  Go back to one of your lists and chose a bunch of content types.  You’ll see some pretty impressive behavior:

image_46_4643CEFD.png (274×341)

Content types are quite powerful and I’ve just scratched the surface here.  They’re used all over the place in SharePoint.  In the MOSS Publishing and Collaboration Portal sites, content types are used to define the fields used in Page Layouts.  This is great concept that helps “prescribe” the fields that users can fill out in when creating new web pages for public facing sites.  And more at home, content types can be used with document libraries to define default document templates.  For instance, you can define a default “contract” document for your entire organization.  Then when users create new documents in a Document Library, they always have the latest contract boiler plate.

There’s certainly more to lists, document libraries and content types, but i hope this has given you a taste of the concept.  It took me a while to understand them, but I’m glad it finally sunk in.  Happy SharePointing.