Sharepoint BDC

8/3/2019 Sharepoint BDC

1/82

1The Business Data Catalog

O

ne of the most outstanding new features available in the MOSS Enterprise Editionis called the Business Data Catalog (BDC). The BDC is a subject worthy of its ownspecial chapter because it fills in a huge part of the overall enterprise information

architecture by providing the ability to incorporate enterprise data with and into SharePoint.While the Enterprise Edition does cost more, the BDC, Excel Services, InfoPath Forms Services,and KPI Tools it includes might pay off quickly.

In a collaborative environment, SharePoint plays a pivotal role since it can store, manage,and search much of the information used on a day-to-day basis. When used for what it doeswell, SharePoint brings to the surface much of the information and resources that were oncesilos on desktops and laptopshowever, it is self-contained. The BDC completes theinformation architecture, because it allows SharePoint to marry itself to enterprise datasources and combine its data with other systems. The BDC enables SharePoint to reach outinto other enterprise systems and data sources and use the data in views or pull actual datainto SharePoint. In addition, data sources defined within the BDC become part of SharePoint

and make the backend data searchable. Using the BDC, the complete picture of an entity canbe created; the information from nearly any backend system can now be combined withdocuments, calendars, and project plans, and all of it can be searched.

The capabilities of the BDC have also been extended into the SharePoint User Profiles.By default, user profiles are created from Active Directory data (or other authenticationsources) and combined with SharePoint specific system and user-defined properties.However, in many large environments, the authentication source is usually not the realsource of user information; it is usually stored in an HR system like PeopleSoft. This isparticularly important regarding personnel movements, new hires, and terminations; themost accurate data is usually tied to the paycheck and not to the system login. The BDCprovides an extension (or connector) that allows this data to be pulled directly into SharePointsUser Profiles, meaning that more accurate data and less user intervention are required.

Some of what the BDCs functionality enables in SharePoint includes the ability to

Provide views of data that can be easily manipulated by the users, including joiningdata to create complex data displays

Provide limited update capability for users to post data updates to backend systems

Create secured profiles of data (down to the field level) that can be used acrossthe farm

1

WEB CHAPTER


2/82

2 M i c r o s o f t O f f i c e S h a r e P o i n t S e r v e r 2 0 0 7 : T h e C o m p l e t e R e f e r e n c e

Provide a Profile Page that is used to view external data, based on the BDCdefinition

Provide the ability to pull BDC data directly into SharePoint, both as columns andas content types

Provide the ability to link BDC data directly to User Profiles Search data sources defined in the BDC, complete with last modified dates

While it may seem complicated at first, the BDC is quite a simple concept; the goal is toprovide users a way to get, relate, and view data and to keep the programmers out of it. Forend users, it provides a way (using several BDC web parts) for users to choose from thedata available, mix and match it, join/link it up in various ways, and then display it withoutany need for coding or development. For developers, the BDC provides a sophisticated wayof marrying external data with SharePoint and the use of defined Content Types that can beused anywhere in lists, libraries, web parts, and User Profiles.

From a usability point of view, the BDC puts enterprise data into the hands of the userswho actually need it without much fuss about where it comes from. The knowledge of thedata and internal relationships and the underlying connection and technical field definitionsare of no consequence to the user or developer. The only thing that matters is what entitiesthe data source represents. In real terms, the BDC enables working with enterprise data thesame way SharePoint lists work.

This is pretty cool when you think about the power available; users (and developers)can associate things themselves by what the item is without caring whats behind it. Thisputs data viewing more in line with the way typical users actually work. With the BDC,users can pick and choose entities as black boxes, which means that users can organize andrelate things that are naturally associated (in their minds). They can even create complexjoins between entities that arent actually related; for example, using data from Siebel andPeopleSoft to determine personnel cost by customer. To start off with covering the

mechanics, there are a few components that make up the BDC:

Data definitions These are created by developers who define the how and what ofa data source (database or web service) and include the connection information anddata format returned.

Content Types These are used by users defined by the Data Definitions and aremanaged by Site Administrators (enabled or disabled as desired).

BDC web parts These are used by end-users for displaying, searching, andmanipulating data.

The best place to start is the heart of the BDC, which is the data definitions that definedata sources, whether theyre databases or web services. First, the data source is described(using XML) in SharePoint, which includes the connection information and the format ofthe data returned (including the database column types used to map them to SharePointContent Types). This encapsulates the nitty-gritty of the connection itself (includingsecurity), which removes the usual barriers of accessing a data source. In the BDC, all ofthe information, connection, and login details are completely abstracted away from users,designers, and developers.


3/82

W e b C h a p t e r 1 : T h e B u s i n e s s D a t a C a t a l o g

The fact that the BDC is called a Catalog is by design. It is a Data Source Catalog andcan even be complemented with associations in order to accessorize the data to get the viewwanted. Just imagine if all of the data sources in your enterprise, such the Siebel CRMcustomer records, the help desk call center statistics, the issues logs, and the PeopleSoftemployee records were spread all over the place. To find any common information between

them, youd have to go to each system manually taking notes along the way. Sound familiar?Now imagine you have a catalog of business data you can browse through and select justwhat you want. As the user, you dont care how that data is returned or how to connect toit since this is defined in the BDC Data Source Definition. You can accessorize it with dataassociations (relationships) to other data. Without programming, data (related or not) can belinked to make a view of some entity or thing; for example, linking a Siebel Customer withRemedy (a trouble ticketing system). This data can even be brought into SharePoint.

The BDC itself is really a manager of definitions of data sources from databases or WebServices. BDC Data Definitions are XML files that define what a data source is and what canbe done with it. Once defined, these definitions can be used directly by the BDC web parts,the matching Content Types used in lists and libraries, and in applications you build on top

of SharePoint. Because the BDC is a Shared Service, the data it represents can be used acrossany sites associated to the Shared Service Provider (SSP); this means either site-specific orfarm-wide. Data definitions can also be localized; data column names have display namesthat can be used to display data in another language with headings to match. To handledata display, the BDC web parts allow you to create queries, provide selections, createcustom displays using XSL, and make connections between parts (master/child andfiltering), all without writing a line of code. (Note that Xsl is code, but it can be createdusing SharePoint Designer.)

As a Content Type, the BDC gives you a way to pull data from backend systems directlyinto SharePoint. I say pull because the BDC can be used to actually populate SharePointlists. BDC Content Types can be used like any other Content Type, and it can also be usedto map to Content Types in User Profiles so the right system of record can be used.

The BDC is really the fulcrum between data and SharePoint, and it doesnt do muchmore than that. The BDC holds the definitions (exposing them to SharePoint) and facilitatesthe pass-through of data by making Methods available. SharePoint handles the display of it(using BDC web parts) or pulls and stores it in lists or User Profiles (when data is pulledand stored in SharePoint, the backend data must be periodically refreshed to keep current,which is covered next).

The BDC also enables enterprise search. Data definitions point directly to the datasource, whether its a database or web services, and SharePoint can be enabled to index thedata and make it searchable. Since the definition is contained in SharePoint, theres nothingthat has to be done with the backend; the search engine takes care of all the details. As forviewing data found in external sources, the Profile Page (explained later) is provided so thatusers can view data much like they view an item in a SharePoint list.

Methods and MetadataIn addition to the data definition itself, the BDC allows you to define specific Methods forthat data, which gives you great power within SharePoint at the user level. While the datadefinition defines what the data source is and how to connect to it, Methods describe what


4/82


it will return as well as any methods that provide update capability. From a data perspective,the Methods provided by BDC Entities, combined with the metadata, are exactly the sameas if you were using a Stored Procedure without all the fuss of dealing with it in .NET code.Because the Method metadata is XML, you can query it to describe the format and fielddefinitions it will return (something you cant do with a Stored Procedure).

