我来帮你一步步排查这个问题——毕竟Postman能成功调用，说明API本身是正常的，问题大概率出在Logic App连接器的配置或者请求/响应的处理上：

1. 先对比Postman和Logic App的请求细节 #

这是最关键的一步，直接找差异：

• 检查请求头：SOAP API基本都要求Content-Type: text/xml; charset=utf-8，你可以去Logic App运行历史里找到这个连接器动作，点击「查看原始输入」，确认请求头是不是和Postman里的一致，有没有被Logic App的默认设置覆盖。
• 核对请求体：把Postman里的原始SOAP XML请求（就是包含用户名、密码的那段）和Logic App发送的请求体逐行对比，重点看参数是否正确填充、XML标签的大小写/命名空间有没有错——SOAP对这些细节特别敏感，少个命名空间或者标签大小写不对，API可能就返回空了。
• 查看原始响应：在Logic App的运行历史里点「查看原始输出」，如果原始响应本身就是空的，那肯定是请求没发对；如果原始响应里有sessionHeader但Logic App解析成了空对象，那就是响应解析的问题。

2. 验证WSDL导入的完整性 #

虽然导入时显示正常，但可能存在隐性的解析问题：

• 打开你的WSDL文件，确认登录操作的<output>部分有没有明确定义<LoginResult>和sessionHeader的结构，尤其是如果WSDL引用了外部XSD文件，要确认导入连接器时这些XSD有没有被一起加载——缺了XSD会导致连接器无法正确识别响应结构，直接返回空对象。
• 试试重新导入WSDL：有时候导入过程中会有缓存或者解析遗漏，删掉现有连接器，重新导入最新的WSDL，导入时留意有没有报错提示，比如某个依赖无法加载之类的。

3. 测试连接器的单独调用 #

脱离Logic App工作流，直接测试连接器：

• 进入自定义连接器的「测试」标签，输入登录参数后发送请求，如果这里返回的也是空，那问题就出在连接器本身的配置上；如果这里能正常拿到sessionHeader，那就是工作流里的参数传递或者动作配置有问题。
• 要是连接器支持日志功能，开启后查看请求和响应的详细日志，能更精准定位问题点。

4. 处理命名空间的坑 #

SOAP API对命名空间的要求几乎是苛刻的：

• 确认Postman请求里的命名空间（比如xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"或者业务相关的自定义命名空间），在Logic App的请求体里有没有完全对应上。很多时候就是因为少了个命名空间，API无法识别请求，直接返回空响应。
• 如果WSDL里定义了目标命名空间，连接器生成的请求体必须和Postman里的一致，不能有偏差。

5. 手动解析响应作为临时方案 #

如果以上步骤都试过还是不行，你可以绕开连接器的自动解析：

• 在Logic App里用「HTTP」动作直接发送和Postman一模一样的SOAP请求，然后用「Parse XML」动作手动解析响应XML，提取sessionHeader。虽然麻烦，但能先保证功能正常，同时继续排查连接器的问题。

内容的提问来源于stack exchange，提问作者crowhill