Sharepoint Business Data Catalog and system adapter patterns

A pattern is a solution that occurs many times.  You recognize it and describe it and others use it.  The Sharepoint Business Data Catalog is an example of a pattern that I'm looking for in other places, the system adapter pattern.

In any enterprise system, if you want to provide a 'generic' mechanism to allow data to be drawn from another system, you have to provide a way to connect the source system to your enterprise app in a manner that allows your app to consistently draw that data out of all source systems.  Of course, that consistency can be tough.  Some systems want you to reach into their database, others have web services, others still have more esoteric communication mechanisms.  They are certainly not consistent.

So you create an adapter interface that allows an adapter to be configured or written.  That adapter will draw the data from the external app and make it available using a consistent interface to your app.

 But what does it mean to "make that data available?'  Why would we need to do this?  One reason is that you need to get these data values from another location because you intend to feed these data values back to that location.  In other words, data from FOO is going to BAR, so get data from BAR to validate against.  But do it generically. Do it in a way that the source of the data is configured, not hard coded, and the number and types of fields are discovered at run time, not coded at compile time.

Sharepoint faced this problem, and they added the Business Data Catalog.  It's a nice feature and useful for what it is good for: pulling data from a remote source and displaying it in a portal.  It is NOT good for local data cache, because it doesn't store the remote data.  It just stores the metadata that allows it to be retrieved, but that's OK for sharepoint.  Two sharepoint users are unlikely to share data.

On the other hand, if you do have a query that most of your users need from a remote system, and it always returns the same rows, you need this pattern plus one more: a local data cache.  That's another blog.

Comments

• Anonymous
  March 10, 2007
  Hi Nick, I use and enjoy Sharepoint as well. However, I do acknowledge that since we are composing in the glass, reusing patterns as you describe...we grab many lines of code that may or may not be actually used.   5 Mins of development for excess code vs. 5 days of development for highly efficient code. All in all, for non-volume and non-critical systems...a worthwhile trade-off. Some call it disposability. -JT