# ATS 批量排产报工接口文档

## 版本信息
- 版本号：v2.0.0
- 创建日期：2026-02-24
- 当前局域网测试地址：
- **前端地址**：http://192.168.1.244:80
- **后端地址**：http://192.168.1.244:8080

## 接口说明

### 1. 批量自动完成接口（异步模式）

#### 1.1 基本信息
- **接口名称**：批量自动完成销售订单（异步提交）
- **接口路径**：`后端地址/production/autoComplete/batchAutoComplete`
- **请求方法**：POST
- **Content-Type**：application/json;charset=UTF-8
- **认证方式**：无需认证（已配置匿名访问）
- **执行模式**：异步执行，立即返回任务ID

#### 1.2 请求参数

##### 请求体（JSON）

```json
{
  "orderNumbers": ["SO202602240001", "SO202602240002"],//订单编号列表，必填
  "routeId": 1001,//工序路线id，可选
  "productionStartTime": "2026-02-24 08:00:00"//生产计划开始时间，可选
}
```

##### 参数说明

| 参数名 | 类型 | 必填 | 说明 |
|--------|------|------|------|
| orderNumbers | Array<String> | 是 | 销售订单编号列表，不能为空 |
| routeId | Long | 否 | 工序路线ID，如不指定则使用物料默认路线 |
| productionStartTime | String | 否 | 生产开始时间，格式：yyyy-MM-dd HH:mm:ss |

##### 参数约束
- `orderNumbers`：必填，至少包含一个有效订单编号
- 订单编号会自动过滤空字符串和null值
- `routeId`：可选，不指定时系统会根据物料配置自动选择路线
- `productionStartTime`：可选，指第一条工单的计划开始时间，不指定时系统会生成模拟时间(生产订单日期作为日期，早8:00-9:00随机时间，后续工单按照系统逻辑读取工序持续时间生成)

#### 1.3 响应结果（立即返回）

##### 成功响应示例

```json
{
  "code": 200,
  "msg": "任务已提交，正在后台处理",
  "data": {
    "taskId": "TASK_20260224_001",
    "totalCount": 50,
    "estimatedSeconds": 50,
    "status": "PENDING",
    "message": "任务已创建，预计需要50秒完成"
  }
}
```

##### 响应字段说明

| 字段名 | 类型 | 说明 |
|--------|------|------|
| code | Integer | 响应状态码，200表示成功 |
| msg | String | 响应消息 |
| data.taskId | String | 任务ID，用于后续查询任务状态 |
| data.totalCount | Integer | 总订单数 |
| data.estimatedSeconds | Integer | 预计耗时（秒） |
| data.status | String | 任务状态：PENDING-待处理 |
| data.message | String | 提示信息 |

---

### 2. 任务状态查询接口

#### 2.1 基本信息
- **接口名称**：查询批量任务状态
- **接口路径**：`后端地址/production/autoComplete/taskStatus/{taskId}`
- **请求方法**：GET
- **认证方式**：无需认证（已配置匿名访问）

#### 2.2 请求参数

##### 路径参数

| 参数名 | 类型 | 必填 | 说明 |
|--------|------|------|------|
| taskId | String | 是 | 任务ID，由提交接口返回 |

##### 请求示例

```
GET /production/autoComplete/taskStatus/TASK_20260224_001
```

#### 2.3 响应结果

##### 处理中响应示例

```json
{
  "code": 200,
  "msg": "查询成功",
  "data": {
    "taskId": "TASK_20260224_001",
    "status": "PROCESSING",
    "totalCount": 50,
    "processedCount": 25,
    "successCount": 23,
    "failedCount": 2,
    "completedCount": 0,
    "percentage": 50,
    "startTime": "2026-02-24 10:00:00",
    "estimatedSeconds": 50,
    "elapsedSeconds": 25,
    "message": "正在处理中，已完成50%"
  }
}
```

##### 已完成响应示例

```json
{
  "code": 200,
  "msg": "查询成功",
  "data": {
    "taskId": "TASK_20260224_001",
    "status": "COMPLETED",
    "totalCount": 50,
    "processedCount": 50,
    "successCount": 48,
    "failedCount": 2,
    "completedCount": 0,
    "percentage": 100,
    "startTime": "2026-02-24 10:00:00",
    "endTime": "2026-02-24 10:00:52",
    "estimatedSeconds": 50,
    "elapsedSeconds": 52,
    "message": "任务已完成",
    "result": {
      "successOrders": ["SO001", "SO002", "..."],
      "failedOrders": ["SO025", "SO038"],
      "completedOrders": [],
      "failureReasons": {
        "SO025": "订单不存在",
        "SO038": "物料未配置工序路线"
      }
    }
  }
}
```