To understand this concept, lets compare this against creating an application. Forexample, lets say you wanted to display some data in SharePoint, and you decided to usethe traditional ASP.NET method of creating a Stored Procedure using a passed parameterwith methods to Add, Update, or Delete a record. In the SQL code, you would then createa procedure that defines the parameter, and then create an If structure to choose the properSQL command to execute. Users could then use a data view or a developer could create aweb part to execute the procedure. In either case, it is up to you to format the data display,and you must know exactly what is being returned. If a change is made, like adding acolumn, everything has to be changed. You also have a security issue, because userstypically dont have access to the database.

Using Methods with the metadata (the actual Content Type Definition) you can provide

the exact same feature, but with a whole lot less pain. The data definition already has theconnection information (and can even support SSO for individual user customization), andeach method has its own definition for both the parameters it supports and the fields thatwill be returned. For a Data View, this is a simple request, and the output can be manipulatedusing an Xsl style sheet. Programmatically, you can determine the fields at runtime, by simplyaccessing the BDC metadata XML to enumerate the fields and definitions that are returnedby a given method. There is no limit to methods; they can be created to perform whatevercommand is supported by the web service or database, whether its a service method, adatabase SQL call, or a Stored Procedure (using Stored Procedures is a best practice).

CAUTIONCAUTION SharePoint does not provide any throttling or limitation on BDC data returned; if amethod returns 5000 records, it will be brought in and eventually be loaded into memory (you

can set a max on web parts). It is up to you to define the methods so that such issues are dealtwith in the web service or database call.

Where the BDC Fits in MOSSThe BDC is a major piece in building up organization-wide information architecture byproviding a window to data in the entire enterprise. In the scheme of things, you haveOffice, which produces documents, content provided by Enterprise Content Management,data in lists in SharePoint, and User Profiles for people data, which covers half of the house.The BDC enterprise data brings in the other. As the roof, SharePoints UI handles thedisplay, relationships, and search for all of it.

Having all of this data combined with the BDC web parts in the UI, a business analystcan quickly create dashboard views of customers, regions, sales, and you name it: all withoutwriting code. Multiple ways of slicing and dicing information related from multiple systemscan be grouped, sorted, and organized to provide various views. Using SharePoint security,they can be used to make them context sensitive to the user.

Outside of the User Interface, Microsoft built a very robust Application ProgramInterface (API) for both the runtime and administrative aspects, meaning you can builda whole new class of applications on top of it. In fact, there is a big emphasis from theMicrosoft teams to leverage the BDC as another tool in the arsenal of building user-basedapplications on top of SharePoint technology (not using MOSS).


5/82


Whats In the BDCThe BDC is much like other SharePoint Galleries, only its specific for data, and in it, you canmanage definitions of data sources for either web services or databases. For actual sources, theBDC supports nearly any database (SQL Server 2000 and higher, Oracle, and any that can use

ODBC or OLEDB) and any web service (including SharePoints, which gives you completeaccess to lists and libraries). The components of the BDC break down into

External data sources (Databases/Web Services)

Data definitions and data profiles (stored in SharePoint as Content Types)

Profile Pages (built in a way to view BDC data)

BDC Data View Web Parts

Metadata (Content Types)

Methods and Method Instances

Actions

The BDC is a go-between between external data and various parts and tools in SharePoint;the metadata (Data Source Profile) stored in the BDC provides the map for both ends. As Imentioned, the data source for the BDC can be either a web service or a database. Data queriesare real time and are used by web parts, Data Views, and any custom applications to pull indata for display. Lists, User Profiles, and Search pull data from the data source and store itin SharePoint directly. This Data View and pull is pretty much one way; the BDC is nottransaction based and cant do embedded transformations or anything like that. The best wayto look at it is as something that is either used to run a query to return data real time or thatpulls data in periodically (directly into lists, as mapped to User Profiles, and into the searchindex). The basic architecture is as shown in Web 1-1.

WEB 1-1 Business Data Catalog components


6/82


Another way of looking at the BDC is to realize that it doesnt really deal with dataitself. Instead, it puts a face on it (like a SharePoint List) and makes it available to integrateinto SharePoint, both for direct data display and for use as Content Types in lists andlibraries. At the same time, it exposes it for you to use in Features, web parts, and otherapplications:

Data ProfilesThe core of the BDC is the data definitions or Data Profiles; a good analogy is to think ofData Profiles as Features for data. These definitions are called a Line of Business Applicationor LobSystem in BDC terms, and they provide the following:

Type of data source (database or web service)

How to connect to it (including passing authentication)

The operations (methods or actions) it supports

What it will return for data (including the format of that data)

The idea behind a Line of Business Application (LobSystem) is that an external datasource most likely represents a Line of Business System in your enterprise, for example, inyour CRM system or your HR system. Of course, the LobSystem name is just a name; theLobSystem can be anything from the current currency conversion rate provided by a webservice to a lookup of available meeting rooms. The data definition XML files come in theform of a single file, or they can be broken up into a Model and one or more Resource files:


7/82


The Model file defines the LOB itself, including the name of the LOB and anyattributes (like Access Control List information) that go with it.

The Properties Resource file defines an LOB Instance and includes the LOBconnection and Entities (items). Entities also include the Methods (actions) that

can be performed on that data. The Permissions Resource file sets the Access Control List (ACL) rights and

permissions on the connection, entities, and methods.

The Localized Display Names Resource file defines localized names for entities(like Content Types themselves), which provides ways to label data by use,language, and so on.

This file or file(s) are created once and then loaded into the BDC where they areavailable across all sites associated with a particular Shared Service Provider (SSP). AsI mentioned, the Model and Resources can all be defined in the same file; the reasonfor using separate files is to manage settings without affecting the LOB Instance.Additional Resource files can be loaded as needed to add new localized names and/ormodify existing settings without having to reload the LOB from scratch. These files(specifically the Model file) make up the metadata that describes the data source in detail,and it has a dual purpose; it not only describes the data, but also is used by the UI to createthe Content Types:

System This represents a data source, either a database or a web service, anddefines

Name This defines the name of the Line of Business System. This is the friendlyname that appears in the User Interface (typically something like Customers,Accounts, and so on).

Type This defines this data source type, either database or web service.

Version This is a fully qualified version number (i.e., 1.0.0.0).

Entities These are the things the data source represents, such as Accounts.

Methods These are operations that can be performed on an Entity.

Method Instances These are specific operations within a Method, and theyinclude:

Finder This returns an entire list (i.e., SELECT *).

SpecificFinder This returns a specific item (i.e., SELECT * WHERE).

IDEnumerator This returns a list of item keys (like finder but with only oneelement).

Actions These are specific operations that the user can perform; a default is ViewProfile, which allows viewing a specific item; other actions can be easily createdusing InfoPath and allow updating data back to the backend system.

Associations These describe relationships between Entities (i.e., Customer toAccount).


8/82


Profile PagesProfile Pages provide a display of a single BDC data source item and are made availableautomatically when a definition is loaded. These provide an item-like view similar to aSharePoint list item; it is also used to view individual items returned by Search. The default

Profile Page provides a very basic line-item view of the data using two of the BDC WebParts: the Business Data Item Builder and the Business Data Item Web Parts. Profile Pagesare expected to be customized (adding more parts, styles, and so on) as you can certainlysee that the default view is pretty bland.

BDC Data View Web PartsBDC Data View Web Parts allow for creating simple to complex application-level functionalityusing BDC data sources and are used in the Profile Pages. Each of the parts provide differentways to view the data, and using web part connections, the various web parts can be usedto create completely interactive data views and joins. Business Data Web Parts include:

Business Data Actions This displays a list of actions from the BDC.

Business Data Item This displays a single item from a data source in the BDC. Business Data Item Builder This creates a business data item from parameters in

the query string and then communicates them to other parts (this is a default parton the Business Data Profile pages).

Business Data List This displays a list of items from a BDC Data Source.

Business Data Related List This displays a list of items related to one or moreparent items from a BDC Data Source.

