Mule APIkit Router multipart/form-data请求类型转换错误排查

• 基于RAML生成的自定义API连接器（即你使用的slack-system-api）自带请求组装逻辑：它不会读取你提前构造好的multipart/form-data格式payload，而是自动从内部变量vars['create-upload-file-request-data']中读取RAML定义的参数（files、channels、thread_ts），自行拼接符合规范的multipart请求体。你当前编写的RAML规范本身没有配置错误，不需要调整。
• 现有流逻辑中手动构造了multipart payload，但没有给连接器要求的入参变量赋值，导致连接器读取files参数时拿到null，尝试将null转为二进制类型时抛出类型转换异常，请求根本没走到APIkit路由后的业务逻辑，和后端接口实现无关。
• Postman测试可正常调用是因为Postman直接向后端接口发送了手动拼接的合规multipart请求，没有经过Mule API连接器的参数映射层，两者调用路径不一致。

• 移除现有Transform Message组件中手动构造multipart/form-data请求体的DataWeave逻辑，不需要手动调用Multipart模块组装请求。
• 选中slack-system-api:create-upload-file连接器组件，在右侧参数配置面板直接传入对应参数：
  • files参数：直接传入file:read组件读取到的本地图片二进制内容（即file:read执行后的默认payload）
  • channels参数：传入目标Slack频道ID字符串，例如"C03PLA21UHX"
  • thread_ts参数：无需线程回复时留空即可，需要回复指定线程时传入对应线程的ts字符串
• （可选排查步骤）如果需要验证参数是否正确传入，可以在连接器前添加Logger组件，输出vars['create-upload-file-request-data']变量内容，确认files字段为二进制值而非null后再发起调用。

补充说明：你注释掉的Multipart::file、Multipart::field写法，仅适用于不使用RAML生成的连接器、直接通过HTTP Request组件调用接口的场景；使用自动生成的API连接器时，这类手动组装请求的逻辑完全多余，反而会干扰连接器的正常参数映射。

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