Hello, I have an interesting situation. I would greatly appreciate any useful information anyone could toss my way.
Here is the scenario. I have a Integration Server package deployed into 2 environments. ( Web Service Connector ) Dev and Certification. Dev environment works perfectly. All calls to the webservice directly are perfect. However the issue is when I call Certification …
The Method being called simply returns a collection c# object via SOAP. Everything seems to work until the service returns more than 10 or so objects.
So, when the call is to return 10 objects it fine. 11 objects I get the message as follows:
( while writing this. i have found the following. )
It appears that Integration Server is validating and adding a time zone declaration randomly… So there is an EDT being added to the passed Date/Times.
webMethods Integration Server; Web Service Connector
Using browsers to consume and call the Web Service Connector.
Error Message is as follows:
[ISS.0088.9139] Output parameters do not conform to targetOutputSignature: errorCode=VV-004 pathName=/GetActivityResult[5]/DateTime errorMessage=[ISC.0082.9030] Type mismatch, String expected errorCode=VV-004 pathName=/GetActivityResult[5]/St errorMessage=[ISC.0082.9030] Type mismatch, String expected errorCode=VV-004 pathName=/GetActivityResult[5]/Am errorMessage=[ISC.0082.9030] Type mismatch, String expected errorCode=VV-004 pathName=/GetActivityResult[5]/Po errorMessage=[ISC.0082.9030] Type mismatch, String expected errorCode=VV-004 pathName=/GetActivityResult[5]/PoE errorMessage=[ISC.0082.9030] Type mismatch, String expected errorCode=VV-004 pathName=/GetActivityResult[5]/PoR errorMessage=[ISC.0082.9030] Type mismatch, String expected
Sorry, I had to change some of the names of the methods to protect their Identity !
.
The “correctly formatted” responses are as follows DateTime 2006-06-19T13:49:32.000 St 1111 Am 0 PoT 100 Po Hungy Hippo PoE 1 PoR 0
The Object thats killing it is… DateTime 2006-06-19 09:49:57 EDT St 1112 Am 0 PoT 100 Po Hungry Hippo PoE 1 PoR 0
the EDT its adding is causing the validation error since the type is DateTime.
All records are added in the same way, and it seems to randomly decide when to add the EDT at the end.
The XML Schema dateTime format calls for expressing the timezone either using a trailing ‘Z’ character to denote UTC time or using an offset in hours and minutes from GMT (e.g. “-04:00” for US Eastern time).
The datetimes in your example are both technically incorrect values for strings constrained as XML schema dateTime types.
If your service is supposed to be returning XML schema dateTime values, it’s not quite right. If it is not supposed to return dateTimes, then I suggest removing that constraint from the output document type. If this doc type was generated from a WSDL that specified XML schema datetime, then I’d guess that your C# service is not returning valid values.
Now, none of that has anything to do with why this would work for the first 10 request but not for the 11th unless somehow your C# service behaves differently after 10.
If you examine the XML response returned from your C# service, my guess is that you will find that the behavior is not random.
What are the IS versions on Dev and Cert? I’m currently chasing a similar issue “Type mismatch; string expected” where the web service connector running on 6.1 works, while on 6.5 it does not.
I think the EDT issue, while definitely a problem as Mark points out, isn’t the cause of the type mismatch error. If you’re running 6.5 I think there may have been a change in behavior of pub.client:soapRPC. The behavior is that the response fields (created by the web service connector wizard when processing the WSDL) are defined as strings, with w3c constraints. But IS 6.5 is marshalling the fields to their w3c data types–e.g. a double is converted to a double, rather than kept as a string. As a result, validation of the response fails with the type mismatch error–expecting a string but found a double (or boolean, or whatever).
I’m investigating now. Let me know what versions your Dev and Cert environments are.
We are using webMethods 6.1 for both Dev and Cert.
I have verified that this issue IS in both environments now. It just took alot of testing.
Yes, We are currently using SOAP-RPC.
Interesting note, I did end up going into the service and ‘strongly’ representing my date so its always in the format of
’ 1979-09-22T04:00:00Z ’ however now its just a plain old string.
And you guessed it, still errors !
Here is what I have now…
[ISS.0088.9139] Output parameters do not conform to targetOutputSignature: errorCode=VV-004 pathName=/GetExtendedMemberTransactionActivityResult[13]/St errorMessage=[ISC.0082.9030] Type mismatch, String expected errorCode=VV-004 pathName=/GetExtendedMemberTransactionActivityResult[13]/Am
errorMessage=[ISC.0082.9030] Type mismatch, String expected errorCode=VV-004 pathName=/GetExtendedMemberTransactionActivityResult[13]/Po errorMessage=[ISC.0082.9030] Type mismatch, String expected errorCode=VV-004 pathName=/GetExtendedMemberTransactionActivityResult[13]/PoE errorMessage=[ISC.0082.9030] Type mismatch, String expected errorCode=VV-004 pathName=/GetExtendedMemberTransactionActivityResult[13]/PoR errorMessage=[ISC.0082.9030] Type mismatch, String expected
Im curious on the String Expected Error, is this caused by validation failure?
Yes it is caused by validation failure. The document as returned and decoded by soapRPC does not match the document type identified in targetOutputSignature.
When you provide targetInputSignature and targetOutputSignature the soapRPC service will validate the input and output docs for conformance. What’s happening (in my case) is that the SOAP decoder is creating the field in the output document to be of the type specified by the content type (the fields I’m working on are double, int and boolean). The validator expects strings to be in the document (cuz that’s how the fields in the IS doc type are defined), not those object types.
Can you confirm that this is what is happening on your system? Can you post the raw XML response that you are getting?
I have an SR open with wM tech support. Will post the findings.
Can you post the WSDL that describes the operation you are invoking?
You can uncheck the validate output box on the web service connector’s input/output tab to suppress these errors. However, doing so hide valid error conditions.
We are using Windows 2003 for the Web Services,
and Im not totally sure what our webMethods servers are, since they are managed in a seperate facility.
If you have access to the web-based Administrator, click on the About link in the upper right to see a variety of information including OS and JVM vendors and versions.
The validation in this case is controlled by the parameters to the soapRPC call, not by the validation settings on the connector service. If you want, you can not set the targetOutputSignature parameter and validation of the output will be skipped.