MashPoint Use Cases

Below are excerpts with links to the MashPoint use cases we've authored to date.  New use cases will be authored and posted to correspond with upcoming MashPoint releases. 

Use Case #1 - Installing Application Definitions in MashPoint: AdventureWorks Sample: 

In this section we will configure MashPoint to work with the AdventureWorks sample database from Microsoft. If you don't have it, you can download it here.  If you are using SLQ Server 2005, download it here, and follow the instructions here.

You also need the Application Definition for AdventureWorks which is included in the download package of MashPoint in the MetadataFiles folder.

After you have installed the AdventureWorks database, it's time to modify the application definition file (ADF) to connect to your database. We will start with the PassThrough authentication mode (you can read more about this on MSDN).

Open up AdventureWorks2000 PassThrough Metadata.xml in your favorite XML editor.

Use Case #2 - Installing Application Definitions in MashPoint: Amazon Web Service Sample: 

In this section, we will configure MashPoint to work with the Amazon Web Service sample from Microsoft. You can read about it in greater detail on MSDN.

You need the Application Definition for AmazonWebService.  It is included in the download package of MashPoint, in the MetadataFiles folder.

Before we can configure the Application Definition File (ADF), we must sign up to use the Amazon Web Services, which you do here. You will receive an e-mail with a link to a page where you will see your access key.  You will need this key to be able to use the Amazon Web Services.

Use Case #3 -  Writing a Custom Data Provider for MashPoint: 

In this section we will write a custom Data Provider for MashPoint.  This sounds much more complicated than it really is since all we are doing is writing a .Net class.  As a matter of fact, any .NET class can be imported into MashPoint.

Our sample provider will allow us to access the file system and display files from a file server in SharePoint.  Authentication and Authorization will be managed by MashPoint so no need to worry about this, and we can focus on the task of returning file information.

The only requirement for a class to be imported is that it's installed into the GAC on all web front ends (WFE's).  This implies that it has to be signed.

Let's start by bringing up Visual Studio, then create a ClassLibrary project, and name it MashPointProvider.

Create a new class called FileSystemProvider.

Use Case #4 -  How to Write Custom Code Against the MashPoint Runtime Object Model: 

In this post I'm going to describe how you write code that uses the MashPoint runtime object model. But before we dive in to the samples we need to get an idea of how MashPoint works.

The MashPoint API can run in two modes:

1. Utilizing the MashPoint implementation.
2. Utilizing the MOSS BDC.

No matter what runtime you will target, you can use the MashPoint APIs. This gives you the benefit of being able to run your code both on MOSS BDC and on Bamboo MashPoint. A company with both MOSS Enterprise farms and WSS farms can now deploy the same Web Parts in both environments if you use the MashPoint APIs instead of the Microsoft specific APIs.

This is accomplished by exposing an interface-based API. When you work with MashPoint, you only use interfaces. We have created interfaces for all public classes in the ApplicationRegistry namespace. When you run on top of the BDC, we wrap all objects coming from the BDC so that you get the MashPoint interface to work with.