### 旺店通·企业奇门数据集成到用友BIP：销售出库单对接销售订单(线下)-p案例分享
在本技术案例中，我们探讨如何实现旺店通·企业奇门的数据高效、安全地集成到用友BIP系统，以确保业务流畅运行。具体而言，本方案配置和执行了销售出库单与销售订单的对接，旨在解决可能出现的漏单、大量数据快速写入、定时可靠抓取等技术挑战。
#### 数据获取及处理流程
首先，通过调用旺店通·企业奇门接口`wdt.stockout.order.query.trade`来定时抓取所有未同步的销售出库单数据。这一步至关重要，因为需要有效处理分页和限流问题，以确保不会遗漏任何订单。在配置过程中，我们设定了合理的数据拉取频率，并使用轻易云平台提供的实时监控功能，全程跟踪每次API调用情况，从而及时应对异常。
```json
{
"api_name": "wdt.stockout.order.query.trade",
"start_time": "2022-01-01T00:00:00",
...
}
```
上述JSON示例展示了标准API调用格式，每个字段均已考虑分页参数和时间范围限制。此外，为了解决接口数据返回速度与服务器性能之间的矛盾，采用多线程分段拉取机制，大幅提升效率。
#### 数据格式转换与映射
由于两大系统间存在显著的数据格式差异，在进入用友BIP之前，需先进行严谨的数据清洗和转换工作。例如，将原始JSON对象中的具体商品信息转化为符合用友BIP `singleSave` API需求的新结构：
```json
{
"data": {
...
"items": [
{
...
}
]
}
}
```
通过逻辑函数划分字段并应用批量映射策略，不仅提高了操作简便性，还保障了数据的一致性和完整性。这些步骤在轻易云平台上实现较为直观，通过其可视化界面可以直接定义复杂映射规则，以及表格式操作减少人为错误。
#### 错误重试机制及日志记录
为了进一步保障整个集成过程无障碍运行，设计了一套详尽的错误处理与重试机制。一旦检测到服务异常或网络波动导致请求失败后，会自动触发重试，同时将详细日志记录存储供后续分析排查。
```json
{
"error_code": "500",
"retry_count": 3,
...
}
```
该机制不仅涵盖常规HTTP错误代码，还附带自定义业务逻辑层面的校验，如库存不足、重复订单等特殊情况。此外，这些
### 调用源系统旺店通·企业奇门接口wdt.stockout.order.query.trade获取并加工数据
在数据集成生命周期的第一步中，调用源系统接口获取数据是至关重要的一环。本文将详细探讨如何使用轻易云数据集成平台配置元数据，调用旺店通·企业奇门接口`wdt.stockout.order.query.trade`来获取销售出库单，并对数据进行初步加工。
#### 接口调用配置
首先，我们需要配置API调用的基本参数。根据提供的元数据配置，我们将使用POST方法来请求`wdt.stockout.order.query.trade`接口。以下是具体的请求参数配置：
```json
{
"api": "wdt.stockout.order.query.trade",
"method": "POST",
"request": [
{"field": "start_time", "label": "开始时间", "type": "datetime", "describe": "增量获取数据，start_time作为开始时间，格式：yyyy-MM-dd HH:mm:ss", "value": "{{LAST_SYNC_TIME|datetime}}"},
{"field": "end_time", "label": "结束时间", "type": "datetime", "describe": "增量获取数据，end_time作为结束时间，格式：yyyy-MM-dd HH:mm:ss", "value": "{{CURRENT_TIME|datetime}}"},
{"field": "status", "label": "状态", "type": "string"},
{"field": "src_order_no", "label": "系统订单编号", "type": "string"},
{"field": "src_tid", "label": "原始单号", "type": "string"},
{"field": "stockout_no", "label": "出库单号",
### 用友BIP API接口数据集成技术案例
在数据集成的生命周期中，第二步是将已经集成的源平台数据进行ETL转换，并转为目标平台用友BIP API接口所能够接收的格式，最终写入目标平台。本文将详细探讨如何利用轻易云数据集成平台完成这一过程。
#### 数据请求与清洗
首先，我们需要从源系统获取销售出库单的数据，并进行必要的清洗和转换，以便后续的ETL处理。这一步通常涉及到数据的提取、去重、标准化等操作。
#### 数据转换与写入
接下来，我们进入数据转换与写入阶段。以下是具体的元数据配置及其应用：
```json
{
"api": "/yonbip/sd/voucherorder/singleSave",
"method": "POST",
"BIPAudit": "/yonbip/sd/voucherorder/batchaudit",
"idCheck": true,
"request": [
{
"field": "resubmitCheckKey",
"label": "保证请求的幂等性",
"type": "string",
"describe": "保证请求的幂等性,该值由客户端生成,并且必须是全局唯一的，长度不能超过32位。",
"value": "{src_order_no}-2"
},
{
"field": "salesOrgId",
"label": "销售组织",
"type": "string",
"describe": "销售组织，传id或者code",
"value": "_findCollection find mapping_sale_org from 4769a428-14c4-33b8-91fd-e8da3b39d5cb where shop_no={shop_no}"
},
{
"field": "transactionTypeId",
"label": "交易类型",
"type": "string",
"describe": "交易类型，传id或者code",
"value": "SO021"
},
{
"field": "bizFlow",
"label": "",
...
}
]
}
```
##### 幂等性保障
为了确保请求的幂等性，我们使用了`resubmitCheckKey`字段，该字段由客户端生成并且必须全局唯一。例如：
```json
{
...
{
"field": "resubmitCheckKey",
...
"value": "{src_order_no}-2"
}
}
```
##### 销售组织映射
销售组织字段需要从源系统映射到目标系统，这里使用了`_findCollection`函数来实现：
```json
{
...
{
"field": "salesOrgId",
...
"value":"_findCollection find mapping_sale_org from 4769a428-14c4-33b8-91fd-e8da3b39d5cb where shop_no={shop_no}"
}
}
```
##### 数据格式转换
日期格式也是一个重要部分，需要将源系统中的日期格式转换为目标系统所需格式：
```json
{
...
{
“field”: “vouchdate”,
“label”: “单据日期”,
“type”: “string”,
“describe”: “单据日期,格式为:yyyy-MM-dd HH:mm:ss”,
“value”: “{consign_time_new}”
}
}
```
##### 子表处理
对于复杂的数据结构，如子表（销售订单子表），我们需要逐一处理每个字段，并进行必要的计算和转换。例如：
```json
{
...
{
“field”: “orderDetails”,
“label”: “销售订单子表”,
“type”: “array”,
...
“children”: [
{
...
{
“field”: “stockId”,
“label”: “仓库”,
...
“value”: "{{details_list.warehouse_no}}"
},
{
...
“field”:“orderDetailPrices!natSum”,
...
”value“:"_function round({{details_list.total_amount}},2)"
}
}
...
]
}
}
```
在上述配置中，我们使用了模板变量和函数来动态生成目标系统所需的数据格式。
##### 最终写入
所有字段配置完成后，通过POST请求将数据发送到用友BIP API接口，实现数据写入：
```json
{
...
api: "/yonbip/sd/voucherorder/singleSave",
method: POST,
request: [ ... ]
}
```
通过以上步骤，我们实现了从源系统到用友BIP API接口的数据无缝对接，确保了数据的一致性和完整性。
