Hi,

I tried do create a new web service operation selecting to NOT unwrap the output parameter, so the output parameter is stored in a java object.

After doing that I could use the java code below to retrieve the response from the web service in DD.

Please give that a try.



   @Override
   public void requestBegin(SCESession mySession) {
   
      GetAgentLoginCredentialsResponse credentials = (GetAgentLoginCredentialsResponse)mySession.getVariable(IProjectVariables.GET_AGENT_LOGIN_CREDENTIALS_RESPONSE).getSimpleVariable().getObjectValue();
      
      GetAgentLoginCredentialsResult_type0 result = credentials.getGetAgentLoginCredentialsResult();
      
      super.requestBegin(mySession);
   }

Try to create a new web service operation and un-check the option to unwrap the output parameters from the web service. When you do that you will see the web service return as one single java object.

After the web service has executed you can get the value of that java object like this:
   
      ZCCS_VALIDATE_NUMBERSResponse response = (ZCCS_VALIDATE_NUMBERSResponse)mySession.getVariable(IProjectVariables.ZCCS_VALIDATE_NUMBERSRESPONSE).getSimpleVariable().getObjectValue();

OD currently do not support NTLM proxy authentication. I think http://ntlmaps.sourceforge.net/ would be a good option for you if your IT people will let you run it. But it might be a lot to configure if it is just the run the sample applications. Maybe you can find an internal web service to play with instead and then avoid having to deal with this?

Sure, you can email me at jakobsen@avaya.com

It looks like it could be a DD issue. Are you using the Axis2 or Axis 1.4 connector? If you post the wsdl file here I can take a look at it.

Axis 1.4 and Axis 2 are different implementation and use different encodings. I know Axis 1.4 did have some problems in the .net area so Axis 2 is probably the best route for you. I have not spent too much time analyzing the low level differences, but from your posts it sounds like you will be ok going with Axis 2, and if we can get that "Web Service Reply <- Variable does not exist " error figured out you would be good to go. Is that correct? It it is, please email a simple application which will product the last trace you posted and I will take a look at it. My email is jakobsen@avaya.com

I can duplicate the error here. Below is the full exception.

Unfortunately that is an exception happening when AXIS2 parses the wsdl file, so that web service is not comparable with Axis2. I only see two ways forward. Keep using the Axis 1.4 connector (It is still included with DD 6.0) or get the owner of the web service to get them to support Axis 2.


Exception in thread "main" org.apache.axis2.wsdl.codegen.CodeGenerationException: java.lang.RuntimeException: java.lang.reflect.
InvocationTargetException
at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:271)
at org.apache.axis2.wsdl.WSDL2Code.main(WSDL2Code.java:35)
at org.apache.axis2.wsdl.WSDL2Java.main(WSDL2Java.java:24)
Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at org.apache.axis2.wsdl.codegen.extension.SimpleDBExtension.engage(SimpleDBExtension.java:53)
at org.apache.axis2.wsdl.codegen.CodeGenerationEngine.generate(CodeGenerationEngine.java:224)
... 2 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.axis2.wsdl.codegen.extension.SimpleDBExtension.engage(SimpleDBExtension.java:50)
... 3 more
Caused by: org.apache.axis2.schema.SchemaCompilationException: can not find type {http://schemas.xmlsoap.org/soap/encoding/}Arra
y from the parent schema http://207.132.203.166:38080/ws/services/WSConnector
at org.apache.axis2.schema.SchemaCompiler.copyMetaInfoHierarchy(SchemaCompiler.java:1296)
at org.apache.axis2.schema.SchemaCompiler.processComplexContent(SchemaCompiler.java:1258)
at org.apache.axis2.schema.SchemaCompiler.processContentModel(SchemaCompiler.java:1153)
at org.apache.axis2.schema.SchemaCompiler.processComplexType(SchemaCompiler.java:1097)
at org.apache.axis2.schema.SchemaCompiler.processNamedComplexSchemaType(SchemaCompiler.java:1017)
at org.apache.axis2.schema.SchemaCompiler.processSchema(SchemaCompiler.java:931)
at org.apache.axis2.schema.SchemaCompiler.processElement(SchemaCompiler.java:592)
at org.apache.axis2.schema.SchemaCompiler.processElement(SchemaCompiler.java:552)
at org.apache.axis2.schema.SchemaCompiler.process(SchemaCompiler.java:1991)
at org.apache.axis2.schema.SchemaCompiler.processParticle(SchemaCompiler.java:1874)
at org.apache.axis2.schema.SchemaCompiler.processComplexType(SchemaCompiler.java:1081)
at org.apache.axis2.schema.SchemaCompiler.processAnonymousComplexSchemaType(SchemaCompiler.java:980)
at org.apache.axis2.schema.SchemaCompiler.processSchema(SchemaCompiler.java:934)
at org.apache.axis2.schema.SchemaCompiler.processElement(SchemaCompiler.java:592)
at org.apache.axis2.schema.SchemaCompiler.processElement(SchemaCompiler.java:563)
at org.apache.axis2.schema.SchemaCompiler.compile(SchemaCompiler.java:370)
at org.apache.axis2.schema.SchemaCompiler.compile(SchemaCompiler.java:280)
at org.apache.axis2.schema.ExtensionUtility.invoke(ExtensionUtility.java:103)
... 8 more

This sounds more like a lower low level error indicating the web service rejected the format of the request sent to it, so I would not expect the web service to throw this kind of exception for a failed authentication.

It looks like the DD application sends a soap request to the web sevice, and the web service responds with an error that content is not allowed in the prolog. That error is usually thrown when spaces have been inserted in xml document before the xml content starts. In your case it looks like the soap being generated by DD and sent to the web service is clean - the first char is the beginning of the xml, so your next step is to contact the owner of the web service and ask why they are raising this error.

If you use the Axis2 wsop connector and do not check the option to unwrap the output parameter you can get to the array like this:

   @Override
   public void requestBegin(SCESession mySession) {
   
      GetCardsResponse cardResponse = (GetCardsResponse)mySession.getVariable(IProjectVariables.GET_CARDS_RESPONSE).getSimpleVariable().getObjectValue();
      
      Ct_CardType[] ret = cardResponse.get_return();
      
      super.requestBegin(mySession);
   }

Please post a DD vxml trace showing the delay.

Where is the delay - on the DD side or in the Web Service

Ahh, you are right - we added soap tracing after 4.1 - I think in 4.1 the soap trace only went to the concole and not the trace file. But that is fine, you can easily find the delay in DD trace file without the soap. If you cannot find it, then post the DD trace for a call with the issue here.

In ddrt.properties you set localsoaptrace=true

Even without doing that you can tell where the time is spent just by looking in a regular DD trance. If the delay is DD waiting for the web service to replay, there is nothing you can do in DD, but you have to work with the provider of the web service asking why it is slow to replay.

Also if you enable soap tracing you can see exactly what and when the DD web service client sent the request to the server, and when the server replayed.