A simple TypeScript Pattern for more synchronize asynchronous programming

Now that the days have become shorter and it’s too cold for long nights on the terrace, I had some time available to play experiment with TypeScript. On CodePlex you’ll find a sample project that illustrates how you can use TypeScript for a more synchronized approache to asynchronous programming.

The AsyncObservable pattern is in fact a simple App that illustrates the power of TypeScript. Not that TypeScript is more powerful than JavaScript. But it helps to apply patterns used in object oriented programming when building powerful and robust JavaScript Apps.

The idea is simple and based on the Observable pattern and it’s no coincidence that it bears great resemblance to the KnockOut.js pattern.

The basic idea is that each asynchronous call to a service will result in a data set or more likely a JSON object e.g.

var egg = GetSomethingFromChicken();

Unfortunately you cannot write code like this when the call is made asynchronous because the method call will return nothing. You’ll need to define a delegate for this that will handle the callback as soon as the data is returned asynchronously.

With the AsyncObservable pattern, however, you can write code that bears some resemblance to the example above:

// Dependency of type SP.Taxonomy.TermStore
var egg= new Dependency<Egg>();

In this case the variable egg is defined as a Dependency object of type T as follows:

class Dependency<T>

Such Dependency classes will have a property of type Array<AsyncObserver> and here the Dependency stores a reference to object (that is an Observer) that created the Dependency in the first place.

Then through some plumbing, the Dependency is added to a queue of Dependencies that is managed by the Observer. Once all Dependencies have been added to the queue, its Enumerator-like behavior can be kickstarted like this:

