Over the past twenty-odd years, companies have spent considerable amounts of money (in the billions of dollars) installing... more

Over the past twenty-odd years, companies have spent considerable amounts of money (in the billions of dollars) installing and maintaining line-of-business (LOB) systems to manage all types of data, including customer data, sales and finance data, and human resource information. In many cases, these business data represent the backbone of the organization. One of the issues with these LOB systems, though, has been accessibility; the systems have been accessible to only a subset of people within the organizations. Though in some cases this accessibility might be by design, for the most part organizations can benefit by exposing much of the business data within the LOB system to their employees. For example, if salespeople have direct access to updating their sales data within the LOB system, they rely less on people who have direct access to the system and subsequently have to copy and paste data out of the system. For those that do have access to the system, there are a number of costs to the organization that are quite significant. For example, in a study entitled “The Financial Impact of Packaged Applications” (Forrester, 07/11/2006), a number of key costs were outlined such as training, temporary business backfill, or change management—all direct costs to the company resulting from an enterprise-wide LOB system implementation (see Figure 1-1). When you consider many LOB system implementations run in the twenty-five million plus region, these cost hits are no small matter.

With the growth of LOB system installations, there have also been some other changes taking place in the workplace. To name a few, many of us engage in an abundance of email communication, sending attached documents like fiscal plans created in Excel spreadsheets “across the wire” instead of posting them on a central document share; many people keep information local to their PCs (think of the problem with intellectual property leakage when these people leave the organization and IT staff wipes the drives of their machines—this information is now lost); the organization has evolved into a more team-based environment, so sharing information and knowledge has become a critical part of our daily collaborative processes; and many people are generally unhappy with the current LOB systems that are costing companies so much to implement today (some studies have found these system have user adoption issues in the neighborhood of 45% of the total user base). With these changes have arrived many new productivity tools to help manage our processes and behaviors within the workplace; in fact, it’s hard to think what our lives would be like without these tools in place. Though there are many different productivity technologies on the market today, this book deals primarily with those tools, servers, and applications found within the Office platform and how these tools can integrate with LOB systems to not only mitigate the cost burdens just described (and shown in Figure 1-1), but also to begin to take better and more discrete use of the business data that lives in these LOB systems. That said, OBAs help mitigate the issues within these scenarios by leveraging the Office platform to:

• Provide a central interface into the business data within a LOB system

• Use existing technology (assuming an organization has deployed Office) to build OBAs

• Improve user adoption issues with users interacting with the business data within a comfortable environment

• Increase cost savings in, for example, training and productivity

Now that you understand the high-level problem, you’re probably asking yourself…

... less

In Chapter 1, we introduced you to a type of composite application called Office Business Application... more

In Chapter 1, we introduced you to a type of composite application called Office Business Application (OBA). One of the key takeaways from Chapter 1 was that OBAs are solutions that integrate with line-of-business (LOB) systems and leverage key Office technologies (for example, Office client customizations and SharePoint server) to integrate key business data with familiar and comfortable environments of information workers. We also provided a high-level overview of some of the technologies that you can use to build OBAs. Building on Chapter 1, this chapter takes you one step forward.

... less

This chapter looks at configuring your Windows Server 2003 server, setting up MOSS on that server, and creating the necessary... more

This chapter looks at configuring your Windows Server 2003 server, setting up MOSS on that server, and creating the necessary accounts for the sales forecast OBA. The goal of this chapter is to focus on helping you set up an environment where you can get the sales forecast OBA operational. To this end, the chapter is broken out in the following main topic areas:

• Baseline and optional server setup

• Installing and configuring MOSS

• Setting up user accounts

• Installing the business application database

Setting up a complete environment isn’t something that is covered in a single chapter of any book for a load-balanced public-facing MOSS installation. This chapter contains elements that, to an experienced IT professional, may already be familiar. To someone new to SharePoint, however, and for certain specific characteristics of the sales forecast OBA environment, this chapter provides the necessary knowledge. The narrative as a whole targets an IT professional or developer who is setting up an environment in which they can leverage the sales forecast OBA components and the knowledge gained by re-creating the core environment that hosts these components.

As a result, how to create a load-balanced set of web sites that leverage a separate SQL Server cluster as well as how to handle permissions outside of the local intranet are beyond the planned scope of this chapter. On the other hand, setting up a combined domain controller, SQL Server, and MOSS host machine that will potentially also be installed with the Office client tools and Visual Studio 2008 is the target.

... less

Chapter 2, “Architectural Guidance and Design Patterns for Office Business Applications,” provided an overview of the Office... more

Chapter 2, “Architectural Guidance and Design Patterns for Office Business Applications,” provided an overview of the Office Business Application (OBA) solution patterns and then applied the patterns to the solution you’ll be working through in this book: the sales forecast OBA. The goal was to lay out a high-level design process to think about the why, what, and how of our OBA using the solution patterns as a reference point. Following on that, this chapter begins building out that design. Specifically, this chapter discusses the Visual Studio Tools for Office (VSTO) document-level customization that you’ll build using Visual Studio 2008. This customization includes a customized task pane that will act as the data manager view and a custom ribbon component that will extend the current Office Fluent UI (the new branding term for the Office UI) even further.