Metadata (Content Types)All BDC data definitions (that return data) become SharePoint Content Types. Like any otherContent Type, they can be used within lists, to define documents, and so on, except that thedefinition is defined using the data definition files (and not modifiable via the User Interface).

Getting Started with the BDCFor users, getting started with the Business Data Catalog begins with using the data definitionsloaded into SharePoint; for developers and administrators, it begins with making thosedefinitions. This creates a bit of a dilemma, because while it would be customary to get rightinto using the BDC features, there are no data definitions defined in the BDC by default, sothere is nothing to work with yet.

Since there is a basic flow to creating and using Business Data Catalog Definitions, Imgoing to follow the complete life cycle starting from scratchfirst covering the development

side, and then covering the actual use on the user side (if you never intend to build a definition,you can skip ahead, though I suggest you review the basic steps so you know what goes intothem). The full life cycle (as defined by Microsoft) for the BDC is

1. Analyst defines business requirements. What data is wanted; similar to defining a report.

2. IT writes and tests the application definition. This is building the data definition andmetadata XML file.

3. Application is uploaded to the BDC in Shared Services. This is done by an administratorin SharePoint, and it loads (and compiles) the BDC definition into SharePoint andcreates the Content Types.


9/82


4. Analyst can build Solutions using the BDC Features created. This is done byend users.

From a best practice point of view, it would be great if you could follow this flow.However, knowing real life, youll probably find that defining the data, as well as creating

and loading the definition is usually done by the developer assigned to the task. End userswill only deal with the BDC Web Parts and Content Types. Regardless of who chooses thedata, the actual work in the BDC begins with the data definition of some data source. This iseither a database or a web service you create, is already part of a Line of Business System, isa subscribed service, and so on. From there, the flow to create the definition is as follows:

1. Define how to connect to the data source (connection string or authenticationmethod).

2. Map the fields and data types that will be returned by the data source.

3. Build the definition file(s).

4. Load the definition file(s) into the BDC.

5. Update the Profile Page for the data source (optional).

The previous steps are pretty much done only once and while there is no automatedtool for the process (as you will learn later in the chapter) there are ways to accomplishmuch of it programmatically, using the SharePoint Object Model. From the usersperspective, the BDC is based on what has been loaded. When the previous steps havebeen completed for a specific data source, it immediately becomes available for users touse with BDC Web Parts for viewing data and integrating the BDC Content Type in listsand libraries.

Creating the Data

Before you can build a data definition, you need to know what data you want and whateverrelational associations you want to make. This, of course, comes directly from the datasource, whether its a database or a web service. To demonstrate this process, youll do bothhere, but for now, you need to create a few tables in SQL Server (or your choice of database)and add some data so you have something to work with.

Im going to keep this very simple by defining just the columns needed to view somedata and link them together with a common key. If you want to use other data, you cansimply skip this step. But, to follow my example, youll need to select tables that create aparent/child (or master/detail) relationship and a third that provides a simple join.

Creating Tables in SQLTo create the data, youll need to select or create the database tables needed. For this example,

you are creating a new database called Accounts_DB and defining the tables. To do this, youmust log in to the SQL Server system and open up the SQL Server Management Studio. In theObject Explorer, expand databases and select the database you will be working with. Imgoing to assume you know how to create a table using either the designer or by simplyentering in SQL statements using a query window. The three tables to create are as follows:

Customer Accounts These are customer accounts with a parent customer ID.

Account Representatives These are the people assigned to customer accounts.

Orders These are orders placed by customer accounts.


10/82


To set up a working scenario, assume that these tables represent some data in a companythat sells products to restaurant chains. The business basis for the tables is as follows:

Each restaurant chain they supply to has a unique Customer Account ID for thecompany.

Each location has its own unique Account IDs.

Orders are processed based on the Account ID for the particular location.

Each Account has a single account representative assigned to them.

Customer Accounts Table

CREATE TABLE [dbo].[CustomerAccounts]([AccountID] [int] NOT NULL,[CustomerAccountID] [int] NULL,[AccountName] [nvarchar](50) NULL,[AccountCity] [nvarchar](50) NULL,

CONSTRAINT [PK_CustomerAccounts] PRIMARY KEY CLUSTERED(

[AccountID] ASC) ON [PRIMARY]

) ON [PRIMARY]

Sample data:

AccountID CustomerAccountID AccountName AccountCity

1 1 Jesses #1 Charlotte

2 1 Jesses #2 Mooresville

3 1 Jesses #3 Concord

4 1 Jesses #4 Matthews

5 2 Ham N Egger #1 Wilmington

6 2 Ham N Egger #2 New Hope

7 2 Ham N Egger #3 South Port

Account Representative Table

CREATE TABLE [dbo].[AccountReps]([AcctRepID] [int] NOT NULL,[AccountID] [int] NOT NULL,

[AcctRepFName] [nvarchar](20) NULL,[AcctRepLName] [nvarchar](20) NULL,[AcctRepEmail] [nvarchar](50) NULL,

CONSTRAINT [PK_AccountReps] PRIMARY KEY CLUSTERED(

[AcctRepID] ASC) ON [PRIMARY]

) ON [PRIMARY]


11/82


Sample data:

AcctRepID AccountID AcctRepFName AcctRepLName AcctRepEmail

1 1 Bob Smith [email protected]

2 2 Mary Perkins [email protected]

3 5 Rick Allen [email protected]

Order Master Table

CREATE TABLE [dbo].[OrderMaster]([OrderID] [int] NOT NULL,[AccountID] [int] NOT NULL,[LineItems] [int] NULL,[OrderName] [nvarchar](50) NULL,[OrderDate] [datetime] NULL,

CONSTRAINT [PK_OrderMaster] PRIMARY KEY CLUSTERED

([OrderID] ASC

) ON [PRIMARY]) ON [PRIMARY]

Sample data:

OrderID AccountID LineItems OrderName OrderDate

1001 1 2 Restock Order 3/15/2007 12:00:00 AM

1002 1 5 Seasonal Promo 4/1/2007 12:00:00 AM

1003 2 1 HRApplications 4/10/2007 12:00:00 AM

To follow this example, you must have at least one Customer Account with two Accountsdefined (rows), one Order tied to an AccountID, and at least one account representative tied tothe CustomerAccountID. You can create as much data as you want here if you decide not touse these tables, but be aware that I will be referring to this structure in the following examples.

Defining the Data for the BDCOnce a data source has been established, the next step is to define the data definition XMLfile(s) to load into the BDC. I will cover everything about the LobSystem (data) definitionhere, but the examples wont use every option; I think once you get the gist of how thingswork, youll have no problem moving on to much more complicated functions.

Now this is where I unfortunately have to break the no code needed myth. Whileusing the LobSystem definitions in the User Interface requires no code, the definitionsthemselves have to be coded in XML. So yes, the BDC does require development of theXML file(s). Writing data (LobSystem) definitions is not too difficult, but unfortunately, itmust be done by hand, which is very time-consuming and tedious. Oddly enough, eventhough Microsoft knows this, it has stated that they have no intention of building a tool forcreating these files. They do, however, throw you a few bones by providing good examplesin the SDK, and the BDC Administration API can be used to semi-automate the process.


12/82


There are some third-party tools now available that do get most of the job done, and theysave a lot of typing. One of these tools is the CodePlex DB Metadata Generator available fordownload at http://www.codeplex.com/DBMetadataGenerator/Wiki/View.aspx. This toolworks quite well, and the source code is available, which will provide much better insight tothe Administration Object Model than I could possibly provide here. One note if you use this

tool: be aware that tables must have primary indexes for this tool to correctly generate theSpecificFinder Method (explained next). Another tool is available (for development and forpurchase) at http://www.bdcmetaman.com/default.aspx. This is a bit more advanced, butat $1200 retail, it seems more targeted at consulting groups and solutions builders and islikely not for the average company (the extra effort to build it manually is minimal).

