When 2007 MOSS was released I was a bit disappointed with the integration options provided in the BDC. Frankly, although they worked, they are a ‘lowest common denominator’ (which I do realize was likely the only choice Microsoft had).
They could of however made the interface open, enabling a ‘provider/consumer’ style interface as they have so often before. We know in software that the strategy design pattern is often at the heart of well architected enterprise software (which is a technique to empower dynamic change and flexibility in your solution – considering your OK in areas such as security, production deployment, scalability, etc.).
My clients often have their core information as ‘domain entities’ and this all but eliminates the disconnects caused by having to translate a ‘customer’ to an Oracle structure (for example) It’s JUST A CUSTOMER. Let the domain layer do the mapping, persistence and other work that is non-value added now. And their web service demands on the organization in my experience require a compeletely new development effort in most cases… Not good…Better then nothing but we can do better.
In this spirit, I am working on a utility to automate the importing of information from the following sources:
1) Domain Objects as Source (not tables): Hibernate XML Mappings . We treat NHibernate/Hibernate’s meta mapping from object to relation as the Industry Standard.
3) OPTIONAL: WSDL for Web Services not the mandates on WHAT your web services are
And the unfortunate fact is the web service interface required for BDC integration is quite ‘un-service oriented’. It’s RPC based… Exactly (again) what we are all moving away from.
MetaMan tool for the Business Data Catalog
So instead of classes you would see something a UML style class diagram populated from .NET Reflection in the work I am doing (although this UI is coming last, then a Visual Studio 2008/2005 addin).
The idea is to let people automate almost all of the somewhat tedious process (even with the new Microsoft utility for BDC Admin or the MetaMan tool).
Both have their places, don’t get me wrong. However there is sufficient metadata already available typically in SOME source in the organization. It is a bit silly to have yet another (although you really have no choice).
So if you can integrate these and ‘publish’ a BDC application to Sharepoint 2007 (as much as possible anyway) it’s easier.
One silly thing I have seen in both tools:
1) They assume a clustered index is the primary key on the database table.
See above for MetaMan…
This makes no sense for a few reasons. For core fact tables rarely would this be true. Clustered indexes are typically (or should be) on foreign keys, for rapid access when that is the usual way the information is retrieved.
Unfortunately many developers forget this simple optimization, however it is strange that these tools would make the same invalid assumption.
EXAMPLE:
Customer table
Invoice table
InvoiceDetail table
For the Sharepoint 2007 BDC all entities must have a single key enumerator which is exposed via the ‘ID Enumerator’ method (you can have 1 per entity).
This is used for iterating results for searching, query string parameter passing for custom actions, etc.
So logically the above would have these keys:
Customer – CustomerID (identity or Oracle Sequence)
Invoice – Invoice ID (identity or Oracle Sequence)
InvoiceDetail – InvoiceDetailID (identity or Oracle Sequence)
In your domain, it’s a given that InvoiceDetail rows are access by InvoiceID most often. Therefore you should have your clustered index on the InvoiceID foreign key.
etc… This is fairly obvious stuff here guys!
So rather then try to write out the XML Format, I am bypassing that completely and using the API.
So far this is working and should allow a somewhat dramatic improvement for linking line of business solutions in your enterprise with the many benefits the Sharepoint 2007 Business Data Catalog provides.
3 Comments
Damon,
Thanks for an interesting post.
What I don’t understand is “How are you going to interface to your domain model”?
I’m under the impression that the BDC will only work with ADO.NET providers or WebServices.
Are you writing an ADO.NET provider that will talk to your domain model (i doubt it) or is this work “just” to transform the existing mappings into BDC mappings and then let the BDC interface directly to your database?
I’m currently looking at the BDC and I can’t find any documentation that let’s me write a “custom provider” so that I can create an Adaptor between my domain model and the BDC and still utilize the BDC Web Parts.
Do you know if there are such an API available?
Thanks again
/Jonas
The solution is a bit of a hybrid of what you describe but essentially for the first version it indeed transforms Domain Mappings to BDC mappings and then relies (in a transparent way) on the existing ADO.NET provider(s).
That being said. I’m OK with it as even NHibernate uses ADO.NET providers behind the scenes. As long as I don’t have to ask anyone to ‘step out of domain thinking’ for this, it’s ok.
The transform SHOULD be easy. Unfortunately as stated there are limitations on actual design expectations the BDC places on you for it to work. That is where the hybrid part comes in and you nailed it by using the word Adapter.
Each environment will be different, but as long as:
1) The BDC is happy with the metadata and
2) It can resolve data population through some ADO.NET provider (the web services API is a lost cause I believe for now) and
3) Where constraints are not present some facade and/or adapter can be used to satisfy the BDC’s requirements
then all is ‘good enough’… Not perfect but what is (grin)?
Damon
Damon,
We have just released a FREE framework named MashPoint.
Take a look here:
http://community.bamboosolutions.com/blogs/mashpoint/
We emulate the BDC and we also allow you to import ANY .NET type. You can see a sample of a simple file system “provider”. So it’s really easy to write custom providers.
We are working on allowing you to bring in your domain models based on NHibernate or Entity Framework or some other O/R mapper.
The biggest challenge right now is the tooling. But If you are working on a tool please look at MashPoint too :)
You will be able to influence the direction it takes by joining Bamboo Nation and our labs.
Thanks
/Jonas