Olite: to_timestamp(...) not working

I am still running olite for an old version of OC4J. Turning on sensor values for in a BPEL process started throwing errors as the query used to to_timestamp(...) which was not working in my version of olite.

After going through Oracle Olite docs, this how I came up with a temp-fix.

- Created a Java Class.
import java.sql.*;
public class Formatter {
public static Timestamp to_X(String date, String format) {
return new Timestamp(System.currentTimeMillis());
}
}

- Loaded this class into olite
SQL> create java class using bfile ('C:\Oracle\10.1.3.1\OracleAS_1\bpel\bin', 'Formatter.class');

- Bound Formatter.to_X(...) to to_timestamp(...) in olite.
SQL> create or replace function to_timestamp(a varchar2, f varchar2)
return timestamp as language java
name 'Formatter.to_X(java.lang.String, java.lang.String) return java.sql.Timestamp';

- Do not forget a commit after this.

Very slow file open dialog/"Save As" on Windows 7

I was recently experiencing very long delays before the "File Open" dialog opened up whenever "Save As" was clicked from Word or Excel. The blue wheel was spinning and spinning for minutes, before the dialog allowed me to choose anything. Finally found out that it was all related to a recent installation of SAP Portal Drive Client on my Windows 7 x64 laptop. Removing this client solved the problem immediately. I will update this blog later when I find out what in the tool was causing such a horrible delay.

OC4J - File interaction spec and last modified date.

The last modified date used by the File or FTP Adapter on BPEL PM or ESB deployed in an OC4J container can be found in
OC4J/j2ee/home/fileftp/controlFiles/_process-name~ver_/_mangled_name_/inbound/lastModifiedDate.txt file.

This file seems to be maintained for every process version, so deploying a new version of the a process will process any residual files in the incoming directory for the second time if the file/ftp adpater is not configured to archive or delete the incoming file.