Azure 函数和 Soap：无法访问信封：无法从给定源创建信封：com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl答案

【问题标题】：Azure Function and Soap: Could not access envelope: Unable to create envelope from given source: com.sun.xml.internal.messaging.saaj.SOAPExceptionImplAzure 函数和 Soap：无法访问信封：无法从给定源创建信封：com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl
【发布时间】：2016-12-23 09:47:42
【问题描述】：

我目前正在尝试从我的 Azure 函数调用 SOAP 服务，这给了我以下错误：

但是，我能够成功处理来自 .NET 应用程序的请求。

HTTP 状态 500 - 请求处理失败；嵌套异常是 org.springframework.ws.soap.saaj.SaajSoapEnvelopeException：不能访问信封：无法从给定来源创建信封：；嵌套的例外是 com.sun.xml.internal.messaging.saaj.SOAPExceptionImpl：无法从给定来源创建信封：

这是一个第三方服务，它是用 Java 编写的。我不知道它是如何部署的，但是是的，因为它在控制台应用程序中运行，我觉得该服务没有任何问题：

string soapEndPoint = "https://<<url>>/endpoints";
string serviceOperationName = "SendLotListService";

SendLotListRequest sendLotListRequest = new SendLotListRequest();
SendLotListResponse sendLotListResponse = null;
sendLotListRequest.LotList = lotRecords.ToArray();

System.ServiceModel.BasicHttpsBinding binding = new BasicHttpsBinding(BasicHttpsSecurityMode.Transport);
binding.BypassProxyOnLocal = true;

EndpointAddress address = new EndpointAddress(soapEndPoint);

using (SendLotListServiceClient sendLotListServiceClient = new SendLotListServiceClient(binding, address))
{
    OperationDescription sendLotListOperation = new OperationDescription(serviceOperationName, new ContractDescription(serviceOperationName));
    sendLotListOperation.Messages.Add(new MessageDescription(serviceOperationName, MessageDirection.Input));
    sendLotListServiceClient.Endpoint.Contract.Operations.Add(sendLotListOperation);
    sendLotListServiceClient.Open();
    sendLotListResponse = sendLotListServiceClient.SendLotList(sendLotListRequest);
}

谁能建议这里有什么问题？

提前感谢您的帮助

【问题讨论】：

好像spring框架版本有问题。这适用于 Http 吗？查看相关问题：stackoverflow.com/questions/12467186/…
这也不适用于 http - 它给出了一个错误，说只支持 https。如果他们可以升级 spring 框架，我会尝试与第三方公司核实。跨度>

标签： java c# azure soap azure-functions

【解决方案1】：

感谢 Peter 和 vivasaayi 的 cmets，我在这些方向上进行了调查。

但是，由于我无法控制服务器上的 spring 框架，我无法升级它。另外，就执行时间而言，我的请求持续时间相对较短，因此超时也不是问题。

我可以通过在我的 .NET 客户端中添加以下代码行来修复它

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

【讨论】：

【解决方案2】：

在 MSDN 上有一个类似的issue，MSFT 对此案例的回复解释说，对于没有发回任何数据的请求有 230 秒的超时，请参见下文。

经过一番调查，我知道发生了什么事。对于未发回任何数据的请求，有 230 秒（即略少于 4 分钟）超时。之后，客户端得到你看到的 500，即使实际上请求被允许继续服务器端。

如果您希望进行持续这么长时间的服务器端处理，我建议您使用以更异步方式工作的备用流程。即让用户排队生成报告，然后在完成后允许他们下载。或者作为替代方案，您可以将结果上传到 blob 存储，并在那里可供取用。

我会争辩说，即使没有这个超时，如果大多数用户看到请求在他们的浏览器中旋转这么长时间，他们自己也会放弃请求。所以异步模式可以带来更好的用户体验。

希望对你有帮助。

【讨论】：