The integration is actually via the Open Database Connectivity (ODBC) API/interface, which has been around since early versions of Windows ( I think I first used ODBC with MS Windows for Workgroups 3.1.1 and Windows 95, in order to connect to the IBM iSeries database ).
This requires some consideration, as the ODBC capability for DB2 is provided by the DB2 Client. Therefore, we have installed the DB2 Client onto the AIX LPARs hosting IIB, via the following response file: -
PROD = CLIENT
FILE = /opt/ibm/db2/V10.1
LIC_AGREEMENT = ACCEPT
INSTALL_TYPE = TYPICAL
FILE = /opt/ibm/db2/V10.1
LIC_AGREEMENT = ACCEPT
INSTALL_TYPE = TYPICAL
and then created a DB2 instance on each LPAR, one per installation of IIB ( we have two here, one of which provides our Enterprise Service Bus - ESB - capability ).
In terms of the interaction, it's something like this: -
-------------------------------------------------------------------------------------------------------------------->
What Flow DB2 Instance DB2 Instance
Where IIB Integration Node DB2 Client DB2 Server
Who wmbadmin db2user1 db2inst1
In order for this to work, it was necessary to catalogue the DB2 server ( db2 catalog tcpip node .... ) and the database ( db2 catalog database ... ) on the DB2 client, as db2user1.
The ODBC.INI file, used by IIB, references the alias name from the catalog, to which the IIB flow connects, essentially making the connection via the DB2 client, to the remote database.
We then tried to add a second catalog entry, for a different user ID, to a different database e.g. database foobar accessed by user db2user2.
So we had a single set of DB2 client binaries, but we had two DB2 users ( instances ), each with its own remote database aliased via the catalog.
This didn't work too well, we found that IIB, via ODBC, would try/fail to connect to the second database using the first set of credentials.
Long story short, we ended up with a different solution; a single DB2 user/instance on the IIB, with both databases in its catalogue, BUT with IIB sending different credentials to the remote DB2 server, depending upon whether the flow was trying to access database 1 or database 2.
This Knowledge Center article covers the integration in more depth: -
Purely for background reading, this Knowledge Center article: -
includes a useful reference for the terminology used in IIB, as compared to the previous WebSphere Message Broker solution: -
No comments:
Post a Comment