I am struggling with the following issue and your input will be very much appreciated!
In webMethods Developer(version 6.0.1), I genereted ws connector (see the attached) based on the wsdl (see the attached). The remote web service was developed in Java, deployed on WebLogic 8.1 (SP5). It takes an object as input and returns an object as response and is invoked by HTTPS. When running the client in Developer, I could not see the response back. The folks on the remote service side said their service see the input was empty. However, username and password passed over in the simple string type were recognized without any problem.
I am new to web service. Did I miss anything? Many thanks! patient-demo.wsdl (7.03 KB)
I am using RPC/encoded. The service take an object called DemographicRequest and output an object called DemographicResponse. Here are the first few steps for my client:
Map —> Set an input string
pub.string: base64Encode —> encode the input string
Map —> map the encoded string to DemographicRequest attribute which is an encoded string (see the attached screenshot). Might this have caused the problem?
pub.client:soapRPC → step to call the remote service
Should I try document/literal too?
Any of you can shred some light on this, I would appreciate it a lot!!
It appears that the ADTMessage within the DemographicRequest is, as you pointed out, a base-64 encoded representation of something. Perhaps a Java object? My guess is that base64 encoding of an input string is not the thing to do–otherwise the input type would simply be a string instead of xsd:base64Binary.
The key is to find out exactly what that web service is expecting for input. If they expect a serialized Java object that is base64 encode, then you’ll need to create such an object and marshall it. If that’s the case, the web service developers aren’t being very nice to their consumers.
Thank you so much for the reply, Rob. Though I was told by the web service provider that either String or byte encoded in base64 should be fine, I double checked the document and think you are right, the WS is expecting a byte encoded in base64 instead of a String.
Is there any built-in function in wM to encode a byte?
Thanks Mark. I found org.apache.commons.codec.binary.Base64 to encode byte and mapped it to ADTMessage. This time I got error ‘input data not conform to targetInputSignature’. Somehow I think the generated schema is not what the web service expected.
May I use Apache Axis API to create the client and then call that client instead of using wM SOAP API? Did anyone try it before?
I would instead use the WmPublic.pub.string.stringToBytes service.
This will take your string and create a byte. Then, you don’t need
to reference anything from apache.
Thanks Brett. I think I know what is the issue: the remote WS is actually expecting a base64Binary encoded byte, but when wM generates the ws connector, it treats base64Binary data type as a string type (encoded, of course).
How do I make wM treats base64Binary as an object encoded in base64, more specifically, as a byte encoded in base64?
One more thing: the web service provider told me that usually the client should be able to take care of the encoding when generated automatically. While in wM, I need to explicitly add a step to do encoding with pub.string:base64Encode. Any comments on this?
Thanks to Mark’s post [URL=“wmusers.com”]wmusers.com, I got the soap request message (see attached own_soap_req.xml). Folks on WS provider side sent me the soap request message (see attached provider_soap_req.xml) using THEIRworking client. Comparing the two requests, I see two major differences:
[LEFT] Tag name is different: in theirs and <stns_x003A_ADTMessage> in mine. I have no clue where <stns_x003A_ADTMessage> comes from. In the schema definition, it shows ADTMessage clearly as element in DemographicRequest.
[/LEFT]
[LEFT] The encoded string in theirs is different from mine! Mine has spaces to seperate the 4 segments. But even I remove the 4 spaces, only the first 110 characters are the same. Any idea?
[/LEFT]
[SIZE=2][COLOR=#0000ff]
There are some other tag names are different. But I guess those are OK. Either of the above two things or both of them cause the WS thinks the input is empty. And I guess <stns_x003A_ADTMessage> is the cause since even the encoding is screwed, the input shouldn’t be empty at least.
I have java service echoMe enclosed in the attached zip file. I followed these steps to register it before I can use it:
Register the service using the pub.soap.processor:registerProcessors built-in service. Specify “echo” for the “directive” and “descriptiveName” parameter and specify the fully qualified name of the java service as the “svcName” parameter.
I confirmed that my custom soap processor is registered using the pub.soap.processor:list built-in service.
I believe the encoding output difference is due to my client is using a different jdk version(1.3.1_19) from WS provider’s testing client (1.4.2_05). When I tried pub.string:base64Encode in webMethods 6.5 which is using jdk1.5, the output is almost the same as WS provider’s, just 6 characters difference.
Wondering if differences of those tag names is caused by version of WSDL as Marked mentioned? How do I find out which version of wsdl wM6.0.1 supports?
I was not referencing a difference in WSDL specification levels supported, but suggesting that if you have different tags in your request than the provider is expecting, then there is some sort of mismatch. They should provide you with a version of hte WSDL that matches the message structure that they are expecting.