ABAP程序效率优化系列之①——业务层面的优化

前言

首先说一句，在HANA上开发程序也需要效率优化。至于原因，下一篇再谈。

其次是，提到效率优化的时候，很多人都觉得是开发顾问的事情，和业务层面有什么关系？但是，程序设计来源于业务需求，程序优化不但离不开业务，而且业务优化绝对是第一步！

(这里不讨论业务层面优化、代码层面优化分别能给程序带来多少效率上的提升——这也因情况而异，我只是说明程序效率优化应该遵循的步骤)

我的ABAP程序效率优化系列，共分三部分：

1、业务层面的优化(全文字，但都是干货)

2、ABAP代码(内容比较多，可能需要多篇)

3、标准程序优化后的代码分享

背景

企业实施SAP系统初期，业务数据量小，系统功能启用的相对较少，ABAP程序的运行速度还都是闪电般的快。

可随着系统应用逐渐深化，启用的功能越来越多，业务数据量越来越大，用户对系统的理解也日益深刻，对系统的开发需求也变的更多……这时候，如果ABAP程序结构设计的不好，程序执行效率就非常堪忧了。

策略

首先我们回顾一下在项目中程序开发的工作步骤，大概都是这样的——

需求产生

业务顾问分析需求

用户确认需求

业务顾问根据需求进行功能设计

开发顾问进行功能开发和基本测试

业务顾问测试

用户测试

需求完成

（红色部分是本篇要重点说明的步骤）

对于SAP的标准功能开发，甚至是其他软件的功能开发，大致上也是遵循这个工作流程的。

而这个流程表述了这样一个概念：所有的功能都是以业务需求为基础的(即便业务需求是潜在需求，功能设计也是以假想需求为基础)。所以功能都是离不开需求的，在进行程序效率优化时，我们首先要进行的就是业务层面的优化。

接下来，为了进一步说明这样做的必要性，我们从反面来举几个例子谈谈原因：

例1：

已经有一个开发好的报表，是查询销售订单、生产订单及其相关的成本、收入等信息，之前的查询条件包括销售组织、工厂、物料、销售订单、生产订单等字段。

现在用户提出一个需求，期望增加一个WBS字段的查询条件和展示字段。然后业务顾问把需求直接转移到开发顾问(像传话筒一样)，开发顾问在代码中SQL语句的查询条件中加一行简单的条件。

之后，用户根据WBS查询时，一条数据都要执行好半天。

原因分析：

并不是所有的销售订单、生产订单都和WBS有关系，简单的SQL更改可能带来的是灾难式的结果。

用户增加一个查询条件和展示字段，这看似简单，但实际上是换了一种模式去查询，用户是希望通过限定WBS取满足条件的数据。而这需要开发顾问根据不同的查询条件输入情况来进行代码优化，可是开发顾问对各模块业务上的逻辑可能并不足够熟悉(足够熟悉是业务顾问的职责)……

应对策略：

业务顾问：决不能当需求的传话筒，对用户提出的需求，首先要做好这一步——“业务顾问分析需求”。比如对于同一个报表需求，可能要根据不同的查询条件，进行有差别的查询设计，而不是纯粹的把查询条件罗列出来那么简单。

开发顾问：面对业务顾问提出的类似更改需求，不妨多问几个问题，深入的了解变更原因，根据用户的真实需求去做适合的更改。

(比如，查询采购订单时，系统中有ME2L、ME2M、ME2N、ME2J等多种方式，就是为了满足不同的查询条件，以更高的效率让用户得到更符合需求的查询结果)

例2：

有这样一个报表需求：项目、项目总成本、项目总收入、项目下的产订单、产品、生产成本、项目下的销售订单、客户、销售订单收入。用户要求在一个报表中展示，并且能汇总统计所有项目的成本和收入。

业务顾问拿到这个需求后，如果一点也不分析，直接转给开发，并且要求做到一个普通的ALV中，这实在是难为开发顾问了。即便是做出来，也肯定是没办法让用户愉快的使用的。而且如果在这个基础上再频繁变更需求，最后的结果肯定是谁也看不懂的代码，以及越来越差的性能体验！

(注意黑色字体：用户提出的是在一个报表中，业务顾问粗略的设计完，传递给开发顾问的时候，要求的是明确的报表类型：ALV，普通的ALV。)

原因分析：

这个报表中，前面三个字段是项目维度，中间三个字段是生产订单维度，后面三个订单是销售订单维度。