To define the files, lets look at the structure of the LobSystem (data) definition. The ModelFile defines the data and is the actual metadata reference SharePoint storesall informationcan be specified in this one file. Resource files are used to merge with the metadata to definelocalized names, set permissions or properties, or to change something like a connectionstring. The format for these files is defined by the bdcmetadata.xsd and bdcmetadataresource.xsd files, which are located in \Program Files\Microsoft Office Servers\12.0\Bin. The

outline structure for the file in XML (basically the same as the object model) is as follows:

LobSystem This defines the Line of Business System that the data

source represents; there is only one of these per file, though

conceptually, Microsoft may enable use of more than one.

LobSystemInstance This defines the Instance for this LOB (only one is permitted).

AccessControlList This defines the rights to access this LOB instance.

Entity This defines the data elements this source represents.

AccessControlList This defines the rights to access the Entity.

LocalizedDisplayNames

This defines a local name for the Entity; used as a friendly name

or for language localization.Identifier This defines the indexer or primary key for the data; this is

required to enable search for this data source.

Method This defines a Method (action) that can be per formed, such as

returning an item, returning all items, return the index (for search)

and so on.

FilterDescription This defines filters of what data to return.

Parameter This defines passable parameters.

TypeDescriptor This defines the type of parameter.

DefaultValue This defines the parameter default.

MethodInstance This defines one of the Method Instance Functions.*

Action This defines Actions (such as reload data).

ActionParameter This defines any parameters needed for the Action.

Association This creates a relational association between Entities.

AccessControlList This defines the rights to access this Association.


13/82


LocalizedDisplayNames This defines a local name for the Association.

SourceEntity This defines the Source Entity Reference.

DestinationEntity This defines the Destination Entity Reference.

* Method Instance Functions are used to perform certain functions and include FinderInstance (for

returning all items), SpecificFinderInstance (for returning a single item), IDEnumerator, and

IDEnumeratorInstance, which are defined to enable search.

To make this view a little clearer, I included the Access Control List and LocalizedDisplay Names entries so you can see that they can be applied at all levels. These settingscan be included in a single file (either a Model or combined file) or separated out asResource files (typical for localized names). There is little difference in the format file types,but their schemas are different; Model files use bdcmetadata.xsd schema and Resource filesuse bdcmetadataresource.xsd. In practice, though, the difference is that the Model is used to

create a new version of a LobSystem. Resource files are merged in with the existingdefinition to add, remove, or modify security, properties, and localized names.The main reason for the different files is that you can create one LobSystem definition

and use it on multiple SSPs. The security, properties available, and localized names canthen be merged separately, providing individual SSPs with custom settings (while notchanging the core). Even if multiple SSPs are not used, it is a best practice to keep Modeland Resource files separate since they each have different purposes, and it can keep thedefinitions a lot cleaner and easier to read. As well, resource files can also be used to modifysingle items in the existing definition (like a connection string) without having to reloadeverything from scratch.

Constructing the Model File and Base Methods

The Model file defines the Line of Business Application for the Business Data Catalog anddefines the connection to the data source. The bare bones definition simply defines thesystem (connection information, security, and so on) not needed:

As you can see, this file references the BDC Namespace and defines the LobSystem andLobSystem Instance. Note that Microsofts design premise here is that for one Line ofBusiness System there can be multiple LOBSystemInstances, with each instance defining adifferent data source in the LobSystem. However, for at least this release, only one instanceis supported.


14/82


How you begin building this file is up to you. Some people like to use SharePointDesigner and others use XML Editor, but my preference is Visual Studio because referencingthe Namespace Automatic Tag Creation is what I will use in this example:

1. Open Visual Studio and create a new Empty Project.

2. When the project opens, the first thing you want to do is add the XSD files to theproject, which provides code sense when working with the XML code. Right-clickon the project name in the Solution Explorer and then select Add | Existing Item.

3. When the file dialog appears, navigate to where the Microsoft Office Servers binfolder is installed (in this example, its the default location c:\Program Files\Microsoft Office Servers\12.0\bin).

4. Select the two XSD files (bdcmetadata.xsd and bdcmetadataresource.xsd) andclick Add:

5. Next, from the toolbar, select File | New |File (or press CTRL-N), select an XML filein the dialog box, and then click Open to open it in the editor:


15/82


6. To get started, you specify the XML namespace and type of LobSystem. The firsttwo lines of the file look like this (notice that the XML line includesstandalone=yes):

7. Everything shown is the same regardless of the LOB. The exception here are thethree attributes:

Name This is the name for this LobSystem (as it will appear in the BDC).

Version This is set to the current version of this LobSystem.

Type This is set to either database or web service.

NOTENOTE This should all be on one line. I have broken itdown for the sake of documentation purposes only.Once you have added this line, you now get codesense:


16/82


8. The next section defines the LobSystem Properties. At the top of this section, youwill want to set the WildCard Character used for this LOB (similar to SQL, as for avalue like %somevalue% ). Add this section as shown:

NOTENOTE The previous step applies to filters that you will add later. I mention it here because this is thecorrect placement of the XML (at the top of the definition). If you do not use filters, this code hasno effect so there is no harm in adding it.

9. The next section is where you can specify specific access control rights. The codelooks like this:

10. The previous code grants Edit, Execute, SetPermissions, and SelectableInClients (AllRights) to the account MSPSD\SPSServices. Note that you do not have to add thiscode. I am showing this for demonstration purposes; the BDC permissions can beset via the SharePoint User Interface so you dont need to add it here. (For reference,ACLs like the previous one allow you to set specific rights on individual items,even Associations). The next section defines the LobSystem Instance. The code forthis is as follows:

PassThrough

SqlServer

MOSSSPSDEV

Account_DB


17/82


SSPI

false

As you can see, this defines the type of connection, the database server, thedatabase name, and so on. As I mentioned previously, the idea is that multipleLobSystemInstances can be definedhowever, at this time only one is supported.Note that connections here support multiple types; Pass Through is the default,but it can support Revert To Self and even use SSO. For example, to connect to anAccess Database, the connection is a bit different:

RevertToSelf

Odbc

Data Source=''; Driver={Microsoft Access Driver (*.mdb, *.accdb)};

DBQ=\\hostserver\fileshare\ActualDBName.accdb;Trusted_Connection=true;

False

If you are using Single Sign-On (for example, using a SQL Login instead of adomain login), you would define the SSO Application and then set the connectionproperties similar to this:

RdbCredentials

SqlServer

Server Name (hosting SQL)

Database Name

false

true

SSO App Name

Microsoft.SharePoint.Portal.SingleSignon.SpsSsoProvider,

Microsoft.SharePoint.Portal.SingleSignon, Version=12.0.0.0,

Culture=neutral, PublicKeyToken=71e9bce111e9429c


18/82


11. Next, you need to define Entities; that is, whats in this service or database. Then youdefine Methods for those Entities. This is not really complicated; it just says that for aMethod, such as FindAccounts, shown later, that the fields returned will be as defined.The Entity entry defines the name of the Entity. In this example, that happens to beCustomerAccount (Customer Account = a real Entity in the business). This also

includes an optional attribute called EstimatedInstanceCount (this is not in the Xsd),which specifies the maximum number of items this particular data source can return.Below that youll see the Identifier defined as the AccountID. As you might guess, thisrepresents a primary key for the data source (note that this should actually be theprimary key if this is a database):

12. An Entity cant do anything by itself; it must have Methods defined to act on it. The

first Method is called the Finder Method, which is used to return all items in theEntity. This defines the command type and the actual command to return the data;for a database, this is as shown in the two properties (while Im indicating a singleSQL Select statement here, this can be any kind of call, Stored Procedure, or similar):

Text

SELECT * FROM CustomerAccounts

