Friday, November 7, 2008

Checking for valid JNDIs in deployed BPEL/ESB projects

One issue I faced at a current client was JNDIs being referenced in BPEL/ESB code. Time and time again, BPEL processes and ESB services written by less experienced SOA developers referenced JNDIs that were not configured on the Application Server. This caused continuous errors in the logs. This also was of particular concern due to their being a single shared Dev environment.

As a result, it was decided to script a procedure that parsed each deployed service, and checked whether it referenced an existing JNDI or not. If it did not, an email would be automatically sent to the development lead notifying him of the details.

Script Output

The output of the BPEL script is as follows:



oracle@oradev1:/home/oracle/scripts> ./check_jndi_bpel.sh $ORACLE_HOME

JNDI Status     JNDI Name          BPEL Domain     BPEL Process
--------------  -----------------  --------------  --------------------
Configured      eis/Apps/CDHAM     ebiz            UpdateEBS
Configured      eis/AQ/EBSAM       ebiz            UpdateEBS
Configured      eis/AQ/EBSAM       ebiz            UpdateEBS
Configured      eis/AQ/SOA         default         DataSynchronization
Configured      eis/AQ/CDHAM       default         DataSynchronization
Configured      eis/AQ/CDHAM       default         DataSynchronization
Configured      eis/AQ/SOA         default         DataSynchronization
Not configured  eis/AQ/SOAD        default         CustomerPropogate

Output file created in: /home/oracle/ahmed/check_jndi_bpel.csv

The script also generates a CSV file with more detailed information (includes domain, process name, version, WSDL that was parsed):


The output of the ESB script is as follows:
oracle@oradev1:/home/oracle/ahmed> ./check_jndi_esb.sh $ORACLE_HOME /tmp/ahmedtmp

JNDI Status     JNDI Name         ESB Service(s) using JNDI
--------------  ----------------  -------------------------------------
Not configured  eis/DB/DEV2       <JNDI not used in any service>
Not configured  eis/DB/DEV2       A_112_Loc|B_112DBAdapter_RS
Configured      eis/DB/EBSAM      GetInvoiceCreationDB
Configured      eis/DB/EBSAM      InvoiceCreation

Output file created in: /home/oracle/ahmed/check_jndi_esb.csv
The script also generates a CSV file with more detailed information (includes project name, WSDL that was parsed, JNDI, ESB service names, ESB GUIDs):

The Logic Behind the Scripts

For BPEL processes, the logic is simply as follows:

  1. BPEL processes are deployed to project subdirectories located in $ORACLE_HOME/bpel/domains/<domain>/tmp.
  2. Parse the WSDL files in each deployed BPEL process.
  3. Browse for JNDI locations, which take the format <jca:address location="...>.
  4. Cross-reference the JNDIs with actual JNDIs configured on the Application Server (the oc4j-ra.xml files for the adapters are located under $ORACLE_HOME/j2ee/oc4j_soa/application-deployments/default/<adapter>).
  5. If a JNDI used in a BPEL process is not configured on the Application Server, then note the JNDI name, the WSDL file it was located in, and the BPEL process and version it belongs to.
For ESB services, the logic is as follows:
  1. When ESB projects are registered to the ESB server, they are deployed as zip files under $ORACLE_HOME/integration/esb/oraesb/deploy.
  2. Extract the zip files in a temporary location, and parse the WSDL files in each deployed ESB project.
  3. Browse for JNDI locations, which take the format <jca:address location="...>.
  4. Cross-reference the JNDIs with actual JNDIs configured on the Application Server (the oc4j-ra.xml files for the adapters are located in $ORACLE_HOME/j2ee/oc4j_soa/application-deployments/default/<adapter>).
  5. If a JNDI used in the ESB project is not configured on the Application Server, then note the JNDI name, the WSDL file it was located in, the ESB service(s) it belongs to, the GUIDs for the ESB service(s) (needed if you want to undeploy it via ant).
To get a copy of the scripts, please contact me.