上周在巴塞罗那享受了SAP TechEd之后，我现在又回到了现实中。我真的很喜欢TechEd。我会称自己为某种怪人，我真的很喜欢了解即将出现的新事物，即使它可能比我的日常业务提前几年，或者它可能永远不会成为我的日常业务。我必须强调的是，我真的很想看到SAP继续走几年前开始与HANA合作的道路。因为我在SAP生态系统工作（到现在已经差不多15年了），这是他们第一次在这么长的时间里遵循同样的策略。技术和产品似乎更加成熟和稳定。当然，经常有改进的地方，但总的来说，我喜欢我所看到的。尤其是SAP变得越来越开放的事实，正如你在几个领域所看到的：openSAP，在标准化方面的贡献（例如OData）和对开源软件的贡献…这绝对是一个很大的进步，我真的很喜欢！

但现在我要说的是我为什么要写这篇博文。我又回到了工作中，回到了我的日常事务中，不知何故我想回到黑暗的一面。这个故事是关于我在一个特定的BAPI和SAP支持方面的经历。

在我开始讲述我的故事之前，我对BAPI概念有一些一般性的评论：

我认为拥有BAPI的概念非常好。当它被引入时，封装业务逻辑是一个非常创新的想法，您可以从另一个系统调用它。但我对许多现有BAPI的一个问题是它们的设计方式。在许多情况下，只有一个BAPI负责对业务对象进行所有更改。这种"一刀切"的方法使得几乎不可能定义所有测试用例来测试整个功能，这就为副作用打开了一扇大门。此外，一些BAPI的签名由20多个表和结构组成。此签名中的某些字段永远不应填充，但您可以填充它们。由于bapi也是非SAP世界的一个接口，因此它们的设计方式导致SAP的声誉非常复杂，大数据的发展前景，在.net、Java开发人员和任何其他不得不使用它们的人中都不容易理解。在我看来，它们如此复杂也是SAP不敢重写它们的原因（它们被包装在SOAP服务中，现在它们常常被包装成OData服务，我想知道S4HANA会发生什么）。不过，我还是很高兴它们的存在，正如我所说的，在引入它们的时候，它们是最先进的。

现在我想讲一个关于过去近18个月的真实故事，以及我在SAP支持下的"乐趣"。说清楚一点：我不想个人责怪任何人。我假设所有参与的人都按照他们被告知的方式来做他们的工作。

这个故事是关于一个自2005年以来就存在的BAPI。在物料主数据区域。在ServiceMarketplace上快速搜索发现，SAP在这18个月内发布了50多条SAP笔记。我并不为这个事实感到骄傲，至少有五张是在我们的一张票之后产生的，返利怎么用，到目前为止，这张票的总数已经达到了九张。事实已经表明，这个BAPI让我很忙。我们将这个BAPI用于主数据接口，它对我们的应用程序非常重要。因此，所有这些问题甚至引起了管理层的注意。每个开发人员都知道，当管理人员试图解决您的软件问题时，解决问题并不容易

好吧，可以说，如果SAP发布了50多个SAP笔记，他们就意识到了质量问题，并安装了一些质量管理流程。我不知道他们是否这样做了，但至少我不这么认为。在我们创建了第一个票证之后，在与SAP支持人员就是否将其声明为bug进行了无休止的讨论之后，我们最终调试了SAP代码，并将它们指向了我们发现bug的位置。即使在这种情况下，也需要数周的时间来修复。现在，在我们打开一张罚单之前，我们先深入研究一下SAP编码。这是一项痛苦的工作，但没有那些讨论那么痛苦。但即使我们告诉他们，"看这里，这一定是一个错误"，他们有时只是忽视我们的提示几个星期。最后，在他们发布的SAP说明中，他们出人意料地更改了提到的代码部分。

我的一位同事已经建议我们应该自己去重新实现BAPI。我仍然相信这是一个完全错误的解决方案（总是使用SAP功能模块来更改SAP表中的数据，这样做是有充分理由的！）。但考虑到我们的投入，我们有可能开发出满足我们需求的BAPI。

SAP从客户那里获得了大量资金支持。他们的客户需要良好的支持，因为他们经常为业务运行任务关键型系统。但是作为一个客户，您应该真正担心您的软件供应商的支持团队是否像我们所经历的那样行事：

对我来说，现有的ERP套件（在客户的绝大多数系统上运行）似乎成了遗留问题。有一些支持团队负责编写几乎没有评论的代码，如果有评论，则使用他们不会说的语言。我只能猜测他们的文件。

这些经历真让我担心！

我所有的经历都是个案还是你有类似的经历？

嗨，马丁，