13. Now that the Method is defined, the BDC needs to know exactly what is returned bythis Method. These are the actual fields (columns) that the data source returns; theyare listed as Parameters and are mapped to the same definitions as in the database:


19/82


14. Next, the MethodInstances (actual actions) of this Method must be defined; as theFinder Method Instance, this action is intended to return all items (up the maxcount if one was specified) as a list:

15. The next Method that is defined is the SpecificFinder Method. The intent of thisone is to return a single row or item based on something passed to it (note that thisMethod must be defined for Profile Pages in the BDC to work). This is pretty muchthe same as the Finder Method, except a Parameter is added and the SQL Statement

updated with a Where clause:

Text

SELECT * FROM Cus-

tomerAccounts WHERE AccountID = @AccountID


20/82


16. Last, the MethodInstances (actual actions) for the Specific Finder Method must bespecified:

17. Be sure to close out XML tags on this file:

18. Save this file as LOBCustomerAccounts_model.XML. At this point, you are ready

to load the file into the BDC; if there are any problems with the file definition, thisis where you will find out.


21/82


While you only need to set up the methods for the ones you want, I suggest a bestpractice for setting up all of them, including Finder, SpecificFinder, and IDEnumerator(shown later in the chapter). You might not need it today, but there is no sense in restrictingyourself (and having to add XML) later. Also as a technical note, if the underlying dataschema changes, you may need to modify the data definition metadata to reflect the change,

and it might also break web parts that are dependent on the data returned. Adding acolumn is usually not an issue, but a rename or drop of a column means a do-over.

Loading the Model FileOnce the Model file has been created, it can be loaded directly into the Business DataCatalog via the Shared Services Provider Administration Site. The BDC loader parses theXML definition, which, if successful, automatically creates the Content Type and creates aProfile Page (the Data View Page as mentioned previously, Ill cover this in detail later on inthe chapter). To load the file, do the following:

1. Open SharePoint 3.0 Central Administration.

2. On the left-hand navigation pane, click the name of the Shared Services Provider toopen the Administration Site (for example, SharedServices1). When the AdministrationPage opens, under the Business Data Catalog Group, click Import ApplicationDefinition:


22/82


3. Use the Browse button to find file to import:

4. Notice that you have the option of loading a Model or a Resource file. If you load a

Model file, it assumes a re-create of the definition from scratch (overlay if you will)as a new version. Resource files are uploaded to make changes to permissions,localization, and so on. Also notice that if this file does include resource definitionsthat you can choose which ones you want to load. Click on the Import button tostart the import. During the Import, the BDC loader will parse the XML file and tryto load the definition. If theres any problem, it will tell you exactly what line theproblem occurred on. Two common issues are not defining a SpecificFinder methodthat will warn that a profile page for the data source was not created (it has no keyto use) and errors in the XML syntax (bad spelling, incorrect name, and so on).Assuming the import is successful, click the OK button to complete the load. Thisbrings you to the BDC Definition Page, which shows what Entities are loaded forthis LobSystem:


23/82


5. To view what the Entity looks like in the BDC, click on the name to open the view:


24/82


6. As you can see, this tells you pretty much everything about this particular datasource, including whether it is crawlable by Search, the Parameters (fields/columns) that are included in it, any Associations and Actions, and so on. Noticethat there is a link under the Actions sectionView Profile. Click this to open theparticular Action settings (this is the same as if you had added one manually):

7. The URL specified here points to the actualpage that is opened when this action is used(you can also specify that it open in a newpage). You can add items here directly tofurther qualify the action with additionalparameters. For example, adding a newParameter allows selecting additional

Parameter fields:

8. You dont want to make any changes here, but you should copy the URL shown toview the profile (below). Click the Cancel button to return. Notice that on this page(as well as most others in the BDC), you can also manage permissions. If you clickthe Manage Permissions link, this is displayed:


25/82


Constructing the Permissions FileAs I mentioned previously, permissions for data sources in the BDC can be manageddirectly through the UI. However, there may be times when you need a granular approachto items, such as preventing a specific type of action. Permissions are loaded separately as aResource file and are in the same format as the Model file. However, instead of settingParameters, it sets the Access Control List Settings for each individual part of the

LobSystem, and any number of users or groups can be assigned rights (this example onlyshows one). The differences, as you will see, are that only the LobSystem Name is used (noType or Version specified), that it uses the BDCMetaDataResource.xsd, and that only theACLs are defined:


26/82



27/82


Importing the Permissions FileImporting the Permissions Resource file is done exactly as the Model file, except instead ofModel, Resource is checked, and only the type of resource is selected:


28/82


Constructing the Localization FileThe Localization Resource file is used to define Localized Display Names that are used forEntities and properties in the LobSystem. This allows any number of names to be associatedto a specific language, thus localizing the data definition names that users see in the UserInterface (it does not affect the underlying definition or name). The Localization file worksjust like the Permissions file and is uploaded as a Resource. In the example shown next,note where the LocalizedDisplayNames appear. As you can see, they define a specificlanguage ID (LCID) and the name (1033 = US English, 2072 = Romanian/Moldovan):


29/82


LCID="2072">Cont Nume

Account CityCont Oras

ID

ID

Customer Account ID

Client Cont ID

Name

Nume


30/82


LCID="1033">Account City

Cont Oras

Notice the LocalizedName definition for the Entity is simply an element; in theTypeDescriptors, it must be within the tag. Also, for a list of Language Code Identifiers(LCIDs), you can simply search the Web or the Microsoft site.

Importing the Localization File

Importing the Localization Resource file is done exactly as the Permissions file; instead ofModel being checked, Resource and Localization File are selected.

Constructing the Properties FileThe Properties Resource file defines only the properties in the LobSystem. While usuallydefined in the Model file as they were previously, the Properties file enables changing anyof the properties without having to reload the LobSystem. An example of this file looks likethis (notice that like the other Resource files, this one uses the BDCMetadataResource.xsdand only specifies the LobSystem Name without the type or version):

%


31/82


Type="System.String">MOSSSPSDEVAccounts_DBSSPI

View Profile

Text

SELECT * FROM CustomerAccounts

Text


32/82


Type="System.String">SELECT * FROM CustomerAccountsWHERE AccountID = @AccountID

Importing the Properties FileImporting the Properties Resource file is done exactly as the Permissions file. Instead ofModel being checked, Resource and Properties File are selected.

IdEnumerator Method (Enabling Search)

The IdEnumerator Method provides a way to retrieve all of the item keys (in this runningexample, the AccountID). This does two things: first, it returns a simple list of IDs, whichare handy for cross referencing lists, using the data for drop-downs, and so on; second, itmakes the data provided by this LobSystem crawlable because the Index Engine has a wayto tie items to IDs that it can index. This method defines the Enumerated Item and a Methodinstance defined as an IdEnumerator Type (this code goes in-between the and tags in the Entityin this example, CustomerAccount):


33/82


FiltersFilters are defined as a part of methods. They are used to control ways to handle the data thatFinders return as well as extend the Methods capabilities by providing user-settableparameters that are used to filter data returned. Filters themselves are footnotes or addendumsto Method input parameters (a tag if you will) that can be set by users or preset using SystemFilters. User-settable parameters can be any item within the data source; system filters provideprefilled parameters such as the current user (and cannot be overridden by the user).

NOTENOTE The Wildcard character defined at the top of the LobSystem shown previously is used byfilters as defined here.

There are several kinds of filter types that define how to filter the data, which allows

creation of like comparisons and use of wildcards as follows:

Wildcard This provides a like condition as in WHERE FName LIKE %Bob%; thisprovides conditions of Starts With and Contains.

Comparison This provides a WHERE comparison, such as WHERE Region=Eastern.

Limit This sets a limit on how many items are returned by the service or database;this basically is a way to prevent users from pulling too much data at one time.

UserContext This limits the data returned by filtering it down to what the currentuser actually has access privilege to (similar to how the Search service works).