根本不在一个维度上的数据，能放在一个普通的ALV里吗？很明显不能，这种报表，业务顾问只要稍微分析一下，尝试用Excel做个样表，就能发现问题了。

应对策略：

业务顾问：决不能当需求的传话筒（重复上面的策略）。面对用户的报表需求，一定要自己尝试做个样表，验证一下用户需求和自己的逻辑。上面举的这个例子，维度区别很明显。还有很多维度比较隐晦的例子，但是经过设计样表的过程之后，就能暴露出来了。

开发顾问：普通的ALV确实不能实现这样的需求，但是ALV TREE还是勉强可以的。但也仅限于勉强。因为在该例子中，销售订单和生产订单同属于项目维度的子维度，可以在ALV树中作为项目节点的子节点。一般情况下，生产订单维度可以作为销售订单维度的子维度。这样可以做一个项目->销售订单->生产订单维度的树状报表。

但是还有两个问题：

1、这样的报表是用户想要的吗？

2、如果生产订单不关联销售订单呢？

所以，问题又回归到业务顾问和用户的需求分析上。

例3：

某客户有个需求，计算每个销售订单上电缆的产品毛利率。为了计算毛利率，需要知道产品的销售收入、原材料的发货成本。

销售收入，在销售模块底表中可以轻松获取。

而对于原材料，业务顾问给出的方案是，根据产品递归反推BOM(BOM有多层)，直至找到原材料的物料号为止。

可当一个开发顾问历尽千辛万苦完成程序开发后，却一个多小时执行不出结果，因为反推BOM频繁取数据库、以及大量的递归循环的计算过程实在是太耗时了。

之后，我带着开发去找业务顾问了解电缆产品和原材料的关系，了解到电缆产品的原材料只有“铜”和“铝”两个物料号，且只能为其中一个。然后我建议在物料主数据上找一个闲置的字段填原材料，但业务顾问解释，因为种种原因不允许更改物料的标准界面或使用物料的其他字段。

之后，我提出了我的解决方案：

1、建立自定义表，维护产品的原材料属性

2、对于所有存量的销售订单，梳理其销售的产品，确定其原材料属性，作为期初数据维护到自定义表中

3、程序每次执行时，取增量的销售订单上的产品数据，检测其是否维护了原材料属性。若有没维护的则提示维护，若都维护了则记录下增量日期。

而回过头来看，如果我们针对频繁取数据库和递归耗时的ABAP代码进行优化，在这样一个业务层面有设计缺陷的功能上进行单纯的代码优化，又能得到什么结果？

原因分析：

原因只有一个：方案做的太、太、太死板。开始的方案设计做不好，再多的优化都是徒劳。基础不对，努力白费！

应对策略：

系统是死的，人是活的，方案更应该是活的。

不是所有的需求都要通过标准的方式或逻辑去实现，更不是系统标准功能掌握的滚瓜烂熟，就可以给客户出一个好方案。

“根据需求进行功能设计”，还是需要用心去做。如果性能比较差，就分析性能差在哪里，想办法用“简单粗暴、直奔主题”的方式解决性能瓶颈。

总结

我们项目中遇到的程序性能问题，在业务层面的表现，大致有以下几种：

1、报表查询维度多，不同的查询维度是完全不同的查询路径

如果大量的查询逻辑和处理代码都是不同的，就应该设计成不同的查询报表。否则将带来极大的运维成本

2、报表展示维度杂乱，用户希望在一个普通ALV中展示，导致运算处理逻辑混乱、低效

需求不规范，一般情况下一张普通的报表就应该只有一个维度，不同维度的应该用多个报表或者树状报表展示

3、业务逻辑复杂，取数过程繁琐，造成大量的性能问题

可以根据具体需求，通过增强、自定义表等方式，在不同的业务数据间建立桥梁，简化业务逻辑，简化取数过程。

其实以上三种都有一个共同的处理思路——即，大道至简！

需求和功能之间存在着很重要的一步——需求转化为功能设计。这是一项由业务顾问主导，开发顾问积极参与并提出建议的工作。它需要业务顾问多掌握一些程序设计的理念，也需要团队所有人都对用户需求更多一些业务理解，然后对该拆分的需求进行拆分，对该合并的需求进行合并，对用户不合理的需求进行引导和优化。

总之，只有整个团队的紧密配合和互相支持，才能在满足用户需求的基础上做出好的功能设计，这是做出好的开发功能的第一步，也是最重要的一步！

之所以说这一步最重要，还是那句话：基础不对，努力白费！

IOS用户打赏——赞赏码