欢迎回到这个糟糕的浪漫系列，从ESS/MSS和Fiori-UX批准请假请求。在第一部分和第二部分。我们已经建立了一个案例和一个从双方同步运行的工作流程。

在这一部分，我将向您解释我们刚才讨论的工作流程的技术部分。所以准备出发！

为了适应工作流中的定制变化，安娜尔返利机器人，大数据支持，我创建了一个带有一些方法的定制类来让我的逻辑工作。

这是我的带有一些方法的定制类，让我们快速掌握这些方法。

1。活动：设置初始审批者（我有一个方法）导入：请求ID，导出：代理（初始审批者）。从方法到任务以及从任务到工作流都进行相同的导入导出绑定。代码如下：

代码是不言自明的，如果你没有得到任何东西，请在评论中问我。我不打算解释FM:ZWF\u GET\u ALL\u APPROVERS\u LEAVE，因为我有自己的逻辑来获取下一个审批者。你可以自己用。

2。活动：获取员工姓名很容易。去吧，从PA0002拿过来，每个人通过

3。活动：批准流程是TS12300097 SAP用于批准请假申请的标准任务。

4。条件：勾选批准：请求状态为拒绝、撤回或批准

5。如果是APPROVED:Activity:Get Next Approver（方法：在我的类中设置\ Next \ Approver）。代码是有据可查的，请过目。导入：请求ID，当前代理）导出：下一个审批者。从方法到任务和从任务到工作流都进行相同的绑定。

6.活动：设置状态发送。导入：请求ID，导出：新状态

7.活动：设置状态已批准。导入：请求ID，导出：新状态

8.活动：获取当前状态。来自PTREQ_头的请求的最新状态

9。循环条件

Rest为标准。电子邮件和短信逻辑遍布互联网。找到并发送它们。

现在我们已经完成了工作流开发和解释。技术部分也做了，如果你有任何问题，请随时评论。

因为，数据支持，我们已经完成了工作流程。很简单是吗？但是挑战在哪里呢

进入第6步：改变状态发送。不知何故，SAP不会改变这个状态并抛出和转储。每当从Fiori或ESS/MSS按下"批准"按钮时，就会出现此转储。为什么会发生这种情况？让我们抓住它！我已经分析了这个问题，我有具体的答案（这是我们大多数人的痛苦领域）。

转储详细信息如下：

只是放一个屏幕截图，只是为了确定。

上面转储说，有一个期望时，大数据都学什么，插入一些表？哪张桌子？让我们分析一下。

此方法中发生的转储：MAP\u SAVE\u TO\u DATABASE行：152。当我试图在我的自定义（change\u Status\u SENT）方法中将状态从APPROVE更改为SENT时发生此转储。

对于刚刚批准休假请求并返回给他的用户来说，这是多么恼火！哇！太好了！太神了！想象一下1800个用户会发生这种情况！

为什么会有这样的垃圾？因为有时候我不知道怎么做。SAP在批准休假时（特别是在多级情况下）输入发送的状态条目。发送的行已经存在于PTREQ\表头中，我正在尝试插入同一行。所以，它说我已经有那一行了，爱返利，你正在尝试插入和转储！让我给你看看桌子。

你看到上面了吗？所有行都设置为已发送。为什么？因为那个肮脏的垃圾！

你可能已经注意到我在我的方法中放了一个WAIT语句，是的，因为让SAP在上面的表中做它的条目，然后我就会做我的把戏。因此，让SAP在请求被批准后在表中输入一个SENT状态。然后我创建一个状态为"已批准"的新行，然后再次发送。

这是一个简单的捕获。如果任何文档出错（请记住，不要谈论工作流）。

只需运行以下两个报告：

这是所有人！我希望你喜欢这个系列，学到了很多。如果您有任何疑问，请告诉我。