Username Passes the SSO username as part of the filtering (used for passingusername to the backend data source).

Password This is the same as Username, but for the SSO Password.

UserProfile This creates a filter based on User Profile properties that can be selected.

SSOTicket This passes the SSO ticket as a parameter (used for SSO handling anduseful when multiple LobSystems use the same authentication).

LastIdSeen This passes the last IDEnumerator (covered later) seen by the user,allowing the data source to return data from a starting point (think paging of data).


34/82


Each of these can include a few optional properties:

UsedForDisambiguation If true, this particular filter is used to generate a list ofpossible matches (kind of like IDEnumerator).

CaseSensitive If true, the filter is case sensitive (typical for passwords).

IsDefault If true indicates that this is the default filter.

The purpose of using filters is to provide a dynamic way of selecting data based ondifferent criteriaeven without having to create a new MethodInstance for each. Filtersare part of the Method definition and are added just after the tag and before the tag (outside of the ACL entry if there is one). The Parameter needed for thefilter (what is passed when the filter is used) is added within the tag. Asshown next, this defines a new Wildcard Filter for City and defines a new (inbound)parameter for it:

...

...

AssociationsAssociations create relationships between Entities similar to a Join in SQL. An Associationhas one or more Source Entities and one Destination Entity tied together by a common key(in this example, AccountID from the CustomerAccounts table). There are two parts to an

Association: first, another Entity must be defined, for the LobSystem will represent theassociated Entity (in other words, what its being linked with), and second is the definitionof the Association between the Entities.

In this example, individual accounts each have an associated Account Representative;the join or common key is the Account ID that appears in both tables. The first step is todefine a new Entity in the LobSystem for representing the Account Representative data andto set up an Identifier (a key) for the Account ID (note that the actual key for this table is theAcctRepID, and that this definition overrides that):

Text


35/82


SELECT [AcctRepID], [AccountID], [CustomerAccountID],[AcctRepFName],

[AcctRepLName],

[AcctRepEmail] FROM [AccountReps]

WHERE [AccountID] = @AccountID

NOTENOTE If using Localization, Local Names must be defined for this Entity.Notice that Im also following a best practice here, and Im not using SELECT * and

opting to select each individual column. This guarantees that as long as fields are notdeleted or types changed, the definition will continue to work and that columns can beadded and so on, without causing any problems here (not true using SELECT *). Once theEntity has been defined, an Association must be created; this is done at the same level as


36/82


Entities (which is logical since it joins entities in some manner) within the LobSystemdefinition. In this example, Im joining the Customer Account Entities individual AccountID to the Account Representative Entity Account ID:

Adding Additional AssociationsWhile all associations are optional, depending on the type of item (Entity), you may wantto define several. For example, while the previous Association related the Account to theAccount Rep, you also have another data item, Orders, which is part of the main definition.To access Order information, you could create a definition for it and then link the two in theUser Interface. Or, as I will show next, simply add this relationship to the Model. Heres anexample of the full entity for Orders By Account, which includes the complete settings forPermissions, Properties, and Localized names (be sure this is between the and tag and does not overlap with any other Entity):

View Profile

Text


37/82


Type="System.String">SELECT [OrderID],[AccountID],[LineItems],[OrderName],[OrderDate]

FROM [OrderMaster] WHERE [AccountID] = @AccountID

ID

ID

Account ID

Cont ID

Item Count

Numarul articole

Order Name


38/82


LCID="2072">Comand Nume

Order DateComand Data

As you can see, this is the full definition, including permissions and so on. You can alsosee that the Localization has been setin this case, English and Romanian. Methods definedfor this entity indicate what can be done with it. In this example, a method to return Ordersrelated to an Account (again using best practices by specifying exactly which fields are to bereturned instead of using SELECT *). Once the Entity itself has been added, the Associationmust be added as well:


39/82


You can add as many associations as needed, simply by defining an Entity and an

Association as shown previously; using this, you can completely emulate the relationalstructure of any data source. Also remember that the granular level of security can limitaccess to associations above and beyond the data source and SharePoint. For example, youmay have an Employee Information Entity; Association to something like Salary can berestricted simply by setting the right on the Association itself.

Using the Profile View PageTo view the Profile Page of the item, you need the URL for the View Profile Action (shownpreviously). If you did not get this URL, you need to go to the SSP Administration page,click View Entities under the Business Data Catalog Group, and then in Business Data

Catalog Applications list, click the name of the LobSystem to view it. Next, click on the Entityto view (in the previous example, CustomerAccount); when the Entity is shown, the ViewProfile Action is shown alongwith a URL. Copy this URL,open a new browser window,and paste in the link, butchange the place holder(AccountID={0}) with a realID number (AccountID=1).This displays the single itemdisplay as shown.

Of note here is that this is a Web Part Page and the first introduction to the web parts

setup for the BDC. To see this, click Site Actions | Edit page:


40/82


As you can see, there are two web parts here: the first is the Business Data Item BuilderWeb Part. This particular part reads data from the URL and can pass it on to any other webpart via connections. The other part is the Business Data Item Web Part, which displays asimple list of a data record (based on the one passed to it by the Business Data Item BuilderPart). You can see the connection here:

Be aware that this data is live and is refreshed directly from the data source each timethe page is shownnothing is actually stored in SharePoint for this. This Profile Page canbe considered the Home Page (and Search View Page) for the data and can obviously belinked to either, through regular links or as done programmatically. Although viewing asingle record is useful, this page can also be enhanced using other web parts to show someadditional information. For example, you have an Association (relationship) defined for thisLobSystem between the Customer Account (as shown) and the Account Representatives.To show this relationship (after all, its always handy to know the Account Representativewhen looking at the account), do the following:

1. From the Profile Page, click Add a Web Part in any zone.

2. When the Add Web Part dialog appears,find the Business Data Related List WebPart, click the check box, and then theAdd button to add it to the page. This

will show that it is not yet configured.3. Click the Open the Tool Pane link to open

the tool pane:


41/82


4. Click the book icon to view the list of Associations available:

5. Obviously, only one has been defined in this particular

SSP. Click to select it and then click OK. On return tothe page, the selected item and the Relationship drop-down are filled with all available Associations (in thiscase only one).

6. Click the Apply and OK buttons to close out the toolpane. The part is displayed with a message that it hasno connection (and wants one to supply CustomerAccount).

7. The connection value this particular relationshipneeds is the Account ID and both of the preexistingweb parts supply this. However, in this case, it is best

to use the Customer Account. The connection can bemade either way, from the Customer Account displayor from the Business Data Related List just created.Using the Edit menu, select Connections | Get RelatedItem From | Customer Account Details as shown:


42/82


8. This will tie the Customer Account Details (specifically the Account ID) to theAccountReps List:

9. This now represents two connections: the Business Data Item Web Part that pullsthe AccountID from the Query String in the URL and passes it to the Customer

Account Details View. This, in turn, passes the AccountID on to the AccountRepslist, which filters to show the account representative for the account shown. Notethat this display isnt necessarily pretty and may not be exactly what you want. Youhave two options here: notice the Edit View link, which allows you to manage howthe view looks:

10. This allows you to customize the view just like any other SharePoint list. Note,however, that the Xsl can also be modified. Use the Edit menu to select ModifyShared Web Part to open the tool pane, scroll down, and then click on the XslEditor:


43/82


As you can see, this editor is really a simple text editor and not very conducive toediting. I suggest using Visual Studio or SharePoint Designer, and then cut andpaste here.

11. Now, if you havent noticed, you are well on your way to building an actualapplication. In just a few clicks, this page now represents a view of a customeraccount and the representative who supports the customerall without having tocode anything other than the base definition. Since you added an additionalassociation, you can add that here too. The additional association was Orders ByAccount, which means you can use this to show current orders for a customer on

the profile. To add this, select Site Actions | Edit Page. When the page enters EditMode, click Add Web Part in the middle right zone. When the Add Web Part dialogbox appears, find Business Data Related List and click the check box to select it:


