For the want of XML parsing, iPayment was lost; for the want of not being able to take payment, business was lost..
By gaurav.verma on Jun 17, 2007
want of a shoe the horse was lost;
and for the want of a horse the
rider was lost,
being overtaken and slain by the enemy,
all for the
want of care about a horseshoe nail." -
-- Benjamin Franklin
Preface - Oracle iPayment
Oracle iPayment is a complete payment and receipt processing solution
that enables efficient, reliable and secure financial transactions. It
is the central payment engine for Oracle E-Business Suite that lowers
costs and improves control by integrating out-of-the-box with major
processors and financial institutions.Oracle Payments offers end-to-end electronic payment processing that
includes validation, aggregation, formatting and secure transmission of
payments to financial institutions.
Impact of iPayment not workingIf a small or enterprise wide business has implemented the
Order-to-Cash business flow and has a moderate to high order volume, it
may not be surprising to have a backlog of 500,000 USD worth of orders
in a short period of downtime.
The impact of iPayment (online and batch transactions) not working would result in customer service representatives being unable to take Credit card orders. This can be highly probable since most of the credit card customers are large corporations or State/Federal Govt. clients.
Needless to say, iPayment not working is not good news for CFOs and results in large revenue losses.
Simple things can spoil the party...In Oracle Applications 11i (11.5.9/11.5.10), Oracle iPayment module relies on XML parsing function. Oracle ATG (Applications technology group) team provides such an XML parser.
An XML parser basically extracts information from a XML document. An illustration can be seen below:
Lets say one wants to come to apply a higher patchset for another functional module (say Fulfillment servers), it may be required to come first on a higher ATG patchset level. After a particular level, ATG upgraded its XML parser from 184.108.40.206 to 9.0.4 version.
The higher version of ATG patchset in 11.5.9 and 11.5.10 are compatible with the newer $JAVA_TOP/xmlparserv2-904.zip java class archive. But at the same time, other Oracle Applications modules (e.g. IBY - iPayment Patchset O - as in "Oh") may only be compatible with the older version of the XML parser, which is delivered in $JAVA_TOP/xmlparserv2.zip java class archive.
This divergent direction by different Oracle modules and ATG module causes issues for dependent modules which have requirement for XML parsing.
Even if you dont apply a higher ATG patchset and run Autoconfig on the server where iPayment servlet has been configured, you can run the risk of making iPayment not work if the following setting is present in the $CONTEXT_FILE :
sandbox07:web_dev> grep xmlparser $CONTEXT_FILE
This will propagate this setting in all the *.properties files in $IAS_ORACLE_HOME/Apache/Jserv/etc and iPayment servlet will use this class archive, thereby making it not to work.
Seeing the error message...
This is what you would see on the screen during a test credit card authorization via the iPayment Administrator responsibility..
And this is what you would see in the debug iby.log:
Root element name must match the DOCTYPE name.
Why doesn't it work...To sum up the issue, here's why it does not work:
xmlparser2-904.zip is newer code for XML parsing which is released by the ATG team. The older version was xmlparserv2.zip.
There is a validation behaviour difference between xml parserv2.zip and xmlparserv2-904.zip. In the newer version, the code raised following exception:
EXCEPTION:[iby.exception.Log.debug.generic]:oracle.xml.parser.v2.XMLParseException: Root element name must match the DOCTYPE name.
Factually speaking, this is just another observation in the series of issues where things used to work with 220.127.116.11(old version of parser) but got flagged with error when moved to 9.0.4 version.
According to the XML 1.x specification, the element name specified in the <!DOCTYPE...> tag must match the root element of the instance document, not the DTD document.
But at the same time, A DTD document may not even have a root element, since it is very possible to define multiple elements none of which ever can appear in the contents of another element. Thus the requirement that the root element of the instance doc match the DTD root element cannot be a requirement of the XML spec and is in fact an unreasonable requirement and can be classified as a code defect. Serveral bugs have been opened with XDK development on this issue (Bug 5080354 - XMLPARSER V2-904 VALIDATE ROOT ELEMENT ISSUE, Bug 5450336 - GENERATED XML PARSE ERROR WHITESPACE REQUIRED etc.)
Working your way around it..Although the ATG team has not provided an official backport of this issue in xmlparserv2-904.zip, a workaround exists: simply use the older version of XML parsing class archive, xmlparserv2.zip.
It is only required to make this change in jserv.properties and jserv_restrict.properties since iPayment servlet uses these configuration files.
sandbox07:web_dev> grep xmlparser $IAS_ORACLE_HOME/Apache/Jserv/etc/*.properties
To be on the safe side, you can even make these modifications in the $CONTEXT_FILE so that these settings are preserved across AutoConfig sessions on the ipayment tier:
sandbox07:web_dev> grep xmlparser $CONTEXT_FILE
<jto_classpath oa_var="s_jto_classpath" osd="unix">.:/ORACLE/apps/dev/common/java/jdbc111.zip:/ORACLE/apps/dev/common/java/xmlparserv2.zip:
<start_cmd oa_var="s_jtffstart">/usr/java/j2sdk1.4.2_07/bin/jre -Xms64m -Xmx256m -classpath.:/ORACLE/apps/dev/common/java/XXARRF.jar:/ORACLE/apps/dev/common/java/jdbc111.zip:
The potential way to resolution..Given the prominence of this bug in terms of XML document handling as well as the difficulty for us of modifying product specific DTDs, perhaps the best thing to do might be for the parser team to provide a fix for the 9.0.4 XML parser logic.
In this case, the IBY - iPayment module can use the workaround suggested, and resolve the problem in 11.5.10. However, as a lot of customers in 11.5.9 and the xml parser can be upgraded to 904 per ATG suggestion and might result in the same kind of error. It is incumbent upon the ATG team to find an answer to this situation.
In the meanwhile, we can use the workaround and keep the business going.