You should be able to access a WCF web service, but it isn't a specifically tested scenario. I know that there can be issues when using an Axis2 client, so you might run into some of them.

If you try using the Axis 1.4 connector, it does give more information on what the error might be.

I was actually thinking the easiest way to parse would be to simply use the REST WSOP, in the Output Parameters section. You can add multiple variables/fields and the first column, Return Parameter, will take an XPath line. It will then find that piece of data and automatically parse into the variable/field you specify.

There is also an Edit Output button that will run the WSOP and give you back the XML in a new window. You can then select individual lines and assign variables to those lines. The XPath expression will be generated for that line. Usually that works fine, but in this case, the URL we're using is local, and it is generated randomly. What I did is add a print out line in the code so I could use the temporary file and get the XPath expressions:

...

			// Close the writer object

			wr.close();

			

			// Store the URL of the temporary file in an OD variable

			mySession.getVariableField(IProjectVariables.URL).setValue(mySession.getTempFileURL(file.getName()));



			// Print the URL to the console

			System.out.println(mySession.getTempFileURL(file.getName()));

...

The URL will look something like this:

http://localhost:8080/text_xml/data/temp/ddtmp5172061335925000918.xml

Once you have that, you can use it in the WSOP as the Endpoint, then click the Edit Output button. Then, assign variables for each piece of data you want, the XPath expressions are created for you, and that should be it. Since you overwrite the URL in Java during run-time, you can leave the Endpoint URL in the WSOP and it won't be used.

By default, the entire response will be stored in a single variable. It can be parsed into separate variables using XPath, though. The Output Editor button will try and run the web service client and let you choose individual values that can be put into variables or fields. If you're familiar with XPath and the format of the output, you could write it yourself in the Return Parameter column as well.

You're going to need to write some Java. The class com.avaya.ade.common.utils.crypto.MD5 will make one for you.

String md5 = MD5.getChecksum("STRING_VALUE");

DD/OD has web service and database connectors that can be used to access those services. Creating an operation file for either from the New menu will enable them, but since you need to configure the database connector, you can also do the following:

Right click Speech application -> Properties -> Dialog/Orchestration Designer -> Pluggable Connectors

There are 3 web service connectors, two which are SOAP based and one REST.

For your first issue, DefaultHttpClient is technically deprecated. Adding the annotation Eclipse suggests will get rid of the warning. If you'd prefer to use something not deprecated, though, you can replace that line with the following:

HttpClient client = HttpClientBuilder.create().build();

For the File issue, yes, java.io.File would be the correct import.

The output of the web service is now being stored in a temporary file, actually, hence why we needed the java.io.File import statement. To use a dynamic URL, yes, you would change the HttpGet line to what you have:

HttpGet request = new HttpGet(mySession.getVariable(IProjectVariables.IN__WSURL).getSimpleVariable().getStringValue()); 

That will read the URL from the OD variable instead. The response of the web service is then stored in a temporary XML file, located within the project. Once that is done, you would then run the REST WSOP, and use the URL of the temporary file. The following line stores the URL to an OD variable, which can then be read in by the REST WSOP:

mySession.getVariableField(IProjectVariables.URL).setValue(mySession.getTempFileURL(file.getName()));

In essence, the sequence of events is this:

1. Create custom Java client objects.
2. Do request to web service using a dynamic URL.
3. Store the response into a temporary file.
4. Read the temporary file using the REST connector.
5. Parse the response into OD variables using the REST connector.

In the VXML servlet, there is a method where you can create your VXML:

	public void markupLanguageGeneration(PrintStream out, Submit submit, SCESession session) {

		out.println("<block>This is hand written VXML.  Hello World!</block>");

		super.markupLanguageGeneration(out, submit, session);

	}

That's from the UserDefinedVXML sample application, and doesn't do anything more advanced. But, the general idea is to create each line and send it to the PrintStream object to append.

Okay, I've figured out a way for you to use the REST connector's parsing abilities to deal with the response from the custom client I provided. Below, I've modified the client with some extra lines. Comments are included:

		HttpClient client = new DefaultHttpClient();

		HttpGet request = new HttpGet("http://www.dickssportinggoods.com/webStoreLocator/index.jsp?store=dsp&zip=32901&maxLoc=4&searchRad=200");

		HttpResponse response;

		BufferedWriter wr;

		

		try {

			

			response = client.execute(request);

			

			// Create a new temporary file

			File file = mySession.createTempFile(".xml");

			

			// Create the reader and the file writer

			BufferedReader rd = new BufferedReader(new InputStreamReader(response.getEntity().getContent()));

			wr = new BufferedWriter(new FileWriter(file));

			

			// Read the first line and throw it away, because it is empty and makes the XML invalid

			String line = rd.readLine();

			while ((line = rd.readLine()) != null) {

				

				// Print the line out to the console (you can remove this if you wish)

				System.out.println(line);

				

				// Add the line to the temporary file

				wr.append(line);

			}

			

			// Close the writer object

			wr.close();

			

			// Store the URL of the temporary file in an OD variable

			mySession.getVariableField(IProjectVariables.URL).setValue(mySession.getTempFileURL(file.getName()));

		}

		catch (ClientProtocolException e) {

			e.printStackTrace();

		}

		catch (IOException e) {

			e.printStackTrace();

		}

