C#对接MES传输数据：从Web API到断线补发的完整实践

简介：面向C#开发者和上位机/工业软件工程师的MES数据对接资源，围绕C#与MES系统之间的数据传输，覆盖PLC通信、OPC UA、Web服务/API调用、数据格式转换与安全传输等关键环节，适合工厂信息化、设备数据采集项目的初、中级开发者快速入手。压缩包共77个文件，约121KB，包含19个cs源码、11个config配置、5个txt说明，以及dll、exe、asmx、resx、pdb、suo等类型，从目录结构可看出同时提供HTTP POST客户端和Webservice服务端两套工程，能直观对照客户端发起请求、服务端接收响应的完整链路。已有6127人学习。资源内含Form1界面逻辑、WebService1.asmx服务端示例、App.config连接配置等可直接参考的工程文件，涉及通过HttpClient、SOAP/REST等方式与MES系统交换数据，也包含异步处理、错误处理、数据序列化等实现细节，对需要开展产线设备数据上报、MES接口联调、数据格式转换的开发者具有实际参考价值。

1. C# 对接 MES 传输数据：先跳出车间的“数据孤岛”

做了几年产线上位机，最常被问的一句话是“C#怎么跟MES对接传数据”。看起来是个接口问题，实际上牵扯到方案选型、报文设计、时序同步和断线兜底。很多人第一反应是数据库直连，省事，但后面翻车也多。我踩过一遍之后，现在倾向于 Web API + JSON 上报，配合本地队列缓冲。这篇文章把这套流程从选型到落地完整拆一遍，顺带列出五个真实翻车现场。适合刚接手 MES 对接的 C# 开发，也适合准备优化现有上位机上报逻辑的工程师。

2. 对接方案怎么选：Web API、数据库直连还是消息队列

2.1 三种主流对接方式的边界

MES 对接 C# 上位机，本质上是一条数据链路：PLC 采集数据，上位机做处理，最终写入 MES。数据怎么过去，常见就三条路：Web API、数据库直连、消息队列。三者的差异不在代码量，而在你愿意为谁买单。

数据库直连是很多老工厂的默认方案。C# 里配一个连接串，INSERT INTO完事。优点是开发最快，不需要 MES 方给你写接口，缺点也明显：MES 数据库表结构一变，上位机必须跟着改；跨网段访问数据库还要开放端口，安全上很被动；更麻烦的是，生产库被上位机反复读写，稍微一个烂 SQL 就能把 MES 拖卡。我见过某工厂因为上位机每两秒查一次工单表，导致 MES 页面转圈，最后排查出来直接傻眼。

Web API 是现在的主流。MES 给你几个 REST 端点，C# 拿HttpClient把 JSON 报上去。优点是边界干净：上位机不碰数据库，MES 侧能做权限校验、接口版本管理、调用审计。缺点是双方要约定报文格式，联调阶段稍微繁琐一点，但这是值得的，因为后期改字段只需要改契约。

消息队列（RabbitMQ、Kafka 这类）是重型方案。C# 把数据写到队列，MES 自己从那头消费。优点是抗峰值、断网缓冲都天然支持，上报线程几乎不会被 MES 的慢接口拖住。但代价是中间多了一套组件要运维，而且传统 MES 不一定愿意配合引入队列。如果 MES 方没有现成的消费端，这个方案基本推不动。

我在大部分项目里优先选 Web API，理由只有一个：接口是双方最容易对齐的契约，出了问题也好定位。

2.2 为什么主流是 Web API + JSON

先说结论：MES 对接选 Web API + JSON，不是因为技术新潮，而是因为它把“谁对谁错”这件事划分得足够清晰。

接口层面上，Web API 的粒度是“操作”而不是“表”。比如“上报产量”是一个接口，MES 内部是更新表还是触发工序流转，上位机不用关心。数据库直连则把表结构暴露给上位机，一旦 MES 升级，上位机就得跟着升，这种耦合在产线上特别致命。

JSON 作为报文格式，优点是自描述性强。字段名叫orderNo，MES 那边不查数据字典也能猜个大概。对比一下老式的 XML 报文或者定长字符串报文，JSON 联调时肉眼可见地好调试。C# 这边JsonConvert一序列化就能发，不需要手拼报文。

还有一层现实因素：MES 厂商现在基本都提供 REST 接口文档，Swagger 打开就能调试。如果对方说“只提供数据库视图给你”，那你要警惕，表面是省事，实际是把风险甩给了上位机这一侧。

