Workflow and ServiceDesk Community

Hi,

I'm trying to create a Web Service integration Library component that connects to our ERP system. The ERP WS uses basic authenticaton and I have tested it with a SOAP testing application and the connection works fine there. When configuring the connection in Workflow WS WizardForm and testing any of the methods, I get a "The request failed with HTTP status 505: HTTP Version Not Supported." error message.

I have traced the communication between Workflow Manager and ERP and I believe that the problem is that the Workflow component doesn't send the authentication information in the HTTP header, even though the details are configured and validated earlier in the WizardForm. Below examples of network traces of the communication between ERP and SOAP Sonar application and Workflow Manager: (host and authorization content changed here, of course)

SOAP Sonar HTTP header:
 POST /oil/services/customer.customerHttpSoap11Endpoint/ HTTP/1.1
User-Agent: Crosscheck Networks SOAPSonar
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:getCustomersWhere"
Authorization: Basic lkuhsdfofihliuhgsaduf=
Host: xxxxxxxxx:8880
Content-Length: 427
Connection: Keep-Alive 

 

To this, ERP Ws repplies with the data requested and everything is fine.

But when the same is sent from Workflow:

  
Workflow HTTP header:
POST /oil/services/customer.customerHttpSoap11Endpoint/ HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.4952)
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:getCustomersWhere"
Host: xxxxxxxxx:8880
Content-Length: 347
Expect: 100-continue 

When ERP WS receives the above request, it replies with a 401 Unathorized message: 

 HTTP/1.1 401 Unauthorized
Server: Apache-Coyote/1.1
WWW-Authenticate: Basic realm="UserDatabase"
Content-Type: text/html;charset=utf-8
Content-Length: 954
Date: Thu, 07 Apr 2011 05:50:10 GMT 

 

Workflow replies to this with a proper header, including the authentication information, BUT before that it has already sent the actualSOAP request: 

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <soap:Body>
  <getCustomersWhere xmlns="http://xxx.xxxxx.xx/xsd">
   <args1>attribute = 999999</args1>
  </getCustomersWhere>
 </soap:Body>
</soap:Envelope> 

After this, Workflow sends the proper authentication HTTP header:

 POST /oil/services/customer.customerHttpSoap11Endpoint/ HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.4952)
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:getCustomersWhere"
Authorization: Basic lkuhsdfofihliuhgsaduf=
Host: xxxxxxx:8880
Content-Length: 347
Expect: 100-continue 

To this the ERP WS replies with the 505 HTTP Version not supported and closes the connection:

 HTTP/1.1 505 HTTP Version Not Supported
Server: Apache-Coyote/1.1
Date: Thu, 07 Apr 2011 05:50:10 GMT
Connection: close 

So, how do I get the authentication information to the original HTTP header, or is the problem somewhere else?

I don't have any solutions for you, but I can tell that the standard authentication pattern matches what you posted above.  You can verify this by looking through IIS logs on any site that has authentication required.

The first contact from a web client will be anonymous.  The web server then replies with a 401 (Unauthorized, but authentication is possible).  Then the web client should then reply with the same request, but include an Authorization header.

What's odd, is that a 505 error literally means that the web client is trying to communicate using an incompatible version of the HTTP protocol.  You can see the version string in first line of each message(HTTP/1.1), and both computers in the conversation appear to be using 1.1, implying that your web server supports 1.1.

If you look through your website logs, see if there is an extension to the status code. It should be an additional number like 505.x.  In IIS, it's in the next column following the status code.

Some things to try:

1.  It might be getting rejected because the web server doesn't want to utilize basic authentication.  See if there is an option to enable it and retest.  Some web based applications will only allow basic authentication if SSL is also enabled.  Check the documentation on your web-service to see if this is the case.

2. A very long time ago, I came across a web service that wouldn't work with the web service caller generator directly.  You should be able to export the WSDL file from your web-service by appending the parameter WSDL to the web-service URL  (http://mywebservice/service.asmx?WSDL).  In the generator use the WSDL file option to generate your components. 

In your project, use the newly generated WS component, and a "Create default access token" component.  Configure the token component with valid credentials, and then use its output variable on the security tab of your WS component.  Test that, and see if functions.  If so, please report back so a bug can be logged through support.

One additional thing occured to me, a bit of a longshot.  Make sure you don't have a proxy server between you and the target webservice.  It might be rewriting either server's message, or rejecting the request on behalf of your webservice.  I.e.  if the webservice isn't HTTP1.1 capable, but the proxy is rewriting the message in 1.1 format, then you could see this sort of odd behaviour.  Usually though, a proxy or reverse proxy is not 100% transparent, so I would expect to see something in the useragent header line.

No proxies in this case. Both systems are in the same network and subnet.

I tried using the WSDL file to generate components and added a "Create Basic Authentication token" component (it was easier :) ) in the workflow. The debugger stops with an Application Error page. Error message below.

The network trace shows exactly the same error as earlier...