##### 响应字段说明

| 字段名 | 类型 | 说明 |
|--------|------|------|
| code | Integer | 响应状态码，200表示成功 |
| msg | String | 响应消息 |
| data.taskId | String | 任务ID |
| data.status | String | 任务状态：PENDING-待处理/PROCESSING-处理中/COMPLETED-已完成/FAILED-失败 |
| data.totalCount | Integer | 总订单数 |
| data.processedCount | Integer | 已处理数量 |
| data.successCount | Integer | 成功数量 |
| data.failedCount | Integer | 失败数量 |
| data.completedCount | Integer | 已完成（跳过）数量 |
| data.percentage | Integer | 完成百分比（0-100） |
| data.startTime | String | 开始时间 |
| data.endTime | String | 结束时间（仅完成时有值） |
| data.estimatedSeconds | Integer | 预计耗时（秒） |
| data.elapsedSeconds | Integer | 已耗时（秒） |
| data.message | String | 状态描述信息 |
| data.result | Object | 详细结果（仅完成时有值） |
| data.result.successOrders | Array<String> | 成功处理的订单编号列表 |
| data.result.failedOrders | Array<String> | 处理失败的订单编号列表 |
| data.result.completedOrders | Array<String> | 已完成（跳过）的订单编号列表 |
| data.result.failureReasons | Map<String, String> | 失败原因映射 |


#### 2.4 错误响应

##### 任务不存在

```json
{
  "code": 500,
  "msg": "任务不存在"
}
```

---

## 业务流程

### 3.1 异步处理流程

```
客户端                    服务端                     数据库
  |                        |                          |
  |--1.提交批量请求------->|                          |
  |                        |--2.创建任务记录--------->|
  |                        |                          |
  |<--3.返回任务ID---------|                          |
  |                        |                          |
  |                        |--4.异步执行任务--------->|
  |                        |   (后台线程池)           |
  |                        |                          |
  |--5.查询任务状态------->|                          |
  |                        |--6.查询任务记录--------->|
  |<--7.返回当前进度-------|<--返回任务数据-----------|
  |                        |                          |
  |--8.再次查询状态------->|                          |
  |                        |--9.查询任务记录--------->|
  |<--10.返回完成结果------|<--返回完成数据-----------|
```

### 3.2 详细处理步骤

#### 步骤1：提交任务（同步，<1秒）

1. **参数验证**
   - 验证订单编号列表不为空
   - 过滤无效的订单编号（null或空字符串）

2. **创建任务记录**
   - 生成唯一任务ID（格式：TASK_yyyyMMdd_HHmmss_随机数）
   - 计算预计耗时（订单数 × 1秒）
   - 初始化任务状态为 PENDING
   - 写入数据库

3. **立即返回**
   - 返回任务ID、总订单数、预计耗时
   - 客户端收到响应，可以开始轮询查询状态

#### 步骤2：异步执行（后台线程池）

1. **更新任务状态为 PROCESSING**
   - 记录开始时间
   - 写入数据库

2. **循环处理订单**
   - 验证订单是否存在
   - 检查订单状态（已完成的订单会跳过）
   - 根据订单类型（连续制造/离散制造）执行不同流程
   - 生成工单、报工单
   - 更新工单状态

3. **批量更新进度（每5个订单）**
   - 更新 processedCount、successCount、failedCount
   - 写入数据库
   - 减少数据库写入频率，提升性能

4. **任务完成**
   - 更新任务状态为 COMPLETED 或 FAILED
   - 记录结束时间
   - 保存完整结果数据（JSON格式）
   - 写入数据库

#### 步骤3：查询任务状态（同步，<100ms）

1. **根据任务ID查询数据库**
2. **计算实时数据**
   - 完成百分比 = (processedCount / totalCount) × 100
   - 已耗时 = 当前时间 - 开始时间
3. **返回任务状态和进度**

### 3.3 数据库更新策略

为了平衡性能和实时性，采用**批量更新策略**：

