Eli Robillard's World of Blog.

I'm posting at 4:47 and the TSPUG meeting start at 6:00, but registration is at capacity so hey, c'est la vie. The complete agenda for tonight is posted on the TSPUG site.

Tonight after the usual pizza and discussion I'll be presenting a session on Site Architecture and Taxonomy, and then we'll have a presentation on Records Management in SharePoint using Meridio. These are great topics to launch the fall season, I hope to see you there!

What's coming up:
October: Disaster Recovery.
November: Windows Workflow Framework (beta 1).
December: SharePoint 2006 (beta 1).

PDC 2005 Session OFF321

This could be the best thing I've seen at PDC -- a powerful way to manage business objects in disparate systems and provide access to them over SharePoint. I think it's a no-brainer to say that of all the features in SharePoint 2006, this will have the most transforming effect on the enterprise, mainly because it does more for managing enterprise knowledge than any other advance.

The Business Data Catalog allows you to centrally manage data models and data. You describe the metadata, upload it to the catalog, and the features "just light up." Data sources could include SAP, Siebel, legacy systems, etc.

Metadata Model

System - data source

Entity - A real-world thing in a System

Method - An operation on an Entity

Association - A relationship between Entities

Metadata has two purposes: to describe a System's API, and to give it meaning to the API and make it easily usable.

Finder Methods

This is a standard way to find instances of an entity. One method of an Entity is registered as the Finder, and another the SpecificFinder.

For example, you could have two WebMethods in a class to retrieve instances of the class (e.g. GetItemCollection and GetItem). In the metadata you include the object schema and the Methods available (like a WSDL). Then you use a MethodInstance section to associate the methods with the types e.g. Finder or SpecificFinder.

Adding a Source to the BDC

The Business Data Catalog is a Shared Service for all Office apps. You get to it through Site Settings, Add Application, and browse to the XML metadata file. Then you click Import and after the Import is complete you get a View page which allows you to manage or display the contained objects.

In a SPSite, you can now add Web Parts: Business Data List, Business Data Item. Then you'd configure the BDList to use your new Application, display certain fields, and boom it works.  From there you can create a connection to provide an object to the BDItem web part. Once again, the BPItem WP allows you to choose which fields to display.

In a SPList, there is a new column type called Business Data, which lets you include your business objects in lists. For example, you could bind a Customer database to a help-desk support list.

You can also connect to a Database as a source. The metadata looks a little different only because of the connection type, and now the Methods are queries rather than web service methods. Back in the UI after an Import, the only different is that the Type is Database rather than Web Service,

Filters

Filters let you control the data returned by data finders. These are composed of annotations on a Methods input parameters. You might use a filter to create a dynamic picker so that in a custom list with a Business Data column, you can now have a rich browser with a search/filter feature (similar to Outlook Web Access).

Properties

Every MetaData object has a Properties collection. Business Data features make use of certain annotations, and you can extend the metadata for your own applications.

Once again, Properties are created in the metadata, either on their own or inside Filters. So now when adding the customer to a custom list, the user can type a part of a name and there will be an automatic lookup which presents a list of choices -- the user doesn't even need to use the Browse to locate a customer, it can be done based on a part of the Customer Name.

IDEnumerators and Search

You can full-text search any Application by exposing an IDEnumerator and SpecificFinder for your data. For example, you can have a WebMethod to GetCustomerIDs, define another MethodInstance to bind this method to the Application. Once published, the Search service can now iterate through the CustomerIDs and retrieve data for each customer (using the SpecificFinder).

Potentially, you could create several IDEnumerators with different names and get the same sort of behaviour as Audiences gives you in slicing Active Directory results.

Actions and WriteBack

Actions are links that travel everywhere with an entity. This allows users to take action in context.

Business Data Catalog API

There are two halvesL runtime and administration

The Runtime API lets you browse metadata, execute methods, retrieve instances, and traverse relationships. This is great for custom application builders.

The Administration API lets you create, read, update, and delete metadaata and manage permissions. It's designed for administrators.

Namespace: Microsoft.Office.Server.ApplicationRegistry (ApplicationRegistry = BDC). Note that this namespace may change.

AuthN, AuthZ, and Auditing

You can set authentication per application. There are two patterns: trusted subsystem or deelegation. There's one place to set permissions, you can control who accesses which entities, and there is support for LDAP. There is also one place to audit and log who accesses which data when.

