Some 'more, in-depth' information on Oracle BPEL PM, ESB and other SOA, day2day things

Wednesday, April 19, 2006

BPEL: Loggers to know

After getting a lot of questions in the shape of ".. I encounter this error, what logger do I need to turn on ..; How do I enable logging .." - I thought to blog some comments on this.

Basically 2 types of loggers can be found within a BPEL instance

  • system-wide loggers, for infrastructure, AXIS and WSIF

    • these can be configured through the BPEL Admin Console (http://hostname:port/BPELAdmin) > logging

    • or by editing log4j-config.xml in $BPEL_HOME\integration\orabpel\system\config

    • org.collaxa.thirdparty.apache.wsif - logger for system-wide WSIF

    • org.collaxa.thirdparty.apache.axis.transport - logger to see what axis is sending on the wire

    • org.collaxa.thirdparty.apache.axis - general axis related logging

    • - all BPEL PM wide services

    • collaxa.cube.infrastructure - infrastructure such as DB connectors

  • and domain-wide loggers

    • these can be configured through the BPEL Console (http://hostname:port/BPELConsole) > manage BPEL domain > logging

    • or by editing log4j-config.xml in $BPEL_HOME\integration\orabpel\domains\<domain>\config

    • <domain>.collaxa.cube.engine.deployment - deployment related logging

    • <domain>.collaxa.cube.compiler - compilation related logging

    • <domain>.collaxa.cube.messaging - messaging layer (as bpel used messaging services to scale)

    • <domain> - server side security (fwrk)

    • <domain> - inside validator logging

    • <domain> - everything that is related to communication (WSIF layer, SOAP, Adapters) - shows you at least a longer stack if something breaks there

    • <domain>.collaxa.cube.xml - xml transformation, storage, hydration

    • <domain> - logging for services like Notification or Human Workflow

    • <domain> - Delivery Service and Manager, responsible for callbacks, and first (initiating) delivery

    • <domain>.collaxa.cube - cube related logging (system)

That should give you an idea, based on the error you get - what loggers are worth to be turned to debug level (standard is info)

Let's consider 3 examples:
  • Your process invokes an outside service (a webservice), and the data that is retrieved on the webservice side is wrong. Loggers to use are

    • <domain> - to see if something goes wrong before sending

    • org.collaxa.thirdparty.apache.axis & org.collaxa.thirdparty.apache.axis.transport - to see what is on the wire

  • A java class is invoked through WSIF binding - and you get a binding fault

    • <domain> - to see the complete stack

    • org.collaxa.thirdparty.apache.wsif - to examine the wsif part, that does the real invocation

  • Your process has invoked an async service and never receives a callback (times out, or waits there forever)

    • <domain> - again this is outbound related

    • org.collaxa.thirdparty.apache.axis & org.collaxa.thirdparty.apache.axis.transport - to see what goes onto the wire, and to see the outgoung WSA Header, that is needed for correlation

    • <domain> - to see what the delivery handler does, and if a message is retrieved, that can be correlated

Having questions? send your feedback on Loggers in Oracle BPEL PM here


Anonymous Anonymous said...

Great article.

12:19 PM

Anonymous Ramkumar Menon said...

Your blog is fantastic. Keep it up, and continue the good work.

12:17 AM

Blogger kgignatyev said...

Makes me wonder: why the troubles? Why BPEL do not have ability to attach a debugger and simply see all the things on demand?
Better yet if I could make corrections in the debugger and restart/resume process instance from an arbitrary point.

Any comments are appreciated in the OTN forum

12:23 AM


Post a Comment

<< Home