44/82


12. Click the Add button to add it to the page. When the part is first displayed, it detectsthat it is not configured. Click the Open Tool Pane link, and when the tool pane openson the right, click the Book icon to open the Associations Relationship dialog box.When that opens, click the OrdersByAccount Business Data Type, as shown:

13. Click the OK button to return to the page. When the LobSystem information is read,

the Relationship drop-down is automatically set to the first available (in this case,AccountToOrders):

14. Click the OK button to save the settings and return to the page. Next, youll need tocreate a connection between the Customer Account and the Orders display. Click onthe Edit menu in the Customer Account Item, and then select Connections | SendSelected Item To | OrdersByAccount List, as shown:


45/82


15. Once the connection is made, you should see any matching orders displayed.Click Exit Edit Mode to see the end result. This one Profile Page is now a viewof several customer aspects: the customer, any orders, and their accountrepresentative:

As you can see, just by using this simple Profile Page it is now possible to create acomplete view of a business entity. Since this is also the page displayed when a BDC itemis clicked on when found in Search, this can provide a very powerful tool in the enterprise.For example, if a help desk employee was working with a client, a simple search on theclient name returns a link to the Profile Page. Clicking the link, the person now knows all

about that client, all on one page. While this is useful, be aware that this example has onlyscratched the surface of the capabilities available. The real power is that all of the partsshown here (and a few others) can be used to create application-like functionality on pagesanywhere in the site.

ActionsIn addition to using the BDC to view and search data, it can also be used to perform actionsfrom updating data in a backend system, to showing a data entry form, to e-mailing amessage. Actions define the specific options or tasks users can perform using the userinterfaceeither with or on the BDC data. Typical actions might be a direct link to view the

data item (the Profile Page explained later on in the chapter) or to open up an InfoPath formfor users to make updates. This may seem a bit out of order, since Actions are really part ofthe definition. However, though they are defined there, they are not visible until you can seethe Profile Pagethus, the out-of-order sequence with the rest of the options.


46/82


Actions are part of an Entity just like Methods; you can think of Methods as ways to pulland view data and Actions as what you can do once the data is shown. You might havenoticed that you have already defined one:

Notice that this action points to the URL of the Profile Page, passing a single parameter ofAccount ID.

Actions are available whenever you are viewing BDC data and are shown in an Item Listdisplay or when an item is returned in Search. However, any number of actions can becreated, from opening up another form to showing a report. To demonstrate this, navigate toa SharePoint site that is associated with the Shared Services Provider. When the site opens:

1. Click the View All Site Content link.

2. From the All Site Content page, click Create.

3. On the Create Page under the Web Pages Group, click Web Part Page. Name thepage BDCActions, choose any layout, and then click OK to create it.

4. When the page appears, click Add a Web Part in any zone.

5. When the Add a Web Part dialog box appears, scroll down to find Business DataList and click the Add button to add it to the page. Click the Open Tool Pane linkto configure the list part.

6. Under the Business Data Type, click the book icon to browse for the BDCLobSystem.

7. On the Business Data Type Picker dialog box, click the Customer Account BusinessData Type to select it. Then, click the OK button in the tool pane to close it. Onreturn, you should see the List in Query mode, as shown:


47/82


8. If you simply click the Retrieve Data link (in either Display or Edit Mode), all datarecords will be returned. However, as you will notice, this is simply a flat list, and thereare no options on any items. To use actions, the view must be modified. With the partin Edit Mode (as shown previously), click the Edit View link. This will open the EditView Page:

9. Notice that you can set all of the options, including setting the criteria that youwant users to be able to select. If you scroll down to the list of displayed columns,you will notice that there is an option called Title next to each. Selecting this meansthat the Actions menubecomes availableunder that particularfield. For this example,click Title next to

Account Name:10. Scroll to the bottom and

click OK to save the change. When you return to the page, click the Retrieve Data linkagain. This time you will notice that simply moving the mouse over an item (in thiscase, Account Name) will display the drop-down menu of Actions:

11. As you can see, there is only one Action shown, which is the default View ProfileAction.


48/82


Adding an ActionActions are based on anything you can do using a URL link, which includes opening anapplication page, an InfoPath Form, a custom ASPX page, and even sending an e-mail. Thebenefit is that you can utilize the BDC data as parameters when calling these and pass them

as query options in the URL itself. These are called ActionParameters and are pointers tofields in the BDC. Action Options include:

Name This is the name shown in the drop-down menu.

DefaultDisplayName This shows as the tooltip.

Position This is the position in Business Data Item Display (in the drop-down list).

IsOpenedInNewWindow This is set to True or False; when True, the link opens ina new browser window.

IsCached This is set to True or False to indicate whether this option should becached (should usually be true).

ImageURL This specifies the URL for an image to display in the drop-down (notethat the relative URL used by default for the View Profile is located in C:\ProgramFiles\Common Files\Microsoft Shared\web server extensions\12\template\LAYOUTS\1033\IMAGES).

URL This is the actual URL to execute when the option is clicked. Its basically aredirect, so that any valid URL can be used and any number of parameters can beused to fill in URL options and query values.

Action Parameters allow you to reference the BDC data and use it in the action URL:

Name This is the name shown in the drop-down menu.

DefaultDisplayName This shows as the tooltip.

Index This is the index of the parameter (i.e. 0 = {0}).

IsCached This is set to True or False to indicate whether this option should becached (usually true).

As an example, assume you wanted to add two Actions to the Custom Account record:one to notify someone to review the account and another that provides a direct search of theAccount Name using MSN.com. In both cases, instead of the Account ID, which is passed inthe default View Profile Action, youd need to pass the Account Name instead. Both of theseare shown next:


49/82


DefaultDisplayName="Search for Client on MSN"IsOpenedInNewWindow="true"URL="http://search.msn.com/results.aspx?q={0}"ImageURL="/_layouts/1033/images/PGNXTON.GIF" IsCached="true" >

To add these actions, you must edit the Application Definition XML file, locate the Entity(in this case Customer Accounts), and then add these actions in between the and tags. To load the Definition, click View Applicationsfrom the Shared ServicesProvider Administration Page. Mouse over the application name and, from the drop-downmenu, select Delete Application. When complete, click Import Application, navigate to findthe definition file, and import it. Assuming you have no issues with loading, you can nowsee the affect of the Actions. If you navigate to the Profile Page for an item, youll see that thenew Actions are now available:

These Actions are also available from other displays; if you navigate back to the custompage created previously, you can see that the same options are now available there (this istrue when items are displayed in Search as well):


50/82


Setting the Default ActionSetting the default action is done in the Entity Properties section. By default, this is set to theView Profile Action as shown:

View Profile

To change this to the Search Action from the previous example, edit the ApplicationDefinition file, find the Entity, and then the Properties section. Change the name asindicated (this name must match the name used to define the Action):

Search MSN

NOTENOTE While this does set the default, it does not affect the Business Data List Display or the ProfileDisplay of the item.

After making this change to the definition file, it must be uploaded. From the SharedServices Provider Administration Page, click View Applications. Mouse over the application

name and from the drop-down, select Delete Application. When its complete, click ImportApplication, and then navigate to find the definition file and import it.

Using the BDC to Update DataActions can be used for a variety of purposes, including linking to different views anddoing things like sending e-mails. But, they can also be used two-way, in terms of writinginformation back to the original data source (referred to as Write Back). However, before youget too excited I do need to clarify this. The BDC itself is not capable of updating a backenddata source, but it is capable of calling something that does. Examples of this might be tocall a backend web application passing something in the query string and another is to openan InfoPath form that handles the business logic and validation for the update. The point is,

something else is handling the actual update, not the BDC.While this may sound kind of limiting, there are good reasons for this. For one, list data

