| Author |
Message
|
| WMBDEV1 |
 Posted: Tue Oct 05, 2010 1:36 am Post subject: |
 |
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Quote: |
I didn't expect I would be required to explain this, as I tried to reduce my problem to its simplest form for clarity, but if you *really* want to know the background, here goes |
People only ask these questions so that they can help understand the issue and offer advice. By doing so we aim to help you evolve from the following position:
| Quote: |
| I also have very little experience with WMB (as you may have guessed) |
into a more rounded developer.
| Quote: |
This has to be completed by the end of the week, hence my fairly obtuse questions, and the need for quick answers. I don't really have time to experiment and play around
|
Time is exactly what you need on a task like this (which sounds like prototyping to me). My concern is that if you dont have the time to "play around" or listen to the suggestions of other more experienced members of the community then you will just move first hack prototype quality solutions into production environments, which may cause you issues further down the line.
| Quote: |
For now, I have an answer and can progress.
|
Congratulations. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Oct 05, 2010 4:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kimbert wrote: |
On the other hand, Vitor said:
| Quote: |
| using a WMB flow to move a file from one place to another is a large sledgehammer on a very small nut. |
Quite true - that would not be the sort of problem that requires WMB. But your problem is more complex than that. It involves parsing and transformation of the input file, and a change from file system to MQ. |
It's not just a file transfer, there's content manipulation as well and there's the reasoning for using WMB right there.
I remain convinced in my own mind that (especially given the tight deadline) ESQL is a better choice for this but if you've got a solution you've got a solution.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| afielden |
| Posted: Tue Oct 05, 2010 5:05 am Post subject: |
|
|
Novice
Joined: 30 Sep 2010
Posts: 10
|
| kimbert wrote: |
| Quote: |
The data file is produced by a legacy application which is used within the company. The requirement is to read this data file, pick out relevant bits of information, and transform it into XML. This XML then sent to a message queue, and the message is picked up by a new system intended to replace the old one.
There are many other legacy apps which will have the same procedure applied... |
You probably won't believe me, but that sounds like the kind of problem that WMB solves very well.
|
Oh I do believe you. I think WMB is a very impressive and powerful product, but we're scratching the surface of its capabilities.
| Quote: |
| Quote: |
| the basic problem was how to use WMB to read a file, access the data, and transform it into XML |
That should be easy - it's a standard problem for WMB. Your problem is that you are trying to use WMB as a Java container in the mistaken belief that you will get the job done faster that way.
|
I will because I know Java much better than WMB
| Quote: |
I still believe the best approach is:
- create a TDS message set to describe your file format. I can help with that.
- set Domain to 'MRM' on the input node, and set the Message Set/Message Type/Message Format properties to reference your TDS message set and its physical format.
- Forget Java. Insert one ordinary Compute node which has one line of ESQL, as follows:
| Code: |
| SET OutputRoot.XMLNSC.rootTag = InputRoot.MRM; |
Or you can continue to fight with the Java / BLOB solution if you like - I gave some good advice 4 days ago on how to make progress there. But I don't believe it's the right way, or that it will produce a good result for your business/client. |
Well its a question of how much effort is required in defining the message set.
From a Java point of view, once I have the message contents (line of file), the code is simple to extract the required fields from the line. |
|
| Back to top |
|
|
| afielden |
| Posted: Tue Oct 05, 2010 5:12 am Post subject: |
|
|
Novice
Joined: 30 Sep 2010
Posts: 10
|
| Vitor wrote: |
| kimbert wrote: |
On the other hand, Vitor said:
| Quote: |
| using a WMB flow to move a file from one place to another is a large sledgehammer on a very small nut. |
Quite true - that would not be the sort of problem that requires WMB. But your problem is more complex than that. It involves parsing and transformation of the input file, and a change from file system to MQ. |
It's not just a file transfer, there's content manipulation as well and there's the reasoning for using WMB right there.
I remain convinced in my own mind that (especially given the tight deadline) ESQL is a better choice for this but if you've got a solution you've got a solution. |
Unfortunately, I don't have the time to become proficient in ESQL. I do however know Java very well, so it won't take me long to code a solution in this language. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 05, 2010 5:25 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| afielden wrote: |
| Well its a question of how much effort is required in defining the message set. |
And if that effort is greater or lesser than devleloping the Java. Not knowing Java or your situation I can't answer that, and suspect only you can.
| afielden wrote: |
| From a Java point of view, once I have the message contents (line of file), the code is simple to extract the required fields from the line. |
But if WMB was selected early on in the project, the "some reason" you wondered about in an earlier post is probably because it can do this sort of thing very easily and efficiently. If you're just going to use it as a Java container, push back and suggest they buy WAS instead. It's cheaper.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| afielden |
| Posted: Tue Oct 05, 2010 5:33 am Post subject: |
|
|
Novice
Joined: 30 Sep 2010
Posts: 10
|
| Vitor wrote: |
But if WMB was selected early on in the project, the "some reason" you wondered about in an earlier post is probably because it can do this sort of thing very easily and efficiently. If you're just going to use it as a Java container, push back and suggest they buy WAS instead. It's cheaper. |
There are open source JMS solutions available, which would have been sufficient for this project. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 05, 2010 5:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| afielden wrote: |
| There are open source JMS solutions available, which would have been sufficient for this project. |
And yet someone paid a ton of money for WMB. I repeat my suggestion to push back.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| afielden |
| Posted: Tue Oct 05, 2010 5:59 am Post subject: |
|
|
Novice
Joined: 30 Sep 2010
Posts: 10
|
| Vitor wrote: |
| afielden wrote: |
| There are open source JMS solutions available, which would have been sufficient for this project. |
And yet someone paid a ton of money for WMB. I repeat my suggestion to push back. |
I certainly would have, if I'd been employed by the company at the time this decision was made. WMB had already been purchased before I started. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 05, 2010 6:03 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I b'lieve he meant push back on 'I don't have time to become proficient in ESQL' and 'I don't have time to develop a message set', not 'I don't think we should use WMB'.
Certainly one of the reasons that WMB includes a JavaCompute node is so that developers do not have to learn ESQL before getting started or even at all.
But unless the data you are parsing is nothing more complicated than a set of fixed length fields, you will be ignoring one of the more powerful features of Broker by doing any complicated parsing at all in Java rather than using a message set. Unless the data is really complicated and there is an existing java parsing solution for it... note that this last comment does not apply to XML. |
|
| Back to top |
|
|
| Jwoodriff |
| Posted: Tue Oct 05, 2010 7:11 am Post subject: Could Someone please summarise |
|
|
Newbie
Joined: 05 Oct 2010
Posts: 1
|
WTF......
I am a WMB7 Noob and have a similar problem. Reading this article was painful, from learning to fish and with a rather choice fishing metaphor which I am sure helped someone. We then have the eating cereal senario, My son likes eating his own boogies, he likes that, doesn't mean I do and definately doesn't help me with WMB. You then tell this poor soul to use MQInput, why would you, when you are trying to read a file, can you even do such a thing.
It looks to me that on the second page you answered the guys question, as he does actually state this!
Then we get the esql vs java bs, great the guy wants Java yet you keep specifying cast it with SET blah.blah (cast) isn't that eSQL, boy that was a useful post.
There aren't enough answers to MQ questions as is, so please guys be to the point. WMB7 is great whether u use eSQL or Java, but please help us noobs by keeping it simple or just simply to the point. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Tue Oct 05, 2010 7:45 am Post subject: Re: Could Someone please summarise |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Jwoodriff wrote: |
Then we get the esql vs java bs, great the guy wants Java yet you keep specifying cast it with SET blah.blah (cast) isn't that eSQL, boy that was a useful post.
|
I have already tried to explain why people here spend their own time and effort persisting with these approaches and I'm sorry if my responses were "painful" to you but I, like others do try to be constructive! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 05, 2010 9:04 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And let's just be clear. There is nothing wrong in using a java compute node approach.
However WMB is a complex product, and for someone who just knows java and knows nothing of WMB such an approach will not do.
Newbies especially, will have to push back and ask their hierarchy for training.
If there is no budget the higher ups will have to realize that it will take a lot more time before the newbie can get through the required documentation ... and understand it.
Trust me, I know java, and I did not get all the documentation on JCN nodes the first time I read through it... You need experimentation and practice to fully understand the consequences of the choices you commit to.
Sometimes, like a lot of others, I find ESQL just to be easier to read and maintain...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 05, 2010 9:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Admiting to a Java phobia and without disagreeing with a single word posted by my most worthy associates, one of the principle management drivers for investing in WMB is that it does this kind of task efficiently and with minimal coding. Those who made such a decision can often be disapointed to learn that the product is not being leveraged in this way and they've ended up with a suite of Java applications.
It can be legitimately argued here that investment in training at the same level as the investment in software purchase would have helped.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Oct 05, 2010 9:38 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
Esteemed collegue Vitor said:
| Quote: |
| WMB ... minimal coding |
If by coding, you mean typing characters, you may have some point. However, WMB Toolkit is a 4GL graphical-based environment and the actual coding is graphical-based. So I see the marketing point about less code using WMB as not accurate.
| Quote: |
| ended up with a suite of Java applications |
What is wrong with that? WMB is a high speed messaging engine. As long as what is coded works, who cares what language was used to code inside the ESB? Does it meet performance and quality objectives?
@Jwoodriff
Lighten up, friend. We need humor. Nothing worse than technospeak without left-field references to humorous events, objects, characters. By the way, have you taken VM663 or equivalent yet?
Book'em Danno!
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 05, 2010 9:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
Esteemed collegue Vitor said:
| Quote: |
| WMB ... minimal coding |
If by coding, you mean typing characters, you may have some point. However, WMB Toolkit is a 4GL graphical-based environment and the actual coding is graphical-based. So I see the marketing point about less code using WMB as not accurate. |
IMHO you're splitting hairs. If you generate a message set by importing a copybook or similar, and then wish to output it as XML, coding (in terms of effort) is minimal.
I'm not going to argue on number of keystrokes for a given solution.
| lancelotlinc wrote: |
| Quote: |
| ended up with a suite of Java applications |
What is wrong with that? WMB is a high speed messaging engine. As long as what is coded works, who cares what language was used to code inside the ESB? Does it meet performance and quality objectives? |
My point was that if you're going to end up with a suite of Java applications then there are solutions that have a smaller footprint within the server & certainly smaller license costs than WMB. I'm the first to admit that an ESB can be built from a number of possible platform & toolkits, including a pure Java one. The last to admit that's the best solution perhaps, but that's a separate discussion.
I was simply trying to articulate that if you're not going to use the functionality provided by WMB but (as this poster appears to have plumped for) simply write Java to process the messages longhand (rather than have WMB do some of the lifting for you) then it's an expensive way of doing it. Not the wrong way, not a bad way, just an expensive way.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