I'll have to talk to the ERP provider and check out the logs and see if we can get more information on that 505 error.

 ErrorMessage = "The underlying connection was closed: An unexpected error occurred on a receive."
HTTP_INPUT_PARAMS = array
    [0] SESSIONID - RB_a9kd520mHKohgCclFmw
    [1] ALL_HTTP - HTTP_CONNECTION:keep-alive
HTTP_KEEP_ALIVE:115
HTTP_ACCEPT:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
HTTP_ACCEPT_CHARSET:ISO-8859-1,utf-8;q=0.7,*;q=0.7
HTTP_ACCEPT_ENCODING:gzip,deflate
HTTP_ACCEPT_LANGUAGE:fi-fi,fi;q=0.8,en-us;q=0.5,en;q=0.3
HTTP_HOST:192.168.150.126:4711
HTTP_USER_AGENT:Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16 ( .NET CLR 3.5.30729; .NET4.0E)

    [2] ALL_RAW - Connection: keep-alive
Keep-Alive: 115
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding: gzip,deflate
Accept-Language: fi-fi,fi;q=0.8,en-us;q=0.5,en;q=0.3
Host: 192.168.150.126:4711
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16 ( .NET CLR 3.5.30729; .NET4.0E)

    [3] APPL_MD_PATH -
    [4] APPL_PHYSICAL_PATH - C:\Program Files (x86)\Symantec\Workflow\WorkflowDeploy\Debug\Debug__3834\
    [5] AUTH_TYPE -
    [6] AUTH_USER -
    [7] AUTH_PASSWORD -
    [8] LOGON_USER -
    [9] REMOTE_USER -
    [10] CERT_COOKIE -
    [11] CERT_FLAGS -
    [12] CERT_ISSUER -
    [13] CERT_KEYSIZE -
    [14] CERT_SECRETKEYSIZE -
    [15] CERT_SERIALNUMBER -
    [16] CERT_SERVER_ISSUER -
    [17] CERT_SERVER_SUBJECT -
    [18] CERT_SUBJECT -
    [19] CONTENT_LENGTH - 0
    [20] CONTENT_TYPE -
    [21] GATEWAY_INTERFACE -
    [22] HTTPS -
    [23] HTTPS_KEYSIZE -
    [24] HTTPS_SECRETKEYSIZE -
    [25] HTTPS_SERVER_ISSUER -
    [26] HTTPS_SERVER_SUBJECT -
    [27] INSTANCE_ID -
    [28] INSTANCE_META_PATH -
    [29] LOCAL_ADDR - 192.168.150.126
    [30] PATH_INFO - /Debug__3834/StartDialog.aspx
    [31] PATH_TRANSLATED - C:\Program Files (x86)\Symantec\Workflow\WorkflowDeploy\Debug\Debug__3834\StartDialog.aspx
    [32] QUERY_STRING - SESSIONID=RB_a9kd520mHKohgCclFmw
    [33] REMOTE_ADDR - 192.168.150.126
    [34] REMOTE_HOST - 192.168.150.126
    [35] REMOTE_PORT -
    [36] REQUEST_METHOD - GET
    [37] SCRIPT_NAME - /Debug__3834/StartDialog.aspx
    [38] SERVER_NAME - 192.168.150.126
    [39] SERVER_PORT - 4711
    [40] SERVER_PORT_SECURE - 0
    [41] SERVER_PROTOCOL - HTTP/1.1
    [42] SERVER_SOFTWARE - LogicBase/7.1.0.0
    [43] URL - /Debug__3834/StartDialog.aspx
    [44] HTTP_CONNECTION - keep-alive
    [45] HTTP_KEEP_ALIVE - 115
    [46] HTTP_ACCEPT - text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    [47] HTTP_ACCEPT_CHARSET - ISO-8859-1,utf-8;q=0.7,*;q=0.7
    [48] HTTP_ACCEPT_ENCODING - gzip,deflate
    [49] HTTP_ACCEPT_LANGUAGE - fi-fi,fi;q=0.8,en-us;q=0.5,en;q=0.3
    [50] HTTP_HOST - 192.168.150.126:4711
    plus 2 other entries
LastComponent = "getCustomersWhere"
ModelID = "9ebfe4b6-ba64-435c-ad73-3965a38807c6"
StackTrace = "   at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
   at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at customerDynamicService.customer.getCustomersWhere(String[] args0, String args1)
   at customerDynamicService.getCustomersWhere.Run(IData data)
   at LogicBase.Core.ExecutionEngine.SinglePathProcessComponentExecutionDelegate.Execute(IData data, IOrchestrationComponent comp, String& outputPath, IExecutionEngine engine, TLExecutionContext context)
   at LogicBase.Core.ExecutionEngine.AbstractExecutionEngine.RunComponent(TLExecutionContext context, IData data, IOrchestrationComponent comp)"
ThisFormData = tunnus =
tunnus = "tunnus = 999999"