Tom Rizzo's SharePoint Blog

Tom,

We met at the February Collab & Portals PAC (have server for the last 2 years).

I agree completely. I think BDC is one of the most significant new capabilities for MOSS 2007 and think it can help bring together structured and unstructured data in applications built on MOSS.

Tom,

Agreed, its a great enabling feature - but I think the hard bit will be ensuring orgs know what BDC is, and what is best practice to use it effectively...

There is so much in MOSS 2007 that it can get lost in the noise..

Tom,

BDC will come of age when we all have a good story of providing security adapters to other data sources [for searches and entity imports]. Without that, BDC will be a great demo that will tot be used. Even if security does not get shipped by RTM, the saving grace will be an announcement "we'll have it done by SP1".

Piotr

Hi Tom,

BDC is such a great feature and will enable so many solutions that would not have been cost-effective before.  A truly great Portal feature.

Piotr's comment about security I think is badly worded (sorry Piotr :p ) - but very valid.  Having only per-entity type security and not per-entity item security will not be granular enough for some scenarios.  Sure it will get used anyway for many scenarios, and I appreciate the difficulty / impossibility of providing a general approach to exposing ACLs through BDC, but if MS would only add the hooks to let devs supply ACLs for a more complete solution?  That would rock.

Other thought is that finding a way to build a community approach to sharing BDC metadata would be fantastic and really enable these scenarios even more for a wider audience.

And lastly - when will the metadata and approach for BDC and IBF merge?  I've asked that before and never heard a good answer from MS :).

Cheers

J

James is right. BDC rocks, and I already intend on using in in beta2, although only for  

For business applications that will be using some sensitive data we need some good way to implement some kind of "per item" security.

This is going to be very hard, as BDC performs several "related" tasks none of would perfectly share the same security model [interactive "show me items i can see" vs cached "who can see this item"]. Also, the data sources typically do not respect whatever will be implemented by SharePoint [forms/ntlm/kerberos], and may require and additional SSO tie-in.

Piotr x2

the BDC is hugely relevant... there's no doubt in my mind that it'll get noticed.

I'm sure it will get lots of exercise in the next few months that will show exactly where it shines and where the not-so-strong spots are. And, as Piotr said, there's always SP1 to get those beefed up. All Hail Iterative Development.

The first wave of implementations will probably be of the "look Ma, no hands!" kind (and cool consultant demos). of course, when scraped knees and bruises follow (things that shouldn't be out there turning up in searches and columns of Business Data type), Ma will put the lid on things until kneepads arrive. One way or another, though, pretty much all of us can ride a bicycle. Ok, enough of the bike metaphore.

I think many of the security concerns can be relieved if:

1. i can be absolutely positively certain that interactively queried data are _never_ cached (except for the same user for performance reasons, for example).
2. i can rely on a clean separation between queries that retrieve cached data and queries that retrieve interactive data.

this way if some place on the portal uses data from an interactive query, i can be certain that the appropriate parameter will be passed to retrieve interactive results. and if the same place uses cached data, i can attempt to override the UI (e.g. search) to trim items that shouldn't be there (via a web service, for example, that checks BDC results against an ACL).

whatever happens, there's obviously some room for prescriptive guidance here :)

Hi Ilya

AFAIK All BDC data is cached... list data is cached and synchronized 'on demand' and of course data in the search index is only refreshed when a crawl is carried out.

It's purely for performance reasons - if you're rendering a list view with say 100 items and there's a couple of BDC columns and you need to make web service / database calls to retrieve the data?  Well keeping that performant with real time calls would be hideous (and a batch interface would be too complex for the role of BDC) - and even with per-user temporary caching, filling that cache the first time round would be way too slow.

...i recall hearing that not everything was cached in the same way. any clarification on this from anyone w/ BDC practical experience?

Is there a way to filter data that is linked to a Business Data List, and use a variable filter?  Can the filter value be picked up from a parameter or let's say, a querystring value?

Thanks,

Gene.

If I have a BDC column in a Sharepoint list (doc library) - is there any way to make that field a required field?

I don't find any way :-(

You can make it a required field through the standard create column UI.  The issue you will run into is when you create a document, we will create the Document Information Panel with the right metadata fields but we don't have the object picker in there to resolve the BDC data.

If you upload a document using the browser, you will get the object picker.  So, my recommendation is to customize the Document Information Panel using InfoPath to make the resolution work against the BDC otherwise use Web Upload.

PingBack from http://jointpainreliefs.info/story.php?id=2028

PingBack from http://insomniacuresite.info/story.php?id=1060

PingBack from http://cellulitecreamsite.info/story.php?id=100