| 更新时机 | 说明 | 频率 |
|---------|------|------|
| 任务创建 | 初始化任务记录 | 1次 |
| 任务开始 | 更新状态为PROCESSING | 1次 |
| 处理过程 | 每处理5个订单更新一次进度 | N/5次 |
| 任务完成 | 更新状态为COMPLETED，保存完整结果 | 1次 |
| 任务失败 | 更新状态为FAILED，保存错误信息 | 1次 |

**示例**：处理50个订单
- 总更新次数：1（创建）+ 1（开始）+ 10（进度）+ 1（完成）= 13次
- 相比实时更新（53次），减少了75%的数据库写入

### 3.4 订单处理流程

#### 连续制造流程
1. 为每个订单明细生成工单
2. 生成默认工序配置
3. 批量生成报工单
4. 更新工单状态为"已完成"

#### 离散制造流程
1. 为每个订单明细生成工单
2. 生成默认工序配置
3. 批量生成报工单
4. 更新工单状态为"已完成"

### 3.5 订单状态说明

| 状态 | 说明 | 处理方式 |
|------|------|----------|
| 待生产 | 订单未开始生产 | 正常处理 |
| 生产中 | 订单正在生产 | 正常处理 |
| 已完成 | 订单已完成 | 跳过处理，计入completedCount |
| 已删除 | 订单已删除 | 返回错误 |

### 3.6 工序路线选择逻辑

1. 如果请求中指定了`routeId`，优先使用指定的路线
2. 如果订单明细中配置了路线，使用明细配置的路线
3. 如果物料配置了默认路线，使用物料默认路线
4. 如果以上都没有，返回错误

## 性能说明

### 4.1 执行时长估算

| 订单数 | 预计耗时 | 数据库更新次数 |
|--------|---------|--------------|
| 5个    | ~5秒    | 4次          |
| 10个   | ~10秒   | 5次          |
| 50个   | ~50秒   | 13次         |
| 100个  | ~100秒  | 23次         |

**说明**：
- 单个订单平均处理时间：1秒（包含生成工单、报工单、更新状态）
- 实际耗时可能因服务器性能、数据库负载而有所差异

### 4.2 并发限制

- **线程池大小**：10个线程
- **最大并发任务数**：10个
- **任务队列长度**：100个
- **超过限制时**：新任务会进入队列等待

### 4.3 超时设置

- **单个任务最大执行时间**：5分钟（300秒）
- **超时后**：任务状态标记为FAILED
- **建议**：单次批量不超过100个订单

---

## 注意事项

### 5.1 性能考虑

- 建议单次批量处理的订单数量不超过100个
- 大批量处理建议分批调用
- 查询状态的轮询间隔建议3-5秒

### 5.2 事务处理

- 每个订单的处理是独立的事务
- 单个订单失败不会影响其他订单的处理
- 任务记录的更新是独立事务

### 5.3 幂等性

- 已完成的订单会被跳过，不会重复处理
- 可以安全地重复调用接口
- 相同订单号不会重复生成工单

### 5.4 匿名访问

- 该接口已配置为允许匿名访问
- 系统会自动使用"system"用户进行数据创建和更新
- 无需传递token或其他认证信息

### 5.5 日志记录

- 所有操作都会记录详细日志
- 建议在生产环境中监控日志以便排查问题
- 任务失败时会记录详细的错误信息

### 5.6 日志记录

- 所有操作都会记录详细日志
- 建议在生产环境中监控日志以便排查问题
- 任务失败时会记录详细的错误信息

---


---

## 为什么必须使用异步模式？

### 同步方式的严重问题

如果不使用异步批量处理方法，而是用同步方式处理大批量订单，会带来以下严重问题：

### 1. HTTP超时问题 ⚠️ 严重

**问题描述**：
- 假设处理50个订单需要50秒
- 大多数HTTP客户端默认超时时间：30-60秒
- Nginx/负载均衡器默认超时：60秒
- 浏览器默认超时：通常2分钟

**后果**：
```
客户端发送请求 → 服务器开始处理50个订单
↓
30秒后...客户端超时断开连接
↓
服务器还在继续处理（已经处理了30个）
↓
客户端收到：504 Gateway Timeout 或 Connection Reset
↓
客户端不知道：订单到底处理了多少？成功了多少？
```

**实际影响**：
- ❌ 客户端认为请求失败，但服务器可能已经处理了部分订单
- ❌ 无法知道哪些订单成功，哪些失败
- ❌ 可能重复提交，导致数据重复
- ❌ 用户体验极差，不知道发生了什么