... less

In organizations today, there exist processes around many of the things that we do. Sometimes these processes are informal... more

In organizations today, there exist processes around many of the things that we do. Sometimes these processes are informal and ad hoc; other times these processes are strict and must adhere to a set of formal steps. Within these processes, data and events must be managed in a strict and rigorous fashion. For example, if you’re building a purchase order (PO) process, oftentimes customer, inventory, and pricing data will be used in tandem with a document of some sort to manage user interaction with the PO data. Further, the PO document may need to be approved by a manager to ensure that the data is correct and then marked as paid by a finance person. The point here is that the example process touches multiple people, must conform to specific organization policies and rules, reads and writes data into a workflow, and requires a set of tools to manage the ways in which the users interface with the process. To handle all of these requires a specific software application that tracks and routes information and documents to the appropriate person in a strictly defined way. Enter workflow.

In this chapter, we discuss the different types of workflow relevant to the sales forecast OBA and provide some general guidance on how you can create them. After you read this chapter, you will want to download the solution files from the sales forecast Codeplex site and explore the custom code within the sales forecast OBA workflow (http://www.codeplex.com/obasales).

... less

This chapter introduces the Outlook Form Region (OFR) to the list of technologies used in this OBA. The OFR is one of the... more

This chapter introduces the Outlook Form Region (OFR) to the list of technologies used in this OBA. The OFR is one of the most powerful tools available to the developer of an OBA because it integrates your custom business logic and data with arguably the most used and liked tool of the Office Suite—Outlook. In the case of the sales forecast OFR, we see the power of that integration within email. Over the years, everyone from the mailroom to the boardroom has used email, and unlike creating a spreadsheet or typing a document, handling email is a task that occurs across all levels of an organization. As a result, as long as your organization is leveraging Outlook as an email client, everyone in the organization from the sales representative to the uber-nerd is familiar with the interface of Outlook.

The result is that if you can go beyond embedding data as an attachment, and instead provide a custom interface that is displayed with the email, you will expose that data to the people who really need to review it. No more unexpected responses that someone couldn’t get an attachment to open, or that they lost the “link” to the project site, or any of a dozen other reasons work couldn’t be completed. Instead, Outlook will host their work in the one application they all check several times a day, and the convenience of directly updating line of business application data will result in a happier user.

This chapter focuses on the steps and key elements of developing an OFR. The chapter talks about pitfalls based on the type of OFR you select, and walks through the key elements of the OFR that is part of the sales forecast OBA implementation. The sales forecast OFR was designed using WPF as the display engine, allowing you to embed 3D graphics within a custom display hosted inside of Outlook. To do this, you’ll walk through the steps to leverage WPF-Windows Forms interoperability, create a custom WPF user control, and populate that control with data retrieved from an XML attachment in your email message. Finally, to make this more than just eye-candy, the OFR will be coded to allow the manager receiving it to connect to the running Sales Forecast Approval Workflow and update the current status of that workflow from within Outlook.

The topics in this chapter include:

• OFR types

• Filtering when an Adjoining or Separate OFR is visible

• Accessing email attachments

• Using the ElementHost control for your WPF display elements

• Parsing the XML attachment to populate the form data

• Leveraging 3D graphics in WPF

• Making Web-service calls to a running workflow to update the MOSS-hosted workflow state

We start with an overview of VSTO and how it allows you to leverage Outlook Form Regions as a development platform for your business requirements.

... less

As part of this book, you expect to see and do a lot of VSTO programming. After all, in building an Office Business Application... more

As part of this book, you expect to see and do a lot of VSTO programming. After all, in building an Office Business Application, you expect to be working with the Office System products. In this chapter, however, you are going to create and work with a project that isn’t available under the Office project types. You don’t need a VSTO project to work with OpenXML. Instead, you’ll leverage a typical application or ASP.NET type project and refer to a Word document and SharePoint library from that custom application.

This chapter focuses on introducing you to the steps and key elements in developing a custom Web service that can create a Word document customized using the OpenXML object model. The Web service will be combined with MOSS and the document will be created in a document library. The topics in this chapter include:

• Introduction to OpenXML

• Creating a Web service to generate a Word document

• Working with the OpenXML data elements

• Creating a new document on SharePoint

Because this project isn’t a VSTO project type, it seems the place to start is with a quick overview of the OpenXML document format. New to Office 2007, this format allows developers much greater direct access to the content of Microsoft Office documents than has been achievable in previous versions of Microsoft Office.

... less

Business intelligence (BI) is not something new; as long as business has been around, there has been some degree of data... more

Business intelligence (BI) is not something new; as long as business has been around, there has been some degree of data and reporting that provides ”intelligence” to help inform the decisions of workers of all types. In the context of Office Business Applications (OBAs), BI takes on a similar meaning. The exciting part for developers, though, is that you have a number of different options available to you to expose important business data within the structure of a report or dashboard to enable information workers to make better business decisions. In some cases, the work of configuring these BI options in SharePoint can be left up to the information worker.

In this chapter, we talk specifically about some of the key features that we used in some capacity in the sales forecast OBA to give you some grounding on these additional features when building your own OBA.

You could summarize the BI features we used in the sales forecast OBA through four main areas:

1. Report Center and BI Dashboards

2. Business Data Catalog (BDC)

3. Key Performance Indicators (KPIs)

4. Excel Services

We discuss each of these in respect to the sales forecast OBA.

... less

One of the ways that the Microsoft Office System has evolved is to integrate new server-based capabilities with what originally... more

One of the ways that the Microsoft Office System has evolved is to integrate new server-based capabilities with what originally was a collection of client components. Over the past several years, however, the Office System has expanded to include collaborative capabilities that are, for the most part, centered on Microsoft Office SharePoint Server (MOSS). In particular, the sales forecast OBA is also centered around a central MOSS server that can act as a collaborative hub.

We shouldn’t stop with collaboration as the only service hosted by the central server. Instead, we need to consider how to leverage this architecture for additional services. Microsoft, long a proponent of the concept of Service Oriented Architecture (SOA), has built the BDC around the basic concepts of SOA. The BDC allows you to treat your business applications as services and then consume those services from your MOSS site, or potentially from a client application. In fact, this later model is one type of SOA architecture that Microsoft has chosen to focus on, calling it Software plus Services (S+S).

The idea is that you can leverage certain key capabilities as hosted solutions; in many ways the Web itself is a giant hosted application. To a limited extent, the entire sales forecast OBA leverages this concept; the key business logic is centered on a custom MOSS site. However, we want to demonstrate exposing your line of business in an environment that is not a dedicated Line of Business (LOB) application. One of the more explicit examples of this is the use of the Business Data Catalog (BDC) as a service on your MOSS implementation.

The Business Data Catalog provides an infrastructure to allow you to incorporate your LOB data into your MOSS site. This chapter focuses on introducing the BDC and illustrating a couple of the ways that you can leverage your LOB data. The topics include:

• Overview of the BDC

• The Application Definition File

• Shared Services on MOSS

• Working with SharePoint Search

• Integrating BDC data with Search

• Exposing BDC data through Web parts

The BDC was introduced as a new element with MOSS 2007, and, though the tools to make developing the metadata to define your key business data aren’t yet mature, the core capabilities of the BDC allow you to define valuable insight into core operational data. Third-party tools are available that help bridge this initial gap, and, certainly, there is significant potential for future enhancements in this area with future releases of MOSS.

... less

To create an Office Business Application (OBA), one of the unofficial requirements is that you leverage one or more client... more

To create an Office Business Application (OBA), one of the unofficial requirements is that you leverage one or more client Microsoft Office applications. In theory, you could call a SharePoint site an OBA if it weren’t for the fact that without some level of custom business logic that extends beyond the web server, calling it a web application based on SharePoint is more accurate and descriptive. The sales forecast OBA includes both an Outlook Form Region and a custom VSTO-enabled Excel Workbook. Installing these on all of the client machines in your organization could be a difficult, time-consuming task. By leveraging SharePoint and Visual Studio 2008’s support for ClickOnce installation, the process can be made more manageable. This chapter looks at:

• Creating ClickOnce packages

• Creating a Sales Tools page

• Updating your trusted locations

• Setting up the Sales Forecast content type on MOSS

This chapter targets an IT professional who may or may not be a developer, because it is the IT professional who will need to manage the installation process. In the case of ClickOnce deployment, this means that the IT professional needs to be involved in configuring the settings associated with the installation of the package.

Some of these installation settings occur on the server. For example, the packages will be hosted on the SharePoint site. The content type that is assigned to the various document libraries is set on the server; however, even when the settings are based on the server on which the solution will be deployed, some of the settings must be configured as part of the package creation inside Visual Studio. This chapter is all about what the IT professional needs to know, and in some cases, pass to the developer in order to be able to deploy these client-side components successfully. This chapter starts with a need to prepare and set up client components, and this starts within Visual Studio 2008, with the creation of the ClickOnce installation package.

... less

Now that you’ve looked at packaging the client components on the server and installing these packages by the clients, the... more

Now that you’ve looked at packaging the client components on the server and installing these packages by the clients, the next step is to examine the custom server components that need to be installed on your server. These are encapsulated in two of the sales forecast OBA applications. The first is the Word Document Generation Web service. This Web service is a custom ASP.NET XML Web service. The second is the custom Sales Forecast Approval Workflow. This involves a custom workflow and three custom InfoPath forms.

Accordingly, this chapter focuses on:

• Creating a web deployment project

• Deploying the Web service

• Publishing the InfoPath templates

• Configuring the custom workflow

In general, the process of deploying these server components is reasonably straightforward. Recognizing the simple steps is probably the biggest challenge.

... less