Output signature oddity, .NET

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