| Author |
Message
|
| bijesh |
 Posted: Wed Mar 14, 2007 8:41 pm Post subject: A Query |
 |
|
Acolyte
Joined: 30 Jan 2007
Posts: 66
|
Hi All,
Need your help.
The problem Statement.
I've a flow which sends a request using a custom HTTPS request node and receives responses. According to certain bad responses, I need to retry posting the same request again. I need to keep track of the number of times a particular message has been retried. How can I keep track of this counter. The counter should be associated with every request. I can't manipulate the request XSD for having one more field which contains the counter. Can anything be done with the Environment Variables?
Any thoughts to share??? |
|
| Back to top |
|
 |
| marcin.kasinski |
| Posted: Thu Mar 15, 2007 12:48 am Post subject: Re: A Query |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| bijesh wrote: |
Hi All,
Can anything be done with the Environment Variables?
Any thoughts to share??? |
Yes,
I think this is good idea.
Simple scenario...
You can implement loop.
When you get "bad response" in compute increment some Environment variable (set to 0 if doesn't exists) and connect out terminal with in terminal of HTTPRequest.
In this compute if you reach max number of attempts you can send message to other terminal |
|
| Back to top |
|
|
| bijesh |
| Posted: Thu Mar 15, 2007 1:14 am Post subject: Re: A Query |
|
|
Acolyte
Joined: 30 Jan 2007
Posts: 66
|
| marcin.kasinski wrote: |
Yes,
I think this is good idea.
Simple scenario...
You can implement loop.
When you get "bad response" in compute increment some Environment variable (set to 0 if doesn't exists) and connect out terminal with in terminal of HTTPRequest.
In this compute if you reach max number of attempts you can send message to other terminal |
this can be done. I've already implemented similar one and it works fine.
Now.
Suppose the response is bad and the message is put into a queue where it is made to wait for some time. After certain time the message is supposed to be posted again. If the response is bad again then it goes back to the queue where it is made to wait for some more time, else the message goes to the success queue. In this case, we cannot have a variable in the environment keeping the counter, right?Because when a message is made to wait for sometime in the queue , some other fresh message can come and that will be using the environment variables' value, right?
hope i've not confused you.
Any solution in tht case. |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Thu Mar 15, 2007 1:29 am Post subject: Re: A Query |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| bijesh wrote: |
| marcin.kasinski wrote: |
Yes,
I think this is good idea.
Simple scenario...
You can implement loop.
When you get "bad response" in compute increment some Environment variable (set to 0 if doesn't exists) and connect out terminal with in terminal of HTTPRequest.
In this compute if you reach max number of attempts you can send message to other terminal |
this can be done. I've already implemented similar one and it works fine.
Now.
Suppose the response is bad and the message is put into a queue where it is made to wait for some time. After certain time the message is supposed to be posted again. If the response is bad again then it goes back to the queue where it is made to wait for some more time, else the message goes to the success queue. In this case, we cannot have a variable in the environment keeping the counter, right?Because when a message is made to wait for sometime in the queue , some other fresh message can come and that will be using the environment variables' value, right?
hope i've not confused you.
Any solution in tht case. |
Then
- when you put this message into "Badresponse queue" add extra data into body which contains number of atempts.
-when you read "Badresponse queue" befor HTTPRequest delete this extra data from body and put into Environment.
- if response is correct do your code
- if response is bad read extra data from Environment , increment value, check if it reaches max number of attempts, add this extra data into body and send message into "Badresponse queue" .
Marcin |
|
| Back to top |
|
|
| bijesh |
| Posted: Thu Mar 15, 2007 1:55 am Post subject: Re: A Query |
|
|
Acolyte
Joined: 30 Jan 2007
Posts: 66
|
Thanks for your quick response.
I forgot to mention that the request MRM cannot be manipulated.
Adding extra body was the first choice for this implementation. Is there any other options than modifying the MRM?
Regards,
Bijesh |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Thu Mar 15, 2007 2:02 am Post subject: Re: A Query |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| bijesh wrote: |
Thanks for your quick response.
I forgot to mention that the request MRM cannot be manipulated.
Adding extra body was the first choice for this implementation. Is there any other options than modifying the MRM?
Regards,
Bijesh |
Yoy could use MQMD to store this information.
ApplicationIdData field is good place for it .
Marcin |
|
| Back to top |
|
|
| bijesh |
| Posted: Thu Mar 15, 2007 2:43 am Post subject: Re: A Query |
|
|
Acolyte
Joined: 30 Jan 2007
Posts: 66
|
| marcin.kasinski wrote: |
Yoy could use MQMD to store this information.
ApplicationIdData field is good place for it .
Marcin |
MQMD values keep changes when we put the message into a queue, right? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 15, 2007 2:54 am Post subject: Re: A Query |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bijesh wrote: |
| marcin.kasinski wrote: |
Yoy could use MQMD to store this information.
ApplicationIdData field is good place for it .
Marcin |
MQMD values keep changes when we put the message into a queue, right? |
The MQMD would be of rather limited value if it didn't.... 
Note that some fields (put date for example) are set by the queue manager on put, so user values in those fields will be overwritten. So long as you stick to the user fields (like ApplicationIdData) you'll be fine.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bijesh |
| Posted: Wed Mar 21, 2007 1:54 am Post subject: Re: A Query |
|
|
Acolyte
Joined: 30 Jan 2007
Posts: 66
|
sorry for the delayed reply.
I've tried using ApplIdentityData from MQMD for storing the data which is required in the following flow.
the problem is like this.
I've two flows.
I'm keeping the output from the first flow in a queue.
This message will be read from the second flow. In this case, If I've stored some value in MQMD.ApplIdentityData, will I get the same value in the second flow? I've tried the same, but am not getting it.
Is there any other solution for carrying a particular value from one flow to another flow. (not by adding extra fields to the message and using Environment variables)
any thoughts on this? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 21, 2007 2:19 am Post subject: Re: A Query |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bijesh wrote: |
| In this case, If I've stored some value in MQMD.ApplIdentityData, will I get the same value in the second flow? I've tried the same, but am not getting it. |
What do you get? I'd have thought that would have worked.
| bijesh wrote: |
| Is there any other solution for carrying a particular value from one flow to another flow. (not by adding extra fields to the message and using Environment variables) |
I'd put an RFH2 header on (if there isn't one already, which I'd expect there would be), store what you need in the usr folder and strip the RFH2 back off in the 2nd flow if it qualifies as a message change.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bijesh |
| Posted: Wed Mar 21, 2007 2:35 am Post subject: Re: A Query |
|
|
Acolyte
Joined: 30 Jan 2007
Posts: 66
|
| Quote: |
| what you mean by storing in 'usr' folder? |
I just got some hint...
Let me try it out. Will let you know of the result. |
|
| Back to top |
|
|
|
|
