Ramkumar Menon's Blog

Today, I ran into a silly issue where BPEL and ESB werent starting up.

There werent any log entries in orabpel.log or domain.log inspite of the fact that the log levels were all "debug".

It was throwing up this error - "Error while invoking bean "finder": Cannot lookup BPEL domain".

I managed to figure this out by going to the $ORACLE_HOME/j2ee/<oc4jInstanceName>/application-deployments/orabpel/<oc4jInstanceName_groupName>_<index>.log

And it gave me the valuable error message stating

07/08/02 11:36:14.961 startup: Error preloading servlet
javax.servlet.ServletException:
ORABPEL START-UP ERROR!!!!!!!!

OraBPEL run-time expected system environment property "orabpel.home".

From here, it was simple. I opened up the opmn.xml and figured out that JVM arguments [java-options] in the start-parameters for the oc4j module werent having the orabpel.home and oraesb.home set up at all.

Wondering how this missed out, but nevertheless, I added in the appropriate -D arguments for both system env properties through EM and restarted the server, and things went just fine.

Here are a few but "not comprehensive" differences between OC4J in a standalone configuration, and OC4J in an Oracle Application Server configuration.

[For comprehensive information, please refer to the "Introduction to OC4J" chapter in the "OC4J configuration and administration Guide"

Properties of OC4J in a Standalone configuration

1) Minimal set of components including J2EE and web services.
2) Comes with EM for administration
3) Can also be configured througth ant tasks or admin_client.jar
4) Available as a single zip file.
5) No backup, restore or disaster recovery capabilities
6) Comes with a builtin OC4J web server
7) Can be started using oc4j script or through oc4j.jar.
    for e.g. to startup the standalone oc4j instance,
   use oc4j -start or java -jar oc4j.jar.
   To shutdown, use oc4j -shutdown or java -jar admin_client.jar <args>. or java -jar <admin.jar> <options>

Properties of OC4J in an Oracle Application Server configuration

1) one or more OC4J Instances in an OAS cluster.
2) Comes with EM for admiinistration
3) Comes with a full fledged HTTP Server
4) Comes with opmn for starting/stopping/monitoring components like oc4j, http server.
5) comes with ONS for managing communication between components in the app server.
6) Allows for load balancing across group of OC4J Instances in a cluster. [communication between objects in the cluter is provided through ONS]
7) Can be administered through
   a) EM
   b) ant tasks
   c) admin_client.jar
   d) admin.jar
8) Backup, restore and disaster recovery capabilities available
9) web communications managed through OHS as the front-end listener. OHS passes incoming HTTP requests to mod_oc4j module, that dispatches the request to the approrpaite OC4J Instance using AJP at a configured port.

Today, I was running into an interesting issue while registering services in OWSM.

Lets say you are registering a service with the OWSM gateway. The WSDL of the service might import other WSDLs. If the WSDLs are imported using a relative location, things dont seem to work [registration would go through]- this is because OWSM does not seem to support virtualizing of imported WSDLs at a relative location. [Note that it does support virtualizing of imported XSDs.]

i.e.

<definitions>
  ...
  <import namespace=www.po.com location="../po.wsdl"/>
  ...
</definitions>

would not work.

What you could do instead is to host this WSDL through Apache, and then refer to the imported WSDL as an absolute URL

for e.g.

<definitions>
  ....
  <import namespace=www.po.com location="http://myserver.com:7777/wsdls/po.wsdl"/>
  ....
</definitions>

I invite comments from the readers on any other interesting alternatives they have taken to alleviate this issue.

There could be two reasons why this is happening.

a) The ESB RT and BPEL are running in separate OC4J containers. If they are, BPEL processes do not get auto-registered in ESB.

b) You had applied a 10.1.3.3 patch, and hadnt backed up your oc4j-ra files. In this case, when the patch is applied, the oc4j-ra files get overwritten with default contents, and the Topic Connection Factories that get used to propagate BPEL process metadata into ESB at deployment time go missing. Hence make sure that you backup all your oc4j-ra.xml files before applying the patch, and restore all of them after applying the patch. On the whole, read the 10.1.3.3 patchset notes carefully before applying the patch.

You might have seen this issue where the BPEL domains not appearing in the BPEL Console on server startup.

One of the reasons why this could happen is that you have an invalid value for the soapCallbackURL and soapServerURL. Ensure that these parameters have appropriate values. [These can be found in BPELAdmin]

The error message that indicates this issue can be found in the domain logs saying

ProcessJob::execute - Attempt 1/15 Trying to connect to <host>:<port>

Timed out connecting to <host>:<port>