Gunter, I appreciate that you used FR to find the indication of the call wanting an int, and it’s great that Mark shared the javacast, but since you’re still having problems applying those discoveries, would you please use one of the tools (whether SOAPUI or the soapclient svc) to let the WEB SERVICE tell you FOR SURE what datatype it expects for userid?
FWIW, I had been holding off suggesting javacast simply because the FIRST focus is to find WHAT datatype it expects. You seem to be dancing all around this simple suggestion I have made from the very first reply yesterday. I don’t understand why.
Was it perhaps challenging for you to find what the tools were reporting as the datatype? Again, since we can’t access the web service remotely, we can’t tell “for you”. Someone may propose that if you share the WSDL, we could look directly at it or point our own wsdl browsing tool at that. But note that often the wsdl will include references to still other wsdl which is pulled in dynamically, so we’d again not have access to that if it’s also not publicly accessible.
Bottom line: does your view of the wsdl or use of either tool show you WHAT datatype is expected for setuserid? Since that seems to be a setter that’s called implicitly, it may not appear in the definition of that getXTMInfo method you’re actually calling, but there should be definition SOMEWHERE in the wsdl that would define it.
I’m sorry, you’re right. But I’m not avoiding it, I simply couldn’t find that info in the SOAPUI application.
I downloaded the WSDL file (XTMCustomerMTOMWebService.xml (266.6 KB) ), and this is specified:
In case it is helpful … I had a similar problem and this was the code I used to manually make a request to the problematic webservice. I apologize that it is not commented very well but just to break it down:
‣ calls a remote webservice : svcUserAdmin Web Service (working url)
‣ notice the function is set to allow the manual entry of the variables (ex: …example.domain.com…) including AuthUserName, AuthPassword and DomainName
‣ notice the method called is GetUsers
‣ notice that after examining the webservice you can see that the result node name is: UserInfo … it would not take much for you to find your node name and required params to pass into your modified version of this function
Converts the data type of a ColdFusion variable to a specified Java type to pass as an argument to Java or .NET object. Use only for scalar, string, and array arguments.
Lucee:
Converts the data type of a CFML variable to pass as an argument to an overloaded method of a Java object.
Use only for scalar and string arguments.
So, meaning it is usable only for Java objects (so, not for “webservice” objects), and only for scalar and string arguments.
So JavaCast() holds no possible solution here anyway, correct?
I could set-up a public accessible URL + login/password to this web service if somebody is willing to investigate it a little further. But for obvious reasons, I don’t want to put those details here.
I really want to migrate our application to Lucee, but unfortunately, I encounter several incompatibilities with CF 9.01, and as long I can’t fix them, I’m forced to migrate it to CF 2018 in the near future, which is not my preference.
My go-to solution years ago was using the WSDL2Java.jar that was with cold fusion that creates a java version of the api and you can call all of that but it’s ugly as hell. PM me some details and I can see if I can get you a workaround.
Thanks Mark.
Mark found out it works perfectly on his setup (5.2.9.31).
I tried it on an express version of 5.2.9.31, and indeed, works as it should be.
So, probably something broke between 5.2.9.31 and 5.3.3.62. Will try with some express versions in between to see where exactly.
It looks like it broke between 5.2.9.31 and 5.3.1.95. Tried with all subsequent versions, none of them works. Tried with that latest snapshot (5.3.5.42), but same problem.
If somebody is willing to investigate this a bit further, or even fix it in code, here is a test code which can be used by everyone. The problem with this webservice is the same as on our private server:
When you run this on Lucee 5.2.9.31, you should receive this output/error, which is expected because the credentials are not good, but the function call is accepted: