| Author |
Message
|
| guest468 |
 Posted: Tue Oct 21, 2008 8:32 am Post subject: Retrieve WMB code from broker |
 |
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
Hi,
Just wondering if there is any way to retrieve the code(complete message flow) from broker. Only thing that i know is by using browse command on brokerresources table. But it would be tedious to build the flow from it.
Thanks |
|
| Back to top |
|
 |
| Gaya3 |
| Posted: Wed Oct 22, 2008 8:22 pm Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
its not that easy, and i dont think IBM recommends/supports fetching tables also.
Why do you need it...?
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| Bharat_123 |
| Posted: Thu Oct 23, 2008 8:08 am Post subject: |
|
|
Acolyte
Joined: 15 Sep 2008
Posts: 58
|
U can retirieve the flow from bar file but not from broker..
IBM never recommends to do that |
|
| Back to top |
|
|
| guest468 |
| Posted: Sat Oct 25, 2008 9:30 am Post subject: |
|
|
Centurion
Joined: 30 May 2006
Posts: 146
Location: NY
|
Well I see the need for this in our Integration environment. We have tons of complex message flows and all developers, support and admins keep deploying different versions of message flows all the time. It's difficult to know what version is deployed especially say I am working on a flow which relies of on other flows whose code i am not yet sure about. Also some teams deploy wrong version of flows. So I always find the need to check/confirm the codes of relevant flows all the time. (tracing helps only to some extent since they cover only the message path)
Thanks, |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Oct 25, 2008 10:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You need governance and source control.
You do not need an ESQL/message flow decompiler.
Also, you should probably have more EGs and queues in Integration, such that a team can deploy what they need to run their tests in a way that does not affect the other teams... |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Sat Oct 25, 2008 10:22 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| guest468 wrote: |
Well I see the need for this in our Integration environment. We have tons of complex message flows and all developers, support and admins keep deploying different versions of message flows all the time. It's difficult to know what version is deployed especially say I am working on a flow which relies of on other flows whose code i am not yet sure about. Also some teams deploy wrong version of flows. So I always find the need to check/confirm the codes of relevant flows all the time. (tracing helps only to some extent since they cover only the message path)
Thanks, |
hhmm you seem to work for an out of control organisation by what you are telling...
so how do you handle for example compiled application programs in your environment then? 
you de-compile instead of proper version management and a change control process???
Your location indicates, NY as in New York? last time I checked SOX is still in effect in the US
I can see having the capability of retrieving flows from the broker itself as a immediate solution to your out of control situation, but
(i you had the capability, which I seriously doubt you will ever get!!!)
I feel it will only lead you to more dis organisation in your organisation.
so look for proper version management and proper change control as the solution to your problems...
just my 2cents...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| dcjs |
| Posted: Sat Oct 25, 2008 5:59 pm Post subject: |
|
|
Acolyte
Joined: 10 Nov 2006
Posts: 53
Location: IBM Bangalore
|
I think its a not a best practice,but iam facing a very similar problem.
Previous developers who developed the message flows deployed bar file on version 5 broker haven't checked neither the the message flows nor the Bar file in version control.
I have an enhancement to perform on it, for that I would like to backup the message flows and message sets (or bar file) from the broker.Really if we think logically broker should store them in some location to run it on Broker to back up those.
I have searched in the forum and developer works,none of the posts says that it is not possible,Is that correct?. 
_________________
TRY TRY UNTIL U SUCCEED |
|
| Back to top |
|
|
| hopsala |
| Posted: Sun Oct 26, 2008 4:03 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
I agree with everyone here who said that this is a very bad idea. Extracting resources from the broker should only be done in emergencies - i.e when critical source code is lost.
This is, however, possible, or at least should be in theory. The flows themselves are stored in the broker database, but it requires knowledge of tables structure and content, which is undocumented, and can be changed in upcoming versions (actually, it has changed quite a bit in the last few version upgrades).
Also, you should be aware that JAR files and others are stored in the broker home directory and under the EG. In windows, for example: "C:\Documents and Settings\All Users\Application Data\IBM\MQSI\components\WBRK6_DEFAULT_BROKER\5042257e-1b01-0000-0080-b625edcfee53\config\".
Again, since these directiories and tables change from version to version, you can't rely on it, and should only try this in emergencies. The broker database can indeed be backed up, but only as a whole and not for seperate flows. Otherwise, if you want to back up your flows, use source control - some source control tools are free, and very simple to use. |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Sun Oct 26, 2008 5:39 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi,
I recommend that you establish a new project that collects (, tests, changes if needed, collects and references reusable function, procedure and sub flow libraries, adds MQSI key words to the resources...) from all the latest versions of the flows etc. under the version handling system, and establish good governance and developing policies for the future.
Otherwise there is a possibility that the mess stays at the environment.
Marko |
|
| Back to top |
|
|
| dcjs |
| Posted: Sun Oct 26, 2008 7:58 am Post subject: |
|
|
Acolyte
Joined: 10 Nov 2006
Posts: 53
Location: IBM Bangalore
|
Thats true,I totally agree with you and we followed all the best practices in our previous projects.
Now i joined a Client which they haven't followed any of those and it is so horrible for me to fix these things.
Still trying to find the solution to restore those message flows and message sets.
Let's put those things aside for a moment and think Logically Broker has to save the message flows,sets somewhere in broker metadata(Tables) or in some file system where we can restore them right 
_________________
TRY TRY UNTIL U SUCCEED |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Sun Oct 26, 2008 9:51 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Ok,
but try to do something for the policies....
Meanwhile you can perhaps try what you can do with mqsireportproperties
| Quote: |
mqsireportproperties.exe brk60 -e TEST -o AllReportableEntityNames -r
ReportableEntityName='MessageFlow'
ReportableEntityName='AllMessageFlows'
ReportableEntityName='ComIbmAggregateNodeFactory'
ReportableEntityName='ComIbmBasicNodeFactory'
ReportableEntityName='ComIbmConfigurationNodeFactory'
ReportableEntityName='ComIbmCpiParserFactory'
ReportableEntityName='ComIbmDBTxnCtxManager'
ReportableEntityName='ComIbmDatabaseConnectionManager'
ReportableEntityName='ComIbmDummyParserFactory'
ReportableEntityName='ComIbmGeneralParserFactory'
ReportableEntityName='ComIbmGenericParserFactory'
ReportableEntityName='ComIbmGenericXmlParserFactory'
ReportableEntityName='ComIbmIDOCParserFactory'
ReportableEntityName='ComIbmJVMManager'
ReportableEntityName='ComIbmJavaNodeFactory'
ReportableEntityName='ComIbmJavaPluginNodeFactory'
ReportableEntityName='ComIbmJmsTransformNodeFactory'
ReportableEntityName='ComIbmMQConnectionManager'
ReportableEntityName='ComIbmMQNodeFactory'
ReportableEntityName='ComIbmMQParserFactory'
ReportableEntityName='ComIbmMQeNodeFactory'
ReportableEntityName='ComIbmMtiParserFactory'
ReportableEntityName='ComIbmSCADANodeFactory'
ReportableEntityName='ComIbmSQLNodeFactory'
ReportableEntityName='ComIbmSocketConnectionManager'
ReportableEntityName='ComIbmTimeoutNodeFactory'
ReportableEntityName='ComIbmWSNodeFactory'
ReportableEntityName='ComIbmWSParserFactory'
ReportableEntityName='ComIbmXMLResourceManager'
ReportableEntityName='ComIbmXSLResourceManager'
ReportableEntityName='ComIbmXmlParserFactory'
ReportableEntityName='DynamicSubscriptionEngine'
ReportableEntityName='EventLog'
ReportableEntityName='JAR'
ReportableEntityName='LabelManager'
ReportableEntityName='MIMEFactory'
ReportableEntityName='TraceLog'
ReportableEntityName='UserTraceLog'
ReportableEntityName='EventLog'
ReportableEntityName='UserTraceLog'
ReportableEntityName='TraceLog'
mqsireportproperties.exe brk60 -e TEST -o AllMessageFlows -r > c:\temp\report_properties.txt
.
.
.
MessageFlow
uuid='6c31c474-1c01-0000-0080-c45ec425857b'
userTraceLevel='none'
traceLevel='none'
userTraceFilter='debugTrace'
traceFilter='none'
label='xxxx'
additionalInstances='0'
commitCount='1'
commitInterval='0'
coordinatedTransaction='no'
threadIdleTimeout='-1'
ComIbmLabelNode
.
.
.
|
Or with brokerresources table on broker db
| Quote: |
db2 "select cast(resourcename as varchar(36) for sbcs data),cast(resourcedata as varchar(25650) for sbcs data) from brokerresources where resourcetype = 'MessageFlow'" |
Marko |
|
| Back to top |
|
|
|
|