### 2. 数据库连接占用 ⚠️ 严重

**问题描述**：
- 同步处理会长时间占用数据库连接
- 处理50个订单可能需要50秒
- 这期间数据库连接一直被占用

**后果**：
```
数据库连接池大小：20个连接
↓
10个客户端同时提交批量请求（每个50个订单）
↓
10个连接被占用50秒
↓
其他正常业务请求无法获取连接
↓
整个系统卡死！
```

**实际影响**：
- ❌ 数据库连接池耗尽
- ❌ 其他业务功能无法使用
- ❌ 系统整体性能下降
- ❌ 可能导致系统崩溃

### 3. 线程阻塞问题 ⚠️ 严重

**问题描述**：
- Tomcat默认最大线程数：200
- 每个同步请求占用一个线程直到完成

**后果**：
```
Tomcat线程池：200个线程
↓
20个客户端同时提交批量请求（每个处理50秒）
↓
20个线程被阻塞50秒
↓
如果有100个这样的请求...
↓
所有线程被占满，新请求无法处理
↓
系统完全无响应！
```

**实际影响**：
- ❌ 线程池耗尽
- ❌ 新请求被拒绝（503 Service Unavailable）
- ❌ 系统无法处理任何请求
- ❌ 需要重启服务器才能恢复

### 4. 用户体验问题 ⚠️ 中等

**问题描述**：
- 用户点击提交后，页面一直转圈
- 50秒内无法做任何操作
- 不知道进度，不知道还要等多久

**后果**：
```
用户点击提交
↓
页面loading...
↓
10秒...20秒...30秒...
↓
用户：是不是卡死了？要不要刷新？
↓
用户刷新页面或关闭浏览器
↓
但服务器还在处理...
↓
数据可能处理了一半，状态不一致
```

**实际影响**：
- ❌ 用户体验极差
- ❌ 用户不知道进度
- ❌ 容易误操作（刷新、重复提交）
- ❌ 客户投诉增加

### 5. 事务管理问题 ⚠️ 中等

**问题描述**：
- 如果50个订单在一个事务中
- 第49个订单失败，前48个都要回滚

**后果**：
```
开始事务
↓
处理订单1...成功
处理订单2...成功
...
处理订单48...成功
处理订单49...失败！
↓
整个事务回滚
↓
前48个订单的工作全部白做
↓
浪费了48秒的处理时间
```

**实际影响**：
- ❌ 一个订单失败，全部失败
- ❌ 无法部分成功
- ❌ 处理效率低下
- ❌ 资源浪费

### 6. 无法监控和追踪 ⚠️ 中等

**问题描述**：
- 同步处理无法查询进度
- 不知道处理到第几个订单
- 出错后无法定位问题

**后果**：
```
提交50个订单
↓
处理中...（黑盒）
↓
30秒后超时
↓
问题：
- 处理了多少个？不知道
- 哪些成功了？不知道
- 哪些失败了？不知道
- 为什么失败？不知道
```

**实际影响**：
- ❌ 无法追踪进度
- ❌ 问题难以排查
- ❌ 无法提供客户支持
- ❌ 数据状态不明确

### 7. 系统稳定性问题 ⚠️ 严重

**问题描述**：
- 大批量同步请求会导致系统资源耗尽
- 可能引发雪崩效应

**后果**：
```
高峰期：100个客户端同时提交批量请求
↓
线程池满 + 数据库连接池满
↓
系统响应变慢
↓
客户端超时重试
↓
更多请求涌入
↓
系统完全崩溃
↓
需要紧急重启
```

**实际影响**：
- ❌ 系统不稳定
- ❌ 容易崩溃
- ❌ 影响所有用户
- ❌ 需要人工干预

### 8. 扩展性问题 ⚠️ 中等

**问题描述**：
- 同步方式无法应对业务增长
- 订单量增加时系统无法承受

**后果**：
```
现在：每次处理50个订单
↓
业务增长：每次需要处理200个订单
↓
处理时间：200秒（3分20秒）
↓
必然超时，系统无法使用
↓
需要重新设计架构
```

**实际影响**：
- ❌ 无法应对业务增长
- ❌ 需要重构代码
- ❌ 技术债务增加
- ❌ 开发成本增加

---

## 同步 vs 异步对比

### 性能对比表

