oraesb database schema corrupted

Problem description
oc4j_soa instance consuming 100% cpu.
ESB message processing running in an infinite loop where JMS adapter message consumers throws exception. When an MDB responds to a message by throwing an exception, the message is not considered delivered and it may be
redelivered. If the MDB might always respond to a given message by throwing an exception, and MaxDeliveryCnt is set to 0 to prevent the message from ever being discarded, the result may be an MDB stuck in an “infinite loop” – failing to process the same message over and over again.) For an MDB this is fine. For a JMS adapter this is more troublesome.
The problem can be seen in the application log $ORACLE_HOME/j2ee/oc4j_soa/oc4j_soa_default_group_1/oc4j/log.xml as continous flow of “Global transaction get” “global transaction begin”, infinite transaction loop, even if no load on system.
So the oraesb schema is basically corrupted.

Error message of type can be seen in container log:
Designtime cache has not been initialized Please look in logs for following signs of failure.
Fix them and restart. (a) Database access errors (b) ESB Bootstrap errors
(c) OC4J class load errors (d) Product installation errors
(e) Export ESB params and verify if host and port parameters are correct.
Please contact Oracle Support if unable to fix the issue.

reset oraesb schema

Of course, Oracle Support was contacted, but they tend to take some time responding, so meanwhile a qucik check on some of the trusted oracle bloggers around gave result:

So now the reset of oraesb was performed, but still there is an issue with the instances view:

ESB instances view:
“Could not retrieve the messages due to the error : ORA-00904: “SEQ”: invalid identifier ”

“Could not retrieve the messages due to the error : ORA-00904: “SEQ”: invalid identifier ”

This was caused by the table ORAESB.ESB_ACTIVITY did not contain the columns SEQ and SUB_FLOW_SEQ. Happened on reset of ORAESB.
The correct DDL was executed, and voila, suddenly the ESB instances view was behaving as expected.


drop table oraesb.esb_activity;

File repository not initialized.May be ESB bootstrap failed

