2020-09-13 10:53发布
点击此处---> 群内免费提供SAP练习系统（在群公告中）加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）大家好，我必须根据工作流程类来调... 显示全部
加入QQ群：457200227（SAP S4 HANA技术交流） 群内免费提供SAP练习系统（在群公告中）
大家好，我必须根据工作流程类来调整SAP标准工作流程。 这是第二次，而且SAP类始终设置为final。 因此，我认为我很聪明，我将使用标准增强功能（如定义新属性等）。不久之后，我得出了这些对象在工作流环境中不可选择的结果。 至少在屏幕快照中，SAP似乎不打算在工作流环境中提供增强功能。 但为什么？ 有太多困难可以关注吗？ 我在下面的SCORE 102 0002/SAP_BASIS 752 0002上体验了我的经验。在另一种情况下，我使用了SRM 7.1（？）。
问题在于经典的BO即将退休，不再是最先进的技术。 因此，如果工作流类可以替代传统的BO，则必须使用继承和增强功能进行扩展。
希望您同意我的看法。
最诚挚的问候， Jens
我不记得SAP的信息来自哪里，这可能是我向他们提出的说明。 但是它已经在这里和之前在SAP-WUG上进行了讨论。 很抱歉，这就是我们无法更改的方式。
感谢您确认我对表级信息的怀疑，因此增强功能纯属代码级。 增强概念由SAP的ABAP部分拥有，不受WF的控制。 如果WF人员在类描述符表上建立他们的数据模型，并且增强功能绕过那些描述符，我只能想象将它们整合进去将是一项巨大的努力，并且WF团队中有更高的优先级。
我知道客户对维修可能会有些偏执，我之前已经进行过这些讨论。 要使用您自己的描述：比较一个不影响功能或不中断任何升级的低风险维修，然后将提供的BAdI，隐含的增强功能，以及另外一个自己的WF类作为影子提供给您， 标准WF类"。 我总是发现增强功能有些难以遵循和调试。 考虑必须修复或进行较小更改的平均（外包？）支持开发人员。 维修途径风险更低，成本更低，易于实施，易于理解。
一个可能的风险论点是，如果在升级期间以重大方式更改SAP类，则您的子类可能会受到影响。 但是，由于您只是将增强功能移到子类中，因此增强也会受到类似的影响。 不管您继承还是增强，净效果都是相同的，因此风险没有差异。
最多设置5个标签!
{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','http://www.easysap.com/data/attach/logo/logo.png', '推荐 Nan4612 的问题《属性，事件，增强类的方法在工作流容器/环境中不可见》','https://www.easysap.com/answer/75106/208298.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
我不记得SAP的信息来自哪里，这可能是我向他们提出的说明。 但是它已经在这里和之前在SAP-WUG上进行了讨论。 很抱歉，这就是我们无法更改的方式。
感谢您确认我对表级信息的怀疑，因此增强功能纯属代码级。 增强概念由SAP的ABAP部分拥有，不受WF的控制。 如果WF人员在类描述符表上建立他们的数据模型，并且增强功能绕过那些描述符，我只能想象将它们整合进去将是一项巨大的努力，并且WF团队中有更高的优先级。
我知道客户对维修可能会有些偏执，我之前已经进行过这些讨论。 要使用您自己的描述：比较一个不影响功能或不中断任何升级的低风险维修，然后将提供的BAdI，隐含的增强功能，以及另外一个自己的WF类作为影子提供给您， 标准WF类"。 我总是发现增强功能有些难以遵循和调试。 考虑必须修复或进行较小更改的平均（外包？）支持开发人员。 维修途径风险更低，成本更低，易于实施，易于理解。
一个可能的风险论点是，如果在升级期间以重大方式更改SAP类，则您的子类可能会受到影响。 但是，由于您只是将增强功能移到子类中，因此增强也会受到类似的影响。 不管您继承还是增强，净效果都是相同的，因此风险没有差异。
一周热门 更多>