That will get a response back and then store it into a temp file within the OD project. The temp file location is stored in an OD variable and used as the endpoint URL for the REST WSOP. I've set that in Java, like what you were doing with the custom URL:

        //}}END:CLASS:CONSTRUCTOR



	String endpoint = mySession.getVariable(IProjectVariables.URL).getSimpleVariable().getStringValue();

	setEndPoint(endpoint);

You can then parse out values into OD variables, like you probably want to, and continue on. I know this is a pretty manual way of doing things, and it requires some work, but since the rules for REST services aren't as rigid, like SOAP services are, issues like this can arise. I also haven't exported this and tried it on a production EP system, so further issues could arise there.

Let me know how it goes and if you run into any problems.

As for your original issue, I haven't been able to find anyway to forgo the XML validation on the web service response. The component that handles it is deep within Apache's framework and isn't really accessible. The only way I can think to make that web service work with OD is to write a custom client. It's a fairly simple thing to do, and involves a few steps. If you would like to try it, I've included the steps necessary below.

1. Download Apache's HttpClient. The current version as of this writing is 4.5, and that was what I used to test.

http://hc.apache.org/downloads.cgi

2. Unzip all the files located in the "lib" directory of the download into a temporary folder.
3. Copy every jar file into your OD project's directory. I would recommend using this folder:

<PROJECT_NAME>/WEB-INF/lib

4. Add the libraries to the project's build path:

Right-click project -> Properties -> Java Build Path -> Libraries tab -> Add JARs...

Navigate to the place where you copied the libraries into your project, and then add all of them. You can highlight all of them at once and add.

5. Create a servlet in your flow and use the following code:

		HttpClient client = new DefaultHttpClient();

		HttpGet request = new HttpGet("http://www.dickssportinggoods.com/webStoreLocator/index.jsp?store=dsp&zip=32901&maxLoc=4&searchRad=200");

		HttpResponse response;

		

		try {

			

			response = client.execute(request);

			BufferedReader rd = new BufferedReader (new InputStreamReader(response.getEntity().getContent()));

			String line = "";

			while ((line = rd.readLine()) != null) {

				System.out.println(line);

			}

			

		}

		catch (ClientProtocolException e) {

			e.printStackTrace();

		}

		catch (IOException e) {

			e.printStackTrace();

		}

You can now run the code above and it will print the response in the Console tab. Instead of writing the URL directly, you could use an OD variable, like you have been doing. The downside to this method is that because the response is treated as a giant string, there is no automatic parsing done, and code must be manually written to get values into OD variables. On the upside, I tested this and was able to get a response back.

Setting the Endpoint URL is correct, like you have in your code. It will build the rest of the URL from your input parameters at run time. Try printing the contents of that variable in the console to see what's being passed. Perhaps the string is empty, for some reason.

So, basically the easiest option would be to use the Axis2 connector rather than Axis for this WSDL. The problem is that Axis 1.4 is having trouble with these lines:


<wsdl:fault name="RequiredFieldException">
<soap12:fault name="RequiredFieldException" use="literal"/>


The highlighted bit there is the main issue. It's complaining that there is no "soap:fault" element because the web service has generated "soap12:fault" elements. Simply removing the "12" won't resolve the issue, and usually it's a bad idea to manually edit a WSDL that was generated unless you really know what you're doing and own the service.

Axis2 does not have a problem reading in the WSDL and generating code, and using it is considered a better long term solution.

MichaelReynolds wrote:Samaresh,
I am following this thread closely as I too need to assign the URL to the ResT web service dynamically. Won't the added endpoint addition to the WSOP JAVA be over written upon generation if it is not below an @override?

Any custom code that is written in autogenerated Java files must exist outside the areas outlined by the "START:CLASS:..." and "END:CLASS:..." comments. For REST Java files, you would write code below the lines that read:

...

        }

	setMessageBody("SlNPTg0KX3tTZXJ2aWNlTWV0cmljc31f");

        //}}END:CLASS:CONSTRUCTOR

...

chani wrote:Hello Samaresh,

I tried to run the application again with a few corrections and now it seems to be getting error while defining the end point. I have attached the console output along with the Web service operations java file.
Please advise if its still the xml response that is the issue or now it is having trouble in defining the endpoint for calling the web service. I had used your previous response to change the end point URL.

Thank you.

The error you're seeing here happens when the URL is not formatted correctly. If the protocol being used doesn't exist, for example, because of a typo. Or if the text itself isn't a URL at all, like if you try and give it a path on your file system without prepending "file:///" to the beginning. Make sure that the URL you're setting is in fact correct and doesn't have any mistakes.

If you're using OD 7 or later, you can create a REST WSOP from the New menu. There is a place where you can enter the full URL yourself, and/or use OD variable values as part of it. The return can then be mapped to another OD variable.