ABAP BCD_BADDATA错误分析

Posted 2022-12-03 狗尾巴草_lan

曾经有人说：所有SAP里解决不了的问题都找原厂。好吧，不必猜测，不必怀疑，不必苦思冥想，这是我说的，哈哈哈哈哈。俗话说百密必有一疏，没想到这次就碰壁了。

那，事情经过是这样的。。。

很久很久以前，从前从前，有个人爱你很久，但偏偏风渐渐把距离吹得好远，咳咳，不好意思跑题了，再来一次。

很久很久以前，我们有个接口，是将SAP ERP的采购订单同步至SAP SRM系统，接口方式是IDOC+PO，即ERP系统在采购订单保存时将数据用IDOC方式发送至PO，然后PO再发送给SRM系统。

突然，某年某月某时，业务顾问说测试机接口不通了，采购订单皆推送不到SRM系统了，SRM查看日志有如下DUMP：

下面是曲曲折折的调查过程

第一步 照例查看源代码

按部就班查看字段类型如下：

字段	数据元素	类型	长度	小数位
ZRC_QUAN	ZERC_QUAN	QUAN	13	3
QUANTITY	BBP_MNG	QUAN	13	3
UEBTO	ZE_UEBTO	DEC	3	1

怎么看？是不没问题？嗯，我也觉得没问题，可怎么就DUMP呢~呢~~呢~~~？

于是我写了个测试程序，字段值同该DUMP时变量值一致。

执行，输出结果如下图：

好的，没有DUMP。嗯，知道了，排除类型问题。

第二步 搜索SAP官网看有没有相关问题

翻了一圈，看到有个提问下SAP回答检查SM59连接配置，需要将目标系统的通信类型设置成Unicode。

好的，检查配置，因为生产机没有出现问题，而生产机配置和测试机配置还真不一样，生产机配置的是非Unicode，那不管三七二十一，先将测试机配置改成和生产机一模一样。顺便我们还检查了PO上的配置，也没发现异常。

再次测试，依然DUMP。好的，这是个坑，因为我们使用的SAP版本是S/4 HANA，且是Unicode系统（可在系统—>状态查看）。SAP系统在早期版本（ERP 6.0 SR2之前）支持Unicode及非Unicode字符集（也称Nonunicode），在较新的版本（ERP 6.0 SR3之后）则只支持Unicode字符集，所以我们系统连接应该配置成Unicode。

这步调查的结果是对咱没任何帮助，只是帮助BASIS将生产机配置改正确了。

第三步 是时候发Message给SAP了

所有SAP里解决不了的问题都找原厂，秉承着这个宗旨，于是我们发了封Very High的Message给SAP，不得不夸赞下SAP的响应速度，11分钟后SAP回复了：

我们依然坚持不懈：

SAP再次回复：

居然被SAP拒绝了。。。。。。怎么办？只能靠我们自己了。

第四步 开发人员尝试注释该行代码

开发人员决定暂时舍弃这行代码，结果再次测试出现了新的DUMP，如下图：

查看源码：

这个INSERT语句没问题，我sure的不要不要的，所以我陷入了思考（请自行脑补沉思者雕塑）。

终于，迎来了我的高光时刻，叮铃铃呤，欢迎我闪亮登场，鼓掌！

这边又有一句至理名言：没有Money是万万不能的，但DEBUG是万能的。想必你们也猜到了这句也是我说的吧，哈哈哈哈哈哈。当我在我的知识海洋里畅游寻找答案时，“不忘初心”猛然跃入脑海，于是我决定从头开始，一点点DEBUG跟源码。

这时候DEBUG看到采购订单4500004533 行项目10 字段UEBTO值为20.0，但是SAP ERP系统里查看这个值为0.0。

 这时候就需要看下这个莫名其妙的20.0是从哪里来的了，查看源码会发现是调用了SAP ERP的远程函数获取了采购订单信息，然后按照行项目号读取修改输出参数表。

 这时候再DEBUG查看变量ET_EKPO[]的值，发现了诡异之处。

自从大哥入了SAP这行以来，还未见过如此妖魔鬼怪，虽然问题经过了包装，但基本可以断定是远程函数出现了问题。因为顾问提及之前是没有问题的，此问题是最近出现的，所以最便捷办法就是比对版本了。经过我一番熟练的操作之后，发现最近SRM系统改过函数输出结构定义，将一个字段的长度由原先30位改成了60位。

 好的，我们进SAP ERP系统查看对应输出参数的结构，发现依然是30位！！！

 这时候内心五味杂陈，不知道该感叹自己技术高超还是学艺不精，也在内心暗暗骂原厂，如此简单的原因，报错不能说浅显易懂，只能说毫无关系。

此刻脑海里猛然跃入一句哲学名言：“凡事不能只看表面，重要的是看事物的本质“，我决定重修哲学去了，88，各位看官，下期再会。