Call to Action

Expose your line-of-business data as with web services or databases.

Write BDC-friendly methods or stored procedures.

I'm posting this as we go through the Q&A portion of this presentation, which covered both InfoPath development, and InfoPath's capabilities in publishing and interacting with different environs. InfoPath forms can now be used both inside MS Infopath ("smart client"), over a browser, or embedded in other apps. Here come the notes...

Importing Forms

An importer will automatically recognize and convert Word docs. It recognizes certain patterns, like a text box for a multi-line form, and a repeating table for tables with headers.

You can create an MSI installer from inside InfoPath.

You can publish a form either into a DocLib, or as a ContentType in SP. At publish time, the xsd is converted into something that can be rendered directly to a browser.

When you create a new instance with New, if the client is a smart client, InfoPath will open. You can also open the browser version directly, and the experience is identical in both.

There is an Importer Framework which you can extend with custom importers to migrate existing templates and data. Out of the box, there are importers for Word and Excel. The interface is IFormTemplateConverter for forms, and IInfoPathDataImporter for data.

Template Parts

You can now re-use sections and logic with Template Parts. This supports auto-updating sections and logic across solutions. It supports formatting and control properties, main data source and secondary data connections, rules and other BL, conditional formatting, and formulas / calculations. A drawback is that this doesn't include code, and the recommendation is that you put code into ActiveX controls.  The control toolbox has a Custom section where these Template Parts can live and be dropped onto the design surface.

The Template Part design environment is identical with the InfoPath designer, but filtered to provide features specific to a section (i.e. no roles, etc.). As an example, you could create a Qty Item Description Cost table with a Totals row at the bottom and re-use this as a Template Part across your forms. In the designer, you wil be notified when the source Template Part is update, and you have the option to right-click and select Update to bring in the changes.

InfoPath Business Logic

A goal of infoPath design is that code should not be required in the majority of solutions.

InfoPath is now fully managed (CLR 2.0). MSXML is gone, they've finally moved to use System.Xml. The development experience is much better (events fire once per change, forms accept input parameters, and you have Preview with Full Trust. The caveats are that this is a new object model. There  are tools to migrate managed code, but the move from MSXML to System.Xml means some manual changes will probably be necessary. That said, you don't need to migrate forms unless you want the browser support. If using the Smart Client, you can continue to use all your existing forms as-is.

VS Integration

Visual Studio for Applications is an IDE for the masses and it's included in InfoPath (similar to the old built-in IDE). Visual Studio Tools for Office is an embedded designer for professional devs. It provides a single IDE for all projects (Workflow, etc.).

The Visual Studio Tools for Office experience is richer, for example you get full debugging support to trace form events.

When presented through the browser, validation will happen during a round-trip after an update, and the view is immediately refreshed to display any errors. This uses XMLHTTP, as its development preceeded Atlas.

Deployment and Security

The two questions to ask: Does my form use data connections, and does my data contain code? Based on these, you can decide which trust level to use: Restricted, Domain, or Full Trust.

If you don't use data connections, Restricted (the default) is fine. For example, this would be a form you might pass around by e-mail.

If you require connections in the same domain or over a trusted connection, or if the form contains code, you can use Domain trust. An example would be a form deployed to SharePoint.

If you require cross-domain connections, or need to run code locally, you would require Full Trust and either install a Smart Client, or sign the deployment.

Custom Task Panes and Add-Ins

You can add custom functionality to InfoPath and re-use this functionality across Office. The interfaces are IDTExtensibility2 and Istartup. For Custom Task Panes, it's ICustomTaskPaneDesigner.

Hosting InfoPath Inside Your Application

There are WinForms and ActiveX controls which you can embed in an application. For example, property editors, or workflow dialogs. There is an analogous aspx control to host browser forms. The ActiveX however is not recommended for browser deployment (use the normal SharePoint / browser deployment for browser forms), and some features aren't available like ink control.

