Steve Fox's OBA Ramblings : Steve Fox

Retrieve SharePoint List Data with XLINQ using VS 2010 Beta 1

Steve Fox — Wed, 17 Jun 2009 22:30:28 GMT

One of the key things you’ll likely want to do with SharePoint is interact a lot with lists. In earlier posts on this blog, I’ve discussed adding data to a SharePoint list using both custom and native SharePoint services (i.e. services that ship with either WSS or MOSS—when I say SharePoint I include both of these SharePoint pieces). A recent post got me thinking about how to not only retrieve data from SharePoint, but then having the ability to take that data offline (e.g. save to a file) or to use it in-memory for other types of processing (e.g. filtering/management within a UI), so I put together a small application that does a couple of things:

1. Retrieves data from a SharePoint list using the Lists web service (a service native to SharePoint 2007);

2. Uses XML to add items to a custom object; and

3. Uses LINQ to query the object and filter/manage into a XAML UI.

All this using the latest Visual Studio 2010 Beta bits.

First, let’s take a quick look at the SharePoint list. It’s called “Products” and lives on my test SharePoint server (“http://stefoxdemo”). You can see a cropped screenshot of the list. It’s pretty simple and should be thought of as such because we really just want to show data coming from the list—not hoards of data.

If you’ve never created a list, you open SharePoint, navigate to your home page, click View All Site Content, click Create, and under Custom Lists click Custom List. Complete the Name and Description fields for your new list and click Create.

Now that you’ve created the list, open Visual Studio 2010 and click File, New Project. Select WPF Application and provide a name (e.g. MySharePointData) and location for your project and click OK—see the figure below.

We’re going to keep things simple here and add nine controls to the WPF UI:

Four labels
One listbox
Two textboxes
Two buttons

If you inspect the XAML code below, you’ll see that this is the resulting code that was generated from me dragging and dropping controls from the VS 2010 Toolbox onto the XAML designer. Check out the different properties of the controls.

The resulting UI from the above code looks like the following:

Once you’ve created your WPF UI, you now will want to add some code-behind to actually do something. The first thing you’ll want to do is to add the SharePoint Lists web service. This provides you with the ability to interact with lists and data in your lists. You can see from the figure below the subset of methods that are available to you. To add the web service to the VS 2010 project, right click References and select Service References. Click Advanced and then click Add Web Reference, and then discover the Lists web service by clicking Web Services on the Local Machine (or entering the service URL in the URL: field, e.g. “http://stefoxdemo/_vti_bin/Lists.asmx”). Provide a name for the service reference (e.g. SPListGetData) and click Add Reference. You now have a reference added to the Lists web service and can use it in code.

One thing I used in my solution was a custom object, which I used to store (in-memory) a list collection of the different elements in my list. This allowed me to use the collection of objects later and run a simple LINQ query against it. To add an object, right-click the project node and select Add, and then select Class.

The custom object comprises three strings (mapping to the three parts of my SharePoint list): 1) a title (or product name), 2) a product number, and 3) a sales figure. The code I have for my custom object is as follows—note that I’ve set the properties on my object to both read/write, but in this file all we’re really doing is reading.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MySharePointData
{
   public class MySPData
    {
        public string clsTitle { get; set; }
        public string clsProductNum { get; set; }
        public string clsSales { get; set; }
    }
}

After you’ve added the class to the project, you can now add some of the heavier-weight code. This code is going to set some class-level variables, use the Lists web service to get the data in my list, iterate through the list and use XLINQ to create and populate the custom object, and then if the user changes the selection on the list the fields will be updated through a LINQ query.

Let’s start with the class-level variables. I’ve added a string to represent the selected item in the listbox, a list collection object (which will be in-memory collection object) called lstSPData, and the declaration of an XDocument (called myXMLDoc), which will be used as the document to which I’ll add the items from the SharePoint list.

…

string strSelectedItem = "";

List<MySPData> lstSPData = new List<MySPData>();

XDocument myXMLDoc = new XDocument();

…

