When you try to call it as a cfobject/createobject, and then you call the method separately, did you try passing in a username/password combination as arguments, like you say you were offered to do in SoapUI? Maybe it’s that the method (of the web service) is requiring that.
Another thought: had you tried setting the wsversion attribute (on cfinvoke or cfobject, or as can be set for createobject as a corresponding key in the argstruct passed on the function call) to 1 or 2? That would change the behavior from axis1 to axis2, and may change how the authentication works. (Whether you should use 1 or 2 depends also on what you CF Admin or application level setting for wsversion is, as to whether you would need to override it on the tag like this.)
I realize I may seem to be speaking over your head, if you are new to all this. But if that helps you take the ball and run with it, great.
thanks for your suggestions, but neither changing wsversion from 2 to 1 nor passing username and password as arguments to the method make it work.
In SoapUI, the username and password are request properties, not arguments to the request. Is there any way to change or add request properties in cfinvoke/cfobject?
Has anybody ever successfully used cfinvoke or cfobject to consume a SAP webservice with recent Coldfusion versions? Or any non-Coldfusion webservice that requires authentication?
1 person found this helpful
I don't know the answer to your question. But I have worked with SOAP requests to non-CF services that require authentication before.
Normally, when a browser makes a request that requires web server authentication (Basic, Windows, digest), the browser will request the URL without credentials, receive an authentication error from the server, request the URL with credentials (after collecting them from the user), then automatically send the credentials for every subsequent request. But if it goes to another server that also requires credentials, it will have to repeat that process.
So, my question is, are the WSDL and the actual service on separate servers? This is allowed, but is not that common. If that's not the case, I'd open a support ticket with Adobe, because this seems like an obvious bug.
Dave Watts, CTO, Fig Leaf Software
thanks for your answer. In our case, the URL for the WSDL and for the actual webservice are indeed different, the service URLs are specified inside the WSDL in a <soap: address location> tag. They are not on a different Server, however, but in a completely different path.
It could well be that cfinvoke has a problem handling this. We don't have an Adobe support contract, so I cannot open a ticket with them, but I decided to abort the cfinvoke route and use cfhttp instead. I used SoapUI to determine the XML necessary to call the Service and copy/pasted that into my Coldfusion Code, works like a charm.
Problem not solved, but sufficient workaround found.
Thanks for sharing that. Please mark it as the correct answer. It will surely help someone else.
I see you have solved your problem, rspitzmd, but to be clear, you don't need any support agreement to open a ticket. What Dave was referring to (I'm sure) is the free, open Adobe CF bug reporting system, at tracker.adobe.com.