SaaSGrid Team

Using Windows Workflow Foundation in your SaaSGrid Application

2009-10-09T10:34:00Z

This article was last updated on November 6, 2009.

Did you know that your SaaSGrid application can use Windows Workflow Foundation? SaaSGrid even provides native support for the most popular aspect of Windows Workflow Foundation: database persistence.

This article describes how to use different features of Windows Workflow Foundation in your SaaSGrid application. Before reading this article, it is helpful to be familiar with Windows Workflow Foundation.

SaaSGrid Considerations

Windows Workflow Foundation (WF) uses a runtime engine, with a variety of runtime services to perform specific actions related to the workflow. The types of runtime services include a persistence service, scheduling service, tracking service, and so on. There are default implementations of these services included with WF.

The default implementations of these services are not compatible with SaaSGrid's deployment model. Microsoft designed the default implementations of their services to communicate directly with Microsoft SQL Server. Because SaaSGrid controls database deployment to handle SaaS concerns (e.g. multi-tenancy), we require SaaSGrid applications to be database provider agnostic so SaaSGrid's database provider can be used when the application is deployed on the cloud.

It is very easy to write custom implementations of runtime services and configure applications to use them. SaaSGrid provides a custom implementation of the persistence service that you can use to persist workflows in your SaaSGrid hosted database which is sufficient for most customers. SaaSGrid does not provide any custom implementations of other runtime services such as the tracking service. The rest of this article describes how to use our persistence service and guidelines for writing your own custom implementation of other runtime services.

SaaSGrid's Persistence Service

SaaSGrid provides a persistence service that you can use. All that is needed is to configure the engine to use it. The following example App.config file provides an example of this. Note the usage of the conditional configuration system to make it easy to develop and test your application locally.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
    <section name="WorkflowRuntime" type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</configSections>
<WorkflowRuntime>
    <CommonParameters>
      
      <add name="ConnectionString" value="Data Source=db1_s.apprenda.local\devsql01;Initial Catalog=IssueTracker; Integrated Security=True;" />
      
      
    </CommonParameters>
    <Services>
      
      <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" UnloadOnIdle="true" LoadIntervalSeconds="5" />
      
      
    </Services>
</WorkflowRuntime>
</configuration>

Note that SaaSGrid's provided SQL persistence service requires the usage of an App.config section in the manner demostrated above, even though it is technically possible to configure runtime services via code. This manner of applying configuration is consistent with how we require you to configure services and classic database connectivity.

Developing your own Runtime Services

As previously mentioned, SaaSGrid does not provide an implementation for other runtime services that you may wish to take advantage of. Fortunately, it is very easy to write your own, and plenty of documentation is available on the MSDN Website.

The main thing to keep in mind when writing your runtime service's database connectivity is to use a configuration-based database provider and connection just as you would for any other code you write in SaaSGrid. In fact, you probably won't be the first person who wishes to use a different provider than SQL Server! There are many blog postings and sample code out there on how to create custom runtime services.

If you can share your experience about creating and using your own runtime service with SaaSGrid, please comment or post in our forums. We'd love to hear about it!

Closing Remarks

To summarize, Workflow Foundation's default implementation of runtime services won't run on SaaSGrid because they are programmed to use the Microsoft SQL Server database provider. SaaSGrid provides a native implementation of the most commonly used feature of Workflow Foundation, which is the persistence service, but you must configure your workflow engine to use it. It is easy to create your own implementations of other runtime services, but be sure to design them to be database provider agnostic and loaded by configuration as you would any SaaSGrid application.

Migrating an Existing Application to SaaSGrid

2009-06-02T20:19:00Z

A common question that we get is "What will it take to change my existing .NET application to work on SaaSGrid?"

The answer depends on these factors:

The current architectural structure of your application and how closely it matches that of SaaSGrid's required structure.
How your application currently handles functionality that SaaSGrid's platform offers for you, such as authentication, roles, purchasing, subscription management, etc.

In this article, I will briefly describe each of these items which will serve as a starting point for understanding what it will take to make your application work on SaaSGrid.

Application Structure

SaaSGrid applications are physical divided into the following 3 components, explained in further detail below:

Data Persistence
Business Logic
User Interface

The data persistence layer (if required for your application) can consist of any standard database elements such as tables, views, etc. You may have exactly one database & schema per application.

