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.

anyone have any ideas?

Dustin,

To clarify, are you consuming a web service implemented using C# from an Integration Server web service connector?

What error message is returned when you request > 10 objects? Can you post a sample response message as an attachment or enclosed in

[CODE]
tags?

Mark

Mark,
Thanks for the quick reply !

• windows 2003 server hosting the .net web service.
• 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.

HTH,

Mark

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.

Aaaahhhh. If you are using Soap-RPC, that could explain things.

BTW, Microsoft recommends against using Soap-RPC for web services.

Mark

Okay, as an update…

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?

Thanks !

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.

This SR may apply to your environment. [URL=“https://advantage.webmethods.com/advantage?targChanId=kb_home&oid=1612295291”]https://advantage.webmethods.com/advantage?targChanId=kb_home&oid=1612295291[/URL]

It refers to IS_6-1_SP1_Fix14 which appears to have been superceded by IS_6-1_SP1_Fix85.

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.

Mark

Dustin, which OS are you using?

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.

Sorry, I had to comment some code out ( names ). hope it doesnt mislead ya.

BTW I really appreciate this

 <?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions name="CommonServicesSoap" targetNamespace="[URL="http://mySOAP.com/"]http://mySOAP.com/[/URL]"
xmlns:tns="[URL="http://-----.com/"]http://-----.com/[/URL]"
xmlns:wsdl="[URL="http://schemas.xmlsoap.org/wsdl/"]http://schemas.xmlsoap.org/wsdl/[/URL]"
xmlns:xsd="[URL="http://www.w3.org/2001/XMLSchema"]http://www.w3.org/2001/XMLSchema[/URL]"
xmlns:wsdns2="http://---------
xmlns:http="[URL="http://schemas.xmlsoap.org/wsdl/http/"]http://schemas.xmlsoap.org/wsdl/http/[/URL]"
xmlns:wsdns1="[URL="http://localhost//CommonServicesSoap/GetMemberTransactionActivity"]http://localhost//CommonServicesSoap/GetMemberTransactionActivity[/URL]"
xmlns:mime="[URL="http://schemas.xmlsoap.org/wsdl/mime/"]http://schemas.xmlsoap.org/wsdl/mime/[/URL]"
xmlns:soap="[URL="http://schemas.xmlsoap.org/wsdl/soap/"]http://schemas.xmlsoap.org/wsdl/soap/[/URL]">
<wsdl:types>
<xsd:schema xmlns:xsd="[URL="http://www.w3.org/2001/XMLSchema"]http://www.w3.org/2001/XMLSchema[/URL]" targetNamespace="[URL="http://localhost/SSADotComServices/CommonServicesSoap/GetMemberTransactionActivity"]http://localhost/SSADotComServices/CommonServicesSoap/GetMemberTransactionActivity[/URL]" xmlns:tns="[URL="http://localhost/SSADotComServices/CommonServicesSoap/GetMemberTransactionActivity"]http://localhost/SSADotComServices/CommonServicesSoap/GetMemberTransactionActivity[/URL]" xmlns:dx="[URL="http://www.speedway.com/speedyrewards/DotComServices"]http://www.speedway.com/speedyrewards/DotComServices[/URL]">
<xsd:import namespace="<A href="http://www.-------------"/">http://www.-------------"/>
<xsd:complexType name="__GetMemberTransactionActivitySoapIn">
<xsd:sequence>
<xsd:element name="MemberId" nillable="true" type="xsd:string" minOccurs="0"/>
<xsd:element name="auth" nillable="true" type="tns:__auth" minOccurs="0"/>
<xsd:element name="_port" nillable="true" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="__auth">
<xsd:sequence>
<xsd:element name="type" nillable="true" type="xsd:string" minOccurs="0"/>
<xsd:element name="user" nillable="true" type="xsd:string"/>
<xsd:element name="pass" nillable="true" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="__GetMemberTransactionActivitySoapOut">
<xsd:sequence>
<xsd:element name="GetMemberTransactionActivityResult" nillable="true" type="dx:ArrayOfPointsHistory" minOccurs="0"/>
<xsd:element name="SOAP-FAULT" nillable="true" type="tns:__SOAP-FAULT" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="__SOAP-FAULT">
<xsd:sequence>
<xsd:element name="faultcode" nillable="true" type="xsd:string" minOccurs="0"/>
<xsd:element name="faultstring" nillable="true" type="xsd:string" minOccurs="0"/>
<xsd:element name="faultactor" nillable="true" type="xsd:string" minOccurs="0"/>
<xsd:element name="detail" nillable="true" type="tns:__detail" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="__detail">
<xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
<xsd:schema xmlns:xsd="[URL="http://www.w3.org/2001/XMLSchema"]http://www.w3.org/2001/XMLSchema[/URL]" targetNamespace="[URL="http://www.speedway.com/speedyrewards/DotComServices"]http://www.speedway.com/speedyrewards/DotComServices[/URL]" xmlns:dx="[URL="http://www.speedway.com/speedyrewards/DotComServices"]http://www.speedway.com/speedyrewards/DotComServices[/URL]" xmlns:SOAP_ENC="[URL="http://schemas.xmlsoap.org/soap/encoding/"]http://schemas.xmlsoap.org/soap/encoding/[/URL]" xmlns:wsdl="[URL="http://schemas.xmlsoap.org/wsdl/"]http://schemas.xmlsoap.org/wsdl/[/URL]">
<xsd:import namespace="<A href="http://schemas.xmlsoap.org/soap/encoding/"/">http://schemas.xmlsoap.org/soap/encoding/"/>
<xsd:complexType name="PointsHistory">
<xsd:sequence>
<xsd:element name="DateTime" nillable="true" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="Store" nillable="true" type="xsd:long" minOccurs="0"/>
<xsd:element name="Amount" nillable="true" type="xsd:long" minOccurs="0"/>
<xsd:element name="PointsProgramId" nillable="true" type="xsd:long" minOccurs="0"/>
<xsd:element name="PointsProgramName" nillable="true" type="xsd:string" minOccurs="0"/>
<xsd:element name="PointsEarned" nillable="true" type="xsd:long" minOccurs="0"/>
<xsd:element name="PointsRedeemed" nillable="true" type="xsd:long" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ArrayOfPointsHistory">
<xsd:complexContent>
<xsd:restriction base="SOAP_ENC:Array">
<xsd:attribute ref="SOAP_ENC:arrayType" wsdl:arrayType="dx:PointsHistory[]"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
</wsdl:types>

<wsdl:message name="GetMemberTransactionActivityInput">
<wsdl:part name="MemberId" type="xsd:string"/>
<wsdl:part name="auth" type="wsdns1:__auth"/>
<wsdl:part name="_port" type="xsd:string"/>
</wsdl:message>

<wsdl:message name="GetMemberTransactionActivityOutput">
<wsdl:part name="GetMemberTransactionActivityResult" type="wsdns2:ArrayOfPointsHistory"/>
<wsdl:part name="SOAP-FAULT" type="wsdns1:__SOAP-FAULT"/>
</wsdl:message>
<wsdl:portType name="SSADotComServices_CommonServicesSoapPortType">
<wsdl:operation name="GetMemberTransactionActivity">
<wsdl:input message="tns:GetMemberTransactionActivityInput"/>
<wsdl:output message="tns:GetMemberTransactionActivityOutput"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="----Services_CommonServicesSoapBinding" type="tns:ServicesSoapPortType">
<soap:binding style="rpc" transport="<A href="http://schemas.xmlsoap.org/soap/http"/">http://schemas.xmlsoap.org/soap/http"/>
<wsdlperation name="GetMemberTransactionActivity">
<soapperation soapAction=""/>
<wsdl:input>
<soap:body encodingStyle="[URL="http://schemas.xmlsoap.org/soap/encoding/"]http://schemas.xmlsoap.org/soap/encoding/[/URL]" namespace="[URL="http://www.----Services"]http://www.----Services[/URL]" use="encoded"/>
</wsdl:input>
<wsdlutput>
<soap:body encodingStyle="[URL="http://schemas.xmlsoap.org/soap/encoding/"]http://schemas.xmlsoap.org/soap/encoding/[/URL]" namespace="[URL="http://www.-----Services"]http://www.-----Services[/URL]" use="encoded"/>
</wsdlutput>
</wsdlperation>
</wsdl:binding>
<wsdl:service name="---ServicesSoapService">
<wsdl:port name="S----ServicesSoapPort0" binding="tns:----ServicesSoapBinding">
<soap:address location="<A href="http://xxx/soap/rpc"/">http://xxx/soap/rpc"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Actually, that sounds like the issue I’m having as well. Yay ! Im not crazy !

This seems strange, I went in to disable it. and well, its already unchecked.

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.

Mark

Can you post this as an attached .txt file? The forum formatting mangled some of the xml tags.

Mark

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.

SOrry for the Redirect… Internet Explorer 7 crashes when I try and upload here…
http://www.guild-zen.com/ul/GetMemberTransactionActivity.txt

Don’t install IE7 Beta 2
GetMemberTransactionActivity.wsdl (5.53 KB)

I dont have access to view that either.

I would dangerously assume that its installed on Windows 2000 or 2003

I attached the WSDL for you after correcting a couple of typos. I think one of your “change all” edits to mask company information mangled the “wsdl:message” element and wsdl:operation “message” attribute.

At any rate, when I run this through the web service connector in Developer 6.5 SP2, I get an output document type containing strings with XML schema constraints of xsd:dateTime, xsd:long and xsd:string as specified in the WSDL. I can’t test how the soap rpc coder works without your service, so the same behavior may exist in this version of IS as well.

As a side note, what you are experiencing is just one of the many interoperability issues with soap rpc that cause many folks (including Microsoft) to recommend against using it. In addition, by attempting to return an array of non-string datatypes you are increasing the odds that a soap client will have interoperability issues with your dotNet web service.

I’ve written elsewhere in the web services / soap forum about using document/literal style for your web services. This requires way too much work from the IS side of things, but will help your dotNet services to be useful to a broader audience with far fewer interoperability issues. Microsoft has written literally mountains of stuff on how to use doc/lit with their tools.

HTH,

Mark

Im going to have to look more into using document/literal then ! hopefully Its a possibility.

thanks =)

