CA Gen Web Service Data Structure/Data Types (versus Java Proxy)
search cancel

CA Gen Web Service Data Structure/Data Types (versus Java Proxy)

book

Article ID: 221346

calendar_today

Updated On:

Products

Gen - Workstation Toolset Gen Gen - Run Time Distributed

Issue/Introduction

Transitioning from Java Proxy -> EJB Servers to Gen EJB Web Services and have an issue with converting data structures/data types.
There is a big difference between Java Proxy proxy and EJB Web Services that will impact the business.

1. Is there any workaround to get the web service data type in xsd to match the attribute/column definition in the model data structure list?
Here is the current summary of data types:


2. Also when generate Gen EJB Web Services with Gen 8.5 numeric attribute of length 10 displays as xs:double in xsd, while for Gen 8.6 it displays as xs:long.

Environment

Release : 8.6

Component : CA Gen Enterprise Java Beans

Resolution

1. Is there any workaround to get out the web service data type in xsd to match the attribute/column definition in the model data structure list?
There is no workaround aside from using custom EJB Web Service and the additional data types available there.
For the reason for the differences in data types between Proxy and EJB Web Service, information received from Gen Engineering is that those are due to the fact that the Gen EJB Web Services implementation uses some JAXB adapters to perform custom marshalling/unmarshalling in order to handle formatting issues with the data. In the Proxy implementation, those formatting issues would be the responsibility of the custom code that invokes the proxy. For example, Gen requires that Dates are sent to the proxy in YYYYMMDD format.
Here is the info on the adapters that are used by the Gen EJB Web Services implementation which matche above spreadsheet screenshot:https://api-broadcom-ca.wolkenservicedesk.com/attachment/get_attachment_content?uniqueFileId=xotpgGX9iZ95ZMSZ6ZKvwQ==

In summary for Gen 8.6 default EJB Web Service numeric attributes:
If the decimal precision flag is not set:
a. For decimal places = 0:
Length 1-4: defined as xs:short
Length 5-9: defined as xs:int
Length > 9: defined as xs:long
b. For decimal places > 0:
All attributes are defined as xs:string irrespective of length.

If the decimal precision flag is set:
All attributes are defined as xs:string irrespective of length.


2. Also when generate Gen EJB Web Services with Gen 8.5 numeric attribute of length 10 displays as xs:double in xsd, while for Gen 8.6 it displays as xs:long.
a. The xs:double v xs:long difference in the generated wsdl between Gen 8.5 & Gen 8.6 is due to not having all required GEN* & RTJ* PTFs installed.
The change from xs:double to xs:long in the generated wsdl occurred with GEN85023/RO86033 which included an EJB Web Service fix for problem "Numeric attributes defined with zero decimal places and a length greater than nine digits will contain a ".0" appended to their values in the SOAP response returned from an EJB Web Service.". That fix was released in late 2015 so well before 8.6 was released in mid-2016 and thus it went into the 8.6 GA codebase. There was also a co-req Java runtime PTF RTJ85010/RO86055.
b. In addition GEN85028/RO87769 fixed problem "Numeric attributes defined with one or more decimal places may be displayed in scientific notation in the SOAP response returned from an EJB Web Service.". That resulted in numeric attributes with decimal places changing from xs:double to xs:string in the generated wsdl which also matches the xs:string generated for numeric attributes with the decimal precision flag set.
NOTE: GEN85023/RO86033 and GEN85028/RO87769 have been superseded by later GEN* PTFs with GEN85048/LU00895 being the latest: CA Gen 8.5 Solutions & Patches