Once you’ve added these three top-level items to the class, you’ll want to double-click on one of the buttons you added to the UI and then add some code for that. In my case, the name of the button was btnGetData and the subsequent event was called btnGetData_Click. The code below shows what I added into that method. There are a few things that are interesting in the code. For example, note that one of the first things we do is create a proxy for the web service, pass my default credentials to call the service (SharePoint must know who you are even at the service level), and then uses an XMLNode object to get all of the items from the Products list. You’ll then also see that I’ve began creating an XML object, but creating an XElement and then setting the declaration type of the XML Document I created earlier. Then to get the data out of the object, you iterate through the nodes and grab the inner text of the XML. In this case, you need to be sure you’re pulling from the SharePoint XML (this is the “ows_Title,” “ows_ProductNum,” and “ows_Sales”). From there on, two major things are happening. The first is that I’m reassigning the XML data from the object being passed back from the web service call with some XML that I’m more comfortable with (and a structure that I prefer to work with), and then I’m creating an instance of the custom object I created and then am populating the list collection for that custom object as I iterate through each of the XML nodes of the returned XML data. You’ll then see two lines of code lying outside of the foreach statement, and this is where I’m first adding the more comfortable version of the XML data to my originally-created XML document, and then I’m saving that XML document to a file share.

private void btnGetData_Click(object sender, RoutedEventArgs e)
{

    MySharePointData.SPListGetData.Lists proxy = new MySharePointData.SPListGetData.Lists();
    proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
    proxy.Url = "http://stefoxdemo/_vti_bin/Lists.asmx";

XmlNode myLIstItems = proxy.GetListItems("Products", null, null, null, null, null, null);

XElement newRootElement = new XElement("NewData");

myXMLDoc.Declaration = new XDeclaration("1.0", "utf-8", "true");

foreach (XmlNode outerNode in myLIstItems.ChildNodes)
{

if (outerNode.NodeType.Equals(System.Xml.XmlNodeType.Element))
{

foreach (XmlNode node in outerNode.ChildNodes)
{

if (node.NodeType.Equals(System.Xml.XmlNodeType.Element))
{

                    XmlNode listFieldTitle = node.Attributes.GetNamedItem("ows_Title");
                    XmlNode listFieldProductNum = node.Attributes.GetNamedItem("ows_ProductNum");
                    XmlNode listFieldSales = node.Attributes.GetNamedItem("ows_Sales");

                    string strListFieldTitle = listFieldTitle.InnerText;
                    string strListFieldProductNum = listFieldProductNum.InnerText;
                    string strListFieldSales = listFieldSales.InnerText;

                    XElement xmlData = new XElement("MyData",
                            new XElement("Title", strListFieldTitle),
                            new XElement("ProductNum", strListFieldProductNum),
                            new XElement("Sales", strListFieldSales));

newRootElement.Add(xmlData);
lstBxProducts.Items.Add(strListFieldTitle);

MySPData clsSPDataInstance = new MySPData();

                    clsSPDataInstance.clsTitle = strListFieldTitle;
                    clsSPDataInstance.clsProductNum = strListFieldProductNum;
                    clsSPDataInstance.clsSales = strListFieldSales;
                    lstSPData.Add(clsSPDataInstance);

                }
            }
        }

}

myXMLDoc.Add(newRootElement);
myXMLDoc.Save("c:\\SPData\\MySharePointData.xml");
}

The key takeaway from this, though, is that there are now two data structures in this app: one that I’ve created as an XML file and saved to disk (or alternatively could be used to inject into another program, say a Word document through Open XML); and one that now represents a list collection of the custom object—this is my in-memory version of the data that I can use for querying.

The next bit of code we’ll look at handles the user interacting with the listbox; that is, when the user changes their selection this will invoke the lstBxProducts_SelectionChanged event, which triggers the following code. This code is fairly straight-forward. I’ve set three string variables as temporary variables, grabbed the currently selected item in the listbox (and am storing it in strSelectedItem) and then am using a LINQ query to get the other data in the record that maps to the product name selected in the listbox. Given the fact that this results in a list of one record, I’m then using the First method to grab the first (and only) element in that record and assigning the text property of the controls to those strings.