Working with wM support it appears that there may be some sort of issue with IS 6.5. If you review the SOAP Developer’s Guide, pg 54, it describes how the SOAP response is decoded into the pipeline. On page 55 it states:

In my cases, this is not happening in 6.5. In the last statement, it implies that if you do not provide a targetOutputSignature, that everything will be rendered as strings. This isn’t happening either. Support is escalating this to development.

On 6.1 it’s worked as expected every time for me.

Dustin, based on this I’d suggest you open a support request with wM.

[/LEFT]

Dustin, does your SOAP response use multi-referenced parameters? The response I’m working with does. I wonder if that’s what the root problem is–mishandling of references. I’ll do some digging…

…Follow-up

Nope. Behavior is the same with “in-line” fields.

Well, here is an update…
There is definitely some sort of issue with the outputTarget

This is pretty neat though, I removed the outputSignature at the mapping step and from the whole service al together…

And now it works perfectly. I know its not the perfect fix, but for this being my first project with webMethods im hoping this is a decent fix.

does anyone know of any issues that may arise from removing the Output signatures?

I am assuming that i should just be more robust in making sure my consumers are validating their data.

Thanks for all the help guys, You’ve all been most helpful.

It Seems there is a problem removing the OutPut type.
Now whenever I consume the service. It essentially doesnt return anything.
Even though in developer it does display the values.

Im going to retire now…

Not quite sure I am following you here.

Are you saying that you can use a web services connector to invoke your C#-based web service and that when you step through the Flow you can see that the web service returns the expected results? If so, you just need to use the pipeline editor to map those results to a document type that is returned by your web services connector.

Mark

Hi All,

I too faced the same issue in 7x , converting the type to object resolved my issue.

pathName=/GetExtendedMemberTransactionActivityResult[13]/Am
errorMessage=[ISC.0082.9030] Type mismatch, String expected errorCode=VV-004

GetExtendedMemberTransactionActivityResult covert it to object in your document properties.

Regards
sandeep