选 Web API 时候也要跟 MES 方确认两件事：一是接口的认证方式，Token 还是 Basic，二是接口的调用频次限制。有的 MES 接口做了限流，上位机每秒钟打 10 次可能直接 429，这个问题联调阶段就要摸清楚。

2.3 接口约定和数据字典怎么定

接口约定这事，一定要在写代码之前跟 MES 方坐下来对齐。别等代码写完了才发现字段命名规则不一样。

常见的报文外层结构是这样：

{ "code": 0, "message": "success", "data": { } }

code = 0表示成功，非 0 表示业务失败。这个结构看着简单，但有个细节：code是 HTTP 状态码还是业务码，必须提前说死。有的 MES 接口 HTTP 永远返回 200，业务是否成功只看code，如果你按 HTTP 状态码判断，就会漏掉一堆业务失败。

字段命名上，C# 默认是 PascalCase（OrderNo），而很多 Java 写的 MES 习惯用 camelCase（orderNo）。这个问题不约定，联调时就是一顿改。解决办法是统一以接口文档为准，C# 里用JsonProperty("orderNo")或者序列化时指定CamelCasePropertyNamesContractResolver。

数据字典至少要覆盖这几类字段：

时间戳这个字段特别容易打架。C# 的DateTime序列化出来默认带毫秒，MES 那边如果只认到秒，你就得在序列化设置里加DateFormatString。反正，数据字典里把每个字段的类型、长度、是否必填都写清，联调能省一半时间。

3. 用 C# 把数据送进 MES：从 HttpClient 封装到断线重试

3.1 封装一个带超时和重试的 HttpHelper

MES 接口不像本地函数调用，网络抖动、服务器重启、连接池耗尽都可能导致调用失败。所以 C# 这边的 HTTP 客户端不能每次new HttpClient()了事，要封装成带超时和重试的稳定客户端。

public class MesApiClient { private readonly HttpClient _http; private readonly string _baseUrl; public MesApiClient(string baseUrl, string token) { _baseUrl = baseUrl; _http = new HttpClient(); _http.Timeout = TimeSpan.FromSeconds(15); _http.DefaultRequestHeaders.Add("Authorization", $"Bearer {token}"); _http.DefaultRequestHeaders.Accept.Add( new MediaTypeWithQualityHeaderValue("application/json")); } public async Task<string> PostJsonAsync(string path, string json, int retry = 3) { var content = new StringContent(json, Encoding.UTF8, "application/json"); Exception lastException = null; for (int i = 0; i < retry; i++) { try { var resp = await _http.PostAsync(_baseUrl + path, content); var body = await resp.Content.ReadAsStringAsync(); if (!resp.IsSuccessStatusCode) { throw new HttpRequestException( $"HTTP {(int)resp.StatusCode}, body={body}"); } return body; } catch (Exception ex) { lastException = ex; Console.WriteLine($"[MES] 第 {i + 1} 次上报失败: {ex.Message}"); await Task.Delay(1000 * (i + 1)); } } throw lastException; } }

这段封装有三个关键点。第一，HttpClient在类里只创建一次，复用它而不是每次 new，避免端口耗尽。第二，超时设置在 15 秒，MES 接口一般 2 秒内能返回，超过 15 秒直接断开，不无限等。第三，重试采用递增延时，第一次失败等 1 秒，第二次等 2 秒，给服务端恢复的时间。

重试次数别设太多，我一般设 3 次。重试太频繁，MES 刚重启还没起来，你这边已经打了几十次，搞得网关拉黑你。另外注意StringContent必须指定Encoding.UTF8，不然中文大概率乱码。

3.2 序列化：把 DataTable 变成 MES 认识的 JSON

上位机里数据常常存在DataTable里，直接从DataGridView或者 PLC 采集结果拿出来就是一行。但DataTable直接序列化成 JSON，字段名、类型都不好控制。我一般会先转成Dictionary再序列化。

