Explain the purpose of middleware for Universe connection.

building semantic layer
1

I am accustomed to building client/server applications where the client side is using ODBC or OLEDB to connect to the database server. In the case of ODBC, I can setup a DSN or DSN-less connection to use with the front end application. It seems with the Universe there is another layer called middleware that is in addition to the ODBC.

Here is the scenario, we created an ODBC DSN to DB2 on an AS400. At this point, we needed to select a middleware, such as, Generic ODBC or IBM iseries V5. Can somebody explain/diagram how the middleware fits into the overall connection stream.

Thank you for any insight.

cmmrfrds (BOB member since 2007-12-11)

2

There are different vendors that provide ODBC drivers for their databases. There is also a “generic” ODBC driver that might work but might not provide the same level of functionality. Basically Designer will talk to the ODBC driver which will in turn talk to the database. Since the ODBC sits in the middle of the chain, it’s called middleware.

Did that help? Or did I just tell you something that you already knew. :slight_smile:

Dave Rathbun :us: (BOB member since 2002-06-06)

3

I am looking for more detail on how/why once I setup an ODBC DSN that there is also an additional step to select middleware and what is the role of the middleware. This appears to be a layer over or above to the traditional client/server I am accustomed to using. I suspect that the middleware may be the database vendors proprietary implementation for ODBC or other client side products. I don’t know, but would like to understand this better.

cmmrfrds (BOB member since 2007-12-11)

4

BO uses the specified database to generate its SQL - is that what you’re looking for?

If you say your database is Teradata, and the ODBC connection is the Teradata ODBC, your saying two things. Obviously, you’ve defined what ODBC connection to use, but you’ve also told Business Objects to use the Teradata syntax for that connection.

If you look under the database connectivity folder (dataAccess), you will see the language files for each database BO supports. BO has set up all it needs to know to generate the proper SQL for that database, and this is where you would customize anything specific for your environment (eg, we have changed the Teradata.sbo file to use UTF8 as our character set - we did not do this for our Access connections).

I don’t know if this is what you need, but I hope it helps.

Brent

bdouglas :switzerland: (BOB member since 2002-08-29)

5

Is there a service that runs on the BOXI Enterprise server that provides the middleware services. If so, what is it called.

Is BOXI considered a three tier architecture where the client interfaces with the middleware which in turn interfaces with the database?

cmmrfrds (BOB member since 2007-12-11)

6

Thank you for the response bdouglas. I do understand that BO needs to interrogate the database vendors meta data in order to build syntatically correct SQL that can be parsed in the Designer. Also, I understand the role of client side products like ODBC. I would like to have a better understanding of what the middleware layer is doing.

cmmrfrds (BOB member since 2007-12-11)

7

I would like to have a better understanding of what the middleware layer is doing.

I think you have the answer already :slight_smile: .

Its not really, in my understanding, if I 'm using SQL Server management studio, for example, the “middleware” / syntax read access will be already built into the management studio application.

Business Objects can connect to many databases so you have to tell it, ideally, instead of generic ODBC, what platform you are using.

I believe that the middleware also accesses the prm files, search for *.prm in the data access folder on your server.
This is basically the same as an .ini file and sets parameters for a vendors connection type.

Unsure about this, maybe the connection server :? .

Mak 1 :uk: (BOB member since 2005-01-06)