| Author |
Message
|
| 4integration |
 Posted: Thu Oct 04, 2007 4:43 am Post subject: WBIA general and synchronous response |
 |
|
Disciple
Joined: 04 Sep 2006
Posts: 197
Location: Gothenburg, Sweden
|
If I have a synchronous request for a WBI Adapter which are putted on the requestqueue, is it possible to have dynamic control which on which queue the response to be putted??
The connector has a response queue configured but for a certain request I want to get the response on RESPONSE_QUEUE_A and for another request I want the response on RESPONSE_QUEUE_B...
- Is this possible?
Some related questions about <jms><Rto>...</Rto></jms>:
- What are the requirement for Rto in WBIA ?
- How are WBIA using Rto ?
_________________
Best regards
4 Integration |
|
| Back to top |
|
 |
| Gaya3 |
| Posted: Sun Oct 07, 2007 11:00 pm Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
Hi
As far as i know, its not possible from the adapter point of view for single connector configuration, other wise you have to come up with one more connector configuration and make it for your requirement.
from one connectory configuration its not possible to connect to different queues,
Hope you got my point
Regards
Gayathri
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| 4integration |
| Posted: Mon Oct 08, 2007 4:07 am Post subject: |
|
|
Disciple
Joined: 04 Sep 2006
Posts: 197
Location: Gothenburg, Sweden
|
Hello,
Since the documentation is quite "thin" I did some tests, using JDBC adapter in two scenarios:
- Asynchronous Insert
- Synchronous Select (request/reply)
Asynchronous Insert
When not having jms/Rto specified the message are stored in the database without any extra messages on any queue. When something goes wrong (e.g. message could not be parsed) the message + error description are placed in the fault queue configured in each connector configuration.
When adding jms/Rto, this change the behavior quite much. All messages posted will be copied to the Rto queue and if errors occurs this queue are used as fault queue as well.
Conclusion: This feels OK but a bit strange. If I want a silent operation, just don't include Rto queue. But if I want to have an archive queue it would be a nice feature but since it also put error messages in that queue it would not work very well. Don't use Rto in asynchronous scenarios.
Synchronous Select (request/reply)
In synchronous request/reply scenarios you have to use the jms/Rto queue since that will point to the queue where the reply will be available. This also adds a nice feature with dynamic handling of which response queue to use (maybe different per message type etc). One negative side effect is that the Rto queue will also be used for errors (e.g. when a message can not be parsed).
Conclusion: You have to use jms/Rto to be able to get a reply 
Summary
Except for the fault handling and it's usage of jms/Rto it works as it should. However, the fact that messages containing errors also are posted to Rto queue mess things up, instead of using the fault queue.
Question
Do you have any idea how to control the fault handling in a better way?
_________________
Best regards
4 Integration
Last edited by 4integration on Mon Oct 08, 2007 7:50 pm; edited 1 time in total |
|
| Back to top |
|
|
| 4integration |
| Posted: Mon Oct 08, 2007 5:29 am Post subject: |
|
|
Disciple
Joined: 04 Sep 2006
Posts: 197
Location: Gothenburg, Sweden
|
After some more thinking I have changed the writing
Since the documentation is quite "thin" I did some tests, using JDBC adapter in two scenarios:
- Database insert in an asynchronous manner
- Database select an a synchronous manner (request/reply)
Database insert in an asynchronous manner
A sample scenario when you want to a database insert to be performed but do not want any feedback of the result (otherwise something goes wrong). This can be achieved by not include any ReplyTo queue. If errors occurs (e.g. message could not be parsed), the error message will be are placed in the fault queue configured in each connector configuration.
However, if you add ReplyTo queue all inserts will get a corresponding reply (both successful and not successful ones), with a status (usr/Status). What I have seen is 1=OK, -1=NOK.
If you are using ReplyTo queue in a asynchronous scenario, ensure that you have a consumer of response messages or the queue will filled up.
Recommendation: Don't use ReplyTo queue in asynchronous scenarios and have the fault queue monitored.
Database select an a synchronous manner (request/reply)
A sample scenario when you want to execute a database select statement and collect some data. Therefore a typical request/reply scenario. To achieve this you will need to add ReplyTo queue otherwise the reply will sent to the uncontrolled binary space. Also this adds a nice feature of using different response queues for different messages.
A side effect is that the jms/Rto queue will also be used for errors (e.g. when a message can not be parsed) and the receiver of the reply have to handle errors that occurs.
Recommendation: You have to use ReplyTo queue to be able to get a reply and you must handle error responses.
PS. The ReplyTo queue can be jms/Rto or MQMD/Rto, which gives the same behavior . DS.
_________________
Best regards
4 Integration
Last edited by 4integration on Mon Oct 08, 2007 7:48 pm; edited 1 time in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 08, 2007 6:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
That yellow color is very unreadable on the white background.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 08, 2007 7:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
| That yellow color is very unreadable on the white background. |
But is great on the default one. 
(So I can't see it clearly either!!!)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| 4integration |
| Posted: Mon Oct 08, 2007 7:46 pm Post subject: |
|
|
Disciple
Joined: 04 Sep 2006
Posts: 197
Location: Gothenburg, Sweden
|
| jefflowrey wrote: |
| That yellow color is very unreadable on the white background. |
Yes, I agree, sorry for that. If you are logged in you get a dark blue background and in combination with yellow it's quite readable.
Personally, I don't like such dark backgrounds (maybe a profile setting somewhere)
Colors will be changed
Edit: My default theme is not changed and it's nice
_________________
Best regards
4 Integration |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 08, 2007 11:35 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| 4integration wrote: |
Personally, I don't like such dark backgrounds (maybe a profile setting somewhere)
|
Specifically at the bottom of the profile page!
IMHO it's much better (but does make yellow hard to see!) 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| 4integration |
| Posted: Tue Oct 09, 2007 1:06 am Post subject: |
|
|
Disciple
Joined: 04 Sep 2006
Posts: 197
Location: Gothenburg, Sweden
|
Ok, the coloring issue is solved
(At least) one technical issues remains...
When using WBIA for JDBC running a stored procedure I can not get the response on the default response queue that are configured in the connector. The only way to get it there is to use jms/Rto or MQMD/Rto explicit in the message.
Shouldn't the behavior be that if no Rto are set, use the default one, or am I completely wrong??
_________________
Best regards
4 Integration |
|
| Back to top |
|
|
|
|