// Now put the wheel in motion
if (this.MoveNext()) {

The MoveNext() method now points to the first Dependency object in the array of Dependencies and the ResolveCurrent() method will call the Resolve method on the Dependency object. This is the method that should be overwritten when the Dependency class is inherited from. It’s in fact the usual callback method.

To keep the wheel in motion it is essential that upon a successful callback the Dependency object notifies its Observer by calling the Resolved() method on itself.

Have a look at the code and any feedback and suggestions are highly appreciated.

Ps, since I’m a SharePoint Architect it will come at no surprise that the example code is for SharePoint. But it’s easy to see that this example is in fact not dependent on SharePoint technology. And I’m also aware that SharePoint can actually execute a batch of queries.



Using TypeScript for SharePoint App Development

This post is the first one in a series on developing SharePoint 2013 Apps using TypeScript. I’ve become a big fan of TypeScript, as it allows me to write cleaner JavaScript code, inspires me because I can think in object oriented patterns like for example Observable etc., helps me organize (and re-use) my code in libraries and gives me the full power of Intellisense in Visual Studio (Express). This first post is about setting up your development environment. No code will be written yet. We’ll come to this later.

With the release of TypeScript 9.1.1 things have become slightly more “difficult” for SharePoint developers. The generated .js file is no longer available directly under the .ts file we’re creating. This means that it’s also not automatically included in the package. Also, the usage of a require framework like CommonJS or require.js is now mandatory.

Step 1 – Download the TypeScript Plugin for Visual Studio

Head over to and follow the instructions to download the plugin for Visual Studio 2012.


Step 2 – Create a development site

I like to create Host Named Site Collections using the PowerShell command below. Specifiying the template to be “DEV#0? gives you an App Development optimized template.

New-SPSite “” -HostHeaderWebApplication “http://dev” -Name “Developer Site” -Description “SharePoint App Developer Site” -OwnerAlias “is-sp2013administrator” -language 1033 -Template “DEV#0?


Step 3 – Create a SharePoint App Project

  1. Click Add > New Project > App for SharePoint 2013
  2. Enter Name and choose location > OK


Step 4 – Specify the App Settings

  1. Choose (and validate) our development site for debugging
  2. Select “SharePoint-hosted” as way to host your App


Step 5 – Add TypeScript Targets (1/2)

TypeScript by default will compile into ordinary JavaScript. However, to make that happen you need to update your project’s .csproj file.

  1. Right click on your project node in the solution explorer
  2. Click to unload the project
  3. Click Edit .csproj


Step 6 – Add TypeScripts Targets (2/2)

Scroll to the bottom of the project’s .csproj file and just below the SharePoint targets, add the following xml snippet, save your changes and reload the project.

<PropertyGroup Condition=”‘$(Configuration)’ == ‘Debug'”>
<PropertyGroup Condition=”‘$(Configuration)’ == ‘Release'”>
<Import Project=”$(VSToolsPath)TypeScriptMicrosoft.TypeScript.targets” />


Step 7 – Download Require.js

To be able to create TypeScript modules (in separate files) you need a framework like CommonJS or require.js. Simply head over to and download the latest version. Alternatively you can also get require.js using the NuGet Package Manager.


Step 8 – Clean up the Scripts Directory

This is just a matter of personal taste, but I like to put .js files in folders for the sake of keeping on top of things.

Step 9 – Add a TypeScript file: App.ts

  1. Since we want to write our App purely using TypeScript we first should delete the default App.js file.
  2. Now right-click on the Scripts-Folder and add a new TypeScript file and enter App.ts as file name


Step 10 – Add the generated .js file to your project

Since the latest release 9.1.1 the auto-generated .js file (which is the compiled JavaScript version of our TypeScript file) is no longer automatically added below our .ts file. Hence Visual Studio is not aware it’s around and for that reason it doesn’t end up in the App Package. There are probably better ways to solve this shortcoming, but I simply like to add the auto-generated .js files to my project.

Step 11 – Update the references in the App’s default page

So far we’ve update our project folder structure and added require.js. Hence we need to update the references in Default.apsx as follows:

  1. Update the path to jQuery (I moved it into the /Scripts/Vendor folder)
  2. Update the reference to App.js since it should be called via require.js and not directly (or else the require.js framework cannot perform its importing-tasks) as follows: <script type=”text/javascript” src=”../Scripts/vendor/require.js” data-main=”../Scripts/App”></script>


Step 12 – Add TypeScript Definitions for jQuery and SharePoint using NuGet

We’re almost done with our preparations. We only need to get the TypeScript definition files for SharePoint and jQuery using NuGet. Simply open the NuGet Package Manager and search for “TypeScript SharePoint” and you’ll find both .d.ts files:

  1. jQuery.TypeScript.DefinitelyTyped
  2. SharePoint.TypeScript.DefinitelyTyped

Ps, a big Thank You to Boris Yankov:


In the next post I’ll be creating a simple App that will call a REST service …



Consuming an External OData service from an SharePoint 2013 App

Ever wondered how you can consume an external OData Service from a SharePoint 2013 App? Well, I did and it came at the cost of a fair bit of headache because I kept feeling I was missing one essential piece of the puzzle: An ODataConnectionSettingId.

Ok, let’s start at the beginning. I created an account with and wanted to retrieve data from my online TFS project in SharePoint. A quick google search made it obvious that, since is offering an OData endpoint, I could simply create a SharePoint 2013 App with an External ContentType that would be the basis for a so called External List. Pretty simple! But then I got stuck at trying to configure my App to use a SharePoint Secure Store Application for storing my (Basic Authentication) Credentials …

Let’s go through it step by step. Prequisites for following my steps in your environment are a fully functional local SharePoint 2013 development enviroment with a working Business Connectivity Service Application and a Secure Store Service Application. And of course you’ll need an account for

Step 1 – Create a Develoment Site

I like to create Host Named Site Collections using the PowerShell command below. Specifiying the template to be “DEV#0″ gives you an App Development optimized template.

New-SPSite “” -HostHeaderWebApplication “http://dev” -Name “Developer Site” -Description “SharePoint App Developer Site” -OwnerAlias “is-sp2013administrator” -language 1033 -Template “DEV#0″


Step 2 – Create a SharePoint App Project in VS2012

  1. Click Add > New Project > App for SharePoint 2013
  2. Enter Name and choose location > OK


Step 3 – Specify the App Settings

  1. Choose (and validate) our development site for debugging
  2. Select “SharePoint-hosted” as way to host your App


Step 4 – Add ContentType for External Datasource

  1. Right click on the project node in the solution explorer
  2. Click Add
  3. Select Content Types for External Data Sources


Step 5 – Specify the OData Source Settings

  1. Enter the OData Endpoint (in my case:
  2. Enter a name for your OData Source


Step 6 – Select the Data Entities

  1. Select OData Entities (I selected WorkItems)
  2. Ensure that the option to create an External List is checked


Step 7 – Create a Secure Store Application

Now we’ll leave our Visual Studio Project for a short moment to create a Secure Store Application where we’ll store the credentials for connecting to our External OData Source.

  1. Navigate to SharePoint 2013’s Central Administration > Application Management > Service Application > Secure Store Service
  2. In the Ribbon, click New
  3. Enter a Target Application ID which you can choose freely – Later it will be the unique identifier for BCS to locate your Application (with the credentials) in the Secure Store Service
  4. Enter your email address (as administrator)
  5. Select Group as Application Type


Step 8 – Specify Field Types (User Name and Password) for Secure Store Application

What now follows may differ, depending on the type of authentication your OData Service requires. In my case,’s OData Endpoint can be configured for Basic Authentication. Hence I needed to change the Field Types from Windows User Name and Windows Password to User Name and Password. Also, you’re only defining the Field Types (and hence the type of supported authentication). You’re NOT setting the credentials at this stage yet!


Step 9 – Add Members that may access the Secure Store Application

On the next page you can enter Users and / or Groups that you want to grant access to the credentials stored in the Secure Store Application. In this case I entered “Everyone”. This means that everyone who uses the App that in turn will use this Secure Store Application will be permitted to make calls to the OData Service specified by the External ContentType.


Step 10 – Set Credentials for Secure Store Application

We’re almost done. The Secure Store Application is created. Now select it and click Set Permissions in the Ribbon of the Secure Store Service and enter the credentials to access the OData Service Endpoint.


Step 11 – Create a BCS Connection using PowerShell

This step is, as I mentioned before, one that I found is hardly documented. But it’s essential! Using PowerShell you need to create a so called ODataConnectionSettings that is then used by our External ContentType to establish a connection to our Secure Store Application. You can choose any name you’ll like. In the next step, however, we’ll need it to configure our External ContentType as it is the ODataConnectionSettingsId. The rest of the arguments for its parameter should be self-explanatory.

New-SPODataConnectionSetting -Name “TfsODataOnlineConnection” -ServiceContext “http://apptast” -ServiceAddressURL “” -AuthenticationMode “Creden
tials” -SecureStoreTargetApplicationId “TfsODataOnline”


Step 12 – Update External ContentType properties in your VS2012 Project

Now we’re ready to get back to our Visual Studio project. Update the following fields:

ODataConnectionSettingsId Use the name you specified in the previous step when you create the ODataConnectionsSettings using Powershell

AuthenticationMode For Basic Authentication you should select “Credentials”

SsoProviderImpementation Here we need to enter the Fully Qualified Assembly Name of SharePoint’s Secure Store Service:

Microsoft.Office.SecureStoreService.Server.SecureStoreProvider, Microsoft.Office.SecureStoreService, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c

Step 13 – Grant BCS Permissions for your App in the AppManifest

As a last step we need to update the AppManifest and make our App request permission to Read from SharePoint’s Business Connectivity Service (BCS).


Step 14 – Update the Start Page of the App so your External List is loaded immediately


Step 15 – Debug your App and Trust it

Hit F5, wait a short moment … Now check the box for the External Connection that the App is requesting permission to read from.


Step 16 – Sit back and enjoy …