The business logic layer consists of one or more WCF-based web services. The web services encapsulate your business logic, are consumed by your user interface(s) or other services, and are responsible for interactions with the data persistence layer. Interactions with the data persistence layer must be in a "provider agnostic way" meaning that your database connections are established via a factory that relies on configured preferences.

The user interface layer (if required for your application) consists of one or more ASP.Net or Silverlight applications that consume the web services from the business logic layer. The user interface cannot access the data persistence layer.

Structuring your application in this way permits us to scale out and deploy your application components as your customer base grows, and permits us to establish multi-tenancy for your application without your needing to incorporate this into your application design.

SaaSGrid's Feature Set

SaaSGrid offers a wide array of features and an API to take full advantage of them, which up until now would typically be handled to some extent by an existing application. This includes aspects such as multi-tenancy, billing, user & role management, access control, feature usage monitoring, and much more. These generally can be divided into two categories:

Features that SaaSGrid handles completely but may exist in your application, such as creating a user, authentication, and billing.
Features that SaaSGrid provides that are tapped via the SaaSGrid API when developing your application, such as securable checks and feature usage monitoring.

Where there is feature overlap, it may be necessary to remove or change code and your data model to work with SaaSGrid. Generally speaking, the more overlap your application has with SaaSGrid's feature set, the more work is required to modify your application to use SaaSGrid and its API. Of course, this all depends on the complexity of your application and its requirements.

In conclusion, this information gives you a better idea of what it takes to get your application working on SaaSGrid, but please also take a look at the following references which can help provide some additional insight:

SaaSGrid Platform Page - an introduction to the features of SaaSGrid
SaaSGrid Quickstart - leads you through a basic example to familiarize yourself with SaaSGrid concepts and the SaaSGrid API
Downloads page - contains code samples, the SDK, and other documentation
Demo - a great way to familiarize yourself with the SaaSGrid's features and capabilities (contact your sales contact for more info)

If you have any additional questions please post in our developer forums.

Accessing Other Tenant’s Data in an Application

2009-06-01T18:27:00Z

Consider the following use cases:

My application permits tenants to create events, and I want to publish a list of all of those events in another location.
I want tenants to be able to mark data as sharable so it can be viewed by other tenants.

SaaSGrid's built-in Tenant and Provider Contexts', in conjunction with a concept called "impersonation", provides a mechanism that can be used to access data for any and all tenants of an application. This article will discuss how this can be done and presents a basic example that involves modifying the existing Taskr sample application.

Introduction to the Tenant and Provider Context

Before getting started, let's review and compare the Tenant and Provider Context:

Tenant Context

Provider Context

Provides information about the tenant that the application's logged in user belongs to

Automatically established

Database queries done only apply to data pertaining to the appropriate tenant

Provides information about the provider of the application currently being used

Manually established