After upgrading SOA suite to the esb.server.bootstrap fails.
Error message in $ORACLE_HOME/opmn/logs/*.log is:
oracle.tip.esb.console.exception.ConsoleTransactionException: An unhandled exception has been thrown in the ESB system. The exception reported is: “oracle.tip.esb.console.exception.ConsoleTransactionException: File repository not initialized.May be ESB bootstrap failed
Please review ESB prameters for their correctness.

A different error message to the same problem is
WSDL parsing failed :unknown protocol: esb

This issue is as a result of ESB-DT, ESB-RT and BPEL being in same container as part of SOA advanced install. ESB server itself is not starting up successfully because the URL ping gets over before it could initialize itself.
ESB bootstrap: Ping to URL failed. Will ping again…
And unknown protocol indicates BPEL is started before ESB has initialized itself successfully, and thus is not ready to provide wsdl’s.
The ESB Components are not loaded properly, and a first try could be to:

  • Restart the oc4j_soa component using the below command:
    opmnctl restartproc process-type=oc4j_soa
    The above command is used to restart only the required component without restarting all the components in the server .
  • It could also be lack of resources during startup, then the following approach could be used:

    1. logon to appserver control,stop orabpel(which should make hw_services down as well)
    2. also stop the HTTP_server, making sure there is no apache-processes running
    3. opmnctl stopall
    4. start the server using opmnctl startall
    5. Once Server is up, start orabpel and hw_services applications from enterprise manager console
    6. This way you control the startup sequence making it more likely that esb-rt and esb-dt can start correctly.

  • Or you could end up doing this:
    # Set appropriate values for following parameters in esb_config.ini or orion-application.xml file.
    Default is 15 for both values. PingInterval is measured in seconds.
    PingCount = 30
    PingInterval = 30

    The orion-application.xml that needs to be updated are in RT and DT application $ORACLE_HOME/j2ee/oc4j_soa/applications/esb-dt/orion-application.xml $ORACLE_HOME/j2ee/oc4j_soa/application-deployments/esb-rt/orion-application.xml
    The esb_config.ini is in $ORACLE_HOME/integration/esb/config/esb_config.ini

  • Finally, if your oraesb.esb_parameter table is empty, or the oraesb schema seems messed up:
    1. go to $ORACLE_HOME/integration/esb/bin
    2. Correct the build.xml, declarations needs to be changed from:
      <property name=”dt.oc4j.http.port” value=”${env.DT_OC4J_HTTPPORT}” />
      <property name=”dt.oc4j.http.port” value=”${env.DT_OC4J_HTTP_PORT}” />

    3. edit esbsetenv.bat to the correct db_url, db_user, db_password, and sys_password, e.g.:
      rem [DB] setup
      set DB_URL=jdbc:oracle:thin:@
      set DB_USER=oraesb
      set DB_PASSWORD=oraesb
      set SYS_PASSWORD=password
    4. Now execute, reset.sh/reset.bat to reinitialize the esb repository. Note: this is only an option in development env. Do not reinitialize your production esb repository, unless you really want to :)
  • Actually, ESB_PARAMETER gets corrupted every now and then, especially during patch upgrades. Here are a valid ESB_PARAMETER data:
    rem change host and port
    Insert into ESB_PARAMETER (PARAM_NAME,PARAM_VALUE) values ('DT_OC4J_HOST','localhost');
    Insert into ESB_PARAMETER (PARAM_NAME,PARAM_VALUE) values ('PROP_NAME_ERROR_RETRY_JNDI','OracleASjms/ESBErrorRetryTopic');
    Insert into ESB_PARAMETER (PARAM_NAME,PARAM_VALUE) values ('ACT_ID_RANGE','891000');

Now the probability of ESB server is starting up successfully is increased, because the URL ping continue for a longer time, making it probable ESB server gets initialized before ping counts are over.

how to view payload from an oracle esb


Viewing the payload of an ESB instance within Oracle SOA suite is not available by default, at least not for successfully executed instances. But during development payload logging has proven extremely useful. And in production the concept of trackable fields have given insight into the core parts of the payload, even for successfully executed instances.
I will first explain how to enable payload logging, through a ESBLoggingInterceptor. And then how to utilize the trackable fields concept.


Starting from Oracle Application Server release, ESB logging capability has been enhanced. To take advantage of this enhanced logging feature, you should perform the following steps:

  • implement the oracle.tip.esb.server.common.interceptor.IEsbMessageInterceptor interface.
  • Add the jar into the ESB classpath, for example: ORACLE_HOME/j2ee/oc4j_soa/server.xml, in block oracle.bpel.common
  • Add the following configuration variables in the esb_config.ini file:
  • inboundMessageInterceptor = no.gwr.esb.ESBLoggingInterceptor
    outboundMessageInterceptor = no.gwr.esb.ESBLoggingInterceptor

package no.gwr.esb;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.w3c.dom.Element;

import oracle.tip.esb.monitor.FlowId;
import oracle.tip.esb.server.common.interceptor.IEsbMessageInterceptor;

public class ESBLoggingInterceptor implements IEsbMessageInterceptor {

	private static final Logger log = LoggerFactory.getLogger(ESBLoggingInterceptor.class);
	private static String tab = "\t";

	public void invoke(FlowId flowId, String instanceId, Element payload, Element header, String serviceName, String systemName, Element response, Throwable throwable, boolean isOutbound,	boolean isResponse) {
		StringBuffer sb = new StringBuffer();
		sb.append("flowId: ").append(flowId).append(tab);
		sb.append("instanceId: ").append(instanceId).append(tab);
		sb.append("serviceName: ").append(serviceName).append(tab);
		sb.append("systemName: ").append(systemName).append(tab);
		if (header!=null)
			sb.append("headerContent: ").append(header.getTextContent()).append(tab);
		if (payload!=null)
		  sb.append("payloadContent: ").append(payload.getTextContent()).append(tab);
		if (response!=null)
			sb.append("response: ").append(response.getTextContent()).append(tab);
			System.out.println(sb.toString());//goes into default log
			log.info(sb.toString());//goes into the configured separate log

As you notice sl4j is used for logging. This could be skipped, if you are happy with the default log for payload output. We separated this as we actually do payload logging also in production. This is to be able to scan historically executed payload content, as an audit log. A sample logback.xml could be:

 	<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
		<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
		<layout class="ch.qos.logback.classic.PatternLayout">
			<Pattern>%d{HH:mm:ss.SSS} %-5level %logger{36} - %msg%n</Pattern>
   <turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter">
  <root level="debug">
    <appender-ref ref="FILE" />

Now payload is available in the ESBInterceptor.%d{yyyy-MM-dd}.log

In short:
To enable ESB Message Interceptor logging
1. Implement the oracle.tip.esb.server.common.interceptor.IEsbMessageInterceptor interface.
2. Add the implementation class into the ESB classpath. ie: server.xml/oracle.bpel.common
3. Add the Message Interceptor configuration variables in the esb_config.ini file
4. Restart the container for changes to take effect.

Trackable fields within ESB

The ESB trackable fields concept can be used to execute xpath-expressions. The way to do it is to deploy a ESB service, configure the trackable fields on the server, and then pull back the file *.esbsvc containing the relevant trackable fields expressions. This is to get the correct syntax of how to define trackable fields. Note that you must connect the trackable field to the correct operation guid, found elsewhere in the *.esbsvc-file.

The xpath is executed, and the trackable fields values are viewable in ESB console, in lower part of pane tracking.

      <trackableField name="sourceSystem" status="ENABLED" bindTo="REQUEST">
         <operationRef guid="C31378D0FFAA11DEBFA619588F2E21CD" qname="ConsumerServices.EventsListener.EventsListener_v1_0.JmsAdapterIn_RS.Consume_Message"/>
         <expression>{/tns:eventsMessage/tns:messageBody/tns:sourceSystem};{ namespace tns=http://soa.gwr.no/shipping/v1.0/shipmentevents }</expression>


Now both the full payload is available in server logs, and a set of chosen payload values are available in ESB console.


@see Oracle bug 6995195
@see Oracle® Application Server Release Notes and New Features
10g Release 3 (

JAXB 2.x inside OC4J


As seen in previous post a combination of XSL-transformation and data binding isolated in a mapping layer gives decoupling of message producer and message consumer.
The pom.xml dependencies are seen below, using Apache Xalan for XSLT and Sun’s JAXB implementation.



When deploying a mapping layer implementation using JAXB 2.x inside OC4J 10.1.3.x the error might be:
javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package {0}
The reason for this is that the OC4J container comes with JAXB 1.0 runtime support. This is found in the shared
library named oracle.xml, and the javax.xml.bind.JAXBContext will be loaded from ORACLE_HOME/lib/xml.jar.
To get around this a separate shared library need to be defined, containing the jaxb-2.x libraries.

Shared library

Open the Application Server Control (ASC), and navigate to the oc4j-instance->Administration. Create a new shared library and give it a name and a version. Then pick the libraries you need. Note that there are some transitive dependencies for the jaxb-impl-2.2.jar from Sun. You need both activation-1.1.jar, jaxb-api-2.2.jar and stax-api-1.0-2.jar.

The next thing is to make sure your application actually loads and uses this shared library. To do this, edit orion-application.xml to import the shared library.



SOA mapping layer


XML is the ubiquitous message format in SOA. To decouple the components exchanging messages, a mapping layer can be introduced, thus isolating the knowledge on message format within this mapping layer. The obvious choice of transforming from the XML format over the wire, from the XML format within component, is XSLT.


The figure illustrates the basic principles of decoupling message producer from message consumer. Using a mapping layer for XSLT, and data binding, will isolate the business logic in message consumer from the xml message format. Whether a mapping layer is introduced on the message producer side, depends on design.
But the mapping layer on producer side will by the same arguments as on the consumer side introduce decoupling between business logic message format and the exchange message format.

package no.gwr.mdb.samples;

@MessageDriven(activationConfig = {
    @ActivationConfigProperty(propertyName = "connectionFactoryJndiName", propertyValue = "jms/TopicConnectionFactory"),
    @ActivationConfigProperty(propertyName = "destinationName", propertyValue = "jms/MyTopic"),
    @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Topic"),
    @ActivationConfigProperty(propertyName = "SubscriptionDurability", propertyValue = "Durable"),
    @ActivationConfigProperty(propertyName = "SubscriptionName", propertyValue = "TopicListener")
public class OrganizationEventsListenerMDBBean implements MessageDrivenBean, MessageListener {

  public void onMessage(Message message) {
    try {
      if (message instanceof TextMessage) {
        TextMessage txtMsg = (TextMessage) message;
        String txt = txtMsg.getText();
        String result = transform(txt);
        Organization organization = unmarshal(result);
        MessageConsumerAdapterImpl handler = new MessageConsumerAdapterImpl();
    } catch (Throwable ex) {
      ex.printStackTrace();//TODO introduce sl4j logging framework, and log to application.log
	/**using XSL (xalan-2.7.1) to transform XML message*/
  public String transform(String txt) throws Exception {
    javax.xml.transform.TransformerFactory tf =  javax.xml.transform.TransformerFactory.newInstance();
    javax.xml.transform.sax.SAXTransformerFactory stf = (javax.xml.transform.sax.SAXTransformerFactory)tf;
    javax.xml.transform.stream.StreamSource xsl = new javax.xml.transform.stream.StreamSource(getClass().getResourceAsStream(XSL_FILE));
    javax.xml.transform.Templates templates = stf.newTemplates(xsl);
    javax.xml.transform.Transformer transformer = templates.newTransformer();
    javax.xml.transform.stream.StreamSource source = new javax.xml.transform.stream.StreamSource(new ByteArrayInputStream(txt.getBytes()));
    javax.xml.transform.stream.StreamResult res =  new javax.xml.transform.stream.StreamResult(new StringWriter());
    transformer.transform(source, res);
    String xmlResult = res.getWriter().toString();
    return xmlResult;
  /**using JAXB (jaxb-2.2) to do the data binding*/
  public Organization unmarshal(String result) throws JAXBException {
    Organization ret=null;
    JAXBContext jc = JAXBContext.newInstance(TNS);
    Unmarshaller u = jc.createUnmarshaller();
    JAXBElement element = (JAXBElement)u.unmarshal(new ByteArrayInputStream(result.getBytes()));
    return ret;


When doing xslt and jaxb inside a container you will most certainly run into classloading issues. But all containers have ways of controlling the application classpath to avoid some old container libraries being used from a parent classloader.


http://xml.apache.org/xalan-j/ for XSLT
https://jaxb.dev.java.net/ for data binding
Make sure you use JAXB 2.x,it has several improvements to 1.0. full XML schema support, generating pojos with annotations and javadoc etc.

MDB to consume messages from remote JMS destination


Asynchronous messaging decouples SOA components and will enable a more robust and reliable SOA system. JMS enables distributed SOA components to communicate asynchronously across networks, platforms ans technologies. Here are the tasks involved in setting up a MDB using ejb3-annotations to consume messages from remote JMS destination.


MDB will be deployed to oc4j_apps container within Oracle SOA suite on server 1, and a oc4j_soa container within Oracle SOA suite on server 2 provides the JMS destination, see figure.
It is actually an ESB JMSAdapterService producing messages to jms/Topic.
A next step will be to introduce a separate container (third-party) responsible for providing the JMS destinations. The only limitation is that a third-party JMS resource adapter must be available from within the soa suite. For this task Spring Integration will come in handy. But ejb3 is far smoother as MDB than the spring alternative MDP (Message-driven POJO). Even if Spring framework does have some advantages, to much of the container responsibility is taken over by DI, and you end up wading around in xml configuration.

on server 2, create JMS resource adapter configuration, JMS connection factory and JMS destination.

  1. oc4j_soa->default->JmsAdapter->Connection Factories->Create

    • Connection Factory Interface : oracle.tip.adapter.jms.IJmsConnectionFactory
    • JNDI Location : eis/Jms/MyTopicConnectionFactory
  2. OC4J_SOA->Administration->JMS Connection Factories->Create New

    • JNDI Location : jms/MyTopicConnectionFactory
  3. OC4J_SOA->Administration->JMS Destinations->Create New

    • Destination name : MyTopic
    • JNDI Location : jms/MyTopic

on server 1, create JMS connection factory and JMS destination.
To find the correct port when creating the RemoteconnectionFactory on server 1, execute
opmnctl status -l
OC4JGroup:default_group | OC4J:oc4j_soa | 11196 | Alive | 857355163 | 253252 | 23:27:49 | jms:12602,ajp:12502,rmis:12702,rmi:12402

  1. OC4J_SOA->Administration->JMS Connection Factories->Create New

    • JNDI Location : jms/MyRemoteTopicConnectionFactory
    • Host : server 2
    • Port :12602
  2. OC4J_SOA->Administration->JMS Destinations->Create New

    • Destination name : MyTopic
    • JNDI Location : jms/MyTopic

Finally, this is the MDB, with ejb3 annotations. What a relief to skip the deployment descriptors, both the standard and the server-specific.

    activationConfig = {
      @ActivationConfigProperty(propertyName="connectionFactoryJndiName", propertyValue="jms/MyRemoteTopicConnectionFactory"),
      @ActivationConfigProperty(propertyName="destinationName", propertyValue="jms/MyTopic"),
public class OrganizationEventsListenerMDBBean implements MessageDrivenBean,MessageListener {
  private static final long serialVersionUID = 1337741483828068799L;
  public void ejbCreate() {}
   public void ejbRemove() {}

    public void onMessage(Message message) {


With EJB 3.0, the standards-based approach, wide use of annotations, and tight integration with the application server all result in greater vendor independence and developer productivity. With Spring, the consistent use of dependency injection and the centralized XML configuration file allow developers to construct more flexible applications and work with several application service providers at a time.


https://support.oracle.com Note 726803.1
onjava: spring-ejb3

Maven JDeveloper plugin

As part of the Apache Myfaces Trinidad project there is a maven JDeveloper plugin developed. This is made available to easily move from the maven project structure to JDeveloper setup. The maven plugin is generating the *.jpr and *.jws files. The command for generating the JDeveloper metafiles is not straight forward, but when you type it correct it will save you a lot of time.

mvn -Djdev.release= org.apache.myfaces.trinidadbuild:maven-jdev-plugin:jdev

Note that there is only project.xml templates for JDeveloper releases,,,, But that is fine. Just go to the a release number before the one actual used, because when opening in JDeveloper, the migration to correct version will happen. Now the next thing would be to have some deploy profiles created, but this could more effectively be done using core maven.

of course mvn eclipse:eclipse will generate .classpath .project to make the project available in eclipse.
So letting maven produce the JDeveloper metafiles and Eclipse metafiles make it easy to switch between the two environments. Something is faster to do in JDev and something is faster to do in Eclipse. Freedom of choice.

See also:





Crowdsourcing is an open call to a large group of people (a crowd) asking for contributions. There are some examples out there where the crowd contributes.

successful examples

  1. Innocentive - connecting companies, academic institutions, public sector and non-profit organizations with brainpower. Any company, no matter how big, can be sure that there is more brainpower outside the company, than inside. Getting the brightest brains to work as freelance problem solvers is the idea. Smart brains that can suggest solution, without risking their career, or reputation among colleagues, have brought up some innovative solutions. Motivation from the solver, and from the seeker, is money, but still it is crowdsourcing. The solver can normally be considered an amateur.
  2. iStockPhoto- connecting contributing photographers and purchasers in a community. The contributors provide photos, videos, illustration, audio through a micropayment model. The contributors consider themselves amateurs, even if there is a money motivation.
  3. planetary geology- analyzing the Mars picture database for craters and other landforms. One professional scanned it in two years, a crowd of amateur astronomers did the same scan in a month, with higher accuracy. That is taking advantage of the passionate crowd.
  4. music, movies, and actually news, have the same low-cost contributor access. All it takes is a camera, a laptop, and dedication. Ok, if you plan for Avatar, it still might take some money.
  5. ideastorm (Dell)- open up for business innovations from everybody.

A crowd of amateurs is contributing because they want to, and thus have a passion for the field. (amateur (fr.) -> amore (lat.) -> passion).

In the digital era both production and distribution is available at low-cost. The cost of consumption is still left to the market.

The community

It is the community that is the real asset of Innocentive, iStockPhoto, Youtube, Facebook, etc. The latter two less interesting from a crowdsourcing perspective.
And the community can split within seconds, either for a better alternative or for something completely different.
So breaking the code is really to maintain the community. Some are successful giving out prize money, others are more modest on prize, but more biased on community recognition. At its best, community really gives a dedicated workforce, performing key functions.

Did pass through all the way to here without mentioning open source and Linux, but check this essay The Cathedral and the Bazaar

reference: Crowdsourcing, by Jeff Howe.

SOA – develop and release deployable unit


When working in a heterogeneous SOA environment there is usually a range of business components implemented using different technologies. The development tools will vary by technology, and by developer preference. Supporting a wide range of development tools will enable developer efficiency.
And there are development tools geared towards the different target platforms, like Oracle JDeveloper, Mule IDE, Netbeans, xml/wsdl generators etc., not to mention the .net side.

deployable unit

But when a deployable unit is prepared it is time to feed it into the release process. This is of course to keep manual intervention, and developer tools, away from the production environment.

Only deployable units that have been run through test, and QA, are processed through to staging and production.

release process

The release process requires a clear cut between development process and production environment. Did I mention ITIL?
And manual intervention should be limited, all the manual steps are error-prone. Putting effort into a standardized way of generating deployable units, and a well-defined process of certifying these deployable units is the way to go.

maven to produce deployable units

We have chosen maven to produce deployable units. Stay away from ant if you can. Still the developer can use the best available tool for efficiency on producing the deployable unit content, but final DU (deployable unit) is generated using maven. Maven is the obvious choice for this task. Wide range of plugins, and possibility to extend with self-made plugins. We had to create some maven plugins on esb and bpel-suitcase generation. This was to handle the different endpoints for different environments (DEV, INTTEST, SYSTEST, STAGING, PROD).

For coding components, like java ws, the different environments is handled by logic. So the component is self-responsible for resolving its environment, and corresponding properties.
The build time knowledge of environment properties is only relevant for configuration components, (esb/bpel).

script to support release process

To support the operational team on release process, a small set of scripts, adapted to the target enviroment is created. When Weblogic was target platform we used wlst, when Oracle SOA suite is target platform, we use the admin-client.jar library, combined with shell-scripts. All platforms will support command-line deployment!

It does take some preparation, but confidence on deployable units is mandatory in a SOA environment


Spend time establishing a release process within a SOA environment. Prepare to spend some time on establishing the final touch, suitable for your organizations needs, but remember that most is done in advance. You will find it in your target platforms libraries and documentation. Pull it out, twist it, and use it as you like.

Oracle ESB debugging

Oracle ESB => open up the black box

When executing service requests on Oracle ESB (pre 11g) it is difficult to trace the execution within the ESB layer. Pretty much left to Request going in, and Response coming out, if lucky. If there is something that requires debugging in the ESB layer it is a matter of enabling as much logging as possible. see how-to-enable-debugging-in-oracle-esb

logging configuration in oracle soa suite, j2ee-logging.xml

when playing around with the log configuration in Oracle SOA Suite the j2ee-logging.xml configuration could easily get corrupted. If you set a logger level to NULL the handler gets removed, and the only way to get the it activated is to edit the j2ee-logging.xml manually.
It is actually useful to have a manual verification that the handlers are not lost.
If log.xml is empty, or contains nothing/less than you expected, go have a look at the j2ee-config.xml to check that it actually makes sense.

Looking at the j2ee\oc4j_soa\config\j2ee-logging.xml it turns out that all the loggers that I configure had no handlers, looking like

<logger name=”oracle.tip.esb.server.service.impl.inadapter” level=”FINE”/>

instead of what I expected, something like

<logger name=”oracle.tip.esb.server.service.impl.inadapter” level=”FINE”>
<handler name=”oc4j-handler”/>
Manually correcting this directly in j2ee-config.xml and everything should start happen in the log.xml file again.

Lack of basic Oracle ESB functionality

To ellaborate a bit on the black box. Look at the ESB Console screenshot in figure 1. It is marked with status green, in the Instance pane, it is also green in the Graphical view, and status in the Details pane is:
Good, the happy day instance is green, but it is not possible to view the incoming request, or response payload on a successful instance.

28.10.2009 , 18_06_39
figure 1: A successful instance example, all green, but no tracing of payload

Another example, now with a more inconsistent set of statuses, Instance view is success, Graphical view is failure, and details view says: “Successful; however, the transaction was rolled back due to an error in undefined.”
Ok, if you say so.
The successful execution was rolled back, due to error in undefined, and I was confused, due to undefined error in undefined.

28.10.2009 , 18_17_10
figure 2: A successful instance example, or maybe a failed instance, at least an undefined error reported

Ok, on to last example, instance with error.
Both instance pane, graphical view and details pane are agreeing on error. And the details of the error is ellaborated in Details pane: “Failed because there was an error while processing the instance.”
Ah, so that is the reason!?

28.10.2009 , 18_14_27
figure 3: A failed instance, and all panes agree on a failed instance. The detailed and clarifying reason for failure is: “there was an error processing the instance.”

The good thing about instances in error are that the payload is available in ESB console, as well as a trace.
28.10.2009 , 18_29_19

Debugging ESB execution with such a console, can be compared to black box testing. You don’t even know if instance was success or failure.

put some light into the esb, enable debugging

By enabling logging, you could have a clue what is actually going on inside the black box of Oracle ESB 10g.

through enterprise manager console, enable FINE log level for



And look in $ORACLE_HOME\j2ee\oc4j_soa\log\oc4j_soa_default_group_1\oc4j\log.xml

(oc4j_soa is the oc4j instance name of oc4j instance running soa suite)


Logger Name Description
oracle.tip.esb.common.control debugging control events triggered from DT to RT
oracle.tip.esb.common.system debugging control events handler for ESB systems
oracle.tip.esb.configuration This package has miscellaneous common classes
oracle.tip.esb.configuration.servlet For debugging servlet that is invoked for deployment from JDev
oracle.tip.esb.configuration.util This package has miscellaneous utility classes
oracle.tip.esb.configuration.wsilbrowser For debugging WSIL browser servlet
oracle.tip.esb.console For debugging ESB Control console issues
oracle.tip.esb.dvm.configuration.servlet For debugging DVM configuration servlet
oracle.tip.esb.model.repository.database.sql For debugging data access layer to access metadata from oraesb schema
oracle.tip.esb.monitor.agent For debugging instance tracking
oracle.tip.esb.monitor.manager For debugging instance tracking
oracle.tip.esb.monitor.manager.database For debugging instance tracking
oracle.tip.esb.server.bootstrap For debugging ESB server bootstrap which manages startup and shutdown of ESB
oracle.tip.esb.server.bootstrap.protocol.esb For debugging slide repository related issues
oracle.tip.esb.server.bootstrap.slide For debugging slide repository related issues
oracle.tip.esb.server.common For debugging transaction related issues
oracle.tip.esb.server.common.cache For debugging cached metadata issues
oracle.tip.esb.server.common.error For debugging error management including retry for failed deferred messages
oracle.tip.esb.server.common.wsif For debugging outbound invocations via WSIF layer including request-response
oracle.tip.esb.server.dispatch For debugging dispatching of message for executing routing service
oracle.tip.esb.server.dispatch.agent For debugging dequeuer thread(s) polling messages on ESB internal topics
oracle.tip.esb.server.headers For debugging runtime header manipulation
oracle.tip.esb.server.service For debugging routing service and transformation
oracle.tip.esb.server.service.impl.bpel For debugging BPEL service invocation
oracle.tip.esb.server.service.impl.inadapter for debugging inbound adapter message headers, payloads etc…
oracle.tip.esb.server.service.impl.outadapter for debugging outbound adapter message headers, payloads etc…
oracle.tip.esb.server.service.impl.soap for debugging outbound SOAP message headers, payloads etc…
oracle.tip.esb.utils This package contains miscellaneous utility classes
oracle.tip.esb.wsif For debugging ESB header and ESB binding related issues