ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » WMBv8.0.0.1-> Application Development

Post new topic  Reply to topic
 WMBv8.0.0.1-> Application Development « View previous topic :: View next topic » 
Author Message
broker_new
PostPosted: Thu Oct 04, 2012 2:27 pm    Post subject: WMBv8.0.0.1-> Application Development Reply with quote

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
View user's profile Send private message
NealM
PostPosted: Thu Oct 04, 2012 3:59 pm    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Thu Oct 04, 2012 10:27 pm    Post subject: Reply with quote

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
View user's profile Send private message
mqsiuser
PostPosted: Thu Oct 04, 2012 11:57 pm    Post subject: Reply with quote

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
View user's profile Send private message
broker_new
PostPosted: Fri Oct 05, 2012 5:17 am    Post subject: Reply with quote

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
View user's profile Send private message
lancelotlinc
PostPosted: Fri Oct 05, 2012 5:19 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
broker_new
PostPosted: Fri Oct 05, 2012 5:54 am    Post subject: Reply with quote

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
View user's profile Send private message
lancelotlinc
PostPosted: Fri Oct 05, 2012 6:12 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
broker_new
PostPosted: Fri Oct 05, 2012 6:34 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Fri Oct 05, 2012 6:43 am    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Fri Oct 05, 2012 7:44 pm    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Sat Oct 06, 2012 2:20 am    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Sat Oct 06, 2012 6:10 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Sat Oct 06, 2012 6:17 am    Post subject: Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Sat Oct 06, 2012 7:49 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » WMBv8.0.0.1-> Application Development
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.