| Author |
Message
|
| EnOne |
 Posted: Mon Jul 15, 2013 7:05 am Post subject: msgflow code review or comparison tools |
 |
|
Centurion
Joined: 09 Oct 2002
Posts: 100
Location: Kansas City
|
| How do people do code reviews of message flows? ESQL changes are easy to spot but the XML within a msgflow isn't set up to be easily human readable. Manually keeping a Print Screen of every message flow to keep track of changes is clunky and prone to errors like any type of manual process. Is there a code review or comparison tool that includes a msgflow reader? |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Jul 15, 2013 7:16 am Post subject: Re: msgflow code review or comparison tools |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| EnOne wrote: |
| How do people do code reviews of message flows? ESQL changes are easy to spot but the XML within a msgflow isn't set up to be easily human readable. Manually keeping a Print Screen of every message flow to keep track of changes is clunky and prone to errors like any type of manual process. Is there a code review or comparison tool that includes a msgflow reader? |
Code reviews are done by senior WMB developers on the blackbox function of the message flow as a whole. No one (that I know of) does code review on the XML. Peer code reviews are sometimes done on the diagram.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| EnOne |
| Posted: Mon Jul 15, 2013 10:46 am Post subject: |
|
|
Centurion
Joined: 09 Oct 2002
Posts: 100
Location: Kansas City
|
| How do they see what the old message flow looked like and compare it to the updated one? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jul 15, 2013 11:18 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| EnOne wrote: |
| How do they see what the old message flow looked like and compare it to the updated one? |
Peer code reviews usually don't care about what the past was. We want to know what the present state of the diagram is and why it exists this way.
If you properly organize your message flows, your diagrams are usually fairly simple, not complex. If your diagrams look like a linear map to buried treasure, then its a good clue that you are well organized. If your diagrams look like a spider's web, with lots of circular paths, then its a good clue your message flow is dis-organized and likely won't work as intended.
A design review walks through the diagram step-by-step with the developer explaining why he/she connected nodes and wrote code in a certain way.
Its a shoe-in that looking at the XML code for a message flow diagram, no developer could explain it satisfactorily.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 15, 2013 11:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EnOne wrote: |
| How do they see what the old message flow looked like and compare it to the updated one? |
We compare the PDFs produced out of the Toolkit as part of the stage gate this time and last time. Not scientific but I'm not aware of an automated method.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 15, 2013 9:14 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'm not aware of any automated method.
The msgflow is just an XML file, so some processing could be written to be smarter about the compare - to notice that nodes were added or removed or that node connections were changed.
It's not entirely clear that other changes are terribly meaningful. The only property changes that should matter are ones that are not overridable. |
|
| Back to top |
|
|
| vsc |
| Posted: Mon Jul 15, 2013 11:20 pm Post subject: |
|
|
Newbie
Joined: 15 Jul 2013
Posts: 7
|
Hi
we use clear case to compare the code with predecessor.
we also have "MARS - Messagebroker Automated Review System"
just type the above string in google
This might help. |
|
| Back to top |
|
|
| EnOne |
| Posted: Wed Jul 17, 2013 5:44 am Post subject: |
|
|
Centurion
Joined: 09 Oct 2002
Posts: 100
Location: Kansas City
|
vsc: Thank you I will look into MARS.
Vitor: I don't know how to create a PDF from the Broker Toolkit, but I can create XPS files which should work the same. I will suggest that to my team.
mqjeff: what I am looking for between the different version is to make sure that the connections that existed before exist in the new version. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Jul 17, 2013 6:51 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| EnOne wrote: |
| mqjeff: what I am looking for between the different version is to make sure that the connections that existed before exist in the new version. |
you mean if the change was in ESQL only, that no connections were accidently broken or deleted?
I can imagine in a change a connection gets changed or deleted on purpose 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| EnOne |
| Posted: Thu Jul 18, 2013 6:40 am Post subject: |
|
|
Centurion
Joined: 09 Oct 2002
Posts: 100
Location: Kansas City
|
I've had three typical places where a connection is changed/lost
1. The developer adds a trace node in development and when they delete it before going to production they do not get all the correct connections back.
2. The developer adds in a new node but does not keep all the old connections
3. The developer reconnects everything but connects to "Out1" instead of "Out"
The third type is noticeable when comparing message flows, the first two are not. |
|
| Back to top |
|
|
| fatherjack |
| Posted: Thu Jul 18, 2013 6:49 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| EnOne wrote: |
I've had three typical places where a connection is changed/lost
1. The developer adds a trace node in development and when they delete it before going to production they do not get all the correct connections back.
2. The developer adds in a new node but does not keep all the old connections
3. The developer reconnects everything but connects to "Out1" instead of "Out"
The third type is noticeable when comparing message flows, the first two are not. |
Surely you spot these mistakes in testing!
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Jul 18, 2013 7:21 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| EnOne wrote: |
I've had three typical places where a connection is changed/lost
1. The developer adds a trace node in development and when they delete it before going to production they do not get all the correct connections back.
2. The developer adds in a new node but does not keep all the old connections
3. The developer reconnects everything but connects to "Out1" instead of "Out"
The third type is noticeable when comparing message flows, the first two are not. |
You should not modify your flows prior to production. There is no reason to delete Trace nodes. Simply turn them off. mqsichangetrace - off disables Trace nodes. Disabled Trace nodes use virtually no resources and do not impact latency.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| fatherjack |
| Posted: Thu Jul 18, 2013 7:26 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| lancelotlinc wrote: |
| There is no reason to delete Trace nodes |
But if you choose to do so then you need to rerun your tests otherwise you are putting into production something you have never tested!
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
|
|
