Skip to Content

Problem with Exception in a Workflow in Fiori

Sep 14, 2017 at 02:07 PM


avatar image

I had to put the approval of a custom Workflow on Fiori. All settings have already been made and the application is working. In the application, we have two options, approve and disapprove.

In Workflow, the approval step is an Activity, and it has four outcomes. One of these outcomes is the default outcome, and the other three of these outputs are defined by exceptions of the DECIDE Method of the INSTMNTPLN Standard Object.

These are the exceptions:

In the method, these exceptions are throwed through the macro EXIT_RETURN when the Workflow is executed normally through SAP GUI.

The problem is that, in FIORI, I can't use this macro in BADI

/IWWRK/ES_WF_WI_BEFORE_UPD_IB (the recommended BADI to implement in FIORI).

So what happens is that for cases where the user approves the WorkItem by FIORI, the flow follows normally because it follows the flow of the "Step Executed". While when the user rejects, I should divert the flow to exception 1001 and by BADI I can't do this.

Does anyone know how to proceed in this case?

bvae8.png (19.9 kB)
h8qgn.png (19.0 kB)
2byf5.png (11.9 kB)
10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

2 Answers

Best Answer
Stéphane Bailleul Sep 16, 2017 at 08:38 AM


I agree with Mike it is bad design eventhough some SAP workflow are design this way (or standard functionality like on the control tab the Flag process can be rejected that raises an exception)

However note 2378748 – Workflows with Approval steps with Exceptions as outcome are not supported in My Inbox will inform you officially that exception does not work in myInbox.



Show 1 Share
10 |10000 characters needed characters left characters exceeded

Stéphane, thank you for show me the SAP Note 2378748!

As I explain to Mike, I have to redesign the WF.



Mike Pokraka Sep 15, 2017 at 11:07 AM

This is bad design. An exception represents an error (usually technical, or an unexpected or rare situation), and should not be used to model a standard business process.

Here you present the user with two buttons and handle the outcome using two different processing types. Bad, for exactly the reason as you are experiencing.

It's a SAP standard object, but it is a very old object created 1997 and released in R/3 3.1g, so among the very first workflow bits ever created. I guess such design considerations and Fiori interoperability were not an issue back then. :-)

I would seize the opportunity and rewrite the function in OO or at least redesign the WF to use a standard decision task.

Show 3 Share
10 |10000 characters needed characters left characters exceeded

Hi Mike, thanks for the answer.

I agree with you, it's a bad design. Unfortunately, this workflow has been in operation for a long time, and now with Fiori, I have to find a way to make it work.

This Standard Method DECIDE (Object INSTMNTPLN) provides a good and functional screen, look:

This way, I can't simply replace the step with a standard decision task, look how much information there's in the screen. It's a standard Module Pool (called by function FKK_S_INSTPLAN_DECIDE). When the users clicks on "Rejeitar" (Reject), the Method throw the exception 1001 back to Workflow.

As you propose, if there is no way to throw that exception in Fiori, I really will have to redesign Workflow.


(These are SAP CCS IS-Utilities objects).

capturar.jpg (141.6 kB)

I wouldn't throw out the idea of a standard decision task so fast. I have done a task listing the payment schedule as part of the text - users found it more convenient to just have the relevant info in a simple list than a complicated screen, and it also means they could also approve them by email if you were to use Extended Notifications. Attaching the original object as an adhoc object always leaves the possibility to open the full view if needed.

So I see three options:

1. Decision task as I just described.

2. Create and ABAP class to represent the same object. Instantiate it in your WF (not much overhead), and copy the functionality from BOR. You can then create the outcomes as you need - the usual way is to have a return parameter that contains the outcome, which gets evaluated in the next step.

3. Subclass and delegate the BOR object, replace the code with the same idea I just described for classes.

Personally I'd go for 2.


Hi Mike! Thanks again.

I appreciate your answer and all the options that you gave me.

I agree with you when you say that "Attaching the original object as an adhoc object always leaves the possibility to open the full view if needed." The fact is that the WF is very large, and at this point, if I replace the step (as you say in 1st option), the Workflow Builder delete all the subsequent steps.

After I read Stéphane's answer, I'm satisfied to know that there's a SAP Note that advise that there's no way to control exceptions with Fiori. So I find my solution redesigning one flow in WF. I created one new attribute in the WF Container and set value to these attribute in case of REJECT. In WF, I check the new attribute for REJECT in APPROVAL flow. It didn't look very nice, but it was the best option.

Thank you!