| 问题 | 同步方式 | 异步方式 |
|------|---------|---------|
| HTTP超时 | ❌ 必然超时（>30秒） | ✅ 立即返回（<1秒） |
| 数据库连接 | ❌ 长时间占用（50秒） | ✅ 短时间占用（<1秒） |
| 线程阻塞 | ❌ 长时间阻塞（50秒） | ✅ 立即释放（<1秒） |
| 用户体验 | ❌ 长时间等待，无反馈 | ✅ 立即响应，可查询进度 |
| 事务管理 | ❌ 全部回滚，一个失败全失败 | ✅ 独立事务，部分成功 |
| 进度追踪 | ❌ 无法追踪，黑盒处理 | ✅ 实时查询进度和结果 |
| 系统稳定性 | ❌ 容易崩溃，资源耗尽 | ✅ 稳定可靠，资源可控 |
| 扩展性 | ❌ 无法扩展，订单量增加即崩溃 | ✅ 易于扩展，支持大批量 |
| 错误处理 | ❌ 难以定位，状态不明 | ✅ 详细错误信息和原因 |
| 并发能力 | ❌ 极差，10个请求即可拖垮系统 | ✅ 优秀，支持高并发 |

### 实际场景对比

**场景**: 10个客户端同时提交50个订单

#### 同步方式：
```
每个请求耗时：50秒
占用线程：10个（持续50秒）
占用数据库连接：10个（持续50秒）
用户等待时间：50秒
超时风险：100%
系统可用性：严重下降
其他业务影响：严重（连接池和线程池被占用）
```

#### 异步方式：
```
每个请求耗时：<1秒（立即返回）
占用线程：10个（持续<1秒）
占用数据库连接：10个（持续<1秒）
用户等待时间：<1秒（可查询进度）
超时风险：0%
系统可用性：正常
其他业务影响：无（资源立即释放）
```

### 资源占用对比图

```
同步方式资源占用：
时间轴：0s -------- 10s -------- 20s -------- 30s -------- 40s -------- 50s
线程：  ████████████████████████████████████████████████████████ (持续占用)
连接：  ████████████████████████████████████████████████████████ (持续占用)
用户：  ⏳等待中...................................................

异步方式资源占用：
时间轴：0s - 1s
线程：  █ (立即释放)
连接：  █ (立即释放)
用户：  ✅已收到任务ID，可查询进度

后台处理：
时间轴：0s -------- 10s -------- 20s -------- 30s -------- 40s -------- 50s
线程：  ████████████████████████████████████████████████████████ (后台线程池)
连接：  █ █ █ █ █ █ █ █ █ █ (批量更新，间歇占用)
用户：  ✅可随时查询进度：20%...40%...60%...80%...100%
```

---

## 异步模式的核心优势

### 1. 立即响应
- ✅ 接口在1秒内返回任务ID
- ✅ 用户无需等待
- ✅ 不会超时

### 2. 进度可追踪
- ✅ 实时查询处理进度（百分比）
- ✅ 查看成功/失败数量
- ✅ 获取详细错误信息

### 3. 资源高效利用
- ✅ HTTP线程立即释放
- ✅ 数据库连接短时间占用
- ✅ 后台线程池统一管理

### 4. 部分成功机制
- ✅ 单个订单失败不影响其他订单
- ✅ 独立事务，可部分成功
- ✅ 详细记录每个订单的处理结果

### 5. 系统稳定性
- ✅ 不会因大批量请求导致系统崩溃
- ✅ 线程池和连接池可控
- ✅ 支持高并发场景

### 6. 易于扩展
- ✅ 订单量增加不影响系统稳定性
- ✅ 可通过调整线程池大小扩展
- ✅ 支持未来业务增长

---

## 结论

**强烈建议使用异步模式！**

异步批量处理是处理大批量、长时间任务的行业标准做法。不使用异步方式会导致：

1. ❌ **系统不可用** - HTTP超时、线程阻塞、连接池耗尽
2. ❌ **用户体验差** - 长时间等待、无进度反馈
3. ❌ **数据不一致** - 超时后状态不明确
4. ❌ **无法扩展** - 业务增长后系统崩溃
5. ❌ **运维困难** - 问题难以排查和监控

使用异步模式后：

1. ✅ **系统稳定** - 资源可控，不会崩溃
2. ✅ **用户体验好** - 立即响应，实时进度
3. ✅ **数据一致** - 详细记录，状态明确
4. ✅ **易于扩展** - 支持大批量和高并发
5. ✅ **运维友好** - 完整日志，易于监控