being updated back to an external data source would likely need some kind of filtering andbusiness logic; this would be pretty near impossible to add on a field-by-field basis. Also, itis never a good idea for a down-line system to be updating the system of record withoutsome kind of workflow and approval.

If you really want some kind of direct update capability, you do have the option ofusing SharePoint Designer to create a Data View. Data Views have update capability thatcan be used to post back directly to the source. However, be forewarned that it can be adangerous practice; any update to an external system, particularly outside of the applicationthat controls it, can have very bad results.

Using the BDC Web PartsFinally, you get to the no code part. Once a complete Application Definition is loaded intothe BDC, it is time to begin using the BDC Web Parts to create Application Views. This ismuch easier than it sounds; in fact, if youve followed the previous examples, youll know


51/82


this was already done twice. First, when setting up the Profile Page with related lists, fourdifferent web parts leveraged the Associations to create a complete Customer View. Inadding actions, a Custom Web Part Page was created that contained a Business Data Listlisting the Customer Accounts.

The best way to explore each of these parts is simply by example. If you followed the

example and already have a Custom Web Part Page created, begin there. If not, you mustnavigate to a SharePoint site that is associated to the Shared Services Provider where theApplication is defined. Select View All Site Content | Create | Web Part Page to create anew page (store it in the local Document Library).

Business Data Item Builder Web PartThis is a custom part used to pull query information directly from the URL; this is onlyuseful on the Profile Page for data items and cannot be used elsewhere.

Business Data Item Web PartThis web part displays a single item from a BDC data source and is the same one used in

the default Profile Page.

1. Add this web part to the page by selecting Site Actions | Edit Page and thenclicking on Add a Web Part in Any Zone. When the Add a Web Part dialog appears,scroll to find the Business Data Item Web Part, click to select it, and then click theAdd button. When this part is first displayed it is not configured, so it will displayan Open Tool Pane link. Click this to configure the part.

2. When the tool pane first opens, you can see that no data source has been selected:


52/82


3. Click the book icon to browse the Catalog for Entities. Click the name of the Entityto select it (Customer Account is selected here, as shown):

4. Click OK to save the options. Next, click the browse icon for items. This opens upthe Query Selection so that you can choose a specific item:

5. Click OK to save the settings. In the background (if you havent guessed), this setsup a query so that each time this is displayed, the correct account is retrieved. Next,you can choose which fields to display by clicking the Fields button:

6. Fields checked will be shown and you can set the order (left to right) in how theywill be displayed. Click OK to save any changes. Next, you can set the Actionsoptions by clicking the Actions button. That is, of the Actions defined for the datasource, what this particular view is going to support:


53/82


Notice that once again, you can set the order here (overriding the default set by thedefinition); click OK to save any changes. The next setting indicates whether you want newActions (if made available) to be automatically included here. If this is disabled, adding anew Action must be done manually. Remaining settings have to do with the actual display:

Xsl Editor This is a plain text editor that allows modifying the Xsl used to displaythe data (cut and paste is suggested).

Parameters Editor This is a plain text editor that allows the modifying of anyparameters defined in XML for this data source (if none, this will be blank).

Sample Data This allows entry of a sample data format to be displayed.

Xsl Link This allows setting a link to an existing Xsl style sheet.

Enable Data View Caching/Caching Time out (Not shown) This sets the cacheparameters for this Data Source View.

Once you have made your settings, click the Apply button in the tool pane to save them.The selected item should display as shown (click OK in the tool pane to close it):


54/82


Business Data List Web PartThis web part displays a list of items from a BDC Data Source (the limit of how much datais returned is controlled by the Application Definition). If you followed the example, thispart is already on the page.

If not, add this web part to the page by doing the following.1. Select Site Actions | Edit Page and then click on Add a Web Part in Any Zone.

2. When the Add a Web Part dialog appears, scroll to find the Business Data List WebPart, click to select it, and then click the Add button.

3. When this part is first displayed, it is not configured, so it will display an Open ToolPane link. Click this to configure the part. When the tool pane opens, you will needto select the Customer Account Application.

4. Under Type, click the browse (book) icon and select Customer Account in the dialogbox. When you click OK and return to the page, you should see the Query Display,as shown:

As is true with most, you can also set Display Options here:

Xsl Editor This is a plain text editor that allows modifying the Xsl used to displaythe data (cut and paste is suggested).

Parameters Editor This is a plain text editor that allows modifying any parametersdefined in XML for this data source (if none, this will be blank).


55/82


Sample Data This allows entry of a sample data format to be displayed.

Xsl Link This allows setting a link to an existing Xsl style sheet.

Enable Data View Caching/Caching Time Out (Not Shown) This sets the cacheparameters for this Data Source View.

When complete, click OK to close the tool pane.At this point, the two web parts are on the page, one listing a specific account and the

other a list of all accounts. However, using Web Part Connections, you can begin to getsome actual application functionality out of this. If the page is not in Edit Mode, select SiteActions | Edit Page. Using the Edit Web Part menu on the Business Data Item Web Part,select Modify Web Part Settings. When the tool pane opens, clear the value in the Item, andthen click OK to close the tool pane; the web part will indicate that it is not configured. Usethe Edit menu again and select Connections | Get Item From | Customer Account List.When the page refreshes, you will now see a change. The Business Data List Web Part nowhas radio buttons next to each item, and whichever is selected is automatically displayed inthe Business Data Item:

Business Data Related List Web PartThis web part displays a list of items that are related to a specific item in the BDC (alsoknown as Associations). As you saw with the setup of the Profile Page, you have twodifferent associations: the Account Representative and the Orders by Account. You canadd this web part to a page by doing the following:

1. Select Site Actions | Edit Page and then click on Add a Web Part in Any Zone.When the Add a Web Part dialog appears, scroll to find the Business Data RelatedList Web Part, click to select it, and then click the Add button.

2. When this part is first displayed, it is not configured, so it will display an Open ToolPane link. Click this to configure the part. When the tool pane opens, you will needto select the Account Representative association. Under Type, click the browse iconand select AccountRep under Business Data Type in the dialog box.


56/82


3. When you click OK and return to the page, you will see that the Relationship drop-down menu is filled (in this example, AccountToAcctRep). Click Apply in the toolpane and the part will indicate that it still needs a connection:

4. Use the Edit menu on the web part to select Connections | Get Related Item From |Customer Account. After the refresh, you should see the connection is made and theaccount representative is being selected from the Customer Account shown in theBusiness Data Item Web Part:

Be aware that this connection could have just as easily been made to the CustomerAccount List since the same key is involved; however, because you know that the BusinessData Item (in this case, the Customer Account) will always be the single value needed, it iscleaner in the logic. To finish off the example, repeat adding another Business Data RelatedList Web Part and this time select Orders. Follow the same steps as shown previously,

including setting the connection to the Business Data Item. When complete and the pagehas been saved, the display should look something like this:


57/82


As you can see, both Related Lists use the Since item, so combined, you have a completedata picture, all selectable by a single part (the Business Data List).

Business Data Actions Web PartCustom Actions added to the Application Definition are accessible when displaying itemsin lists and when shown in search results. When viewing a single item, however, using theBusiness Data Item Web Part, the option is not available. The Business Data Actions WebPart is where this comes in (assuming you have Actions), though by default, most everyBDC Data Source will at least have the View Profile option.

1. To add this to the page, select Site Actions | Edit Page and then click on Add a WebPart in Any Zone.

2. When the Add a Web Part dialog appears, scroll to find the Business Data ActionsWeb Part, click to select it, and then click the Add button.

3. When this part is first displayed, it is not configured and will display an Open ToolPane link. Click this to configure the part.

4. When the tool pane opens, under Type, click the browse icon. From the BusinessData Type Picker, you will see the list of Entities. In this case, click CustomerAccount to select it and then click OK.

5. When you return, leave the Item field empty and click the Apply button (the web

Sharepoint BDC

Documents

Transcript of Sharepoint BDC