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
  
  
  • collaxa.cube.services - 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>.collaxa.cube.security - server side security (fwrk)
  
  
  • <domain>.oracle.bpel.security - inside validator logging
  
  
  • <domain>.collaxa.cube.ws - 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>.collaxa.cube.services - logging for services like Notification or Human Workflow
  
  
  • <domain>.collaxa.cube.engine.delivery - 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>.collaxa.cube.ws - 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>.collaxa.cube.ws - 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>.collaxa.cube.ws - 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>.collaxa.cube.engine.delivery - 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