public static string BuildReportPayload( DataRow row, string orderNo, string deviceCode) { var dataFields = row.Table.Columns .Cast<DataColumn>() .ToDictionary( c => c.ColumnName, c => row[c.ColumnName] == DBNull.Value ? null : row[c.ColumnName] ); var payload = new Dictionary<string, object> { ["orderNo"] = orderNo, ["deviceCode"] = deviceCode, ["eventTime"] = DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss.fff"), ["data"] = dataFields }; return JsonConvert.SerializeObject(payload, new JsonSerializerSettings { NullValueHandling = NullValueHandling.Ignore, DateFormatString = "yyyy-MM-dd HH:mm:ss" }); }

这里绕开了DataTable直接序列化，因为DataTable序列化会产生TableName、Rows这类多余结构，MES 方很难解析。转成Dictionary后，字段名就是键名，干净可控。

两个细节容易踩。一个是DBNull.Value要先转成null，否则序列化后可能变成奇怪的类型或者直接报错。另一个是时间格式，eventTime我故意用字符串而不是DateTime，避免序列化时带出T和时区偏移量，MES 那边如果用的是LocalDateTime或VARCHAR存时间，字符串最不容易出错。

生产环境里发现设备编码有带前导零的，比如“0012”。如果 DataColumn 是 int 类型早就丢了，建议在数据字典阶段就把设备编码定义为字符串字段，避免这种坑。

3.3 上报策略：定时轮询加事件触发

对接 MES 不光是“有数据就发”这么简单。PLC 采集频率可能 200 毫秒一次，MES 接口不可能接受这么高频的调用。所以要分层：PLC 高频采集，数据先进缓存，上位机按自己的节奏上报。

我用的是“定时轮询 + 事件触发”双轨制。定时轮询用来兜底，保证数据不会因为一个事件漏发；事件触发用来保实时性，比如关机、报警这种关键状态变化必须立刻上报。

private readonly Channel<Dictionary<string, object>> _uploadQueue = Channel.CreateUnbounded<Dictionary<string, object>>(); private void InitReportTimer() { var timer = new System.Timers.Timer(5000); timer.Elapsed += async (_, _) => { if (_uploadQueue.Reader.Count == 0) return; var batch = new List<Dictionary<string, object>>(); while (_uploadQueue.Reader.TryRead(out var item)) { batch.Add(item); if (batch.Count >= 100) break; } var json = JsonConvert.SerializeObject(batch); await _mesClient.PostJsonAsync("/api/mes/upload", json); }; timer.Start(); }

定时器设置 5 秒一次，每次最多取 100 条批量上报。这里用Channel<T>做内存队列，PLC 采集线程往队列里写，上报线程从队列里读，两个线程互不阻塞。

事件触发部分，比如 PLC 报警信号上升沿，直接往队列里塞一条高优先级数据，然后立刻触发一次上报，而不是等下一个定时周期。做法是在报警事件里调用_uploadQueue.Writer.TryWrite(item)，然后手动调一次上报方法。

必须明确的一点：Channel只是内存队列，程序崩溃就丢。所以生产环境里我在上报成功后会落一份记录到本地 SQLite，或者至少写日志文件。断开重连后拿本地记录跟 MES 对账，缺什么补什么。这个习惯救过我好几次。

4. MES 对接避坑指南：六个常见翻车现场和排查顺序

4.1 现象：报文结构对不上，接口返回 500

联调第一天最容易遇到的：用 Postman 调 MES 接口是通的，换成 C# 程序调就报 500，返回体提示字段缺失或类型错误。

原因不是代码问题，是报文结构不一致。比如接口要求data是数组，你发的是对象；或者要求qty是数字类型，你序列化出来是字符串。

解决：先把 C# 里JsonConvert.SerializeObject的输出打印出来，跟接口文档逐个字段比对。我一般在开发环境写一个调试开关，把请求报文完整记录到日志文件里，比对一次基本能定位。别凭肉眼猜，报文打印出来看。

4.2 现象：数据偶发丢失，服务端查不到记录

有段时间某工厂跟我说每天产量少了十几条，不多，但月底对不上账。看了代码，上报逻辑是：内存队列取出，发 HTTP，收到成功就删。问题就出在“收到成功就删”这个动作上。

原因是网络返回成功不代表 MES 落库成功。MES 接口返回 200 且code=0，数据才真正进库。但更隐蔽的是，如果 C# 进程在发送后、拿到响应前崩溃，这条数据就永远没了。

解决：上报不能只走内存，成功的数据也要落盘。我后来改成“先写本地待确认表，MES 返回成功后再标记”，定期扫描待确认表，超过 5 分钟没确认的就补发。这一套下来，月底对账再也没缺过。

4.3 现象：时间戳差 8 小时，排产全乱

有一次 MES 侧看到的上报时间是凌晨 2 点，实际是上午 10 点发生的。整个排产计划全乱了。

原因是 C# 序列化DateTime默认带Kind，如果 PLC 工控机时区设置不对，或者DateTime.UtcNow跟本地时间混用，序列化后就带着时区偏移，MES 反序列化成 UTC 再转本地就差了 8 小时。

解决：统一时间格式，不要传DateTime对象，直接传字符串。我在BuildReportPayload里已经用DateTime.Now.ToString("yyyy-MM-dd HH:mm:ss.fff")，这样两端都不用考虑时区转换。如果 MES 那边说必须传标准时间，那就明确约定用 ISO8601 带时区，两边按同一个标准来，谁也不能含糊。

4.4 现象：中文变问号，批次号错乱

工单号里带中文，上报到 MES 全变成???，或者中文字段被截断。

原因基本是两个：一是StringContent没指定Encoding.UTF8，默认可能是text/plain或 ISO-8859-1；二是 MES 侧数据库连接串没设置字符集，Java 那边常用的 MySQL 连接串少了characterEncoding=utf8。

解决：C# 这边确保每一个StringContent都显式传Encoding.UTF8，并且设置ContentType为application/json; charset=utf-8。MES 侧的问题只能在联调时提醒对方检查连接串。这种事不是你代码能救的，但要能判断出是哪边的锅，别自己瞎调半天。

4.5 现象：接口超时，连带 PLC 采集被拖垮

MES 服务偶发变慢，一个接口 5 秒才返回。结果 C# 上位机里所有上报调用都在等，线程池被占满，PLC 采集线程也等锁，最后整个程序卡死，连操作界面都点不动。

原因是把 HTTP 调用和 PLC 采集放在了同一个业务链路里，采集线程同步等待上报。解决从两个方向做：一是给HttpClient设置硬超时，15 秒必须断，不能无限等；二是采集和上报彻底分离，PLC 采集线程只负责把数据写进队列，上报线程去处理 HTTP，两边完全不互相阻塞。

代码结构上，我一般开一个单独的Task跑上报消费者，PLC 采集永远不等它。这样 MES 再慢，最多是队列积压，不会把产线采集拖死。

4.6 排查顺序：日志、报文、网络

MES 对接出问题，最忌讳上来就猜。我现在的固定顺序是：先看日志，再看报文，最后查网络。

日志看的是请求和响应，C# 那边记录每一条 HTTP 请求的时间、路径、状态码、响应体。报文看的是字段值，比对数据字典，确认是不是序列化问题。网络查的是延迟和丢包，ping 和tcping走一遍，确认是偶发还是持续。

这套顺序帮我挡掉了至少 80% 的冤枉路。很多问题根本不是代码写的错，是报文里某个字段的值不符合 MES 的枚举定义，比如状态传了“完成”，MES 只认“FINISHED”。这种问题不看报文根本看不出来。

5. 进阶：给 C# 上位机加一层本地缓存，把断网补发写进代码习惯

跟 MES 对接做到稳定之后，我做的第一件事是给整个链路加一层本地缓存。这一层看着不多，但把最磨人的“网络抖动丢数据”问题彻底解决了。

我用的方案是两级队列：内存队列Channel<T>保证高吞吐，本地 SQLite 表pending_upload保证持久化。PLC 采集线程把数据写进Channel，上报线程从Channel读出来后，先写pending_upload表，再发 HTTP。MES 返回成功后删掉本地记录。删不掉也没关系，下次启动扫描全表补发。

public async Task UploadWithPersistAsync(Dictionary<string, object> payload) { // 先落本地库，保证进程崩溃也不丢 await _localDb.InsertAsync("pending_upload", payload); var json = JsonConvert.SerializeObject(payload); var resp = await _mesClient.PostJsonAsync("/api/mes/upload", json); var result = JsonConvert.DeserializeObject<MesResponse>(resp); if (result.code == 0) { await _localDb.DeleteAsync("pending_upload", payload["id"]); } }

这个模式看起来简单，实际价值很大。第一，MES 系统半夜重启、早上恢复，数据一条不丢，全在本地等着补发。第二，产线网络抖动 10 分钟，队列积压到几万条，MES 恢复后批量补发，也不会压垮它，因为补发有 5 秒定时器控制节奏。第三，对账变得很简单：本地pending_upload表里还有记录，就是还没进 MES 的，清空即对齐。

从那以后，我每次做 MES 对接都强制自己走一遍这个流程：方案先选 Web API，字段先定数据字典，上报先落本地缓存，问题先查报文。这套习惯帮我绕开了不少坑，也希望帮到你。

本文还有配套的精品资源，点击获取