Adaptive RFC 2 Model generates wrong Dictionary Type -> Exception

[michael_chytracek3]

Hi Experts,

We use CE7.1 EHP1 SP3 Pat0000. When generating a Webdynpro Model for a Bapi which uses a Attribute Domain based on a CHAR1 type the Java Datatype choosen is always a "boolean". At runtime this causes a "com.sap.tc.cm.base.exception.BaseModelRuntimeException: Class 'java.lang.String' of new attribute value is not assignment compatible for attribute 'Fltype' of type 'boolean' in model ... ".

This happens during unmarshalling from JCo Record and i haven't found a workaround yet (except changing the BAPI datatype which is not possible in this case). In our opinion this is a bug in RFC2 model generation because every ABAP Domain based on a CHAR1 field leads to a Java Attribute of type Boolean (even with a specified valueset, so that this attribute is not meant to be a kind of boolean).

Generating an "old style" RFC Model (which is now deprecated) works fine and the generated Java datatype is String with the correct valueset from the Abap dictionary metadata.

You can test this behaviour with the well known Bapi_Sflight_Getdetail flight example.

Any ideas for a workaround or if this is a bug when it gets fixed?

Regards

Michael

[Former Member]

Hi Michael

If your Issue is still not solved;

I actually have the same problem within a migration from arfc1 to arfc2.

After some tests and many times of troubleshooting, I created the whole

model again and reimported in into each public part and recreated nearly

the whole context (because of the structure-usage) - but it doesn't help!

Even after a redeployment and a restart of the j2ee, the model doesn't work propery!

I tried to get some information out of sap Note: 1310216

But nothing realy helpful was in there...

>I'm using a sap-standard structure (HRP1001) because of that, i can't edit the structure very easy..

Has someone else the same problem?

Best Regards

Marco

Some further informations: [|]

[Former Member]

Hi,

Please have a look at SAP Note Number: 1310216. Similar situation is explained for Webservice.

May be it helps.

Regards.

Rajat