| Author |
Message
|
| broker_new |
 Posted: Thu Oct 04, 2012 2:27 pm Post subject: WMBv8.0.0.1-> Application Development |
 |
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
Hi Guys,
We can start development work by starting by creating an application in broker toolkit which will have all project/application related objects in one place..i like the Idea but i realized that if we need to make any changes we need to redeploy all the artifacts for every deployment which means that we can't create a bar file to deploy a message flow/esql...file that we are interested in deploying...which results in regression test the complete application...do you agree? 
_________________
IBM ->Let's build a smarter planet |
|
| Back to top |
|
 |
| NealM |
| Posted: Thu Oct 04, 2012 3:59 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
OK, I'll agree, from a somewhat different angle. I usually end up with a couple disparate projects at a company, where I might group several totally independent flows that have related purpose (eg, environment control flows; experimental flows). Normally only a single flow in the project is being worked on/deployed at a time, and in the case of a grouping of experimental flows in a project, I may be re-using the same input queues and thus would not want to have all deployed. The new MB8 Application block deploy works counter to that, and I haven't yet got my brain around an equally satisfactory approach.
If you open an RFE I'll be happy to give it a vote. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Oct 04, 2012 10:27 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Currently...
I tend to use a separate Workspace/Toolkit instance for test/experimental 'stuff'. No SVN etc.
Then I prefer to have a separate workspace for each release version. Then I can apply maintenance to the currently deployed version whilst working on the next one. We have appropriate version branches in SVN.
moving forward to V8. All our current projects are based upon V7.0.0.4. All future one will be V8.0.0.1 (or later)
I take the view (yes I know that I'm a  ) in that if the deployable/executable object gets rebuilt then it must undergo full regression testing. Having everything (all flows etc) in one Application and making a change to one of them requiring a redeploy of everything does not fit into my idea of KISS. I need to do some experimentation but if it works as I currently understand it does, I won't be recommending the use of a single 'Application' when I update out 'best practices' guide next month.
I am willing to be corrected by those who understand it better but I'm not altogether sold in the benefits of 'Applications' vs separate projects and individually deployable objects.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Thu Oct 04, 2012 11:57 pm Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| smdavies99 wrote: |
| I take the view (yes I know that I'm a ) in that if the deployable/executable object gets rebuilt then it must undergo full regression testing. |
mqjeff and others recommend to check in bar files and deploy these. In Java there is more "build from source"... so at least when you go from a DEV- to a TEST-Environment in (old) Broker (times) you'd deploy the bar file that worked in your (local) DEV-Environment... in J2EE you check in your code and then 'build tooling' may create jars from source.
| smdavies99 wrote: |
| Having everything (all flows etc) in one Application and making a change to one of them requiring a redeploy of everything does not fit into my idea of KISS. I need to do some experimentation but if it works as I currently understand it does, I won't be recommending the use of a single 'Application' when I update out 'best practices' guide next month. |
As of my knowledge a couple of (meaningfully) grouped bar files (e.g. containing msg-sets and flows for one interface) is advisable. The unit that has been (is) tested in a broker world is rather the bar-file and you want to keep your (regression-)testing effords low. Again: In Java (imho) the source-code is / can be more the basis of testing / deployments.
ESQL is a scripting language: So you can look into the bar file (an the source code)... java is byte code (o.k. ... you may disassemble that (but: probably losing meaningful variable-names)).
As usual Java-ideas swapp towards / into the Broker world...
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| broker_new |
| Posted: Fri Oct 05, 2012 5:17 am Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
My question was more specific to the deployment.
If i would like to deploy a single message flow/esql/subflow from the application, we can't...we have to deploy the complete application..is it not defeating the standards?
_________________
IBM ->Let's build a smarter planet |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Oct 05, 2012 5:19 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| broker_new wrote: |
My question was more specific to the deployment.
If i would like to deploy a single message flow/esql/subflow from the application, we can't...we have to deploy the complete application..is it not defeating the standards? |
More granular applications would be in order.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| broker_new |
| Posted: Fri Oct 05, 2012 5:54 am Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
i didn't get you.my question is very transparent 
_________________
IBM ->Let's build a smarter planet |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Fri Oct 05, 2012 6:12 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| broker_new wrote: |
| i didn't get you.my question is very transparent |
Normally, I would recommend training; but you don't seem to be grapsing the basic WMB documentation. Maybe you should start with a more mainstream technology like Java to get the hang of things. In order to be successful at using IBM WebSphere Message Broker, you need to be able to read and understand the documentation as it is presented in the InfoCentre format. I'll grant you the organization of the InfoCentre is difficult to get used to .
To more explain my suggestion around fine-grained granularity: If your business requirement is to be able to deploy parts of things, and your application is a composite of several parts, then you need to break up your application so that it is in smaller chunks, and have several smaller applications rather than one monolithic giant application.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| broker_new |
| Posted: Fri Oct 05, 2012 6:34 am Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
I think i need to come 2 steps down....
it doesn't really make sense to split the projects into multiple projects just for the sake of deployment....all i am saying is why don't we allow the option of choosing the message flows/sets/ that we are interested in deployment..
It makes sense for the initial deployment that we have to deploy the complete application....
This questions is more specific to the enhancements...we have to deploy the complete application vs deploying the specific module.
_________________
IBM ->Let's build a smarter planet |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 05, 2012 6:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The whole point of an application is that it's a unit of deployment, more or less.
In essence, you should work with independent resources until you know you have a firm unit. Then you should consolidate things into an app or a library and deploy that.
There's still some work going on in this area, though, so I halfway expect that behavior will change over the next couple of fixpacks - particularly if people file RFEs... |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Oct 05, 2012 7:44 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
lancelotlinc
Normally, I would recommend training
|
The OP has been around this forum a lot longer than yourself. The issue is more of making the right choices when you move to V8 not training.
By the way, havve you done your V8 training yet? 
back to the subject.
If you choose to use a project structure in V8.0.0.1 identical to that of V7.0.0.x then you may get lots of these warnings. This is what you get if you import from a V7 esported workspace AND have projects that are referenced in several other ones.
| Code: |
Subflow defined in the LOGGING/LOGGING.msgflow file within message flow is supported during development but handled differently when added to the BAR file. When deployed, it can only be in-lined into the parent flow as part of compiled flow CMF. If you choose to deploy the parent flow as a source file then the error message is displayed during creation of the BAR file. XXXXX.msgflow /XXXX Unknown Message Flow Node Content Problem
|
That is fine but I really don't want 220 (thats how many I see with my current environment) warnings present all the time. I'll have to work out if I can turn just these ones off when I get some time and can concentrate on moving to V8.
[/quote]
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Oct 06, 2012 2:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smdavies99 wrote: |
| Code: |
Subflow defined in the LOGGING/LOGGING.msgflow file within message flow is supported during development but handled differently when added to the BAR file. When deployed, it can only be in-lined into the parent flow as part of compiled flow CMF. If you choose to deploy the parent flow as a source file then the error message is displayed during creation of the BAR file. XXXXX.msgflow /XXXX Unknown Message Flow Node Content Problem
|
|
You should be able to tell Toolkit not to report this warning.... or, well, at least, not *display* this warning. If nothing else, I know you can tell it to only show warnings on the *current* project.
Otherwise you can rename all your ".msgflow" files that are subflows as ".subflow" and this warning will go away. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Oct 06, 2012 6:10 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| mqjeff wrote: |
Otherwise you can rename all your ".msgflow" files that are subflows as ".subflow" and this warning will go away. |
Sadly you can't do that through the tool kit.
Test case.
Message flow with a subflow. thus two .msgflow files in the same project
You can't rename the subflow to .subflow in the toolkit. You can try but 8.0.0.1 won't accept anything but .msgflow.
Oh well, I'll just have to keep trying nowt much else to do out here in the Desert.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Oct 06, 2012 6:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| smdavies99 wrote: |
| You can't rename the subflow to .subflow in the toolkit. You can try but 8.0.0.1 won't accept anything but .msgflow. |
Yeah.
You have to choose the "convert to subflow" item in the pop-up menu when you right-click on the .msgflow file.
Which renames it to .subflow. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Oct 06, 2012 7:49 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Thanks mqjeff. That solved it apart from one flow. I'll take a look at it another time. Now I have to get back to the wonders (not) of SNMP traps.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
