Can I use business objects as a data source?

We have decided to use business objects in our new application, which seems to be working well, since they can be used as a binding source for grids, etc.

I am trying to evaluate whether SSIS is a practical solution for our ETL requirements. The problem is, I can't find any examples or references, or even the slightest hint that anyone is using them with business objects. Any attempts to search yield a ton of results which are based on a commercial product called "Business Objects" rather than the design pattern.

It is currently a requirement of our development team that all data access must be done via business objects, rather than communicating directly with the database.

Can anyone provide some more information (besides just suggesting I write a custom connection manager)? Is there anyone who has actually made SSIS work with business objects?

Thanks, Richard

What is a "business object"?|||I don't know what kind of information you're looking for. Yes, it can be done. Yes, you'll have to write custom components to talk to the business objects instead of the database. I've done it for Reporting Services as a custom data extension (source) and it wasn't a bunch of fun. SSIS I think would be even less. Biggest downside I can think of off-hand is that you won't be able to bulk load into the database (think row-by-row), which is going to be really painful in an ETL scenario. I've never heard of an ETL process that wasn't allowed to access the database directly.
|||I'd concur with Jay's assessment. I've done some similar work in the past. Business objects are usually not very efficient for accessing large amounts of data. If your data movement is going to be on an individual row basis, I'm not sure SSIS is the best option for implementing it.|||

We are a 3PL, so in our case, ETL is more along the lines of importing batches of orders and exporting batches of shipping confirmations from and to a variety of data formats. Row-by-row is not an issue.

It would be nice to find a working example of how to do this prior to investing a bunch of time into SSIS.

|||This sounds more like BizTalk than SSIS. It isn't your business objects that I'd be concerned about in SSIS, it's the "variety of data formats". SSIS wants to move 10,000+ rows per second between well-defined sources and destinations and do a bunch of transformations along the way. BizTalk wants to route transactions between different systems and talk different formats to each one.
|||

BizTalk has a price tag. We already have SSIS. Everything I've read to date on it indicates that it is something we should be able to use to meet our needs. I am not questioning whether SSIS is the best choice. I would like to know if anyone has used it successfully with business objects, and if so, can they provide some examples, or other helpful information.

Thanks, Richard.

|||What will your business objects be constructed as? COM objects, web services, .NET assemblies? That has an impact on how easy they are to interface with.|||

SSIS Evaluator wrote:

BizTalk has a price tag. We already have SSIS. Everything I've read to date on it indicates that it is something we should be able to use to meet our needs. I am not questioning whether SSIS is the best choice. I would like to know if anyone has used it successfully with business objects, and if so, can they provide some examples, or other helpful information.

Thanks, Richard.

Can I reiterate Phil's question (above)? What exactly are these "business objects"?

-Jamie

|||

It's a generic term for objects that represent business entities and the rules associated with those entities. So you might have a Customer business object, with all the attributes that a customer has, and methods to represent any operations that can be performed on the customer. Usually, these provide a layer of abstraction between the database and the user interface. Business objects know where their data is stored for persistence, and user interfaces request information from the business objects rather than accessing the database directly. Changes in the data from the UI are also handled through the business object. Data validation, enforcement of business rules, etc, are all handled in the business object.

In the OP's case, evidently they have made an architectural decision that all data access has to go through these business objects. As has been stated, it is possible to do this with SSIS. The degree of complexity depends in large part on how the business objects are implemented. If this is being looked at a method to handle importing or exporting data from business objects to an external database, it might work OK, assuming performance is not the major concern. If it is for business object to business object communication, I really think the OP would be better off investigating other tools.