There is a component, ReportingMDB, who consumes the messages from dist_wli.reporting.jmsprovider.queue_auto and stores in the DB.
When something goes wrong and the message cannot be persisted to DB, the message is still consumed from dist_wli.reporting.jmsprovider.queue_auto, but it is stored in
dist_wli.reporting.jmsprovider_error.queue_auto.
It's a good practice to monitor this dist_wli.reporting.jmsprovider_error.queue_auto queue for messages.
These messages in WebLogic console look like
ObjectMessage[ID:<200612.1321621841486.0>,com.bea.wli.reporting.jmsprovider.runtime.ReportMessage@2e9846b]
JMS_BEA_DeliveryFailureReason 2 java.lang.Integer
MSGTYPE 1 java.lang.Integer
REPORTINGDATATYPE 1 java.lang.Integer
JMSXDeliveryCount 1 java.lang.Integer
MSGTYPE is always set to 1 See also http://www.javamonamour.org/2011/08/dissecting-osb-jms-reporting-provider.html
To read those messages, you can use this code http://jvzoggel.wordpress.com/2012/02/15/oracle-service-bus-logging-tracing-iii-create-custom-report-provider/
If you export the JMS message using the "View Messages/Export" facility of WebLogic console you get this:
<?xml version="1.0" encoding="UTF-8"?> <JMSMessageExport> <mes:WLJMSMessage xmlns:mes="http://www.bea.com/WLS/JMS/Message"> <mes:Header> <mes:JMSMessageID>ID:<200612.1321621841486.0></mes:JMSMessageID> <mes:JMSDeliveryMode>PERSISTENT</mes:JMSDeliveryMode> <mes:JMSExpiration>0</mes:JMSExpiration> <mes:JMSPriority>4</mes:JMSPriority> <mes:JMSRedelivered>false</mes:JMSRedelivered> <mes:JMSTimestamp>1321621841486</mes:JMSTimestamp> <mes:Properties> <mes:property name="JMS_BEA_DeliveryFailureReason"> <mes:Int>2</mes:Int> </mes:property> <mes:property name="MSGTYPE"> <mes:Int>1</mes:Int> </mes:property> <mes:property name="REPORTINGDATATYPE"> <mes:Int>1</mes:Int> </mes:property> <mes:property name="JMSXDeliveryCount"> <mes:Int>1</mes:Int> </mes:property> </mes:Properties> </mes:Header> <mes:Body> <mes:Object>rO0ABXNyADdjb20uYmVhLndsaS5yZXBvcnRpbmcuam1zcHJvdmlkZXIucnVudGltZS5SZXBvcnRNZXNzYWdlie8aww8dKHQCAARbAApiaW5QYXlsb2FkdAACW0JMAAhtZXRhZGF0YXQAH0xvcmcvYXBhY2hlL3htbGJlYW5zL1htbE9iamVjdDtMAApzdHJQYXlsb2FkdAASTGphdmEvbGFuZy9TdHJpbmc7TAAKeG1sUGF5bG9hZHEAfgACeHBwc3IAQm9yZy5hcGFjaGUueG1sYmVhbnMuaW1wbC52YWx1ZXMuWG1sT2JqZWN0QmFzZSRTZXJpYWxpemVkUm9vdE9iamVjdAAAAAAAAAABAwAAeHB2cgAsY29tLmJlYS53bGkucmVwb3J0aW5nLk1lc3NhZ2Vjb250ZXh0RG9jdW1lbnQAAAAAAAAAAAAAAHhwdwYAAAABAAF0Awk8cmVwOm1lc3NhZ2Vjb250ZXh0IHhtbG5zOnJlcD0iaHR0cDovL3d3dy5iZWEuY29tL3dsaS9yZXBvcnRpbmciPjxyZXA6Y29udGVudC1lbmNvZGluZz5VVEYtODwvcmVwOmNvbnRlbnQtZW5jb2Rpbmc+PHJlcDpsYWJlbHM+bWVzc2FnZUlEPTwvcmVwOmxhYmVscz48cmVwOmluYm91bmQtZW5kcG9pbnQgbmFtZT0iUHJveHlTZXJ2aWNlJFBob2VuaXhfUHVyY2hhc2VPcmRlciRQUyRQdXJjaGFzZU9yZGVyX0ZGTVdfUFMiPjxyZXA6c2VydmljZT48cmVwOm9wZXJhdGlvbj5SZWFkPC9yZXA6b3BlcmF0aW9uPjwvcmVwOnNlcnZpY2U+PHJlcDp0cmFuc3BvcnQ+PHJlcDp1cmk+amNhOi8vZWlzL0ZpbGVBZGFwdGVyPC9yZXA6dXJpPjxyZXA6bW9kZT5yZXF1ZXN0PC9yZXA6bW9kZT48cmVwOnF1YWxpdHlPZlNlcnZpY2U+YmVzdC1lZmZvcnQ8L3JlcDpxdWFsaXR5T2ZTZXJ2aWNlPjwvcmVwOnRyYW5zcG9ydD48L3JlcDppbmJvdW5kLWVuZHBvaW50PjxyZXA6b3JpZ2luPjxyZXA6c3RhdGU+UkVRVUVTVDwvcmVwOnN0YXRlPjxyZXA6bm9kZT5QUExfTmVzc29yYV9QT19GRk1XX0ZpbGVQb2xsZXJfZmlsZTwvcmVwOm5vZGU+PHJlcDpwaXBlbGluZT5QUExfTmVzc29yYV9QT19GRk1XX0ZpbGVQb2xsZXJfZmlsZV9yZXF1ZXN0PC9yZXA6cGlwZWxpbmU+PHJlcDpzdGFnZT5SZXBvcnRFbnRyeTwvcmVwOnN0YWdlPjwvcmVwOm9yaWdpbj48cmVwOnRpbWVzdGFtcD4yMDExLTExLTE4VDE0OjEwOjQxLjM4NSswMTowMDwvcmVwOnRpbWVzdGFtcD48L3JlcDptZXNzYWdlY29udGV4dD53AQB4dAAmUHVyY2hhc2UgT3JkZXIgRmlsZSBjb25zdW1lZCBmcm9tIEZGTVdw</mes:Object> </mes:Body> </mes:WLJMSMessage> </JMSMessageExport>
Evidently the com.bea.wli.reporting.jmsprovider.runtime.ReportMessage Object is serialized in the body element.
1 comment:
com.bea.wli.reporting.jmsprovider.runtime.ReportMessage Object is serialized in the body element. --- not correct
It´s 64-based encoded
Post a Comment