数据集成与转换：将吉客云数据导入用友BIPAPI

  • 轻易云集成顾问-曹润

案例分享：吉客云·奇门数据集成到用友BIP

在本篇文章中，我们将深入探讨一个实际运行的系统对接案例，通过轻易云数据集成平台，实现吉客云·奇门的数据无缝转移和高效整合到用友BIP。具体方案名称为“2C线上-吉客云-销售单-YS-销售订单-合并-京东”。该方案旨在优化从吉客云获取的电商平台数据，顺畅地写入到用友BIP系统中，从而实现业务数据的统一管理。

高吞吐量的数据写入能力

为了满足大规模电商交易信息快速处理的需求，该解决方案充分利用了轻易云平台支持的大量数据快速写入能力。通过调用吉客云·奇门提供的jackyun.tradenotsensitiveinfos.list.get API接口，我们能够及时抓取最新的销售记录，并批量传输至用友BIP。这一过程不仅提升了业务处理效率，还确保了关键交易信息不漏单、不延迟。

实时监控与告警系统

在整个数据处理流程中，集中化监控和告警系统发挥了重要作用。我们实时追踪每个API调用及其状态，通过可视化面板及时发现异常问题。例如，当检测到由于网络波动导致部分请求失败时，预设的重试机制会立即启动，确保所有有效交易信息均能成功录入到目标系统。

数据质量与异常检测

为了保证高质量的数据流通，我们采用了一系列严格的数据质量监控和异常检测策略。在源头获取阶段，对从jackyun.tradenotsensitiveinfos.list.get接口返回的数据进行初步校验；随后，在传输至用友BIP前，再次执行详细验证，以便排除可能存在的不一致或缺陷。同时，对于分页加载和限流控制等技术难点，本方案也有针对性地进行了优化，使得大量连续请求可以稳定、可靠地完成。

自定义转换逻辑与格式适配

不同于一般简单的数据搬运任务，本项目中的两大系统—吉客云·奇门与用友BIP—存在显著的数据结构差异，为了解决这类复杂对接需求，我方自定义了一套精细化的数据转换逻辑。尤其是在逐笔订单细节映射过程中，需要考虑来源字段与目标字段间的一致性匹配。此外，根据企业特定需求，对原始格式进行了多层级调整，以确保完整、准确地反映真实业务情况。

此次案例展示，不仅强调了解决跨平台应用常见挑战的重要手段，也为如何有效利用现代技术工具提供了实践参考。在后续内容中，将进一步详述具体实施步骤及相关技术细 用友与MES系统接口开发配置

调用吉客云·奇门接口jackyun.tradenotsensitiveinfos.list.get获取并加工数据

在轻易云数据集成平台的生命周期中，第一步是从源系统获取数据。本文将详细探讨如何通过调用吉客云·奇门接口jackyun.tradenotsensitiveinfos.list.get来获取销售订单数据，并对其进行初步加工处理。

接口调用配置

首先，我们需要配置接口调用的相关参数。根据提供的元数据配置，可以看到该接口采用POST方法，主要参数如下：

  • api: jackyun.tradenotsensitiveinfos.list.get
  • method: POST
  • number: tradeNo
  • id: tradeId
  • pagination: 支持分页，每页记录数默认50，最大1000
  • idCheck: true

请求参数包括时间范围、销售单号、页码等信息。以下是一些关键字段及其描述：

  • modified_begin 和 modified_end：修改起始和结束时间，必须同时存在且间隔不超过七天。
  • startConsignTime 和 endConsignTime：发货时间范围，通常使用上次同步时间和当前时间。
  • tradeStatus：订单状态，用于筛选特定状态的订单。
  • fields：需要返回的字段列表，以逗号分隔。

请求示例

基于上述配置，我们可以构建一个请求示例：

{
  "modified_begin": "2023-09-01T00:00:00",
  "modified_end": "2023-09-07T23:59:59",
  "pageSize": 50,
  "pageIndex": 0,
  "hasTotal": 1,
  "startConsignTime": "{{LAST_SYNC_TIME|datetime}}",
  "endConsignTime": "{{CURRENT_TIME|datetime}}",
  "tradeStatus": "6000",
  "fields": "checkTotal,tradeNo,postFee,otherFee,chargeCurrency,accountName,payType,payNo,sellerMemo,buyerMemo,goodsDetail.goodsNo,goodsDetail.goodsName,goodsDetail.specName,goodsDetail.barcode,goodsDetail.sellCount"
}

数据清洗与转换

在获取到原始数据后，需要对其进行清洗和转换，以便后续处理。以下是一些常见的数据清洗与转换操作：

  1. 字段重命名与格式化

    • 将consignTime字段重命名为consigndate并格式化为日期类型。

  2. 条件过滤

    • 根据条件过滤掉不符合要求的数据，例如订单状态不等于6000或商品销售数量为0的记录。

  3. 嵌套结构扁平化

    • 将嵌套的商品详情（goodsDetail）扁平化处理，以便更容易进行后续的数据分析和处理。

数据清洗示例

假设我们从接口获取到如下原始数据：

{
  "tradeId": "123456789",
  "tradeNo": "JD202309010001",
  "consignTime": "2023-09-05T14:30:00",
  "goodsDetail": [
    {
      "goodsNo": "G001",
      "goodsName": "商品A",
      "sellCount": 2
    },
    {
      "goodsNo": "G002",
      "goodsName": "商品B",
      "sellCount": 0
    }
  ]
}

经过清洗和转换后的数据应如下所示：

