Its seems that you have not defined the local name or the namespace property of your flow service properly.
The value of “local name” property should be same as the name of the root element of your input document and name space of your input document and flow service should also be same.
I have the local name property set to same as root element of and namespace name of input document and Flow service is same.
I am having this problem with not only my service, I downloaded the samples from Sticky posts of mcarlson and cjeganathan and both are giving me the same error HTTP error 404.
is there any way to find out whether the default soap processor working or not?
Usually the deault url for the default soap processor is:
http://:5555/soap/default
calling it form a browser should give you an error message something like this:
[ISS.0088.9109] SOAP is only supported using HTTP POST protocol
If you get a 404 calling this url from a browser the default soap processor is not accessible from soap/default.
If you examine the flow steps in the connector created, you should be able to find out which exact url the connector is using. I would suggest calling that url from a browser.
Note that i am referring to version 7.1.2 so my ideas might not apply for version 6.1.
Otherwise i noticed that the wsdl generated has an empty ‘soapAction’ attribute in the soap Operation element. This element is not necessary though, and i don’t know exactly how the default soap processor is dispatching requests to the right flow service.
In addition (but not related to your problem), there is a schema import statement with schemaLocation attribute, which in my opinion is pretty much useless:
The Integration Server provides a default SOAP processor registered under the name
“default.” The SOAP message handler invokes this SOAP processor when it receives a
URL whose process directive is set to “default” or is omitted entirely. This means that you can use following two URLS to access default soap processor.
http://:/soap/default
http://:/soap
And if default SOAP processor is working fine it should give you similer error that tom1299 has mentioned.
The default SOAP processor acts as a dispatcher that delegates messages to other services
on the Integration Server. It does this by invoking the service whose universal name
matches the qualified name (QName) of the message body’s first element. This service is
referred to as the target service.
The default SOAP processor selects a target service by matching the fully expanded
QName of message body’s first element to a universal name (implicit or explicit) of a
service on the webMethods Integration Server.
I can recall that once I resolved similer issue by setting the Execute ACL to anonymous and then restart the server.
Another possibility could be, that if you set the ACL of your service to anonymous, and pass a wrong user credentials, you will receive Access Denied exception.
To understand the authentication of a web service in webMethods following content might be helpful.
The Integration Server’s SOAP RPC and default processors do not authenticate a client’s user ID and password (credentials) when they receive a SOAP request. Instead, they authenticate a client just before invoking the target service. If the client’s credentials are not valid (as specified by the Execute ACL associated with the target service), the processor returns an HTTP 500 status code. A 500 status code indicates that the request could not be fulfilled because an internal error occurred on the server.
Certain SOAP clients (.NET clients, for example) issue an authentication challenge before submitting their credentials to a server. These clients do not supply a user ID and password when they transmit their initial SOAP requests. Instead, they provide these credentials only when they receive an HTTP 401 status code (which indicates an authorization error) from the server. Because the Integration Server’s built-in SOAP processors permit anonymous access, these clients never receive the 401 status code that will cause them to submit their credentials.
I am not sure how XML Spy passes access parameters, however you might get some idea if you compare the SOAP envelope generated by XML Spy and webMethods connector.