| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Truncating fields vs real validation |
« View previous topic :: View next topic » |
| Author |
Message
|
| frankie72 |
 Posted: Mon Dec 12, 2011 8:30 am Post subject: Truncating fields vs real validation |
 |
|
Newbie
Joined: 05 Oct 2011
Posts: 5
|
Hi. I have a request from application side to do something they outhgt to handle themselves and need some feedback
Application cannot/will not implement field length validation.. so they want to ESB to truncate fields to 11chars. Fine.. I can live with that somewhat. BUT they also want us to IF field > longer than 11 chars, send email to support org.
Thats a whole different story to me. Means I have to do logic that actually checks the length and then take actions based on that. I mean, if its "just" truncating meaning no actual validation, then I suppose, it would not steal much processor time etc, but, by doing actual validation then that is probably going to cost much more performance wise..
So, should I take the fight. Refuse to do this and let application handle this in the first place? How have you guys handled similar issues? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Dec 12, 2011 8:48 am Post subject: Re: Truncating fields vs real validation |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| frankie72 wrote: |
| So, should I take the fight. Refuse to do this and let application handle this in the first place? How have you guys handled similar issues? |
My personal 2 cents:
There is a long and dishonourable tradition of WMB cleaning up after applications and/or wiping the drool from their chins. Your story of "we can't implement that in the application because our framework doesn't support it / our delivery plan is backed up / our implementation schedule is after go live" is depressingly familar to me.
So you're right, this is an application issue. You should fight. You should be prepared to lose; if you don't then yay. If you do (or it looks like you will) at a psychologically significant point, sigh & agree to do it ensuring that everybody (especially management) knows that it's a PITA for you, you're taking one for the team and it's just because the application is useless. Huff and let your shoulders droop when anyone asks how you're doing. Ensure that other broker development is delayed because of this, drinking enough coffee to ensure a management measurable delay occurs if the coding is simplistic. 
In terms of performance, it's not that bad. Every time you truncate a field add the field name & original value to an Environment variable. Once you've finished anything in that variable should be formed into a message and sent to another flow that asyncronously sends the support email. So the only extra "cost" to the real flow is assembling the data and how much it costs to send the email is irrelevant because it's not impacting the SLA or anything else that matters. Also keeps the whole "email is out / mailbox is full" scenario away from your actual business flow.
Like I said, personal view. Other views (and other technical solutions) are equally valid and may have more merit.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 12, 2011 8:58 am Post subject: Re: Truncating fields vs real validation |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| frankie72 wrote: |
| Application cannot/will not implement field length validation.. |
Is this any kind of revenge for having to deal with files properly as you indicate here? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| frankie72 |
| Posted: Mon Dec 12, 2011 11:23 am Post subject: Re: Truncating fields vs real validation |
|
|
Newbie
Joined: 05 Oct 2011
Posts: 5
|
| Vitor wrote: |
| frankie72 wrote: |
| So, should I take the fight. Refuse to do this and let application handle this in the first place? How have you guys handled similar issues? |
My personal 2 cents:
There is a long and dishonourable tradition of WMB cleaning up after applications and/or wiping the drool from their chins. Your story of "we can't implement that in the application because our framework doesn't support it / our delivery plan is backed up / our implementation schedule is after go live" is depressingly familar to me.
So you're right, this is an application issue. You should fight. You should be prepared to lose; if you don't then yay. If you do (or it looks like you will) at a psychologically significant point, sigh & agree to do it ensuring that everybody (especially management) knows that it's a PITA for you, you're taking one for the team and it's just because the application is useless. Huff and let your shoulders droop when anyone asks how you're doing. Ensure that other broker development is delayed because of this, drinking enough coffee to ensure a management measurable delay occurs if the coding is simplistic.
In terms of performance, it's not that bad. Every time you truncate a field add the field name & original value to an Environment variable. Once you've finished anything in that variable should be formed into a message and sent to another flow that asyncronously sends the support email. So the only extra "cost" to the real flow is assembling the data and how much it costs to send the email is irrelevant because it's not impacting the SLA or anything else that matters. Also keeps the whole "email is out / mailbox is full" scenario away from your actual business flow.
Like I said, personal view. Other views (and other technical solutions) are equally valid and may have more merit. |
Thanks. I will try to make this as painful as possible for application =)
I dont follow your coding logic/solution though. Im used to esql and to truncate i just do SET field = esql.right((myfieldvaluehere),11) or something similar (im pretty sure you java gurus out there have a really neat function for this). So, I'm not really keeping track if the truncation is needed or not. And theres my dilemma. I now need to keep track of if the truncation was really needed in first place if you follow. So one extra IF length > 11 somewhere.. If I read your suggestion you should keep track of when the truncation was actually needed and then assemble all of those into one message and send via email. Perhaps the extra IF not so costly performance wise after all. The application side will probably accept anything as long as they can blame the ESB if anything goes wrong.. sounds familiar huh =) |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 12, 2011 11:33 am Post subject: Re: Truncating fields vs real validation |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| frankie72 wrote: |
| If I read your suggestion you should keep track of when the truncation was actually needed and then assemble all of those into one message and send via email. |
That was entirely based on my perception of the likely response of the support people to the email. I took the view that if you sent an email with just "WMB had to truncate a field" they're more likely to ask "which field" than look at the input to see which field was too long.
| frankie72 wrote: |
| Perhaps the extra IF not so costly performance wise after all. |
There may well be some ingenious way to truncate the field and record the fact in a single operation (esql.right sounds like a Mapping node to me which adds slightly to that challenge IMHO). It comes down to exactly how you're doing the transformation, what exactly you need to produce and how ingenious a coder you are.
I stand by my assertion that other & possibly better solutions than the one I expounded may exist. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| inMo |
| Posted: Mon Dec 12, 2011 11:49 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
| Quote: |
| SET field = esql.right((myfieldvaluehere),11) |
Assuming you go along with the powers that be, you'll need to get a bit more creative then the blind truncate.
| Quote: |
| im pretty sure you java gurus out there have a really neat function for this |
Have you considered ESQL's "CREATE FUNCTION"? |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