{
  "tradeId": "123456789",
  "tradeNo": "JD202309010001",
  "consigndate": "2023-09-05",
  "goodsDetail_goodsNo_1": {
    "goodsNo": "G001",
    "goodsName": "商品A",
    "sellCount": 2
  }
}

自动填充与补偿机制

为了确保数据完整性和一致性，轻易云平台支持自动填充响应和遗漏补偿机制。例如，当某些字段缺失时，可以自动填充默认值；当某些请求失败时，可以通过定时任务（如crontab）重新发起请求以补偿遗漏的数据。

{
  ...
  “omissionRemedy”: {
    “crontab”: “20 */2 * * *”,
    “takeOverRequest”: []
  },
  “autoFillResponse”: true,
}

以上内容展示了如何通过轻易云平台调用吉客云·奇门接口获取销售订单数据，并对其进行初步加工处理。这一步骤是整个数据集成生命周期中的关键环节，为后续的数据转换与写入奠定了基础。 用友与外部系统接口集成开发

数据集成与ETL转换：将源数据转化为用友BIP API格式

在数据集成生命周期的第二步，我们需要将已经集成的源平台数据进行ETL（提取、转换、加载）转换，使其符合目标平台用友BIP API接口所能够接收的格式，并最终写入目标平台。本文将详细探讨这一过程中的关键技术细节和配置要点。

1. 数据提取与清洗

首先，从源系统提取销售订单数据。假设我们从吉客云中提取了销售订单数据，这些数据可能包含多个字段，如商品编号、销售数量、优惠后金额等。在这个阶段，我们需要对这些数据进行初步清洗，确保其完整性和准确性。例如，去除重复记录、处理缺失值等。

2. 数据转换

接下来是数据转换阶段。这一步骤至关重要，因为我们需要将源数据转换为用友BIP API所需的格式。以下是具体的元数据配置和字段映射：

{
    "api": "/yonbip/sd/voucherorder/singleSave",
    "method": "POST",
    "idCheck": true,
    "operation": {
        "method": "merge",
        "field": "consigndate,shopCode,warehouseCode",
        "bodyName": "items",
        "bodySum": ["goodsDetail_shareFavourableAfterFee", "goodsDetail_sellCount"],
        "header": ["shopCode", "consigndate", "warehouseCode"],
        "body": ["goodsDetail_goodsNo", "goodsDetail_shareFavourableAfterFee", "goodsDetail_sellCount"]
    },
    ...
}

在上述配置中，我们定义了API接口的路径和请求方法，同时指定了主键检查idCheck为true，以确保幂等性。操作类型设置为merge，表示合并操作。

2.1 主表字段映射

主表字段的映射如下：

  • resubmitCheckKey: 保证请求的幂等性，由客户端生成并且必须全局唯一。
  • salesOrgId: 销售组织，传递店铺编码{shopCode}。
  • transactionTypeId: 交易类型，固定值J01。
  • bizFlow: 流程ID，固定值35f60e0d-3ad8-459d-b3bb-52a997334a37。
  • vouchdate: 单据日期，格式为yyyy-MM-dd HH:mm:ss。
  • code: 单据编码，由系统规则生成，例如：XSDD{consigndate}{shopCode}{warehouseCode}。

其他字段如发票抬头、纳税人识别号、营业电话等，根据业务需求进行填充。

2.2 子表字段映射

子表字段的映射较为复杂，需要处理多个嵌套结构：

  • stockId: 仓库编码 {warehouseCode}。
  • isExpiryDateManage: 是否有效期管理，固定值false。
  • orderDetailPrices!natSum: 本币含税金额，通过函数计算得出，例如：abs(round({{goodsDetail_shareFavourableAfterFee}},2))。
  • productId: 商品编号 {goodsDetail_goodsNo}。

其他字段如主计量单位、销售换算率、税额等，根据具体业务逻辑进行计算和填充。例如：

{
    "field": "orderDetailPrices!oriTax",
    "label": "税额",
    "type": "string",
    "describe": "税额",
    "value": "_function case '{goodsDetail_goodsNo}' when 'X0001' then abs(round({{goodsDetail_shareFavourableAfterFee}}/(1+0.06),2)-{{goodsDetail_shareFavourableAfterFee}}) else abs(round({{goodsDetail_shareFavourableAfterFee}}/(1+0.13),2)-{{goodsDetail_shareFavourableAfterFee}}) end"
}

上述配置中使用了条件语句，根据商品编号不同计算不同的税率。

3. 数据加载

最后，将转换后的数据通过POST请求写入用友BIP系统。确保请求体符合API规范，并包含所有必要字段。示例如下：

{
    "_status": "Insert",
    ...
}

在实际操作中，需要注意以下几点：

  1. 幂等性：通过唯一键保证每次请求都是幂等的，不会重复创建相同的数据。
  2. 错误处理：捕获并处理API返回的错误信息，以便及时调整和修正数据。
  3. 性能优化：对于大批量数据，可以考虑分批次提交，以提高系统性能和稳定性。

通过上述步骤，我们可以高效地将源平台的数据转化为目标平台用友BIP API所能接收的格式，并成功写入目标系统，实现不同系统间的数据无缝对接。 钉钉与CRM系统接口开发配置

版权声明

该文章《吉客云与用友BIP无缝衔接：提高电商业务效率》为原创内容，版权归 广东轻亿云软件科技有限公司 所有。 未经本公司书面授权，严禁转载、引用、复制或建立镜像等行为。 若需转载或引用本文内容，请联系本公司获取授权，并在显著位置注明作者姓名、文章出处（包括原文链接）等信息。

轻易云AI数据分析
更多系统对接方案