cancel
Showing results for 
Search instead for 
Did you mean: 

Adaptive Webservice Model with datatype base64Binary in Response

Former Member
0 Kudos

Hi,

i want to consume a webservice in a webdynpro-application using the Adaptive Webservice Model. The response of the webservice has a value of the XML schema datatype base64Binary. The model is constructed correctly with the relevant attribute as internal datatype binary. However, during runtime i get an exception when the framework tries to construct the instance of the modelobject for the response out of the soap-response (the value of the response is correct, i checked it with the base64-decoder of the SUN-jre).

Relevant stacktrace:

Caused by: java.rmi.RemoteException: Attribute value is not valid for attribute 'Response' of model class 'GenerateGridChartResponse'; nested exception is:

com.sap.tc.webdynpro.model.webservice.base.exception.BaseModelRuntimeException: Attribute value is not valid for attribute 'Response' of model class 'GenerateGridChartResponse'

at Config1BindingStub._invoke(Config1BindingStub.java:201)

at com.sap.engine.services.webservices.espbase.client.dynamic.impl.DInterfaceInvokerImpl.invokeOperation(DInterfaceInvokerImpl.java:63)

at com.sap.tc.webdynpro.model.webservice.model.WSGenericModelClassExecutable.execute(WSGenericModelClassExecutable.java:62)

... 34 more

Caused by: com.sap.tc.webdynpro.model.webservice.base.exception.BaseModelRuntimeException: Attribute value is not valid for attribute 'Response' of model class 'GenerateGridChartResponse'

at com.sap.tc.webdynpro.model.webservice.base.model.BaseGenericModelClass.setAttributeValue(BaseGenericModelClass.java:307)

at com.sap.tc.webdynpro.model.webservice.model.WSGenericModelClass.setAttributeForName(WSGenericModelClass.java:188)

at com.sap.tc.webdynpro.model.webservice.model.WSGenericModelClass._setField(WSGenericModelClass.java:67)

at com.sap.tc.webdynpro.model.webservice.gci.WSTypedModelClass._setField(WSTypedModelClass.java:125)

at com.sap.engine.services.webservices.jaxrpc.encoding.InstanceBuilder.readElement(InstanceBuilder.java:599)

at com.sap.engine.services.webservices.jaxrpc.encoding.InstanceBuilder.readSequence(InstanceBuilder.java:978)

at com.sap.engine.services.webservices.jaxrpc.encoding.InstanceBuilder.readContent(InstanceBuilder.java:1105)

at com.sap.engine.services.webservices.jaxrpc.encoding.GeneratedComplexType.deserialize(GeneratedComplexType.java:1621)

at com.sap.engine.services.webservices.jaxrpc.wsdl2java.soapbinding.MimeHttpBinding.getResponseDocument(MimeHttpBinding.java:1111)

at com.sap.engine.services.webservices.jaxrpc.wsdl2java.soapbinding.MimeHttpBinding.call(MimeHttpBinding.java:1439)

at Config1BindingStub._invoke(Config1BindingStub.java:192)

... 36 more

Caused by: com.sap.dictionary.runtime.DdCheckException

at com.sap.dictionary.runtime.DdTypeBinary.checkValid(DdTypeBinary.java:107)

at com.sap.tc.webdynpro.model.webservice.base.model.BaseGenericModelClass.setAttributeValue(BaseGenericModelClass.java:304)

... 46 more

I see no opportunity to change the internal datatype, as it is not editable. Reading the forum it seems that others had also similar problems with base64binary as datatype in a webservice. However, no solution was provided as well as it might have been the old webservice model.

Any solution would be nice, otherwise i guess i have to use another webservice-framework.

Thanks

Frank

Accepted Solutions (0)

Answers (1)

Answers (1)

SB9
Active Participant
0 Kudos

Hi,

One way would be to create a deployable proxy of the web service. you can use the wizard present in NWDS for creating a deployable proxy.

Then you can call this proxy from the webdynpro application to get response from webservice.

Another way out, is to encode the binary in string by writing a wrapper over existing webservice and then use the wrapper to get the response. The encoded string can then be decoded back to get the actual data. But in order to do this you should have access on the system exposing the webservice.

HTH!

Thanks,

S-B

Former Member
0 Kudos

Thanks for the offered solutions. Using string as returntype would be a possible workaround, as the application is currently the only consumer of the webservice.

Still i wonder if anybody else had this problem.

regards

Frank