I don’t think the IS soapRPC service knows how to unmarshal or deserialize the electric.util.mime.MIMEData object.
It is possible to embed Glue into IS such that you can write Java services that invoke methods on Glue classes. Support can give you details on an update to the WmTomcat package that makes embedding Glue into IS a bit more straightforward.
If you can’t change the design of the web services you are consuming to avoid returning custom java objects, you will probably have to use an “embedded” Glue server to consume the services instead of the IS pub.client:soapRPC built-in service.
You are running into a very common interoperability challenge of SoapRPC. You are calling a service that is returning “objects” that your soap processor does not understand. Returning custom objects in a web service dramatically reduces their usefulness and interoperability as the consumer must understand something about the underlying implementation of the service in order to properly represent it internally.
Java based libraries such as JAXB (and Glue) provide mechanisms, often called mapping files, to tell the library or soap processor how to unmarshall a custom java object. IS does not have a way for you to do this.
This is one reason why the WS-I Basic Profile specifically excludes the soap-rpc/encoded “style” of web services.
HTH,
Mark
#webMethods#Integration-Server-and-ESB#Flow-and-Java-services