Friday, January 29, 2016

Oracle Kills Off The Java Plugin


Oracle has announced that they will be killing off the Java Plugin. Chrome and Firefox are removing support for plugins anyway, so the Java plugin is a vestigial security risk leftover from an earlier web.



Saturday, January 23, 2016

eText woes


What is the worst report template to work with ? After 9 years of working on varous Oracle report template formats, I am happy and frustrated to report that that would the the eText BIP template from Oracle.

It is commonly used to generate Payment Texts, to be processed by banks and other financial institutions, like ADP. It is the only Oracle template which can generate output in .txt format. It has very little functions, and all the documentation can be summarized to this one page. That’s it. All the functions and settings which can be used on the eText template is right there. The output of this template is not meant to be human-read, it is always meant to be transmitted to a banking or payment system via secure ftp. From the initial version of the template system, no new function has been added. So it is kinda version independent, there is no dependency on what version of BIP you have installed. eText templates designed on older versions of BIP will happily work on newer versions. And vice versa. But this is probably the only good thing ever about this template format.

Whereas BIP RTF templates also have some functions supported, there are ways to inject some xslt/xdofx functions in different namespaces into them. So this gives rise to redundant, but useful bunch of functions. And there is an added functionality of writing xsl templates within BIP RTF templates. And if even that does not work, one can link in external jars with added functions. But none of these can be done on eText templates. You have to make do with what you have.

Well this makes working on eText templates extremely frustrating. And error prone. The fact that you are designing payment system integrations increases the seriousness of the situation. If there are even fractional errors during the processing, that would direct the banks to pay a different amount out.Scary.

The good thing is that there is a small community of eText developers/consulants which can be accessed via supportweb. Most of the usual issues one faces are documented with workarounds. If a requirement cannot be done , all you can do is blame Oracle and tell the customer.

Here is an issue: you use the Number command to print numbers in the eText output.


Internally the template uses the format_number function to convert the source into a number. But this function has a problem, it errors out if the source data has non-numbers in it. It cannot even handle a null. So if the PAYMENT tag in the xml contains null or any non-integer, the template will error out.

Simplest solution ? Just multiply the source with 1  !


Multiplying with 1 will work fine if PAYMENT has numbers in it. And in case of any non-number, it will just get converted to 0 ! No errors thrown !

Weird. But it works, no need to do a separate check of null or isnumber.


Originally published on

Siebel IP 18 - 2018 SOD

Oracle is going ahead and staying with Siebel. For now. They have just released the statement of direction for IP 2018. At a high level th...