ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » WMB: The given SOAPAction x does not match an operation

Post new topic  Reply to topic Goto page 1, 2  Next
 WMB: The given SOAPAction x does not match an operation « View previous topic :: View next topic » 
Author Message
Mhalaise
PostPosted: Wed Mar 02, 2016 4:43 am    Post subject: WMB: The given SOAPAction x does not match an operation Reply with quote

Newbie

Joined: 02 Mar 2016
Posts: 9

Hallo,

We're experiencing an issue with a SOAP call from WMB (ver 6.1.0.5) to an external (to us) webservice. We have a message flow which has worked correctly for a number of years, until the supplier of the webservice changed things their end. We were told by the suppliers that NO change (except the URL) was necessary, everything should just continue to work. But, we now get the dreaded "The given SOAPAction xxx does not match an operation" error! Other areas of our dev teams (those not using WMB) are able to use the service directly as they always. We, using WMB, suddenly cannot.

We've tried importing the 3rd party's .wsdl (even though we were told we wouldn't need to) and that has made no difference (except that the SOAPAction 'named' in the error is slightly different). In both .wsdls, the SOAPAction specified in the <soapOperation> is blank (""). We're at a complete loss as to what else to check for or how to resolve our issue. We've looked on the web but haven't really found anything to guide us (down to our own ignorance as much as anything else). Is this a case of our version of WMB being too far out of date? Or could there be something else? We'd be grateful for any pointers anyone could give. Also, what information would it be useful for us to provide to help you help us?

Many thanks,

Allan
Back to top
View user's profile Send private message
maurito
PostPosted: Wed Mar 02, 2016 4:49 am    Post subject: Re: WMB: The given SOAPAction x does not match an operation Reply with quote

Partisan

Joined: 17 Apr 2014
Posts: 358

Mhalaise wrote:
Hallo,

We're experiencing an issue with a SOAP call from WMB (ver 6.1.0.5) to an external (to us) webservice. We have a message flow which has worked correctly for a number of years, until the supplier of the webservice changed things their end. We were told by the suppliers that NO change (except the URL) was necessary, everything should just continue to work. But, we now get the dreaded "The given SOAPAction xxx does not match an operation" error! Other areas of our dev teams (those not using WMB) are able to use the service directly as they always. We, using WMB, suddenly cannot.

We've tried importing the 3rd party's .wsdl (even though we were told we wouldn't need to) and that has made no difference (except that the SOAPAction 'named' in the error is slightly different). In both .wsdls, the SOAPAction specified in the <soapOperation> is blank (""). We're at a complete loss as to what else to check for or how to resolve our issue. We've looked on the web but haven't really found anything to guide us (down to our own ignorance as much as anything else). Is this a case of our version of WMB being too far out of date? Or could there be something else? We'd be grateful for any pointers anyone could give. Also, what information would it be useful for us to provide to help you help us?

Many thanks,

Allan

First of all, wmb 6.0.1.5 is no longer supported.
Secondly, if the supplier changed the service that used to work, go back to them and tell them that they have broken it and ask them to fix it.
It is very likely that the message format has changed. Compare the old and the new wsdl and see if there are any changes.

You can also try importing the wsdl into SOAPUI and generating a message, then compare that message with the one you are generating.
Back to top
View user's profile Send private message
Mhalaise
PostPosted: Wed Mar 02, 2016 7:11 am    Post subject: Reply with quote

Newbie

Joined: 02 Mar 2016
Posts: 9

I am aware we're far behind on valid versions. One day, we might come out of the dark ages but I'm unable to influence that, sadly. I have to use what we currently have...

I agree with you regarding your 'secondly'. However, their service works when not invoked by WMB.

Indeed, I have tried SOAP-UI with the message format I am absolutely sure WMB is using yet, SOAP-UI works and WMB doesn't. The response, if I'm correct, comes from the backend we're invoking/calling so clearly something is wrong with our request but I cannot see, for the life of me, what.

The 2 wsdls (old and new) are similar in structure, the only differences I can see are around the spelling of port type, imported binding, binding operation and service port, all of which have been picked up correctly from the respective wsdls. A complete puzzle when you consider the 3rd party advised no change was required and, in the case of the the 'other' users, no changes have been made...
Back to top
View user's profile Send private message
mqjeff
PostPosted: Wed Mar 02, 2016 7:16 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

How are you specifying the action in the flow?

Is it possible that they've done stupid things like changing the case of the action? (I forget if SOAP cares about the case of actions).
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
Mhalaise
PostPosted: Wed Mar 02, 2016 7:41 am    Post subject: Reply with quote

Newbie

Joined: 02 Mar 2016
Posts: 9

The SOAPAction? We don't set that, and it's blank ("") in their wsdl. However, their new URL is along the lines of http://domain/function, where function is the function of the service we're invoking. The older URL was along the lines of http://domain/path_to_service and the function was embedded in the XML we send. We've been told it doesn't matter if the function is still in the XML. Indeed, I've tried with and without and it doesn't seem to matter, I get the same error

Worth noting is that the structure of the XML is a repeaing group of nodes, one of which can, itself, contain XML enclosed by CDATA. Totally horrible but the overall structure and the CDATA'd XML hasn't changed in both cases.

Cheers,
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Mar 02, 2016 8:13 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Mhalaise wrote:
The SOAPAction? We don't set that, and it's blank ("") in their wsdl. However, their new URL is along the lines of http://domain/function, where function is the function of the service we're invoking. The older URL was along the lines of http://domain/path_to_service and the function was embedded in the XML we send. We've been told it doesn't matter if the function is still in the XML. Indeed, I've tried with and without and it doesn't seem to matter, I get the same error

Worth noting is that the structure of the XML is a repeaing group of nodes, one of which can, itself, contain XML enclosed by CDATA. Totally horrible but the overall structure and the CDATA'd XML hasn't changed in both cases.

Cheers,

Is the SOAPAction still blank when SOAPUI is sending the request?
Is it blank or missing when IIB is sending the request?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
timber
PostPosted: Wed Mar 02, 2016 8:46 am    Post subject: Reply with quote

Grand Master

Joined: 25 Aug 2015
Posts: 1292

Is it possible that this is an SSL / TLS issue, and the error message is a bit misleading? One of the problems with using old software is that you don't get the latest security features...
Back to top
View user's profile Send private message
joebuckeye
PostPosted: Wed Mar 02, 2016 10:24 am    Post subject: Reply with quote

Partisan

Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH

fjb_saper wrote:
Is the SOAPAction still blank when SOAPUI is sending the request?
Is it blank or missing when IIB is sending the request?


This is what I would check. I know many people don't realize all the stuff soapUI does behind the scenes. Check the RAW tab and make sure that is the request (body and HTTP headers) the broker is creating.
Back to top
View user's profile Send private message
Mhalaise
PostPosted: Thu Mar 03, 2016 2:44 am    Post subject: Reply with quote

Newbie

Joined: 02 Mar 2016
Posts: 9

I've checked SOAPAction from SOAP-UI - it's blank. However, I can't see how to tell what WMB has done with SOAPAction. The "RAW" tab has been mentioned but I don't know what that is, probably it's not something our ancient WMB has?

I've dumped ${Root} after the call has faulted, the SOAP block of that shows operation as blank with an operation type of "UNKNOWN". But I don't know if that's pertinent here.

Not sure about it being an SSL/TLS issue - as far as we're aware, nothing has changed there.

Just to say thanks for all the suggestions/help so far, it's really appreciated
Back to top
View user's profile Send private message
maurito
PostPosted: Thu Mar 03, 2016 2:51 am    Post subject: Reply with quote

Partisan

Joined: 17 Apr 2014
Posts: 358

Mhalaise wrote:
I've checked SOAPAction from SOAP-UI - it's blank. However, I can't see how to tell what WMB has done with SOAPAction. The "RAW" tab has been mentioned but I don't know what that is, probably it's not something our ancient WMB has?

I've dumped ${Root} after the call has faulted, the SOAP block of that shows operation as blank with an operation type of "UNKNOWN". But I don't know if that's pertinent here.

Not sure about it being an SSL/TLS issue - as far as we're aware, nothing has changed there.

Just to say thanks for all the suggestions/help so far, it's really appreciated

Other things to check:
Namespace of the first element under the message Body. ( case sensitive )
Name of the first element under the message Body ( case sensitive )
Back to top
View user's profile Send private message
smdavies99
PostPosted: Thu Mar 03, 2016 2:52 am    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

I'd look at creating my own endpoint (SOAP Input node) run in Gatweay Mode. Then trace using a Trace node the ${Root} and ${LocalEnvironment} of your broker call AND SOAP/UI
That way you should be able to see the differences. Other than that, I'd resort to a tool such as WireShark to see both request types.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995

Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Back to top
View user's profile Send private message
Mhalaise
PostPosted: Fri Mar 04, 2016 2:19 am    Post subject: Reply with quote

Newbie

Joined: 02 Mar 2016
Posts: 9

Hi all,

Just wanted to let you know I'm still not having any success. I didn't want you all to think I'd 'fixed' the issue and rudely walked off without letting you all know.

maurito - namespace and names are all correct (spelling and case), butthanks for that suggestion - it did, at least, cause a double check

smdavies99 - good suggestion of the creating own endpoint, I did try that and, on the WMB side, I successfully traced the result. However, I was thwarted by our own firewall in trying to access that endpoint from SOAP-UI. That 'might' be sorted before I give up and come at this with a completely fresh solution (not sure what that'll be yet).

Overall, this has been a completely frustrating exercise so far, especially in light of the 3rd party say "no changes necessary" and that being proven by non-WMB use. If anybody has any further bright ideas, I'd love to hear them. Of course, if I manage to solve it this end, I'll let you all know (how, etc). I won't just walk off leaving you wondering...

Thanks for all the helpful suggestions so far, much appreciated
Back to top
View user's profile Send private message
maurito
PostPosted: Fri Mar 04, 2016 3:13 am    Post subject: Reply with quote

Partisan

Joined: 17 Apr 2014
Posts: 358

Mhalaise wrote:
Hi all,

Just wanted to let you know I'm still not having any success. I didn't want you all to think I'd 'fixed' the issue and rudely walked off without letting you all know.

maurito - namespace and names are all correct (spelling and case), butthanks for that suggestion - it did, at least, cause a double check

smdavies99 - good suggestion of the creating own endpoint, I did try that and, on the WMB side, I successfully traced the result. However, I was thwarted by our own firewall in trying to access that endpoint from SOAP-UI. That 'might' be sorted before I give up and come at this with a completely fresh solution (not sure what that'll be yet).

Overall, this has been a completely frustrating exercise so far, especially in light of the 3rd party say "no changes necessary" and that being proven by non-WMB use. If anybody has any further bright ideas, I'd love to hear them. Of course, if I manage to solve it this end, I'll let you all know (how, etc). I won't just walk off leaving you wondering...

Thanks for all the helpful suggestions so far, much appreciated

Just one more thought, and probably you have already done it, but anyway, you said you imported the new WSDL into your workspace. Have you dragged and dropped the new WSDL into the SOAPRequest node ?
Back to top
View user's profile Send private message
Mhalaise
PostPosted: Fri Mar 04, 2016 7:18 am    Post subject: Reply with quote

Newbie

Joined: 02 Mar 2016
Posts: 9

Hi maurito,

Yes indeed. Also used botht he 'old' service's wsdl, and the 'new' with same results (all bar the name of the SOAPAction which couldn't be 'found'). The two wsdls are identical except for some names (e.g. occurences of xxxWS have become xxxWService). Both wsdls work in SOAP-UI accessing both the 'old' service and the 'new'. Very strange...

Cheers.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Mar 04, 2016 8:52 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Mhalaise wrote:
Hi maurito,

Yes indeed. Also used botht he 'old' service's wsdl, and the 'new' with same results (all bar the name of the SOAPAction which couldn't be 'found'). The two wsdls are identical except for some names (e.g. occurences of xxxWS have become xxxWService). Both wsdls work in SOAP-UI accessing both the 'old' service and the 'new'. Very strange...

Cheers.


Usually I have 2 libs:
1st where I import / develop the xsds / wsdl, validate them.
2nd where I import the wsdl from 1st lib and assign to the flow.

The content of both wsdls is not necessarily identical, which is the reason why I do it that way.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » WMB: The given SOAPAction x does not match an operation
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.