Hi,
I’m pretty sure that this Siebel Provider Web Service was originally working, but, it’s now started throwing the following error and the Siebel Guys are saying the request isn’t even reaching Siebel. Does anyone have any ideas ??

com.wm.app.b2b.server.ServiceException: [ISS.0088.9138] Input parameters do not conform to targetInputSignature:
errorCode=VV-003
pathName=/tns:LN_spcWMS_spcSO_spcUnlock_spc-_spcInbound_1_Input/xsdLocal1:ListOfLNWMSOrderInbound/xsdLocal1:OrderEntry-Orders/xsdLocal1:ListOfOrderEntry-LineItems/xsdLocal1:OrderEntry-LineItems
errorMessage=[ISC.0082.9027] Dimension mismatch, List expected

Thanks in advance for any assistance that can be provided.

David.

Check this element in the document:

/tns:LN_spcWMS_spcSO_spcUnlock_spc-_spcInbound_1_Input/xsdLocal1:ListOfLNWMSOrderInbound/xsdLocal1:OrderEntry-Orders/xsdLocal1:ListOfOrderEntry-LineItems/xsdLocal1:OrderEntry-LineItems

It is supposed to be a list but apparently is being created as a single record. Most likely a mapping issue when creating the doc to be sent.

Yeah finally got it… Tried specifying the documentTypeName on the xmlNodeToDocument, but, that wouldn’t create the document list when there was only one item (even though it is a document list in the document). Ended up setting makeArrays to True, setting the arrays name (not fully qualified - just xsdLocal1:OrderEntry-LineItems) and mixedModal to True. It’s now creating the correct DocumnetList with only one item… Thanks for your assistance Reamon.

Cheers,
David

If setting the documentTypeName in the call to xmlNodeToDocument didn’t work, then something is incorrrect in the document type definition or the XML being parsed. You should not be forced to use makeArrays set to true when you have a correct doc type.

I’m converting Tibco Integrations to webMethods. I have to use existing Tibco WSDL without changes as end-point applications are not to change (except for addressing URL). The document in question was generated out of the imported WSDL…

Hi,

Is there any way to suppress this validation?

Thanks
Kesavaraman

Recreate the wsdl and do a comparison with existing wsdl to find any differences. Let us know the result.

/Naidu

Hi Naidu,

Thanks for your reply.

What I want is to disable the validation feature for this webservice at connector side.
I believe right now the validation is enabled by default and the request is being validated against the WSDL definition and throws validation error. By all means there are no issues in WSDL and WM validation process.

In my analysis I found that watt.server.soap.validateResponse property can be used to disable/enable the response message validation but not sure how to control request message validation.

Do you have any idea?

In Detail:
watt.server.soap.validateResponse
Enables or disables SOAP response validation. When set to true, Integration Server
validates the SOAP response received by a web service connector. When set to false,
Integration Server does not validate the received SOAP response. The default is true.

This validation will be done by the soap processor against the input and output documents generated while creating the consumer.

I would suggest below for your requirement -

You can change all the elements (simple and complex) to optional. Then this validation won’t be done.
set attribute minOccurs=“0” for all the elements.

Once you change wsdl and create the consumer ws. So, now the documents(input and output signatures) will be having all optional fields. This helps in passing through the validation by soap processor.

Try to do a sample and test. How it works.

/Naidu

Hi Naidu,

Thanks for your suggestion.
Actually that’s what we are doing in worst cases. As we have hundred’s of webservices it’s a burden for us to update the client’s WSDL for every change requests. Hence by explaining WMs limitation to client we are getting the WSDLs with required definition.

As all other tools have an option to disable/enable the validation I feel WM also should have something similar to that but I couldn’t find.

Thanks
Kesa

Disabling validation is not the way. A wsdl is a contract between two parties. Manually changing the wsdl means you don’t agree to the contract in its current form. Just imagine what would happen if you send the other party a document which was invalid? The other party is going to reject the document.

If the other party is going to change the wsdl then they should notify you somehow giving you time to react to the changes and change code as needed.