| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Create an application to call a MQSI Statement from an ESQL |
« View previous topic :: View next topic » |
| Author |
Message
|
| akshat.jain |
 Posted: Wed Apr 16, 2014 10:27 am Post subject: Create an application to call a MQSI Statement from an ESQL |
 |
|
Novice
Joined: 02 Feb 2010
Posts: 13
|
Hi All,
As per my project's latest requirement, I will be receiving an XML on MQ, which will contain the following fields, i.e. Broker Name, Execution Group Name and Flow Name.
I have to create a process which will read this message from the queue, if required create a MQSI Command for the same and stop the respective Broker flow for further processing. End result is to stop the broker flow.
This is the only details i can provide as of now, I am currently using Broker 8.0 for my development.
Can anyone please suggest me the way / techniques which i can use to implement this requirement?
Regards,
Akshat |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Wed Apr 16, 2014 11:34 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Your requirement has one great big flaw.
What happens when you receive a message that will stop the flow that is processing the message? Then what happens when you are required to stop another flow? You can't because you are stopped.
May I humbly suggest that you go back to whoever gave you this requirement and ask them to think again.
Then there is the question of why you are trying to use Broker for something that clearly should be done by another method
For example the CMP API can do all this for you.
_________________
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 |
|
|
| akshat.jain |
| Posted: Thu Apr 17, 2014 4:04 am Post subject: |
|
|
Novice
Joined: 02 Feb 2010
Posts: 13
|
Hey,
Thanks for the response, But we will never receive a Message to Stop this flow, We have implemented an exit handler which will generate these XMLs from which the respective broker flow has to be stopped if the Database is failing. There is threshold for retry, and If the retry count is reached.
The data being received cannot be lost and the throughput is also large, I know it can be handled separately, but it would really be helpful, if we could stop the flows right away. So just want to know the way to do so.
We are also looking into other options. Can you please confirm if this could be done or we have to look for some other way?
Akshat |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Apr 17, 2014 4:22 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| akshat.jain wrote: |
Hey,
Thanks for the response, But we will never receive a Message to Stop this flow,
|
Things that can go wrong, will go wrong. Don't ever say never in the IT world. IT is asking for disaster 
| Quote: |
We are also looking into other options. Can you please confirm if this could be done or we have to look for some other way?
Akshat |
See the last line of my reply. Do it outside of broker.
Have you really covered every possible error code you can get back from your DB? Can you handle a network glitch? fails once but will work if you retry it?
That must be some hefty bit of ESQL in your exit handler.
IMHO/AFAIK, most people here shy away from this task simply because it is too hard. We tend to use other methods of not losing data in these in stances.
What happens if the DB has a Fixpack applied and some of the error conditions change? Are you able to test for each and every type of error you may get? Your use cases must be huge. I know from my own experiece that actually generating some of the error conditions in testing is very difficult if not downright impossible.
If you do get all this sorted out (i.e. the exit handle) I am sure that you will get a lot of interest here if you care to explain how you did it and were able to test each and every failure condition.
_________________
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 |
|
|
| akshat.jain |
| Posted: Fri Apr 18, 2014 7:55 am Post subject: |
|
|
Novice
Joined: 02 Feb 2010
Posts: 13
|
Hey,
I have created a sub flow as of now which checks all the exception encountered in the nodes after, As per my reading most of the Database related exceptions has a SQLSTATE as D% and it can be caught from there.
There is a 3 times retry for all database exceptions using the SLEEP function, after which the message is added to the Backout Queue and exception so received is send to a process a Exception sub flow for loading and processing.
Additional functionality required as a part was to stop and start flows when the database is not responding, as we have a central database, record and Replay also considered, but incase of DB exceptions the Messages were getting lost, as it also used database to store the messages.
Anyways, I will try to see if i can build anything outside the scope of broker to implement this. Thanks for all the help.
Akshat |
|
| 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
|
|
|
|
