In WL Console I have created a DataSource pointing to this schema,
using wlsbjmsrpDataSource as JNDI name (I first needed to rename the existing Derby datasource JNDI name, otherwise it would give conflict).
I restarted WebLogic, because the JNDI entry was being cached by the provider and it would keep pointing to Derby.
Each time I do a Report action, a row is created in WLI_QS_REPORT_DATA and in WLI_QS_REPORT_ATTRIBUTE tables.
WLI_QS_REPORT_DATA.DATA_VALUE (blob) contains the data associated with the Report action (if you do "report $body", the payload will end up here)
the labels are in WLI_QS_REPORT_ATTRIBUTE.MSG_LABELS, in a list:
keyone=24;keytwo=pierre
WLI_QS_REPORT_ATTRIBUTE.INBOUND_SERVICE_NAME is filled with ProxyService$ReportingTest$reportingPS
(ReportingTest = project name, reportingPS = proxy name)
WLI_QS_REPORT_ATTRIBUTE.INBOUND_SERVICE_URI = /ReportingTest/reportingPS
WLI_QS_REPORT_ATTRIBUTE.OUTBOUND* are NULL, such as WLI_QS_REPORT_ATTRIBUTE.*
WLI_QS_REPORT_ATTRIBUTE.STATE = REQUEST
node, pipeline name and stage info are duly filled.
Things change radically if the Report action is in a Error Handler.
I trigger the error with a "Raise Error" action, error code="MYERRORCODE" and error reason "MYERRORREASON".
This is the $fault originated:
<con:fault xmlns:con="http://www.bea.com/wli/sb/context"> <con:errorCode>MYERRORCODE</con:errorCode> <con:reason>MYERRORREASON</con:reason> <con:location> <con:node>PipelinePairNode1</con:node> <con:pipeline>PipelinePairNode1_request</con:pipeline> <con:stage>stage1</con:stage> <con:path>request-pipeline</con:path> </con:location> </con:fault>
In this case:
WLI_QS_REPORT_ATTRIBUTE.STATE = ERROR
WLI_QS_REPORT_ATTRIBUTE.ERROR_CODE = MYERRORCODE
WLI_QS_REPORT_ATTRIBUTE.ERROR_REASON = MYERRORREASON
and all the node, pipeline name and stage info are blank.
WLI_QS_REPORT_ATTRIBUTE.ERROR_DETAILS is empty
The ReportingMDB consumes messages from the JMS queue wli.reporting.jmsprovider.queue, and inserts them into the DB.
If you pause consumption on the jmsResources!wli.reporting.jmsprovider.queue you can see the XML message itself, which is a:
ObjectMessage[ID:<997757.1312300601672.0>,com.bea.wli.reporting.jmsprovider.runtime.ReportMessage@368701b]
with some custom JMS properties like
REPORTINGDATATYPE=2
MSGTYPE=1
the meaning of REPORTINGDATATYPE should be:
STRING_MSGCONTENT = 1;
XML_MSGCONTENT = 2;
BINARY_MSGCONTENT = 3;
as defined in com.bea.wli.reporting.jmsprovider.utils.ReportingConstants
The ReportingMDB is deployed as a EJB module of:
C:\Oracle\Middleware\Oracle_OSB1\lib\common\jmsreportprovider.ear
4 comments:
Hi !
I've observed the same behaviour concerning the null values (stage_name,etc.) when you populate data through report in an error handler.
Can you explain that behaviour ? Is there a workaround ?
Thanks,
Romain.
I am still pondering if I should really use the JMS Reporting provider, or write my own little reporting utility... unless you hack the code (surely not supported by Oracle), or write your own custom reporting provider....
anyway in the fault section you "should" find the exact location of the error...
can i have the detailed information about custom reporting provider..
I have written something about the Custom reporting provider here
http://www.javamonamour.org/2011/11/osb-custom-reporting-provider.html
but I have never implemented one... it doesn't seem terribly difficult though...
Post a Comment