This discussion is archived
2 Replies Latest reply: Apr 27, 2012 2:50 PM by Invinceable (Vince) RSS

DB Adapter - DB2/JD Edwards Graphic Datatype Error

Invinceable (Vince) Newbie
Currently Being Moderated
Hello,

I am not sure which forum I should post this question to. If there is another forum, please let me know.

I am running into an issue with using the DB Adapter to insert into a DB2 database hosted on an AS/400. The column I am attempting to insert into is a graphic datatype which contains character data. The table is a JD Edwards table where character data is stored in graphic columns.

My development environment consists of the following:
J Developer 11.1.1.5
SOA Suite 11.1.1.5
DB2/400 Version 6, release 1
JDBC Driver - IBM JT400.jar
WebLogic 10.3.5

When I run the composite application in WebLogic, the process faults at the insert statement (error messages are posted below). When I look at my or-mappings.xml file I find the following mapping for the column causing the error:

<attribute-mapping xsi:type="direct-mapping">
<attribute-name>absic</attribute-name>
<field table="F0101" name="ABSIC" xsi:type="column"/>
<attribute-classification>[B</attribute-classification>
</attribute-mapping>

The attribute-classification seems incorrect. In J Developer 10, the attribute-classification was java.lang.String. When I manually change this attribute to java.lang.String, the application works correctly. This same error happens on all graphic datatype columns. At the top of the or-mappings.xml file, there is a reference to eclipselink. In J Developer 10, I think there was a reference to Toplink vs Eclipselink. So it appears that J Developer is now using EclipseLink by default to create the or-mappings.xml file.

I would rather not have to change the attribute-classification each time I want to create an insert statement. Is there a way to fix/configure how J Developer/EclipseLink creates this mapping? Is it safe to manually edit the or-mappings.xml file?

Thanks in advance.


The error messages I receive are:

<bpelFault><faultType>0</faultType><bindingFault xmlns="http://schemas.oracle.com/bpel/extension"><part name="summary"><summary>Exception occured when binding was invoked. Exception occured during invocation of JCA binding: "JCA Binding execute of Reference operation 'insert' failed due to: DBWriteInteractionSpec Execute Failed Exception. insert failed. Descriptor name: [F0101.F0101]. Caused by Exception [EclipseLink-3001] (Eclipse Persistence Services - 2.1.3.v20110304-r9073): org.eclipse.persistence.exceptions.ConversionException Exception Description: The object [xs:base64Binary SR Test Case - Vince], of class [class java.lang.String], could not be converted to [class java.sql.Timestamp]. Internal Exception: java.io.IOException: Error in encoded stream: needed 4 valid base64 characters but only got 3 before EOF, the 10 most recent characters were: "se - Vince". Please see the logs for the full DBAdapter logging output prior to this exception. ConnectionFactory property platformClassName was set to org.eclipse.persistence.platform.database.oracle.Oracle10Platform but the database you are connecting to is DB2 UDB for AS/400. Please validate your platformClassName setting. This mismatch can cause the adapter to trigger runtime exceptions or execute SQL that is invalid for the database you are connected to. This exception is considered not retriable, likely due to a modelling mistake. ". The invoked JCA adapter raised a resource exception. Please examine the above error message carefully to determine a resolution. </summary></part><part name="detail"><detail> Exception Description: The object [xs:base64Binary SR Test Case - Vince], of class [class java.lang.String], could not be converted to [class java.sql.Timestamp]. Internal Exception: java.io.IOException: Error in encoded stream: needed 4 valid base64 characters but only got 3 before EOF, the 10 most recent characters were: "se - Vince"</detail></part><part name="code"><code>null</code></part></bindingFault></bpelFault>

Exception occured when binding was invoked. Exception occured during invocation of JCA binding: "JCA Binding execute of Reference operation 'insert' failed due to: DBWriteInteractionSpec Execute Failed Exception. insert failed. Descriptor name: [F0101.F0101]. Caused by Exception [EclipseLink-3001] (Eclipse Persistence Services - 2.1.3.v20110304-r9073): org.eclipse.persistence.exceptions.ConversionException Exception Description: The object [xs:base64Binary SR Test Case - Vince], of class [class java.lang.String], could not be converted to [class java.sql.Timestamp]. Internal Exception: java.io.IOException: Error in encoded stream: needed 4 valid base64 characters but only got 3 before EOF, the 10 most recent characters were: "se - Vince". Please see the logs for the full DBAdapter logging output prior to this exception. ConnectionFactory property platformClassName was set to org.eclipse.persistence.platform.database.oracle.Oracle10Platform but the database you are connecting to is DB2 UDB for AS/400. Please validate your platformClassName setting. This mismatch can cause the adapter to trigger runtime exceptions or execute SQL that is invalid for the database you are connected to. This exception is considered not retriable, likely due to a modelling mistake. ". The invoked JCA adapter raised a resource exception. Please examine the above error message carefully to determine a resolution.
  • 1. Re: DB Adapter - DB2/JD Edwards Graphic Datatype Error
    JimScheitel Newbie
    Currently Being Moderated
    Just as an FYI for anyone else running into this problem - we have had an SR open with Oracle Support for a while on this and they are working on the issue.

    The problem is essentially this:

    JDE Oneworld running on iSeries/DB2 utilized CCSID 65535 GRAPHIC data types behind the scenes to handle storage of unicode information in EBCDIC. The JDBC driver handles this conversion for you, returning unicode data as long as you include the "translate binary=true" clause in the JDBC connection string. The driver returns string/nchar data for these CCSID 65535 GRAPHIC fields - they are not returned to the client as binary/clobs.

    SOA Suite 10.1.3.4.0 used "Oracle Toplink - 10g Release 3" for object persistence and mappings. In 11g, this was swapped out to use "Eclipse Persistence Services 2.x.x" for the object persistence and mappings. The original Toplink had a default behavior, that if it did not understand the type of the field, it would assume that the driver was handling it and would assume it was a string value, ie it would map it as xs:string and NCHAR. So one could argue (and Oracle support did...) that it was a bug that this ever worked in 10g/OAS. However it was a bug that worked out favorably. Eclipse Persistence Services did not have this bug, and whenever the developers see a GRAPHIC db data type, they assume that the information being returned to the client by the JDBC driver is in xs:base64Binary format.

    Bottom line if you do a simple hello world java project to use the jdbc driver and return the value, and examine that in hex, it is returning straight string values, not xs:base64Binary format stuff that need blob conversion code run.

    The good news is that Oracle has come up with a solution and is working on a patch for Oracle SOA 11.1.1.6.

    As a side note - Vince came up with a temporary workaround to get this working, which involves changing the three generated mappings/schema files manually to update the types, and per a suggestion from a very helpful Oracle technical Sales resource (Mike Loos) was working on an ant script to automate that process.

    If you need any more details, post and let us know. Vince or I will update this message when the patch is available.

    Jim
  • 2. Re: DB Adapter - DB2/JD Edwards Graphic Datatype Error
    Invinceable (Vince) Newbie
    Currently Being Moderated
    Resolution: Oracle created a patch for J Developer to solve the problem. Essentially the patch mapped the graphic datatypes to string datatypes. This was the behavior in Oracle 10g. I'm not sure how things are going to work if/when we have a graphic column that actually contains binary data instead of string.

    Patch that I applied: p13591655_111160_Generic.zip

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points