| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ message not making it past MQINPUT niode |
« View previous topic :: View next topic » |
| Author |
Message
|
| BCWolf |
 Posted: Wed Aug 07, 2013 4:13 pm Post subject: MQ message not making it past MQINPUT niode |
 |
|
Newbie
Joined: 13 Mar 2013
Posts: 7
|
I have an MQInput getting a XML datagram from a queue, but despite the node apparently being able to parse the message, it is routing to the Failure branch rather than Out.
Looking at the ExceptionList in the debugger, i find
| Quote: |
ExceptionList
RecoverableException
File:CHARACTER:/build/S700_P/src/DataFlowEngine/ImbMqInputNode.cpp
Line:INTEGER:2129
Function:CHARACTER:ImbCommonInputNode::eligibleForBackout
Type:CHARACTER:ComIbmMQInputNode
Name:CHARACTER:com/icbc/edl/esb/flow/sync/providerAdapter/EDL_AdjudicatedBirthCertificateProvider#FCMComposite_1_1
Label:CHARACTER:com.icbc.edl.esb.flow.sync.providerAdapter.EDL_AdjudicatedBirthCertificateProvider_v1.0.0.AdjudicatedBirthCertificate
Catalog:CHARACTER:BIPmsgs
Severity:INTEGER:3
Number:INTEGER:2652
Text:CHARACTER:Dequeued failed message. Propagating a message to the failure terminal |
and yet, the message has successfully parsed the XML message:
| Quote: |
Message
Properties
MessageSet:CHARACTER:
MessageType:CHARACTER:
MessageFormat:CHARACTER:
Encoding:INTEGER:546
CodedCharSetId:INTEGER:819
Transactional:BOOLEAN:true
Persistence:BOOLEAN:false
CreationTime:TIMESTAMP:java.util.GregorianCalendar[time=1375921446180,areFieldsSet=true,areAllFieldsSet=false,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Vancouver",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=189,lastRule=java.util.SimpleTimeZone[id=America/Vancouver,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=?,YEAR=2013,MONTH=7,WEEK_OF_YEAR=?,WEEK_OF_MONTH=?,DAY_OF_MONTH=7,DAY_OF_YEAR=?,DAY_OF_WEEK=?,DAY_OF_WEEK_IN_MONTH=?,AM_PM=1,HOUR=5,HOUR_OF_DAY=17,MINUTE=24,SECOND=6,MILLISECOND=180,ZONE_OFFSET=?,DST_OFFSET=?]
ExpirationTime:INTEGER:-1
Priority:INTEGER:0
ReplyIdentifier:BLOB:[B@13701370
ReplyProtocol:CHARACTER:MQ
Topic:UNKNOWN:null
ContentType:CHARACTER:
IdentitySourceType:CHARACTER:
IdentitySourceToken:CHARACTER:
IdentitySourcePassword:CHARACTER:
IdentitySourceIssuedBy:CHARACTER:
IdentityMappedType:CHARACTER:
IdentityMappedToken:CHARACTER:
IdentityMappedPassword:CHARACTER:
IdentityMappedIssuedBy:CHARACTER:
MQMD
SourceQueue:CHARACTER:EDL.ADJ.RPLY.BCVS
Transactional:BOOLEAN:true
Encoding:INTEGER:546
CodedCharSetId:INTEGER:819
Format:CHARACTER:MQSTR
Version:INTEGER:2
Report:INTEGER:0
MsgType:INTEGER:8
Expiry:INTEGER:-1
Feedback:INTEGER:0
Priority:INTEGER:0
Persistence:INTEGER:0
MsgId:BLOB:[B@29b829b8
CorrelId:BLOB:[B@2a602a60
BackoutCount:INTEGER:1
ReplyToQ:CHARACTER:EDL.RPLY.BCVS
ReplyToQMgr:CHARACTER:AuditLogQMgr
UserIdentifier:CHARACTER:svcmh6h
AccountingToken:BLOB:[B@2e5e2e5e
ApplIdentityData:CHARACTER:
PutApplType:INTEGER:6
PutApplName:CHARACTER:WebSphere Datapower MQClient
PutDate:DATE:java.util.GregorianCalendar[time=1375858800000,areFieldsSet=true,areAllFieldsSet=false,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Vancouver",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=189,lastRule=java.util.SimpleTimeZone[id=America/Vancouver,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=?,YEAR=2013,MONTH=7,WEEK_OF_YEAR=?,WEEK_OF_MONTH=?,DAY_OF_MONTH=7,DAY_OF_YEAR=?,DAY_OF_WEEK=?,DAY_OF_WEEK_IN_MONTH=?,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=0,MILLISECOND=?,ZONE_OFFSET=?,DST_OFFSET=?]
PutTime:TIME:java.util.GregorianCalendar[time=-62167386953820,areFieldsSet=false,areAllFieldsSet=false,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Vancouver",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=189,lastRule=java.util.SimpleTimeZone[id=America/Vancouver,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=0,YEAR=2,MONTH=11,WEEK_OF_YEAR=?,WEEK_OF_MONTH=?,DAY_OF_MONTH=31,DAY_OF_YEAR=?,DAY_OF_WEEK=?,DAY_OF_WEEK_IN_MONTH=?,AM_PM=1,HOUR=5,HOUR_OF_DAY=17,MINUTE=24,SECOND=6,MILLISECOND=180,ZONE_OFFSET=?,DST_OFFSET=?]
ApplOriginData:CHARACTER:
GroupId:BLOB:[B@36323632
MsgSeqNumber:INTEGER:1
Offset:INTEGER:0
MsgFlags:INTEGER:0
OriginalLength:INTEGER:-1
XMLNSC
XmlDeclaration
Version:CHARACTER:1.0
Encoding:CHARACTER:UTF-8
BirthCertificateValidation
TransactionTypeCode:CHARACTER:003
PayloadCreationDateTime:CHARACTER:2013-08-07T18:24:03Z
Source:CHARACTER:059
Target:CHARACTER:007
Priority:CHARACTER:1
RequestId:CHARACTER:201308071024000407300000000000000000000000000000
ResponseId:CHARACTER:30916
Request
ReferenceNumber:CHARACTER:4073
Adjudication:CHARACTER:1
BirthCertificateNumber:CHARACTER:20110702
BirthCertificateIssueDate:CHARACTER:2007-11-20
BirthRegistrationNumber:CHARACTER:2007-59-037157
BirthRegistrationDate
OccurrenceCity:CHARACTER:VICTORIA
Child
Name
Surname:CHARACTER:LOPAZ
GivenNames:CHARACTER:PASCHAL GEORGE
BirthDate:CHARACTER:2007-08-28
GenderCode:CHARACTER:1
Mother
Name
Surname
GivenNames
BirthPlace
Country
Province
Father
Name
Surname
GivenNames
BirthPlace
Country
Province
Response
CertificateNumberMatchCode:CHARACTER:1
CertificateIssueDateMatchCode:CHARACTER:1
CertificateStatusValidationCode:CHARACTER:1
RegistrationNumberMatchCode:CHARACTER:1
RegistrationDateMatchCode:CHARACTER:9
SurnameMatchCode:CHARACTER:1
GivenNamesMatchCode:CHARACTER:1
BirthDateMatchCode:CHARACTER:1
GenderCodeMatchCode:CHARACTER:1
OccurrenceCityMatchCode:CHARACTER:1
MthrSurnameMatchCode:CHARACTER:9
MthrGivenNamesMatchCode:CHARACTER:9
MthrBirthCountryMatchCode:CHARACTER:9
MthrBirthProvMatchCode:CHARACTER:9
FthrSurnameMatchCode:CHARACTER:9
FthrGivenNamesMatchCode:CHARACTER:9
FthrBirthCountryMatchCode:CHARACTER:9
FthrBirthProvMatchCode:CHARACTER:9
DeathIndicatorCode:CHARACTER:0
QueryStatusCode:CHARACTER:1
LegalNameChangeCode:CHARACTER:0 |
The node is using an XMLNSC parser and all parser options are off (although i did provide the associated MessageSet), advanced options are left at the defaults, validation is disabled, security is defined as Transport Default and the remaining fields are blank, Despite the MsgType being 8 (Datagram), there is a ReplyTo queue manager and queue defined in the MQMD header, but we tried removing those using RFHUTIL and it didn't change things when submitting the updated message to the queue. We have a backout queue defined on the monitored queue, and i have a Trace node wired between the Failure terminal and our Error handler -- but it only dumps the same information as seen in the debugger (as would be expected).
What obvious thing are we missing here that causes the message to not enter the flow proper? |
|
| Back to top |
|
 |
| NealM |
| Posted: Wed Aug 07, 2013 5:44 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| hmm, if you supplied a message set name in the input Message Model, I would expect that it would show up in the Properties - MessageSet field in your trace that you attached. Maybe you have valid XML but it's not valid for your schema? |
|
| Back to top |
|
|
| Simbu |
| Posted: Wed Aug 07, 2013 8:04 pm Post subject: Re: MQ message not making it past MQINPUT niode |
|
|
Master
Joined: 17 Jun 2011
Posts: 289
Location: Tamil Nadu, India
|
| BCWolf wrote: |
i have a Trace node wired between the Failure terminal and our Error handler -- but it only dumps the same information as seen in the debugger (as would be expected).
What obvious thing are we missing here that causes the message to not enter the flow proper? |
Please try running UserTrace. It will provide much more information. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Wed Aug 07, 2013 8:42 pm Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
The amount of debugging is inadequate. BIP2652 is a general message:
Examine previous messages and the message flow to determine why the message is being backed out. Correct this situation if possible. Perform any local error recovery processing required.
You need to run a user trace, look it at and find out why the message is being rejected.
You also need to look at error messages in the Event Log/System log ( depending on you operating system ). Normally the error messages associated with the failure are there. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Thu Aug 08, 2013 6:08 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
Is it better to check the MQMD.Backout count and see if it is greater than teh backout threshold, which means your flow has already received this message and failed for some reason.
Do you have a backout queue defined for your input queue? If not try defining one. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 08, 2013 6:25 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kash3338 wrote: |
| Is it better to check the MQMD.Backout count and see if it is greater than teh backout threshold, which means your flow has already received this message and failed for some reason. |
WMB does this for you. There's no need for a check.
| kash3338 wrote: |
| Do you have a backout queue defined for your input queue? If not try defining one. |
So instead of going down the failure path, the message will go down the failure path and then onto the defined backout queue. How will that help the OP diagnose the problem?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| NealM |
| Posted: Thu Aug 08, 2013 7:36 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
BCWolf, getting back to your trace, here is what (part of) an incoming message would look like, at least on the Catch terminal, if your input node's message model had actually taken:
| Code: |
(0x01000000:Folder):XMLNSC = ( ['xmlnsc' : 0x8d215600]
(0x01000400:NamespaceDecl):XmlDeclaration = (
(0x03000100:Attribute):Version = '1.0' (CHARACTER)
(0x03000100:Attribute):Encoding = 'UTF-8' (CHARACTER)
)
(0x01000000:Folder )http://schemas.xmlsoap.org/soap/envelope/:Envelope = (
(0x03000102:NamespaceDecl)http://www.w3.org/2000/xmlns/:xsi = 'http://www.w3.org/2001/XMLSchema-instance' (CHARACTER)
(0x03000102:NamespaceDecl)http://www.w3.org/2000/xmlns/:xsd = 'http://www.w3.org/2001/XMLSchema' (CHARACTER)
(0x03000102:NamespaceDecl)http://www.w3.org/2000/xmlns/:soapenc = 'http://schemas.xmlsoap.org/soap/encoding/' (CHARACTER)
(0x03000102:NamespaceDecl)http://www.w3.org/2000/xmlns/:soapenv = 'http://schemas.xmlsoap.org/soap/envelope/' (CHARACTER)
(0x01000000:Folder )http://schemas.xmlsoap.org/soap/envelope/:Header =
(0x01000000:Folder )http://schemas.xmlsoap.org/soap/envelope/:Body = (
(0x01000000:Folder)http://<mycompany>/BranchTellerSync:maintainRequest = (
(0x03000102:NamespaceDecl)http://www.w3.org/2000/xmlns/:p1 = 'http://<my company>/BranchTellerSync' (CHARACTER)
(0x01000000:Folder ):header = (
(0x03000000:PCDataField):processingDate = DATE '2012-07-16' (DATE)
(0x03000000:PCDataField):companyID = '1234567890' (CHARACTER)
(0x03000000:PCDataField):channelID = '222222222222222' (CHARACTER)
(0x03000000:PCDataField):branchID = 77 (DECIMAL)
(0x03000000:PCDataField):tellerID = 3 (DECIMAL)
(0x03000000:PCDataField):employeeID = 3941 (DECIMAL)
(0x03000000:PCDataField):workstationID = '10.66.40.138' (CHARACTER)
(0x03000000:PCDataField):transactionID = 394102451142614 (DECIMAL)
(0x03000000:PCDataField):transactionRetry = FALSE (BOOLEAN)
|
Note the DATE type, etc. Your trace just shows CHARACTER types for everything, as though no message model were applied. Is your schema the same as the one your org supplied to the DataPower appliance feeding your flow?
Also, I agree with the other posters that you might find a bit more info if you set a debug level User trace on your flow. If it is dieing in the input node, the trace will at least show the parser(s) involved. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Thu Aug 08, 2013 10:22 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| Vitor wrote: |
| kash3338 wrote: |
| Is it better to check the MQMD.Backout count and see if it is greater than teh backout threshold, which means your flow has already received this message and failed for some reason. |
WMB does this for you. There's no need for a check. |
When the catch terminal is not connected to handle the error in the flow and there is no backout queue defined for the input queue and if the backout count is equal to or greater than the threshold, the message directly goes to the failure terminal of the MQInput node and throws the error Dequeued failed message. Propagating a message to the failure terminal |
|
| Back to top |
|
|
| dogorsy |
| Posted: Thu Aug 08, 2013 10:42 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| kash3338 wrote: |
| Vitor wrote: |
| kash3338 wrote: |
| Is it better to check the MQMD.Backout count and see if it is greater than teh backout threshold, which means your flow has already received this message and failed for some reason. |
WMB does this for you. There's no need for a check. |
When the catch terminal is not connected to handle the error in the flow and there is no backout queue defined for the input queue and if the backout count is equal to or greater than the threshold, the message directly goes to the failure terminal of the MQInput node and throws the error Dequeued failed message. Propagating a message to the failure terminal |
are you saying that connecting the catch terminal will solve the problem ?
| Quote: |
| Is it better to check the MQMD.Backout count |
why is that? checking the backout count better than getting a user trace ?..hmmm , never heard that before.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Aug 08, 2013 10:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kash3338 wrote: |
| When the catch terminal is not connected to handle the error in the flow and there is no backout queue defined for the input queue and if the backout count is equal to or greater than the threshold, the message directly goes to the failure terminal of the MQInput node and throws the error Dequeued failed message. Propagating a message to the failure terminal |
Yes, because WMB has detected that the backout count of the message exceeds the threshold on the queue it throws an error. This goes to either the catch terminal or the failure terminal according to the rules in the InfoCenter. If unhandled, WMB will put the message onto the backout queue defined to the input queue; if that's not possible (because no queue is defined, or the queue is full) the message goes to the DLQ of the queue manager.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Aug 08, 2013 11:11 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
IMHO, it is good practice to use a BOQ all the time. That way you don't get a poision message stopping the whole flow. The ONLY time I'd recommend not using one is if there is 'Message Affinity' involved, unless you really want to handle poison messages in some other way.
Then there is The Catch Terminal.
At the very least this should be wired up to a trace node that outputs the ExceptionList.
You should have propper error handling that does something recordaboe with the error AND makes the real reason for the error HUMAN READABLE and UNDERSTANDABLE.
(no matter what LaneclotLinc says about using 'grep').
Finally the Failure Terminal
I've never wired this to anything. I know that there are sometimes valid reasons to wire it up but if your Error Handler is up to scratch there really is no need at al (IMHO).
The advantage of putting 'failed' messages onto a BOQ is that they are available for further examination,replay or being forwarded to support as part of the 'Must Gather' data. Having the original message is often invaluable in rectifying faults OR pointing the finger at the originators and telling them that their system is broke and that they should fix it.
Just my 2p worth (FWIW)
Just my 2p worth.
_________________
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 |
|
|
| BCWolf |
| Posted: Thu Aug 08, 2013 11:18 am Post subject: |
|
|
Newbie
Joined: 13 Mar 2013
Posts: 7
|
| NealM wrote: |
| hmm, if you supplied a message set name in the input Message Model, I would expect that it would show up in the Properties - MessageSet field in your trace that you attached. Maybe you have valid XML but it's not valid for your schema? |
That's because in fact the capture was taken from the first run, before i added the message set to see if it changed anything. Thanks to those with the suggestions about User Trace, i will have to experiment with that. However, another developer suggested i simply delete the MQInput node and add it anew (since that had worked for him a year ago when he was having issues with another flow) and -- surprise, surprise -- that solved the problem.
Why, i have NO idea. However, given how much time this has delayed me, i am simply going to thank Providence, call it a JOOT, and move forward.
Thanks to all for your help. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Aug 08, 2013 2:02 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
In response to NealM's comment ( somewhat late, sorry about that ):
By default, the XMLNSC domain builds the message tree using the CHARACTER data type throughout. If you want the xsd types to be used then you must explicitly request that via the 'Build tree using XML Schema' property. The reason for this non-obvious default behaviour is that XMLNSC in v6.0 did not support validation, and therefore would always build the tree using the CHARACTER data type throughout. So v6.1 had to follow the precedent to avoid breaking v6.0 users.
The SOAP domain ( which also uses XMLNSC internally ) was introduced for the first time in v6.1 so it was not burdened with any history. It defaults to building the tree using the xsd types.
Probably more info than you all wanted, but I feel better now...
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Thu Aug 08, 2013 9:21 pm Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| kimbert wrote: |
Probably more info than you all wanted, but I feel better now... |
no, good explanation, I have asked a similar question before. Cheers kimbert !! |
|
| Back to top |
|
|
| NealM |
| Posted: Thu Aug 08, 2013 9:32 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
Yes, thanks Kimbert. I got so used to setting that 'Build tree using XML Schema' property since 6.1 that I forgot about what the v6.0 tree looked like.
I would like to point out an additional benefit of using that property; It usually eliminates having to do a lot of CASTs, especially if you are using Mapping Nodes for transforms. |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
