| Author |
Message
|
| Yanghui |
 Posted: Wed Feb 19, 2003 10:13 am Post subject: Requeue a msg or msgs kept in database via warehouse node |
 |
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Hi,
We all know to use warehouse node to keep a copy of MQ msg in database. Does anybody know a good way to get a msg or msgs stroed in database back on queue? I am looking for an utility or plugin node or whatever method to achieve this.
I haven't done plugin node before. Does anybody have any idea how much effort needed for a beginner?
Any comments or suggestions or ideas are highly appreciated. Thanks a lot in advance.
Kind Regards
-Yanghui |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Feb 20, 2003 6:27 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| You should be able to use ESQL to select the data you want, and then assign it to your output message body. |
|
| Back to top |
|
|
| Yanghui |
| Posted: Fri Feb 21, 2003 3:35 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Thanks for the response.
I knew that it's doable but the tricky part is to parse and reuse the MQMD of the message stored in database via warehouse node. I have had a interim solution but I need some further testing. The main idea is to send an ID on input queue to trigger msgflow to find the correcpondent msg and requeue. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 21, 2003 8:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Maybe it would be easier to use a compute node to store the data in your own table instead of using the warehouse node.
Then you could store the different pieces of the message in different columns, and it would be easier to recreate the message. |
|
| Back to top |
|
|
| Yanghui |
| Posted: Tue Feb 25, 2003 9:37 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Thanks for your response.
Yes, you are right. I changed to use Database node instead of Warehouse.
I've got a new problem of parsing MQMD (the original one stored together with original application msg) by using the supplied MQMD msgset in WMQI 2.1 CSD4.
Here is the part of MQMD retrieved from DB. (Sorry for the bad format!)
00000000 MD .... ........ 4D442020 00000002 00000000 00000008
00000016 ........ ........ FFFFFFFF 00000000 00000111 0000039B
00000032 MQSTR ........ 4D515354 52202020 00000003 00000001
00000048 AMQ QM_T IBMQS2 414D5120 514D5F54 49424D51 53322020
00000064 =..... R 41A9F885 3DE48FB7 00B42052 34314139 46383835
00000080 FFFFF9D8 ........ 46464646 46394438 00000000 00000000
00000096 .... 00000000 20202020 20202020 20202020
00000112 20202020 20202020 20202020 20202020
00000128 20202020 20202020 20202020 20202020
00000144 QM_T IBMQS2 20202020 514D5F54 49424D51 53322020
00000160 20202020 20202020 20202020 20202020
00000176 20202020 20202020 20202020 20202020
00000192 20202020 20202020 20202020 20202020
00000208 None.... ........ 4E6F6E65 00000000 00000000 00000000
00000224 ........ ........ 00000000 00000000 00000000 00000000
00000240 init 696E6974 20202020 20202020 20202020
00000256 20202020 20202020 20202020 20202020
00000272 ....SMQS ToMQSeri 00000006 534D5153 546F4D51 53657269
00000288 es 65732020 20202020 20202020 20202020
00000304 20030221 11070280 32303033 30323231 31313037 30323830
00000320 .... ........ 20202020 00000000 00000000 00000000
00000336 ........ ........ 00000000 00000000 00000000 00000001
00000352 ........ ....<?xm 00000000 00000000 FFFFFFFF 3C3F786D
00000368 l versio n="1.0" 6C207665 7273696F 6E3D2231 2E302220
00000384 encoding ="UTF-8" 656E636F 64696E67 3D225554 462D3822
00000400 ?><BOITI BMESSAGE 3F3E3C42 4F495449 424D4553 53414745
00000416 ><MESSAG EHEADER> 3E3C4D45 53534147 45484541 4445523E
The result parsed in MRM is
(0x1000021)MRM = (
(0x300000B)StrucId = 'MD '
(0x300000B)Version = 33554432
(0x300000B)Report = 0
(0x300000B)MsgType = 134217728
(0x300000B)Expiry = -1
(0x300000B)Feedback = 0
(0x300000B)Encoding = 285278208
(0x300000B)CodedCharSetId = -1694302208
(0x300000B)Format = 'MQSTR '
(0x300000B)Priority = 50331648
(0x300000B)Persistence = 16777216
(0x300000B)MsgId = X'414d5120514d5f5449424d51533220203de48fb700b420d2'
(0x300000B)CorrelId = X'343141413036343746464646463946330000000000000000'
(0x300000B)BackoutCount = 0
(0x300000B)ReplyToQ = ' '
(0x300000B)ReplyToQMgr = 'QM_TIBMQS2 '
(0x300000B)UserIdentifier = ' '
(0x300000B)AccountingToken = X'4e6f6e6500000000000000000000000000000000000000000000000000000000'
(0x300000B)ApplIdentityData = 'init '
(0x300000B)PutApplType = 100663296
(0x300000B)PutApplName = 'SMQSToMQSeries '
(0x300000B)PutDate = '20030221'
(0x300000B)PutTime = '10083281'
(0x300000B)ApplOriginData = ' '
(0x300000B)GroupId = X'000000000000000000000000000000000000000000000000'
(0x300000B)MsgSeqNumber = 16777216
(0x300000B)Offset = 0
(0x300000B)MsgFlags = 0
(0x300000B)OriginalLength = -1
)
Obviously all the positive integars are completely wrong. I don't understand why I can get this result. Have you come cross similar problem? Many thanks for any idea or comments.
Regards
-Yanghui |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Feb 25, 2003 11:20 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
At a first guess this appears to be a data conversion issue between the way numbers are stored on your database server and the way numbers are stored on your broker machine (big-endian vs. little-endian). You may be able to 'solve' this problem a number of ways - by enabling conversion in your ODBC data source specification, by using the CAST function, or by manually manipulating the data yourself.
Consult the ESQL manual and your DBMS documentation for more information. |
|
| Back to top |
|
|
| Yanghui |
| Posted: Wed Feb 26, 2003 5:16 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Thanks.
With your suggestion, I have solved the problem. It is encoding thing.
I realise I made two mistakes.
1). I shouldn't use MQExplorer (on NT) to send sample messages on the queues belonging to the queue manager on Solaris. If I do so, the message will carry the default NT encoding (546).
2). I shouldn't config MQInput node to do convert. Somehow msgflow doesn't like the setup and just throw msg on DLQ without any warning or errors. Frankly, I don't understand why. In which circumstance, (it seems not this one), the Convert attr of MQInput node is supposed to use. My understanding was incoming msg would be converted to the local machine's encoding and CodedCharSetId if the Convert is chose with no Encoding and CCSID supply.
Any comments about this? Many thanks.
Regards
-Yanghui |
|
| Back to top |
|
|
|
|
