I'm getting the following exception when attempting to execute an Axis 1 web service:

18/06/2014 12:25:16:821 DEBUG - 2C5BA99142CB1D6D50A1AF77BFA77187:/SCIF : Calling Web Service [VoiceServices] at [http://<server_ip>/ScifWSProxy/VoiceServices.svc] operation [emailLossRunReport]

18/06/2014 12:25:16:821  INFO - 2C5BA99142CB1D6D50A1AF77BFA77187:/SCIF : Capturing exception [com.avaya.sce.runtimecommon.SCERuntimeException].  Message [Unexpected format of web serivce client for VoiceServices. Could not find method to invoke the service.]

I have verified the web service method exists at the specified location (I wrote the web service), and I am able to execute the web service outside of Orchestration Designer using tools like SOAPUI and the Microsoft WCF Test Client.

I have attached both the WSOP file and the WSDL file. I'm passing a complex variable as the input parameter. In other web services at the same URL (all written by me), I am passing the same complex variable without issue. At first, I thought this complex variable may be the problem, but it's not as none of the other web services are having any problem accepting the complex variable. This is the only web service operation that is throwing this error, and I cannot figure out why.

Thanks in advance,
Michael

Apparently having an "int" input variable in an Axis 1 web service causes the problem. I changed the last input parameter from "int" to "string" and now it's working fine.

This appears to be a bug in the OD 6 framework. I do not know if it's present in OD 7.

Michael

Hmm, can you clarify what you mean when you say you changed something from an int to a string? Is this some Java code you're writing? Or do you mean in the web service itself, and WSDL?

The original exception you were having isn't actually coming from the framework, though it does look that way. It happens when the Axis 1.4 connector has issues with finding the method to invoke. Unfortunately, it's difficult to tell exactly what that means, as there are a few places in the code where that exact exception can be thrown. It seems like you've solved things already, but if you had more of the original stack trace I could figure out what the actual issue is and perhaps you wouldn't need to modify ints to be strings.

A couple of final things:

1. To address the OD 7 thing, this is an exception coming from Axis 1.4 so you'd still get the error in the latest OD.

2. Is there a reason why you're not using the Axis2 connector? Obviously it isn't required, but I know I've experienced situations where the newer Axis2 works hassle free, while Axis 1.4 takes some work.

Hi Samaresh, sorry for the delay, it's been an absolutely crazy day!

So, I changed the web service (WCF Web Service) input parameter from int to string, then regenerated the OD WSOP file. Once I did this, the web service was executed perfectly.

Prior to updating the WCF web service, I saw no activity from the OD application to the WCF web service prior to the error. The error happened while it was "Collecting" the input parameter values from the OD WSOP, prior to executing the WCF web service. Understanding that the error "usually" indicates the web service method doesn't exist, my first instinct was to add more debugging to the WCF web service. That's when I determined the problem was happening prior to OD calling the WCF web service.

As far as not using the Axis 2 connector... it doesn't work for what we need. Trying to pass an array of objects from WCF to OD forces us to use custom servlet code in order to properly parse the data and store it in an OD variable. Axis 1 creates the OD variable and stores the values correctly without needing to create custom code. I can provide a sample WCF web service and OD application to demonstrate this if needed, just let me know. Since we're a 3rd party developer, most of our customers aren't fluent in Java, so the need to "keep it simple" takes precedence over using the latest technology. By not needing to create custom Java servlets to parse the data, the customer can maintain the application after we've handed the code over to them. :)

Let me know if there's anything else.

Michael