private void lstBxProducts_SelectionChanged(object sender, SelectionChangedEventArgs e)
   {
       string strTempTitle = "";
       string strTempProductNum = "";
       string strTempSales = "";

strSelectedItem = lstBxProducts.SelectedItem.ToString();

       var lstXMLObject = from lstXML in lstSPData
                          where lstXML.clsTitle == strSelectedItem
                          select new
                          {
                              strTempTitle = lstXML.clsTitle,
                              strTempProductNum = lstXML.clsProductNum,
                              strTempSales = lstXML.clsSales

};

txtBxProductNum.Text = lstXMLObject.First().strTempProductNum;
txtBxSales.Text = lstXMLObject.First().strTempSales;

}

The finished product results in the following cool and slick (okay, not so much…but functional) WPF UI first getting SharePoint list data and then allowing you to query that data in the context of your whiz-bang UI. Note that it also saves the XML to your local file system. When you F5, you should see the following UI. Click the Get Data button, which triggers the service call. This will populate the Product Name listbox and subsequently allow you to click on an item in the listbox and filter on that item.

If you browse to the location where you saved your XML file (in my case this was c:\SPData), you will find an XML file that hopefully resembles the data you have in your list.

<?xml version="1.0" encoding="utf-8"?>
<NewData>
<MyData>
    <Title>ALK-Bike Crank</Title>
    <ProductNum>0398021</ProductNum>
    <Sales>$209,002.98</Sales>
</MyData>
<MyData>
    <Title>OUU-Bicycle Riding Helmet</Title>
    <ProductNum>38271920</ProductNum>
    <Sales>$901,199.23</Sales>
</MyData>
<MyData>
    <Title>YTT-Road Bicycle Wheel</Title>
    <ProductNum>03929901</ProductNum>
    <Sales>$890,872.12</Sales>
</MyData>
<MyData>
    <Title>HGT-Off-Road Bike Gear Pack</Title>
    <ProductNum>3746281</ProductNum>
    <Sales>$459,922.10</Sales>
</MyData>
<MyData>
    <Title>BKP-Bianchi Racing Bike</Title>
    <ProductNum>3902443</ProductNum>
    <Sales>$2,019,100.29</Sales>
</MyData>
</NewData>

Lastly, the Exit button you see on my UI also calls a method; basically a simple method to exit the application. The code for this is as follows:

private void btnExit_Click(object sender, RoutedEventArgs e)
{
Application.Current.Shutdown();
}

And that’s it! Wasn’t that fun? I thought so. For your reference, the entire code sample from the core Windows.xaml.cs file is pasted below.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Navigation;
using System.Windows.Shapes;
using System.Xml;
using System.Xml.Linq;

namespace MySharePointData
{
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
        }
        string strSelectedItem = "";

List<MySPData> lstSPData = new List<MySPData>();

XDocument myXMLDoc = new XDocument();

        private void btnGetData_Click(object sender, RoutedEventArgs e)
        {

            MySharePointData.SPListGetData.Lists proxy = new MySharePointData.SPListGetData.Lists();
            proxy.Credentials = System.Net.CredentialCache.DefaultCredentials;
            proxy.Url = "http://stefoxdemo/_vti_bin/Lists.asmx";

            XmlNode myLIstItems = proxy.GetListItems("TR8", null, null, null, null, null, null);
            //Creation
            XElement newRootElement = new XElement("NewData");
            myXMLDoc.Declaration = new XDeclaration("1.0", "utf-8", "true");

foreach (XmlNode outerNode in myLIstItems.ChildNodes)
{

if (outerNode.NodeType.Equals(System.Xml.XmlNodeType.Element))
{

foreach (XmlNode node in outerNode.ChildNodes)
{

if (node.NodeType.Equals(System.Xml.XmlNodeType.Element))
{

                            XmlNode listFieldTitle = node.Attributes.GetNamedItem("ows_Title");
                            XmlNode listFieldProductNum = node.Attributes.GetNamedItem("ows_ProductNum");
                            XmlNode listFieldSales = node.Attributes.GetNamedItem("ows_Sales");

                            string strListFieldTitle = listFieldTitle.InnerText;
                            string strListFieldProductNum = listFieldProductNum.InnerText;
                            string strListFieldSales = listFieldSales.InnerText;

                            XElement xmlData = new XElement("MyData",
                                    new XElement("Title", strListFieldTitle),
                                    new XElement("ProductNum", strListFieldProductNum),
                                    new XElement("Sales", strListFieldSales));

                            newRootElement.Add(xmlData);
                            //tempAll = strListFieldTitle + " " + strListFieldProductNum + " " + strListFieldSales;
                            lstBxProducts.Items.Add(strListFieldTitle);

MySPData clsSPDataInstance = new MySPData();

                            clsSPDataInstance.clsTitle = strListFieldTitle;
                            clsSPDataInstance.clsProductNum = strListFieldProductNum;
                            clsSPDataInstance.clsSales = strListFieldSales;
                            lstSPData.Add(clsSPDataInstance);

                        }
                    }
                }

}

myXMLDoc.Add(newRootElement);
myXMLDoc.Save("c:\\SPData\\MySharePointData.xml");

MessageBox.Show("XML Data Saved to File!");
}

        private void btnExit_Click(object sender, RoutedEventArgs e)
        {
            Application.Current.Shutdown();
        }

        private void lstBxProducts_SelectionChanged(object sender, SelectionChangedEventArgs e)
        {
            string strTempTitle = "";
            string strTempProductNum = "";
            string strTempSales = "";

strSelectedItem = lstBxProducts.SelectedItem.ToString();

            var lstXMLObject = from lstXML in lstSPData
                               where lstXML.clsTitle == strSelectedItem
                               select new
                               {
                                   strTempTitle = lstXML.clsTitle,
                                   strTempProductNum = lstXML.clsProductNum,
                                   strTempSales = lstXML.clsSales

};

txtBxProductNum.Text = lstXMLObject.First().strTempProductNum;
txtBxSales.Text = lstXMLObject.First().strTempSales;

}
}
}

Happy coding!

End-to-End Sales Forecast OBA Released To Web!

Steve Fox — Sat, 25 Oct 2008 05:28:00 GMT

It's been a while, but I wanted to let all you OBA developers out there know of something cool that we recently released, which is the End-to-End (E2E) Sales Forecast OBA. As you know from reading this blog, you know that OBA is an Office Business Application and involves mutltiple technologies within the Office platform. The E2E Sales Forecast OBA is a solution that walks you through a scenario where a salesperson creates and submits a quarterly sales forecast. Using a customized Excel template (built using VS 2008/VSTO), our salesperson has the ability to navigate to the team Sales Forecast portal (SharePoint portal), invoke a custom Excel sales forecast template from the New button (content type mapping to a custom template), load line-of-business sales data into the document (via WPF custom actions pane), generate executive reports for the forecast (via Open XML), and submit the document for approval (through SharePoint workflow). It essentially uses all of the concepts and technologies that I've discussed thus far in this blog--plus a few that I haven't.

In the demo solution (which is available on CodePlex--see link below), the approving manager can interact directly with SharePoint or choose to approve the workflow via a custom Outlook Form Region (built using VS 2008/VSTO). Messaging of the workflow is marshaled by SharePoint, and Open XML enables the solution to parse out the necessary data and attach to workflow and to the custom Outlook from region. This is a great starter solution if you're looking to get your hands on some code, and includes the technologies below:

- SharePoint

- Office Client Ribbon and Action Pane Customizations (VS 2008/VSTO)

- Outlook Custom Form Regions

- Open XML

- Unified Communications (UC)

- SharePoint Workflow

- Windows Presentation Foundation (WPF)

- ++

For the community source-code download and accompanying book, you can check out the following resources:

Sales Forecast Codeplex Source Code Site

http://www.codeplex.com/obasales

Sales Forecast Wrox Book Accompaniment

http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470377313.html

The goal of the book is to walk you through all of the code and you would set up and deploy the sales forecast OBA.

Enjoy!!

Steve

The OBA Sample Application Kits

Steve Fox — Fri, 25 Apr 2008 23:07:00 GMT

