| Author |
Message
|
| sebastia |
 Posted: Sun Feb 17, 2013 2:22 am Post subject: .msgflow version |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Good morning.
We are using the "Version" field to identify versions of the .msgflow, clicking on the canvas and then going "Properties".
Can we access this field from within ESQL, in a Compute Node ?
And how can we Trace this value ?
Sebastian. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Sun Feb 17, 2013 5:19 am Post subject: Re: .msgflow version |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
Can we access this field from within ESQL, in a Compute Node ?
And how can we Trace this value ? |
Why?
The only value that springs to mind is that your version control is broken & you don't know what version of what flow you're running, or you're trying to route traffic based on the version of the flow rather than the payload of the message. Which is a very odd solution.
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Sun Feb 17, 2013 7:11 am; edited 2 times in total |
|
| Back to top |
|
|
| sebastia |
| Posted: Sun Feb 17, 2013 5:53 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Maybe I am not sure of what version of flow is running, yes. Or viceversa, I want to make sure that this trace corresponds to that flow version. The opposite (I think i am debugging version A but the trace is from version B) is a situation I dont want to be involved into.
Is this string is available, I would like to display it.
And maybe use it to route trafic, why not ... just one final branch to enque here or there ...
Sebastian. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Feb 17, 2013 7:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| Maybe I am not sure of what version of flow is running, yes. |
No, you should always have sufficient control to be sure what's running. Even if "you" is the administrator.
| sebastia wrote: |
| I want to make sure that this trace corresponds to that flow version. The opposite (I think i am debugging version A but the trace is from version B) is a situation I dont want to be involved into. |
If you had authority to obtain a trace, you have authority to obtain version from the command line.
| sebastia wrote: |
| Is this string is available |
I don't believe you can use this or any of the other non-exposed properties in ESQL. I'll stand correction.
| sebastia wrote: |
| And maybe use it to route trafic, why not ... just one final branch to enque here or there ... |
So you've got 2 versions of the same flow, which must be running in different execution groups, and you have (by some means) determined which version of the flow will receive the payload via a transport mechanism which must be aware of the broker's EG structure (or couldn't have found the correct flow version) and depending on which version of the flow the flow detects it is, it then routes the message to 1 destination or another and all of this has nothing to do with the message itself (or you'd be determining routing from either content or metadata) and everything to do with which version of the flow code you invoked.
IMHO that's why not, if you have a use case that calls for that I'd be interested in an outline and I'm going to stick with "very odd solution".
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Sun Feb 17, 2013 8:53 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Vitor : you are suposing we are working on real time, and that maybe is not the case. We had a problem, we have a trace, and the BAR in the EG now is the same or maybe not.
I like to have a trace node in the flow, and I would like it to write some text into the text output file, and maybe change the flow - I am still developing maybe ... Just asking "is it possible or not" .. and i get a strange question - "why do you want to do this?"
I am learning MQ and ESQL and would like to know if it is possible or not.
Someone told me "keep your mind open" ... and I try.
Sebastian. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Feb 17, 2013 12:12 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 18, 2013 6:28 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| Vitor : you are suposing we are working on real time, and that maybe is not the case. We had a problem, we have a trace, and the BAR in the EG now is the same or maybe not. |
I did not suppose that, and I repeat my assertion above that if you have the administrative ability to obtain a trace you have the administrative ability to obtain the version property of the flow deployed into the execution group. No ESQL needed.
I'll also remind you that you don't deploy BAR files to execution groups. You deploy message flows & message sets that are contained in BAR files. This can be significant, especially in troubleshooting situations, if a BAR file contains a previous version of a flow that it's not supposed to be in it. I repeat my comments regarding controls, especially in non-development environments.
| sebastia wrote: |
| Just asking "is it possible or not" .. and i get a strange question - "why do you want to do this?" |
The answer to "is it possible" is always "what happens when you try it?". Depending on why you want to do it, it may be possible to achieve your aims by other means which we can advise you of. As I'm pointing out the administrative options open to you. I call this "helping".
| sebastia wrote: |
Someone told me "keep your mind open" ... and I try.
Sebastian. |
You could also try opening your mind to the possibility I'm not on your case just because I asked a question in response to your question.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 18, 2013 7:47 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The broker's Java Admin API can give you as much information as the toolkit.
Just remember to close the resource. Also remember to store the information in a variable with the appropriate scope and to require that information only once at flow start.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| craigp |
| Posted: Mon Feb 18, 2013 3:24 pm Post subject: |
|
|
Newbie
Joined: 28 Mar 2011
Posts: 8
|
Hi,
We approach this a little differently, I have a flow with an HTTP input node,
Testers/Developers can access this via an HTTP get, and then we have an XSLT on the flow:
| Code: |
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<head>
<title>Version</title>
<style type="text/css">
h1 { font-size: 11pt; margin: 0 0 0 0; color: #454c5d;
font-weight: bold; }
</style>
</head>
<body>
<center>
<h1>Message Broker Version Flow</h1>
<div><font size="2" color="red">Version : MB_@build_module@_@build_version@</font></div>
<div><font size="2">Build Master : @build_user_id@</font></div>
<div><font size="2">Build ID : @build_version@</font></div>
<div><font size="2">Build Date: @build_date_time@</font></div>
</center>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
|
ANT substitutes the real values at build time copying the file into a temp workspace and the XSLT gets packaged into the BAR.
| Code: |
<!-- Copy the version XSL file -->
<copy todir="${workspace.dir}/@{module}/common.flows" overwrite="true">
<fileset dir="${src.root}/${project.path.common.flows}">
<include name="**/*.xsl"/>
<include name="**/*.msgflow"/>
</fileset>
<filterset>
<filter token="build_module" value="@{module}"/>
<filter token="build_version" value="@{version}"/>
<filter token="build_date_time" value="${build.time}"/>
<filter token="build_user_id" value="${user.name}"/>
</filterset>
</copy>
|
We can see what version is running in each execution group real time.
(Good for testers/fixed in build etc). |
|
| Back to top |
|
|
|
|