Database queries done apply to all data pertaining to the application (all tenant's data)

Note: In addition to the Tenant and Provider Contexts', there is also Session, Request, User, and Subscription Contexts' that will not be discussed further here but may be helpful when developing your application. Please consult the SaaSGrid Developer Guide for additional information.

Using the Provider Context to Get Application Data

All database queries done within an instance of the Provider Context apply to all of an application's data. See the code snippet below to see an example of creating and using the provider context.

Sample Provider Context Usage

using (ProviderContext providerContext =

ProviderContext.NewProviderContext())

{

// Data queries here execute for all application

// data - not just the current user's tenant.

}

"Wrapping" database calls as shown above is essentially all that is required to do basic operations that pertain to all data in the system. This approach does have some limitations pertaining to data retrieval:

No information is returned pertaining to the tenant of each data item. For example, if I have a database query that returns a list of all tasks, there is no way to tell which task corresponds to which tenant. (This is addressed in the next section.)
When developing locally, there will be no difference in the data returned. This is because the database that you are using locally by design contains a single tenant's data.

In the next section, we'll take a look at another approach that allows you to retrieve data while knowing which tenant created it. This is enabled with a concept called "context impersonation."

Context Impersonation

It is possible to nest the Tenant and Provider Contexts within one another to affect the scope of a command being executed, much like the stack available within a traditional programming language. The diagram below shows how the scope of commands are changed as the application developer manually instantiates various Tenant and Provider contexts.

The following code example shows how to use context impersonation to perform data retrieval for all of a provider's data while having access to information about the tenant that created it.

Sample Context Impersonation

using (ProviderContext providerContext =

ProviderContext.NewProviderContext())

{

IList<ITenantProfile> customers =

providerContext.GetCustomers();

foreach (var customer in customers)

{

using (TenantContext tenantContext =

TenantContext.NewTenantContext(customer.ID))

{

// Data queries here execute for the

// designated tenant. You can link

// the tenant information to the data this way.

}

Warning: This specific code example could take a very long time if your application has many customers. You'll probably want to consider calling code that loops through every tenant sparingly due to the performance implications.

Please also note that we are cognizant of the anticipated need to include tenant data, or some means of linking rows with tenant information, for data returned from queries executed in a provider context. We're looking to include this in a future release of SaaSGrid, thus eliminating the need to loop through each tenant.

Live Example

We produced an additional sample that demonstrates usage of the Provider and Tenant Context. We took the "Taskr with Linq" example, and added an additional view beneath the task list showing all of the tasks from other companies, as depicted in the screenshot below.

An additional method on the Taskr Core service was implemented to return the data for this grid, whose code is shown below. As you can see, this loops through each and every tenant and builds the list of tasks that should be displayed on the grid.

Taskr Service Addition

Guid myTenantId = TenantContext.Current.GetCompanyProfile().Id;

IList<TaskFromOtherDTO> tasks = new List<TaskFromOtherDTO>();

using (ProviderContext providerContext =

ProviderContext.NewProviderContext())

{

IList<ITenantProfile> customers = providerContext.GetCustomers();

foreach (var customer in customers)

{

if (!customer.Id.Equals(myTenantId))

{

using (TenantContext tenantContext =

TenantContext.NewTenantContext(customer.Id))

{

TaskrDataContext db = new TaskrDataContext(

ConfigurationProvider.GetConnection("Taskr"));

foreach (var task in db.Tasks.OrderBy(t => t.DueDate))

{

tasks.Add(TaskFromOtherDTO.StaticMapFrom(

task, customer.Name));

}

return tasks;

You can download the full sample of this special Taskr version from our download area by clicking here.

Of course, as always, please post a comment to this article or post in our developer center if you have any questions or feedback.

Using built-in ASP.NET providers on public websites

2009-04-17T19:36:00Z

This article assumes that you are creating a public website for your SaaSGrid application, and you wish to take advantage of ASP.NET's Providers. This article talks about considerations to keep in mind when using these providers within a SaaSGrid application.

Recall that ASP.Net Providers provide an extensible way to perform common application tasks such as user authentication, role management, and more. Basic implementations of these providers exist, and many of them utilize your SQL Server Database to operate. An excellent way to get familiar with all of the ASP.Net Providers is to take a look at Microsoft's Provider Toolkit site.

The tenant's website typically wouldn't use any of these providers because of SaaSGrid's built-in user, subscription, and role management capabilities, but they can be useful on a public website that require these capabilities.

There are two key considerations to always keep in mind not only when using these providers but also when writing any ASP.NET Web Application for SaaSGrid:

No direct database access: SaaSGrid applications are 3 tiers with a clear division between the presentation, business, and persistence layers. Your application's data access must be coordinated through the WCF services that make up your business layer.
No Microsoft SQL Server Client-specific Code: SaaSGrid uses its own client to handle database calls within the SaaSGrid cloud. Therefore, you must program your connectivity against ADO.NET Abstract classes (e.g. DbConnection, not SqlConnection).

These two considerations severely restrict which implementations of the included ASP.NET Providers you can use. For example, the SqlMembershipProvider cannot be used because it accesses the database directly, and its underlying implementation uses the SqlConnection class instead of the generic ADO.NET class.

Fortunately, Microsoft has introduced WCF-based Provider Services (which others have improved to address some limitations). Therefore, you can take advantage of the ASP.NET Provider Model in your ASP.NET application, and create a WCF Service with the appropriate logic as needed.

An Intro To The SaaSGridControlToolkit

2009-03-31T12:15:00Z

Last week we released the first version of a development library called the SaaSGridControlToolkit that will make developing ASP.NET user interfaces for SaaSGrid even easier. The SaaSGridControlToolkit is a collection of ASP.NET controls that provide out-of-the-box functionality powered by the SaaSGrid API and the SaaSGrid operating environment itself at runtime. Development of the SaaSGridControlToolkit is an ongoing effort here at Apprenda. If you've developed any ASP.NET user controls that utilize the SaaSGrid API and would like us to include them in future releases of the SaaSGridControlToolkit, please let us know!

Start by downloading the latest release of the SaaSGridControlToolkit library.

Example: LogoutHyperLink

The first control we'll look at is the LogoutHyperLink (SaaSGridControlToolkit.LogoutHyperLink). This very basic control simply renders a hyperlink to an ASP.NET page that directs the user to the SaaSGrid logout URL. The reason this control is important as an out-of-the-box component is because there is no notion of "logging out" of an application while developing locally. Since authentication is handled by the SaaSGrid cloud instance that applications are deployed to, a developer could not reliably build a logout button into their application without knowledge of that cloud instance's URL and authentication paths. This is where the LogoutHyperLink comes in. The control obtains information from the SaaSGrid runtime and renders a 'Logout' link to the proper URL, allowing the user to exit the application.

The LogoutHyperLink control has one property that can be overridden, and that is the Text property. By default, the text of the hyperlink is 'Logout'. By overriding this property, developers can render the text of their choice.

For example, the simple tag on an ASP.NET page might look like this: <SaaSGridControlToolkit:LogoutHyperLink runat="server" Text="Logout of MyApp" />

Important Note: The LogoutHyperLink control uses SaaSGrid cloud instance information that is only available in live SaaSGrid environments. During local development, the control still appears exactly as it will when deployed, but the link triggers a javascript alert telling the developer that the control will work when the application is deployed.

Lastly, you may recognize the LogoutHyperLink, because we use it in the SaaSGrid Portals!

Updates to the SaaSGrid Mocker

2009-03-10T02:22:00Z

We've just released a new version of the SaaSGrid Mocker to support the new functionality introduced with the latest version of the SaaSGrid SDK (v 1.6) as well as some minor bug fixes.

The bug fixes are related to issues trying to save the active configuration and in the process we also introduced the ability to “Save As…” on the active configuration allowing you to easily create configuration copies.

The new functionality is to support public websites and concurrent subscriptions through a new section:

You can get the new Mocker here or by downloading the latest version of the SaaSGrid SDK here.

Public Websites & Concurrent Usage

2009-02-25T17:11:00Z

Introduction: With the release of the SaaSGrid SDK v1.6 we introduced 2 very cool new features, the first one is the ability to support the notion of public websites and the second one which goes hand in hand with the first one is the ability to control application usage based on the number of concurrent users using the application.

Public websites are a set of user interfaces that do not require authentication into SaaSGrid in the traditional sense but instead it allows you to expose a website that contacts your application web services and access is controlled based on the number of concurrent users accessing the website.

Common examples of applications that would benefit from this functionality are applications such as: Help Desk software that might allow end users to track the status of their tickets or navigate knowledge base articles that are available to the public for limited functionality. Another example can be a Bug Tracking application that allows end users to submit bugs through a web form or allow end users to see if the bugs have been resolved.

The goal is that you can expose limited functionality to "restricted" users without having to charge for the full amount of a named user since their usage of the application would only be really limited.

Now that we know what the two features are, let's dive a bit into how to use them:

The first thing you need to do is create a public website. Public websites are identical to regular websites with the only difference that they will go under a new section in you application archive called PublicInterfaces. This is done to allow maximum flexibility in the creation of the website as well as to instruct SaaSGrid how to deploy your application. If you were to look at an archive with a public website it would look like this:

Creating an httpModule: The second thing you need to do is create an httpModule where you will establish a session to SaaSGrid and grab a concurrent subscription from the pool of subscriptions, you should return the subscription to the pool when the subscription is no longer in use.

You can find a sample httpModule below that works on a per request basis, if you are planning on having "authenticated users" using the public websites we will cover keeping a long running session in a future article but this should get you started.

[code]
/// <summary>
/// This is a small module that establishes sessions based on a
/// request basis.
/// </summary>

public class RequestBasedModule : IHttpModule
{
private Guid subscriptionId = Guid.Empty;
private Session sess = null;

public void Dispose() { }

    public void Init(HttpApplication context)
    {
        context.BeginRequest += BeginRequestHandler;
        context.EndRequest += EndRequestHandler;
    }

    void BeginRequestHandler(object sender, EventArgs e)
    {
        sess = Session.EstablishSession();
        subscriptionId = TenantContext.Current.AssignConcurrentSubscription();
    }

    void EndRequestHandler(object sender, EventArgs e)
    {
        if (Guid.Empty != subscriptionId)
        {
            TenantContext.Current.RemoveSubscriptionAssignee(subscriptionId);
        }
        if (null != sess)
        {
            sess.ReleaseSession();
        }
    }
}

[/code]

When your application is deployed in SaaSGrid, if you had a public website, SaaSGrid will create two websites for each tenant that signs up to your application under the following protocol: http://app_alias.tenant_alias.saasgrid_instance.com and http://public.app_alias.tenant_alias.saasgrid_instance.com where app_alias is the alias of your application, tenant_alias is the alias of the tenant signing up and saasgrid_instance.com is the host name of the SaaSGrid instance being used. This allows each tenant to map a custom domain name to their applications, both the private and public portions.

Setting up the Local Environment: In order to test public websites and concurrent users in your local environment you need to add a new section to the execution context called concurrentSubscriptions that simulate the number of concurrent subscriptions available for the tenant. The new tag looks like this:

[code]< concurrentSubscriptions limit="5" />[/code]

Sample Application: Please use the following sample as a reference of how to set this up and don't hesitate to use the forums if you have any questions.

Cheers!

- Abe

LINQ to SQL Common Pitfalls

2009-02-12T13:00:00Z

By default, LINQ to SQL uses fully qualified object names derived from the application's datacontext file (.dbml) during compilation. When you initially create this datacontext file for your application, every table entry has a property called 'Source' which contains the fully qualified table name for that table. By default, this 'Source' property is set to dbo.[TableName], indicating the default dbo schema. An issue arises after deploying this application into a live SaaSGrid environment. You will get the following error message:

[SQL Operation] permission denied on object '[TableName]', database '[GUID]', schema 'dbo'.

The reason for this error is that SaaSGrid does not allow explicit schema references in SQL statements. The simple fix for this is to remove any schema references in your datacontext file.

The following default setting is INCORRECT:

Consider the following CORRECT example from the Taskr With LINQ example:

Notice that the 'Source' property is simply the name of the table 'Task', rather than the fully qualified table name 'dbo.Task'.

Another common pitfall using LINQ to SQL is trying to use auto incrementing columns as the idnetity column, at this time we don't support auto incrementing columns and instead we recomment that you use a Guid as the identity column.

Options for Locating the SaaSGrid Configuration File

2009-02-11T03:12:00Z

One of the powerful features of the SaaSGrid platform is the ability to work against a "mock" SaaSGrid environment when developing locally. An XML file is read when executing code locally to establish the context of the user and tenant. This article will describe the options that you have for how to locate and reference this file when developing on SaaSGrid.

There are two options for specifying the location of the SaaSGrid Settings file:

Place a file called SaaSGrid.cfg.xml in the root directory of your client code (typically a web project)
Place a file in a specific location, and configure the client code to look for it

Option 1: Root Directory

This option is the easiest option, and happens by default when creating a new SaaSGrid Solution using Visual Studio.

If you need to do this manually, follow these steps:

Right-click the project in Visual Studio
Under the SaaSGrid category, choose SaaSGrid Configuration File
Call the file SaaSGrid.cfg.xml

Option 2: Specific Location

Sometimes an alternate location for the configuration file is needed. Common scenarios include sharing the file between multiple users or projects.

First, create the configuration file in the desired location. Then, update either the App.config or Web.config with the following sections:

<configSections> <section name="saaSGridLocal" type="System.Configuration.AppSettingsSection"/> </configSections> <saaSGridLocal> <add key="configFile" value="disk(\)::driveletter:@\Path\to\file.cfg.xml"/> </saaSGridLocal> Finally, update the configFile key point to the appropriate location.

If you need additional information, see the Developing on SaaSGrid reference guide, also installed with the SaaSGrid SDK.

Want to use SaaSGrid meters to limit pageviews?

2009-01-29T19:26:00Z

A nifty aspect of the SaaSGrid API and the various contexts (Tenant, User, Subscription) is that they are accessible at any point in the lifecycle of an ASP.NET request in your application. You are not limited to accessing the API in the codebehind of your ASPX pages or other UI handlers. You can use many other ASP.NET features in conjunction with the SaaSGrid API. A perfect example is HttpModules. Consider the following example, where an ISV wants customers to pay for viewing a particular URL or resource type within their application:

The ISV writes an HttpModule called PageViewModule. The module's handler for BeginRequest looks like this:

[code language="csharp"]

            HttpContext ctx = HttpContext.Current;
            SubscriptionContext subscriptionCtx = SubscriptionContext.Instance;

            if (subscriptionCtx.IsBlockExhausted("PageViews").Value)
            {
                ctx.Response.Write("I'm sorry, you've exceeded the number of page views allowed by your subscription.");
                ctx.Response.End();
            }

[/code]

The handler simply checks against the SaaSGrid API to see if the block meter called "PageViews" is exhausted, and if it is the handler writes to the response stream and then aborts processing using Response.End() - the only thing sent back to the browser will be the text "I'm sorry, you've exceeded the number of page views allowed by your subscription". Now imagine a scenario where a customer purchases a subscription that comes with 1,000 pageviews... on the 1,001th page view the user of that subscription will receive this message. The ISV may give the customer the ability to purchase more blocks of PageViews, thus adding to the meter - 1,000 included, blocks of +500 for $10 each. The possibilities are terrific!

But, if we're going to limit the user's page views, we're going to need to decrement the "PageView" meter each time they utilize its functionality. Using the SaaSGrid API, the implementation for that is simple, and it is found in the handler for EndRequest within the HttpModule:

[code language="csharp"]

            SubscriptionContext subscriptionCtx = SubscriptionContext.Instance;

            if (!subscriptionCtx.IsBlockExhausted("PageViews").Value)
            {
                    sCtx.DecrementBlock("PageViews");
            }

[/code]

We do this in the EndRequest handler because we only want to decrement the block meter "PageViews" if we are certain that the response is going to make it back to browser, and that there were no internal errors during processing the request that caused the request to abort (You could also check Server.LastError to ensure that all went well and that the user is not going to get back an error page instead of what they were expecting).

And there we have an HttpModule that will allow a user to make X requests (where X is the size of the block "PageViews" that they purchased as part of their subscription), and then gives the user a simple message telling them that they've used up the block.

Don't forget that an HttpModule applies to all requests within the web application. It's up to you to get creative in the module if you want to limit which request types, filetypes, or query string parameters will affect the usage of a meter. For instance, if you built an application that renders images in various forms, and there is a query string parameter that tells your application to render the image in hi-res, but you have a block meter that limits the number of hi-res images a user can view, you can check for that query string parameter before decrementing the block! If the hi-res block is exhausted, simply do a Response.Redirect() to the url of a placeholder image that let's the user know they've exceeded the number of hi-res images they are allowed to view.

Approaches to calling a WCF service from Javascript

2009-01-29T13:34:00Z

Most existing Javascript frameworks (Microsoft AJAX, ExtJS, jQuery, etc) give the client developer a clean and easy way to make AJAX calls to the server, receive data back, and update a portion of the current page without needing to make a roundtrip post that reloads the entire page. The newest release of ASP.NET contain classes that make this process even easier, especially when contacting WCF service endpoints directly from Javascript.

Consuming a WCF Service From Javascript Within an ASP.NET Web Application

ASP.NET provides a set of classes and controls that make consuming WCF services quite easy. This is because these controls actually generate Javascript proxy classes for you on the client that wrap all interaction with the WCF service. This makes communicating with WCF from Javascript very similar to doing the same in C#. The key to consuming WCF web services from the client in an ASP.NET application is the ScriptManager control. When this control is included on the page, it is able to read the WSDLs of included WCF service references and it outputs Javascript proxy code to the browser. This makes Javascript objects available to the rest of your client scripts after the page loads. Here's how to consume a WCF called 'MyWCFService' using the ScriptManager control:

[code language="csharp"]

    <asp:ScriptManager runat="server">
        <Services>
            <asp:ServiceReference Path="MyWCFService.svc" />
        </Services>
    </asp:ScriptManager>

[/code]

The inclusion of MyWCFService via a ServiceReference tag tells the ScriptManager control to 'consume' the WSDL of the WCF service located at the specified path and output javascript to the browser. There are articles online that describe this process in greater detail. Basically, this means that if the full namespace of your MyWCFService class is MyApp.MyWCFService, you will now have a Javascript object called MyApp.MyWCFService whose prototype contains all the methods of your web service, and you can call them in Javascript as if they were simply another method on your client:

[code language="javascript"]

var results = MyApp.MyWCFService.Method1(parameters);

[/code]

For more information and detailed samples, see http://www.asp.net/ajax/documentation/live/

Consuming a WCF Service From Javascript Outside of an ASP.NET Web Application

You may want to contact a WCF service from Javascript outside of an ASP.NET web application (for instance if you are building desktop apps or widgets that communicate with your SaaSGrid app), which means you'll be doing so without the benefit of the ScriptManager control. Because a hosted WCF service exposes a WSDL contract just like any other web service (think of ASMX, for example), you can still contact that web service using Javascript. If you are using the Microsoft Ajax client libraries, you can make an asyncronous web service call like this:

[code language="javascript"]

        Sys.Net.WebServiceProxy.invoke(
            'MyWCFService.svc',
            'Method1',
            false,
            { parameters as json },
            successCallbackFunction,
            errorCallbackFunction, timeoutCallbackFunction);

[/code]

Not surprisingly, this is actually what your ScriptManager-generated proxy classes do within an ASP.NET application like in the example above. Just, in this case, you are calling the WCF service directly yourself using the Microsoft Ajax client library built-in Ajax utilities. For more information about this method of calling a WCF web service from Javascript, view the documentation on using the Sys.Net.WebServiceProxy invoke method for communication.

Another technique, if you don't have access directly to the WCF service endpoint via the web, is to make a front-end web service using ASP.NET's ASMX structure, and communicate with that endpoint from your Javascript. From within your ASMX web service class, you can use a proxy to communicate with your WCF service just as you would if you were utilizing the WCF service from a code-behind on an ASPX page.

Hopefully this information will be useful when you are designing the methods of communication you will use from the client to your web services deployed on SaaSGrid. If you have any questions, feel free to post them in the comments or email me directly at mammerman [at] apprenda [dot] com.

Writing Silverlight User Interfaces for SaaSGrid Applications

2009-01-22T17:26:00Z

SaaSGrid application deployments support a variety of technologies at the user interface layer. Consider the following scenarios:

Standard ASP.NET web user interface using traditional WebForms.
Standard ASP.NET web user interface using the new ASP.NET MVC Framework
"Client only" user interface utilizing client frameworks such as Microsoft Ajax, ExtJs, YUI, or MooTools.
"Client only" user interface utilizing presentation frameworks such as Flash or Silverlight.

In the case of user interfaces that implement data retrieval by way of AJAX requests, developers will need to create an intermediary ASP.NET web service (typically .asmx files) in their user interface project that communicates with the backing WCF services of their application.

This requirement applies to user interfaces built with Silverlight. Here is an good article that explains how to implement this technique from a Silverlight frontend:

Consuming ASMX Web Services with Silverlight 2

Starting WCF Services in Visual Studio 2005

2009-01-21T02:06:00Z

Unlike Visual Studio 2008, Visual Studio 2005 provides no automatic way to launch a WCF Service. This is a major pain point for those of you developing SaaSGrid applications, but this article leads you through the process of creating a simple helper project that can start one or more WCF Services inside of Visual Studio 2005.

Note: This article was written specifically to work with the Calculator example, which is created during a tutorial included with the QuickStart document (installed with the SDK). It should be easy to adapt this example to your specific implementation, but if you have any trouble, don't hesitate to post to our developer forums.

Right-click on the open solution, and add choose Add -> New Project.
Choose Console Application as the project type, and set the name to ServiceStarter. Press OK.
For the new project, add these references:

CalculatorService (project reference)
Apprenda.Execution.CallContextStorage
Apprenda.FSDrivers
SaaSGrid.API.Local
System.ServiceModel

Edit the Main method in Program.cs to look like the following:

    static void Main(string[] args)
    {
        ServiceHost host1 = new ServiceHost(typeof(Calculator));

        host1.Open();

        Console.WriteLine("Services started; press Enter to stop.");
        Console.ReadLine();

        try
        {
            host1.Close();
        }
        catch { }
    }

Add the following using directives:

    using System.ServiceModel;
    using CalculatorService;

Verify that the solution compiles.
Right-click the ServiceStarter project and add a new Application Configuration File.Keep the default name and press OK.
Copy the contents of App.config from the CalculatorService project into the one that you just created.
You should now be able to run the service. To do so, right-click on the project, select Debug -> Start New Instance. If the service is started you'll see "Services started; press Enter to stop."

You can now run the UI in addition to the service if you are ready to test your service calls. Leave the service running using the steps above, but detach from it by selecting Debug -> Detach All. The command window should still be open, leaving the service running, but you can now start up any other project using conventional means.

Introducing the SaaSGrid Mocker!

2009-01-08T14:46:00Z

Who should read this article?
If you are developing a SaaSGrid application you should read this article to understand how the new SaaSGrid Mocker can help you debug your application right from Visual Studio prior to deploying it to a cloud instance of SaaSGrid.

What is the SaaSGrid Mocker?
The SaaSGrid Mocker is a new tool that allows developers to easily mock out a simulation SaaSGrid environment to test and debug their applications locally. Using the Mocker, developers can test different subscription, customer and security scenarios during development without having to test in the cloud.

When developing SaaSGrid applications, developers have the ability to use the API to tap into certain resources available through SaaSGrid such as user information, feature metering, securables and other data. These resources are available in a live environment based on the logged in user, their credentials and their subscription. To simulate this on a local environment the SaaSGrid SDK provides a local implementation that simulates the live environment based on an XML definition (known as SaaSGrid.cfg.xml files).

The SaaSGrid Mocker is a front end to a standard, hand-modifiable SaaSGrid configuration file, thus allowing for easier manipulation. It can be used to either modify an on-disk file or can be used to attach to a locally executing SaaSGrid application and modify execution settings at runtime.

So let’s take a look at using the SaaSGrid Mocker:

Using the SaaSGrid Mocker:

To start, download the SaaSGrid Mocker here.

The SaaSGrid Mocker can be divided into two primary functional areas:

1) A "database" of mock customers (the local SaaSGrid Tenants section in the configuration file).

2) A section that establishes runtime parameters, such as which customer to 'Run As' and any subscription parameters that will dictate the behavior you are testing (the local SaaSGrid ExecutionContext section in the configuration file).

Customers Section

Application Parameters

Running Customer

By changing which one of your customers is running the application or by modifying execution parameters such as meters that the user has access to, you can see how your application handles boundary conditions when features are disabled or simply exhausted and test your applications reaction to those changes.

Next we will follow along with a simple case using the Taskr example to see how you can use the SaaSGrid Mocker to help you when developing locally.

Following along with Taskr!

The first thing you need to do is download the Taskr example on the community portal and get it up and running. Once you get Taskr running you should see a screen like this one:

After Taskr is up and running you should be able to attach with the mocker so that you can load the current configuration being used. You do this by either pressing Ctrl+Shift+O or by clicking Options | Live Debugging | Load Configuration. Once the configuration is loaded you should see this in the mocker:

Notice how in the Execution Context the running user is Jorge Lucas which matches the welcome message of Taskr!. Try switching the running as user to something else, push the configuration changes back to Taskr (Ctrl+Shift+S or Options | Live Debugging | Push Configuration) and notice how the welcome message should be for the newly selected user.

It's easy to see how with the help of the Mocker you can easily test different scenarios on how your application behaves depending on different subscription cases, for example when the running user has reached the maximum count for an allowed limiter, or when a feature is not available to a user or when a user doesn't have the necessary roles to access a securable or many other examples.

We invite you to start using the Mocker to help you build your SaaSGrid application's and give us feedback on how we can improve it.

Problems you may encounter:

The SaaSGrid Mocker was only introduced with the SaaSGrid SDK v1.5 released on January 08 2009, if you are trying to attach to an application that was developed with an earlier version of the SDK you won't be able to. In order to attach to an older application you must first download and install the latest version of the SDK here and then modify the Web.config of your root web application to include the following:

[code lang="xml"]

[/code]

Microsoft SaaS Architecture Team Experiences SaaSGrid

2008-09-12T10:16:00Z

Recently, we had the opportunity to demo SaaSGrid to Eugenio Pace and Gianpaolo Carraro from Microsoft's SaaS Architecture team. You can read about their impressions of the platform here:

Northwind Hosting exists, it's better than what you saw and it's called SaaSGrid

During the demo, Apprenda's team and the SaaS Architecture team from Microsoft had some terrific conversations surrounding all of the ideas they've expressed over the course of the past couple of years. One key concept that kept coming up was about the 'non-intrusive' nature of SaaSGrid. This was especially great to hear during this conversation because we've taken great care while designing SaaSGrid to ensure that the platform provides expected platform-esque services without clobbering the efforts of ISVs who deploy to it. We believe that ISVs should not have to relinquish their IP by uploading source code through mangling processes, or worse yet, write their SaaS apps in a new proprietary language among other things.

Sinclair Schuller helps the conversation along in his newest SaaSBlogs post:

How Important Is "Non Intrusiveness" In A PaaS Offering?