Just a quick post to check out the OBA Sample Application for Kits MSDN page. The kits provide comprehensive guidance on how to integrate Office with SAP and PeopleSoft (and we'll have others in the future). The kits include whitepaper, install guide, technical walkthrough doc, and source code. We announced the latest of the kits (the OBA Sample Application Kit for PeopleSoft) last week at Kurt DelBene's keynote at Collaborate 08.

You can get to the page here: http://msdn2.microsoft.com/en-us/office/cc442491.aspx

From this page, you can get to the individual kits.

Check it out! This is awesome stuff, and it is a rarity to find kits that provide guidance against these two very popular LOB Systems (that is PeopleSoft and SAP).

Cheers,

Steve

Your First Outlook Add-in...

Steve Fox — Thu, 27 Mar 2008 21:47:00 GMT

I just finished a private technical briefing and during the session showed a few demos. Many of the attendees asked me to share the code, so I thought I'd post to my blog to get my butt in gear and actually post some useful stuff and get the code up here so the attendees could read up on it.

When thinking about OBAs, one of the key integration points in Office is Outlook. It makes sense; a ton of people use this tool every day, so why wouldn't you leverage the Outlook OM and VSTO to create some killer OBAs? To get you started, I put together a small demo that shows how you integrate Outlook with AdventureWorks using VSTO. The demo shows i) how to add a custom task pane that's bound to data and enables you to create a new contact (or more widely access the Outlook OM).

First, the environment. My dev environment is Windows Server 2003, MOSS 2007 (which I won't use in this demo), VS 2008 (which includes VSTO 3.0), Expression Blend, SQL Server 2005, and Office Enterprise 2007. I've also downloaded the Adventureworks 2005 sample db off of Codeplex.

To begin, open Visual Studio and create a new project (File, New, Project, click Visual C# (or Visual Basic), Office, and then select Outlook Add-in). Name the project what you want and click OK. This creates the VSTO Outlook project shell for you.

In my project, I first added the Adventureworks database (Data, Add New Data Source, and walk through the wizard to add the database). The only table you'll want to add to the project is the vSalesPerson table. Once the database is added, click Data, Show Data Sources to make sure it's there.

I then added a new user control (right click project, click Add, New Item, and then select User Control in the New Item dialog). Resize the control to be about 300 x 760. I then dragged a few of the fields from the Data view onto the user control--specifically, I added FirstName, Lastname, Phone, Email, AddressLine1, and City. You can select the ones you want; just remember you'll need to account for them in your code-behind. Once you've done this, add a button to the user control (see attached image).

I added some code-behind to the button, which is listed below:

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Drawing;

using System.Data;

using System.Linq;

using System.Text;

using System.Windows.Forms;

using Outlook = Microsoft.Office.Interop.Outlook;

namespace MyTestAddin

{

public partial class CustomerBrowser : UserControl

{

string strFirstName;

string strLastName;

string strPhone;

string strEmail;

string strAddress;

string strCity;

public CustomerBrowser()

{

InitializeComponent();

}

private void CustomerBrowser_Load(object sender, EventArgs e)

{

vSalesPersonTableAdapter.Fill(this.adventureWorks_DataDataSet.vSalesPerson);

}

private void button1_Click(object sender, EventArgs e)

{

strFirstName = firstNameTextBox.Text;

strLastName = lastNameTextBox.Text;

strPhone = phoneTextBox.Text;

strEmail = emailAddressTextBox.Text;

strAddress = addressLine1TextBox.Text;

strCity = cityTextBox.Text;

createCustomerContact(

strFirstName,

strLastName,

strPhone,

strEmail,

strAddress,

strCity);

}

private void createCustomerContact(

string firstName,

string lastname,

string phone,

string email,

string address,

string city)

{

Outlook._Application myOutlookObject = new Outlook.Application();

Outlook.MAPIFolder custContacts = (Outlook.MAPIFolder)myOutlookObject.Session.GetDefaultFolder(Outlook.OlDefaultFolders.olFolderContacts);

Outlook.ContactItem newSalesContact = (Outlook.ContactItem)custContacts.Items.Add(Outlook.OlItemType.olContactItem);

newSalesContact.FirstName = firstName;

newSalesContact.LastName = lastname;

newSalesContact.Business2TelephoneNumber = phone;

newSalesContact.Email1Address = email;

newSalesContact.BusinessAddress = address;

newSalesContact.BusinessAddressCity = city;

newSalesContact.Save();

}

You'll note that you need to call the FIll method when the user controls loads to ensure the data from the Adventureworks database loads. But, most of the other data is pretty self-explanatory. You're essentially grabbing the string variables and then mapping them to the properties of the new contact item you've created. You need to note that there is no error handling in this code, though. So, for example I could add the same person from the data source over and over again. You may not want to do that.

Hit F6 to build, but don't run just yet. After you've successfully built the app, go to the ThisAddIn class and make sure you have the following code in it:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Xml.Linq;

using Outlook = Microsoft.Office.Interop.Outlook;

using Office = Microsoft.Office.Core;

namespace MyTestAddin

{

public partial class ThisAddIn

{

Microsoft.Office.Tools.CustomTaskPane ctp;

private CustomerBrowser ctrl = new CustomerBrowser();

string title = "Demo";

private void ThisAddIn_Startup(object sender, System.EventArgs e)

{

ctp = this.CustomTaskPanes.Add(ctrl, title);

ctp.Visible = true;

ctp.Width = 350;

ctp.DockPosition = Microsoft.Office.Core.MsoCTPDockPosition.msoCTPDockPositionRight;

}

private void ThisAddIn_Shutdown(object sender, System.EventArgs e)

{

}

#region VSTO generated code

/// <summary>

/// Required method for Designer support - do not modify

/// the contents of this method with the code editor.

/// </summary>

private void InternalStartup()

{

this.Startup += new System.EventHandler(ThisAddIn_Startup);

this.Shutdown += new System.EventHandler(ThisAddIn_Shutdown);

}

#endregion

}

The important code here is that you need to create a custom task pane object (CTP) and then add an instance of the newly created user control to the CTP object and then set some properties on the CTP object. What this will do (notice that we've added some of the code in the ThisAddinStartup method) is invoke the custom task pane.

You can now F5 to build. You should see the user control on the right-hand side of the screen. Open your Contacts folder, and then browse to a sales person from the Adventureworks db and click the button to add them to your Contacts. Voila! You've created your first Outlook add-in.

The extrapolation for an OBA is connecting to a LOB system via a service. You can try and wrap the Adventureworks db in a service and do the same thing we did above--just do it through a service call--and you'd have built a small OBA.

Well, happy coding!

Steve

PS I recently picked up the book Programming Applications for Office Outlook 2007, and this helped me with some questions I had about coding against the Outlook OM. Lots of code samples in it, and very well written.

The ramblings continue...starting out on OBA

Steve Fox — Wed, 12 Mar 2008 00:34:00 GMT

It's been a while since I've blogged last, and things have been very busy. Over the past three months, I've been to a number of conferences including the most recent Office Developer Conference and SharePoint Conference. It was great to see more OBA-centric content at these events. Coming up, I'll also be hitting VSLive, DevConnections, Collaborate, TechEd, SAP TechEd, Oracle OpenWorld, and PDC. And at these events, you're going to see some additional OBA content that will help you get on your way.

To start though, I'd like to offer those who are new to OBA some key resources...the things you might take a look at if you're a developer not necessarily new to .NET, but new to developing Office solutions.So, in this blog I'm going to list out a few places you might go to get more information.

OBA Overview: http://msdn2.microsoft.com/en-us/library/bb614538.aspx. This is a good article (chapter excerpt actually) to get your hands dirty.
OBA Central: www.obacentral.com. A decent portal for partner and customer OBA information. I've worked with some of the companies on here, and it's always great to see companies highlighted and on OBA Central.
Office Developer Center: http://r.office.microsoft.com/r/rlidOfficeDeveloperCenter?clid=th-TH. This is a good place to go for general Office development information. There are a ton of decent How-to videos you can find here (which I think are one of the quickest ways to get yourself up to speed on very specific areas of development).
VSTO Developer Center: http://msdn2.microsoft.com/en-us/office/aa905533.aspx. VSTO is key to developing the client-side portion of OBAs (as well as doing some server-side stuff such as SharePoint workflow). It's come a long way, so I encourage you to check it out (VSTO 3.0 is the most current version).
SharePoint (WSS) Developer Center: http://msdn2.microsoft.com/en-us/sharepoint/default.aspx. This is Windows SharePoint Services (WSS), the underlying infrstructure and object model for Microsoft Office SharePoint Server (MOSS) 2007. WSS is great for those of you who want to get into understanding the object model and dynamic creation of sites, lists, etc.
SharePoint (MOSS) Developer Cetner: http://msdn2.microsoft.com/en-us/office/aa905503.aspx. This is the MOSS portal, where you can find lots of great information. There are a number of key features you'll want to learn about when beginning to build OBAs. For example, you'll want to understand how to build Key Performance Indicators (KPIs), Excel Services, Business Data Catalog (BDC) Web parts to build integration into your line-of-business systems and provide business intelligence into your MOSS-based solutions.
OBA Solution Patterns: http://msdn2.microsoft.com/en-us/library/bb614541.aspx. OBA solution patterns provide some guidance to architects and developers on design patterns. We have some ways to on these, but they're a great step towards guiding you on how to craft your solution after an existing pattern.
OBA RAPs: http://msdn2.microsoft.com/en-us/architecture/bb643797.aspx. This is the link to one OBA Reference Architecture Pack (RAP), which is a great way to learn about industry-specific OBAs. Mike has created a number of other ones, so make sure you check those out as well.
Six Office Business Applications for Office SharePoint Server (MS Press): http://www.microsoft.com/MSPress/books/9471.aspx. A book that provides an overview of six different OBAs and how developers could go about building them.
Programming Office Business Applications (MS Press): http://www.microsoft.com/MSPress/books/12194.aspx. A book that looks at the different technologies that makie up an OBA--ranging from business intelligence, to social networking, to OpenXML, to SharePoint Workflow. Again, a developer-focused book.

In future blogs, I'm going to walk through some specifics about OBAs and try and cover them from top-to-bottom. I'll also try and find some additional things that you might find useful in your OBA ramp-up.

Until then (which I promise will not be too long), happy reading, coding.

Steve

The ramblings begin...

Steve Fox — Fri, 14 Dec 2007 03:07:00 GMT

Well it's December 13th, and I have not really started my Holiday shopping yet...how sad is that. But alas, I'm sure you're not tuning into this blog to hear about the lameness of my shopping habits, but you're probably looking for a little info on this mysterious thing called OBA. And if you have, then great...because I'll be using this blog to update you regularly on all things OBA. And while the title of the blog implies perambulation, fear not; I'll try and be somewhat structured in my delivery of information to you as I find it or create it.

In this blog entry, all I'm going to do is define OBA to keep things simple. As this blog grows, I'll add more information, sample code, and pointers to great content so you can fulfill your quest to learn, build and deploy OBAs in your organization. So, without further delay: What is OBA?

OBA, which stands for Office Business Application, is not a product SKU; moreover, it is the building of composite applications that leverage the Office development platform - or what some are also referring to as the OBA framework. I simplify my definition of OBA to the potential integration of three major components: i) a LOB system that manages your organization's business processes (e.g. SAP, PeopleSoft, Siebel, MS Dynamics, etc.). ii) the customization of the Office client (using tools like VSTO), and iii) the development and/or customization of MOSS 2007. The server side, while predominantly MOSS-centric (MOSS being Microsoft Office SharePoint Server) is not necessarily restricted to SharePoint; however, it is a primary piece of the pie.). And I say potential because you can different flavors of OBAs. For example, I could build an OBA that is Office client customizations tied to a LOB system; another type of OBA is server-side customizations (think MOSS BDC web part) tied to a LOB system; and yet another that combines both client and server customizations and one or more LOB systems. More forward looking, we'll likely see more OBAs that leverage hosted services/mash-ups in the cloud

There are various levels of value from creating OBAs in the organization today. For example, large-scale LOB systems are often cumbersome to learn and use and often don't return the desired investments. This means training costs, change management costs, etc. Thus, OBAs (through leveraging the Office platform) enable developers to integrate LOB systems into the Office client and MOSS and accomplish two primary things: i) keep the information worker in the context of a familiar and comfortable environment, and ii) drive specific disciplinary and/or business data directly into the purview of the people who need and use it. This integration can mitigate some of the aforementioned costs thus decreasing total cost of ownership and driving productivity into the appropriate organizational disciplines.

There is a lot of OBA momentum underway, and you can check out www.obacentral.com to see some of what's happening out there. However, in future blogs I'll be posting lots of useful information, so look out for client customization information, integration techniques with MOSS, and more. Of course, I'll also provide some additional business value information (and pointers to other blogs, articles, etc.) that may also be useful to you.

Until then, I hope you'll find our chats useful and fun!

Steve