| Author |
Message
|
| jborella |
 Posted: Thu Mar 03, 2011 2:04 am Post subject: BrokerDataSource in WMB v7 |
 |
|
Apprentice
Joined: 04 Jun 2009
Posts: 26
|
Our company is planning to upgrade from WMB v6 to v7. We would like to upgrade the environment and then deploy the bar files unchanged from v6. Changing the bar files would require extensive testing, which isn't feasible.
The problem is, that some developers are using the BrokerDataSource property (reading some config, which is stored in the broker database) in v6. Since v7 of wmb doesn't use a database, this property is no longer available.
Is there some way to set BrokerDataSource in wmb v7 without changing the bar-files? After all IBM promises that v6 flows can run unchanged in v7, but the BrokerDataSource property has been removed from the documentation in the v7 documentation, so hopes arent high. |
|
| Back to top |
|
 |
| fatherjack |
| Posted: Thu Mar 03, 2011 4:13 am Post subject: Re: BrokerDataSource in WMB v7 |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| jborella wrote: |
| reading some config, which is stored in the broker database |
Why? 
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| jborella |
| Posted: Thu Mar 03, 2011 4:23 am Post subject: Re: BrokerDataSource in WMB v7 |
|
|
Apprentice
Joined: 04 Jun 2009
Posts: 26
|
| fatherjack wrote: |
| jborella wrote: |
| reading some config, which is stored in the broker database |
Why? |
Some extra tables has been added with some routing information. Maybe its bad design, but now it's there and the challenge is to find a way to work around it (if possible). |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 03, 2011 5:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You should be able to create a new ESQL file that defines this variable at the schema level, and add this to the bar file.
"BrokerDataSource" is just a name, after all. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Mar 03, 2011 5:04 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Can you define BrokerDataSource as a WMB DB2 ODBC data source like any other? However the DB2 supplied with WMB 6 is not licensed for business data in the first place.
You would be better off either using a licensed copy of DB2 or migrate to another database type that your company uses. |
|
| Back to top |
|
|
| SANTYP |
| Posted: Thu Mar 03, 2011 10:25 pm Post subject: |
|
|
Centurion
Joined: 27 Mar 2007
Posts: 142
|
You no need to change the bar files ... only thing you have to do is you have to set that DSN for the broker using mqsisetdbparams
and add an entry in odbc.ini file(for that DSN) |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Fri Mar 04, 2011 5:19 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| Quote: |
| We would like to upgrade the environment and then deploy the bar files unchanged from v6. |
I sure hope your flows don't have any plug-in nodes in them then.
Some former v6 plug-in nodes became built-in with v7 and their configuration and/or functionality does not exactly match their v6 predecessors.
The ones we spent time on changing were the Email, WTX and Zip nodes. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Mar 04, 2011 5:22 am Post subject: Re: BrokerDataSource in WMB v7 |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| jborella wrote: |
| Our company is planning to upgrade from WMB v6 to v7. We would like to upgrade the environment and then deploy the bar files unchanged from v6. Changing the bar files would require extensive testing, which isn't feasible. |
You should be testing all of your Broker artifacts continuously. I don't understand why you (or your boss) thinks that system and software does not need to be tested.
When you developed your message flows, did you also develop Junit test cases? If not, why not? Writing core functionality is only one-third part of the whole exercise. You must also write test cases that prove the functions developed satisfy the business case.
If your company is spending a chunk of money to upgrade to v7 (which is a great idea by the way), why doesn't your company recognize the need to invest in solid, mature development practices?
Developing business systems on a shoestring is a sure way to fail, eventually. If you are going to spend money building a system, what is the logic in not spending money maintaining the same?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| jborella |
| Posted: Mon Mar 07, 2011 4:08 am Post subject: |
|
|
Apprentice
Joined: 04 Jun 2009
Posts: 26
|
| zpat wrote: |
| However the DB2 supplied with WMB 6 is not licensed for business data in the first place. |
We are running against a MS SQL server (soon 2008), so there aren't any licensing issues.
| zpat wrote: |
| Can you define BrokerDataSource as a WMB DB2 ODBC data source like any other? |
I'll try that, but my guess is that the BrokerDataSource is only related to WMB6, so how should it be recognized as a property in WMB 7 without additional work? |
|
| Back to top |
|
|
| jborella |
| Posted: Mon Mar 07, 2011 4:09 am Post subject: |
|
|
Apprentice
Joined: 04 Jun 2009
Posts: 26
|
| mqjeff wrote: |
You should be able to create a new ESQL file that defines this variable at the schema level, and add this to the bar file.
"BrokerDataSource" is just a name, after all. |
Thanks for the suggestion. I'll try that. |
|
| Back to top |
|
|
| jborella |
| Posted: Mon Mar 07, 2011 4:19 am Post subject: Re: BrokerDataSource in WMB v7 |
|
|
Apprentice
Joined: 04 Jun 2009
Posts: 26
|
| lancelotlinc wrote: |
| You should be testing all of your Broker artifacts continuously. I don't understand why you (or your boss) thinks that system and software does not need to be tested. |
I totally agree with You, but unfurtunately my compagny doesn't. Trust me, I've tried selling more and continuous testing.
| lancelotlinc wrote: |
| Developing business systems on a shoestring is a sure way to fail, eventually. If you are going to spend money building a system, what is the logic in not spending money maintaining the same? |
The problem lies in Your own words: "eventually". I've said the same as You all the way, but at the end of the day it's still running. |
|
| Back to top |
|
|
|
|
