我不记得SAP的信息来自哪里，这可能是我向他们提出的说明。 但是它已经在这里和之前在SAP-WUG上进行了讨论。 很抱歉，这就是我们无法更改的方式。

感谢您确认我对表级信息的怀疑，因此增强功能纯属代码级。 增强概念由SAP的ABAP部分拥有，不受WF的控制。 如果WF人员在类描述符表上建立他们的数据模型，并且增强功能绕过那些描述符，我只能想象将它们整合进去将是一项巨大的努力，并且WF团队中有更高的优先级。

我知道客户对维修可能会有些偏执，我之前已经进行过这些讨论。 要使用您自己的描述：比较一个不影响功能或不中断任何升级的低风险维修，然后将提供的BAdI，隐含的增强功能，以及另外一个自己的WF类作为影子提供给您， 标准WF类"。 我总是发现增强功能有些难以遵循和调试。 考虑必须修复或进行较小更改的平均（外包？）支持开发人员。 维修途径风险更低，成本更低，易于实施，易于理解。

一个可能的风险论点是，如果在升级期间以重大方式更改SAP类，则您的子类可能会受到影响。 但是，由于您只是将增强功能移到子类中，因此增强也会受到类似的影响。 不管您继承还是增强，净效果都是相同的，因此风险没有差异。

增强功能存储在表ENH *中。 在这里，类CL_OO_CLASS_COMPONENTS_FLAT由CL_SWF_EXP_SERVICE调用，这是WF运行时的更深部分。 但是您是对的，在WF运行时中的任何地方都不能相同。

我不是那么了解情况，但也许BPM业务流程会考虑这一点，并在WF运行时替换它。

无论如何，非常感谢您的讨论。

这是一个已知的限制，SAP已经确认了这一点。 公平地说，我不认为这是工作人员的错，但我怀疑这与增强功能的工作方式有关。

我还没有机会验证这一点，但是我想可能在类定义中看不到增强功能-查看SEOCOMPO/COMPDF表（名称可能略有不同，不在系统前面）以 看看您的增强功能是否可见。

我的解决方案是一种简单的修复方法，可以从类中删除最终标志并将其子类化。 这是您可以进行的最低风险的维修，因此明智的人应该对此表示同意。 然后尝试将增强功能保留在子类中-例如 一种包装方法，用于调用要增强的方法。

你好迈克，

感谢您的快速回复。 如果可以找到有关此主题的内容，我不会在这里写。 有什么提示和建议如何处理这些情况？

可能我的话有点过于刺耳，但是我会假设在引入增强功能时这些事情已列入议程，并且可以看到BO的结尾。 而且，开发人员也意识到，仅凭良好的意愿和准备的BAdI是不够的。 但这是另一个问题。

我重复了一些计划中的增强功能。 没错，我在表SEOCOMPO/SEOCOMPODF中找不到这些对象。 但是，如果提供了相应的参数，则上述类将解决它们。 我再次测试了。

是的，删除标志的风险很小，但是一些客户对任何类型的维修/修改都非常敏感。

现在，我的解决方案是将提供的BAdI，在多个点上进行隐式增强以及将自己的WF类作为标准WF类的影子的混合物，以完成我喜欢在标准类中实现的工作。

最诚挚的问候，

Jens