In WinForms, this appears as the FormControl in the toolbox. You basically add a FormControl to the design surface, add code (e.g. during the Form Load event) to initialize the embedded form with the location of the xsn (FormControl1.NewFromSolution(@"c:\myForm.xsn"), and that's it. The host application also has acess to data inside the form via the InfoPath Object Model (OM). For example, FormControl1.XmlForm.Errors.Count. All of InfoPath's commands are accessible via ILACommandTarget (sp?). For example, you could create your own toolbars which call InfoPath functions on the embedded form, and you can combine this with access to the OM for some pretty powerful interop. 

Notes from a terrifc session today at PDC. I expect to post notes from other sessions, the main delay will be converting from ink to text and doing a bit of proof-reading. All in all, it's beena  grat day for SharePoint, and I hope this gives you a good taste of what's to come.

Core improvements to List architecture

Version history for all Lists, shows changes to the item for each item.

Will have line-by-line diff-ing for text fields.

Append-only comment fields.

Multi-valued lookups

Large list indexing support

Update Issue Tracking template

Integration with Windows Workflow Foundation

Project Tasks List

Lightweight project management functionality

Gantt charts for visualization of project plan (or any series with date fields)

Charts have drag and drop for moving events around

E-mail

SharePoint lists can now receive e-mail. Discussion Boards, Calendars, DocLibs, Announcements accept incoming mail. Discussion boards maintain e-mail threading and full html messages. Calendars process incoming iCals, DocLibs map attachments to documents.

There is extensible support for custom "e-mail handlers." So custom lists can support e-mail by writing a handler. SharePoint handles the routing of e-mail, and your code can map e-mail data to fields in a list.

An SMTP Server is integrated with SP, or you can use Exchange.

There is also Distribution List support. Site groups can have an associated DistList. You can create a distribution list for site members on site creation. SPSites will talk with directory services to create or manage DistLists. The interface with DS is pluggable through SP directory management Web service interface. An AD directory management WS provided with SP. There is also approval and management that can be added to this, so that only a manager can create or manage DistLists.

Outlook and Syncronization APIs

Outlook allows one to work with personal and team data in one place. It's now a true 2-way sync with R/W access to SP datatypes (Calendar, tasks, contacts, discussions, and documents). And, there is sync for offline support. The ChangeLog APIs are optimized for synchronization. E.g. GetListItemChangesSinceToken - Web service method that returns a list of items that changed (adds, updates, deletes). The ChangeLog is stored as a separate log, so the original data doesn't need to be re-queried. The mailbox is polled every 2 minutes (by default, didn't say whether this is configurable).

There is a now a SP object picker that lets you select objects from AD, for example, to add members to a site -- so you no longer need Outlook installed locally to pull up an address book.

The UI for side-by-side item display in Outlook is finally what you'd expect, and the experience will be similar between SP and Outlook. The teams are working together on the design to ensure the consistency.

Keeping Informed

Alerts can now be filtered, and there is richer information about what's changed.. There is a way to customize the formatting of events and alerts. You can also assign alerts to other people. The granularity is also much deeper. For example, you can be alerted if anything changes, or only for certain conditions (e.g. the president changes a list item). The alerts are stored as xml in a sort of prefix nesting. Everything can be rendered out as RSS.

UI

Breadcrumbs (from Asp.net)

Security-trimmed UI so users only see options they can assert

The QuickLaunch is now on every page, and it's easier to navigate to sibling nodes in the path.

Lists can be filtered, and the refreshes use Atlas to fetch and update. These features now work cross-browser too.

There is a new Actions and Settings menu (Site Actions), these are also drop-downs. The drop-downs also include help text to provide help in context.

To add features to the standard menus, you can deploy changes without touching the files shipped by SharePoint.

RSS

You can subscribe to a feed on any list, and even choose which columns will be part of the feed. For calendar items you'll be able to subscribe to iCals, it's all good.

Atlas.asp.net went live at 8:00am PDT today to coincide with the keynote.

(More to come on PDC Tuesday!)

PDC is coming next week, and it promises to be a great week of insight into what's coming in the months and years ahead for SharePoint, ASP.NET, and the Windows platform. I'll be posting on the PDC Bloggers feed, and plan to do a presentation on what's coming for SharePoint later this year for the Toronto SharePoint Users Group.

Speaking of user groups, I'm scheduled to co-present at the October meeting of the Metro Toronto .NET Users Group. The topic will be Web Parts for both Whidbey and SharePoint, and I'm sure we'll have a bit of time to talk about what's ahead for ASP.NET and IIS as well.

See you there!