NTLMAutClient认证正常但JSON PATCH请求遇0x80072530错误求助

我们已实现NTLMAutClient，使用有效NTLM凭证可正常完成认证，但执行JSON PATCH请求时，API返回错误码0x80072530，错误提示为**"Passed entity object cannot be null or empty"**。

请求JSON Payload #

{
    "headers":
    {
        "Content-Type": "application/json"
    },
    
    "endPoint": "",
    "baseUrl": "${crm_base_url}/api/data/v9.1/contacts(mli_integrationkey='CAS-${clientNumber}')",
    "method": "PATCH",
    
    "body":
    {
        "mli_mcfuserid": ""
    }
}

QMetry记录的请求与响应详情 #

请求详情 #

Client out-bound request
PATCH https://baseurl.com/CRM/api/data/v9.1/contacts(mli_integrationkey=%27CAS-1234567890%27)
Content-Type: application/json
{"mli_mcfuserid":""}

响应详情 #

Client in-bound response
400
Cache-Control: no-cache
Allow: OPTIONS,GET,HEAD,POST
Content-Type: application/json; odata.metadata=minimal
Expires: -1
Server:
x-ms-service-request-id: 8e609396-690e-44f4-8d9a-2cf2d423856e
Strict-Transport-Security: max-age=31536000; includeSubDomains
REQ_ID: 8e609396-690e-44f4-8d9a-2cf2d423856e
REQ_ID: 8e609396-690e-44f4-8d9a-2cf2d423856e
Set-Cookie: ReqClientId=20330979-0d93-47d0-bd2b-0313bef1fb24; expires=Fri, 19-Jan-2074 10:46:11 GMT; path=/; secure; HttpOnly
Set-Cookie: orgId=f1983a41-2ae6-e811-8120-0050568b693f; expires=Fri, 19-Jan-2074 10:46:11 GMT; path=/; secure; HttpOnly
OData-Version: 4.0
Persistent-Auth: true
Public: OPTIONS,GET,HEAD,POST
Timing-Allow-Origin: *
Date: Fri, 19 Jan 2024 10:46:10 GMT
Content-Length: 89

错误响应体

{
    "error": {
        "code": "0x80072530",
        "message": "Passed entity object cannot be null or empty."
    }
}

已尝试的调试手段 #

• 更新qaf-support-ws版本
• 更换不同NTLM凭证（包含/不包含ntlm.workstation和ntlm.domain参数）
• 尝试多种请求头组合

读取并执行JSON Payload的代码实现 #

JSONParser jsonParser = new JSONParser();
File file = new File(path);
Object data = jsonParser.parse(new FileReader(file));
JsonObject jsonObject = new Gson().toJsonTree(data).getAsJsonObject();
HashMap<String, Object> result;

try {
    result = new ObjectMapper().readValue(jsonObject.toString(), HashMap.class);
    RestRequestBean bean = new RestRequestBean();
    bean.fillData(jsonObject.toString());
    bean.resolveParameters(result);
    return WsStep.request(bean);
} catch (JsonParseException e) {
    logger.info("JsonParseException: ", e);
} catch (JsonMappingException f) {
    logger.info("JsonParseException: ", f);
} catch (IOException g) {
    logger.info("JsonParseException: ", g);
}

依赖版本 #

qaf: 3.0.0
qaf-support-ws: 2.1.13
quantum-version: 1.23.0

排查思路与解决方案 #

1. 修正请求体字段值格式 #

当前请求体中mli_mcfuserid为空字符串，部分OData服务（如Dynamics 365）会将空字符串判定为无效实体：

• 若要清空字段，改为传入null（需确认字段支持空值）：

  {"mli_mcfuserid": null}
  

• 若字段不允许为空，传入合法非空值测试。

2. 补充OData PATCH必备请求头 #

Dynamics 365等OData服务通常要求If-Match头支持并发控制，添加该头可解决部分实体校验问题：

"headers": {
    "Content-Type": "application/json",
    "If-Match": "*"
}

3. 统一JSON处理库避免序列化异常 #

代码同时混用org.json.JSONParser、Gson和Jackson ObjectMapper，可能导致请求体解析异常，建议统一使用Jackson：

ObjectMapper mapper = new ObjectMapper();
File file = new File(path);
Map<String, Object> result = mapper.readValue(file, new TypeReference<Map<String, Object>>() {});

RestRequestBean bean = new RestRequestBean();
bean.fillData(mapper.writeValueAsString(result));
bean.resolveParameters(result);
return WsStep.request(bean);

调试时打印bean中的请求体内容，确认最终发送的JSON与预期一致。

4. 验证框架请求构造逻辑 #

检查RestRequestBean和WsStep.request是否正确处理PATCH请求的body：

• 启用QMetry详细日志，查看请求发送前的body内容
• 用原生HTTP客户端（如OkHttp）直接构造PATCH请求，排除框架层面问题

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