Real Life Experiences Extending Fiori My

Inbox
FollowingRSS feedLike
17 Li kes 15,403 Views 29 C omments

Understand what it takes to extend Fiori My Inbox; how to get the most from the Extensibility
Cookbook; and learn from our missteps.

Fiori My Inbox – The Challenge

Murali Shanmugham and I wanted to share our experiences in implementing and extending My
Inbox for a Proof of Concept at one of the Australian public sector agencies.

What we did: We extended the Fiori My Inbox App to include line items for both ECC FI Journals
(preliminary posting docs) and SRM Shopping Cart Approvals.

Why we did it: This provided a one stop mobile approvals user experience for managers who need
to be able to approve anywhere anytime. The managers in the pilot group were particularly
mobile. They were reported to be at their desks less than 1 hour per day. In addition many of these
approvals were urgent – purchases were often reactive to rapidly changing circumstances. So
success criteria included:

 Speed (minimum clicks & good performance);

 Simple “don’t make me think” user interface;
 Phone/tablet/desktop responsive.

What we want you to know: It also turned out to be a great example of how to get the most from
the Extensibility Cookbook for Fiori My Inbox. And also how to approach extending My Inbox from a
UX (User Experience) – not just a UI (User Interface) – perspective, even when the conditions aren’t
ideal.

As an added bonus we were able to extend Fiori My Inbox WITHOUT CHANGING THE CUSTOM
WORKFLOWS AT ALL! That was a huge win as it meant no significant change for business or IT
support staff – reducing risk and change management costs.

What we’ll show you:

 The difference between My Inbox Out of the Box (OOTB) and our final extended version
 How we approached the project – making sure we considered UX not just a UI
 The major steps: Installation, Configuration, Extension
 Lessons learned and what we’d do differently next time
Fiori My Inbox OOTB: Custom Workflows from
Multiple Systems
The below screen capture shows the look and feel of the standard Fiori My Inbox app out of the
box. In this screenshot you can see this is a custom workflow.

Yes that’s correct – Fiori My Inbox does support custom workflows right out of the box!

It also provides out of the box support for workflows from multiple backend systems as well. This
was good news for our scenario as we were working with ECC and SRM backend systems. The
subject, long description, due/created dates, status, priority, and previous processor are all shown
much as in any workflow inbox.

A particularly nice feature is the green (“Positive”) and red (“Negative”) colouring to reinforce
approve/reject buttons. This is very simple to set up via the standard My Inbox configuration.

The final icon button is used to send an email. We kept this as a contact the author or contact
support feature. It dragged the subject text and a few other details into the email – enough to make
it useful.

In the same button toolbar that holds the Approve all Items and Reject all Items buttons, note the
“Open Task” icon button which applies the standard task launch. The standard task launch is
typically whatever is configured in transaction SWFVISU – Task Visualization for the relevant
task. Now this could go to any web-capable user interface such as SAPGUI for HTML or Web
Dynpro ABAP or SAPUI5. But not all of the SWFVISU options are suitable for tablet and
smartphone use.

To make the inbox suitable for tablet and smartphone, we need to extend the inbox to override the Open
Task button with a more responsive design.
Fiori My Inbox – Extended
The following screen shots show our final extended version.

What we changed:

 Master List – include additional info such as amount

 Group By/Filter/Sort by additional info in the master list
 Specific Task Detail user interfaces for each task
 For Journals – configured standard approve/reject options
 For Shopping Carts – extended the Task Detail to enable line item approval
 Remove unnecessary icon tabs – such as processing log and history
 Remove unnecessary workflow features – such as Release Forward, Suspend
 Added mass approval/reject options using the standard Multi-Select button on the master list

First the Journal work items. The approver can see the essential journal details including all the journal
line items directly in the task details pane. We’ve even aligned the debit and credit columns so the
approver can see at a glance how the journal is balanced. We’ve also removed unnecessary tabs and
action buttons. The underlying task in the custom workflow was a User Decision.
Now with financial journals there are always lots of number codes – for G/L accounts, cost centres, funds,
tax codes, project (WBS) codes, etc. The users told us that over time they became very familiar with their
codes. But of course for newbies they can be hard to remember. So we have provided the line item
expand “>” option to let them check what all those codes mean. And in the top right hand you can see the
up/down arrows so they can move from one item to the next/previous without having to go back to the
main journal display.
We also added a new task detail display for the Shopping Cart approvals.

Here the My Inbox Extensibility Cookbook was especially helpful because it uses the shopping cart as an
example – including showing how to do the line item approval.

We took it to the next level by: removing unnecessary tabs and actions, and adding the line item expand
“>” option to show the accounting information which might be to single or multiple cost objects.
Here again there are potentially a lot of cost objects. One line item can even be assigned to multiple
cost objects. So again we pushed the detail out to an optional user interface accessed by expanding
the line item via the “>” symbol at the end of each item.
If you look closely at the screenshots you will also see we adjusted the master list itself. Because
the managers primarily approved financial information it made sense to add the value of the journal
or shopping cart into the master list. For instance we allowed the manager to filter by value.

We also completely reworked the subject text – there’s a standard BADI provided as part of the My
Inbox solution for this purpose. We added some additional attributes to the master list to make it
even more useful – the blurred section is the name of the person submitting the journal or shopping
cart.

Where we started: Treat it as UX not UI

We were keen to make this a User Experience project – not just a User Interface project – to achieve
the best possible result.

So even given tight timeframes and a small team, we worked at approaching it from a UX
perspective to ensure we maximized success for the end users and the business outcomes. So we
followed the UXaaS Discover > Design > Deliver lifecycle as seemed appropriate to the scope,
context and audience – including allowing for some iteration.

Now we are not saying the UXaaS lifecycle flow was ideal – there was no design thinking; no low
fidelity wireframes; limited solution validation; and no access to the UXaaS tools provided by
HCP. Culturally UXaaS wasn’t on the radar of the organisation yet either. Sometimes that’s just the
way it is when you are doing a proof of concept. But despite these challenges were able to draw on
the UX approach as much as we deemed appropriate to the circumstances.

It is our belief that approaching the problem from a holistic User Experience perspective made all the
difference in getting the Proof of Concept to the next stage of consideration.

In fact taking the UX perspective changed not just what we designed and delivered – it
changed our whole view of the problem.

Discover: Existing Problems and Challenges

From the beginning the current user experience pain was clear. Both business and IT support
raised numerous challenges.
The existing solution was web-based and ostensibly created to be simple – but it was fairly evident
that somewhere along the line the voice of the end user had been left out.

Most important pain points to overcome to improve the user experience were:

 Undesirable delays – part of the solution included an overnight replication of some of the
data – this meant that same day approvals were sometimes impossible as the data wasn’t
there to support it
 Poor performance – a summary icon button that caused a spinning wheel of death for any
shopping carts with a large number of items
 Information overload – too many buttons, too many features, too much poorly understood
technology

There were also some serious support challenges. IT Support reported that they were often requested to
manipulate the org structure to find alternative approvers. Sometimes they were also asked to reassign
work to alternate approvers. The org structure manipulation caused undesirable impacts on other
workflows such as the same alternate approvers being accidentally identified as the approver of other
workflows.

So how did we approach the problem? First target was getting the voice of the end user back
into the solution.

Discover: the End User Voice is Critical to Solving the

Right Problem
A bedrock of User Experience is to deliberately consider the perspective of the end users
themselves. As this was a proof of concept and the UX perspective was new to the organisation,
access to end users was limited. Even so we took every opportunity to listen to and observe as
many users as possible. Where we couldn’t reach the end users themselves we talked to people
who had met with them in their workplace. We even talked to some users over the phone.

Any contact with end users is better than none. In fact if we hadn’t talked to the end users we
might have solved the wrong problem!

Initially we had talked to the IT Support team about the type of support incidents that were being
raised and the impact of the user behaviours they had seen. We also conducted workshops with
key stakeholders and business analysts to understand the initial requirements. That helped us
identify the workflows, tasks and people affected; and the gaps in the standard solution. We
identified the different task types to be shown in the My Inbox app; and worked through what
information needed to be shown to the approver.

But even our limited contact with end users gave us a very different view of the problem and much
greater insight into their user experience.

Observing end users makes the difference between understanding the symptoms and the
cause.
The challenges the IT Support team and Business reported were valid – but we quickly realised
those challenges were mostly symptoms rather than causes. To get to the causes we needed to
look to the current user experience of end users.

For instance, IT Support saw lots of examples of users trying to twist the system into knots to set up
alternate approvers for their workflows. When we talked to the users why they were doing this
became clear. The end users weren’t really interested in finding alternate approvers – they were just
trying to get their journals and shopping carts approved – many of which were urgent. The real
problem was that the current solution was desktop based, but the managers who needed to approve
journals and shopping carts were extremely mobile. They simply weren’t at their desk often enough
to deal with all the approvals in a timely manner.

That critical understanding changed our whole view of the user experience.

For starters it was clear that a mobile solution was crucial to a good user experience. It also opened
up opportunities to suggest features which had not initially come out of the workshops. Such as the
adjustments we made to the master list to make it easier for the approver to prioritise their work on
the fly.

Design: Agree on the UI design.. and be Prepared to

Iterate
One of the nice things about starting with existing Fiori apps is that you have a baseline for the
design. In our scenario we actually looked to two existing Fiori apps – Fiori My Inbox and Approve
Shopping Carts. What was needed was one central inbox for all approvals, but with the Task Detail
screens extended for each task. The Fiori My Inbox extensibility cookbook in SAP Note 2118812 –
How to extend Fiori My Inbox shows the extension options.

Particularly useful for communicating within our own team was Appendix D – which shows what can
be customized without extension – just using the normal configuration. We also had some screen
shots highlighting in a similar way what can be changed in Fiori My Inbox. These we were able to
source from conference presentations on My Inbox – but they are pretty easy to draw up yourself.

NOTE: We considered it important that we not to distinguish between configuration or extension for
workshop participants – many of whom were our stakeholders. We just needed to be clear what
could be changed and what would stay the same.

So from a design perspective we ran our workshop this way:

1. Here’s the standard Fiori My Inbox functionality and where we can extend it
2. Here’s an example of a tailored screen for approving shopping carts
3. Let’s talk about how we merge these together
4. Let’s talk about what you would need to see for approving journals
5. What else needs to be added or removed to make the inbox useful and as simple as
possible
Granted this is not a full start-from-scratch UX design – but it is a valid approach when adapting existing
apps.

We came out with a set of mock up slides showing our design. Essentially a high fidelity prototype.

We did iterate our design… Part the way through our delivery we realised that making the changes
was going to be easier than we first thought, and we looked for further improvements we could add
into scope. A number of changes to the master list came about during the iteration.

We used MS PowerPoint (PPT) at the time to create mock up screens and validate the design. It was too
early to get access to BUILD then… but we would have loved to use it instead – PPT worked but was a
little tedious. And being able to distribute the design as a user study would have made the feedback
process easier.

Deliver: Verify your Fiori app installation

Early on we realised we needed to install both a Fiori landscape – Gateway, Fiori Launchpad, etc.
– and two Fiori apps.

Even though we were only going to give the users one end result it was still useful to provide the
Fiori Launchpad to explain how the UX would scale over time. The FLP is also handy for showing
how you will integrate apps into existing Portal, Business Client, or other entry point.

Why two (2) apps? By installing both Fiori My Inbox and Fiori Approve Shopping Carts we
were able to reuse some of the underlying components from the OData Services of Approve
Shopping Carts in building our final solution. It was also very helpful to have both OOTB
versions of the apps working as a comparison to our final runtime app. If it worked in the original
app but not in our final version yet, then we had something to guide us in our troubleshooting.

Later the approve shopping cart apps also gave us a pattern for creating the task details for the
financial journals – for which there were no OData Services available.

Before we started we verified the software components were being installed are in the right version. As
per recommended practice for Fiori we set up the Gateway in hub mode as the Fiori frontend system,
connected to our two backend systems ECC and SRM.

Most importantly, we implemented all the relevant SAP notes both for the Fiori Apps and also the related
SAPUI5 framework. This meant applying SAP Notes to both the Gateway and in some cases to the
backend systems. Much better to get the apps and the framework in the best possible state from the
beginning, than waste time rediscovering problems that had already been fixed in standard.

A starting point for this is SAP Note 2106212 Release Information Note for SAP Fiori My Inbox. This
note consolidates a lot of the fixes for My Inbox.
NOTE: As we were aiming for a mobile responsive solution another note that was important was SAP
Note 1935915 Fiori for Business Suite: Browser / Devices / OS Information. We didn’t need to wait
for the mobile configuration to be completed to verify our installation. A lot of the mobile set up was done
in parallel with configuration and extension.

We followed the standard guides and instructions to register the /IWPGW/TASKPROCESSING (version
2) OData service and activate the standard Fiori My Inbox App.

Once everything was installed and before making any changes or doing anything more than the
absolute minimum configuration we verified the standard apps were working as intended OOTB. For
My Inbox minimum configuration primarily involves setting up the connection from the Task
Processing Services in the Gateway to the two backend systems. You don’t even need to configure
the workflows and tasks at this point.

My Inbox is great for this OOTB verification approach because the moment you configure the My
Inbox app to connect to the backend systems all the work items of the user are immediately brought
into the inbox. If your workflows are already running in the backend system, they will start working
straight away after configuring the MyInbox App. It doesn’t matter if they are SAP Standard Workflows or
custom workflows.

We tried all the standard features to confirm they were working as expected. That also helped us
reconfirm the changes we needed to make based on our agreed Design.

We recommend the SCN collaborative document on SAP Fiori – My Inbox as it highlighted several other
SAP Notes we should look at to maximise the OOTB functionality.

Good notes to look at include:

 Any SAP Note mentioning the keywords “Task Gateway” – these relate to the OData Services in
Gateway that support handling of Business Workflow, BPM and 3rd party provider tasks
 Any SAP Note mentioning CL_WAPI_MOBILE_INBOX – this is the underlying ABAP Class used
to flexibly extract workflow and work items in a lightweight manner
 Any SAP Note mentioning the keywords “My Inbox” – these include backend workflow system
adjustments to ensure data is passed correctly to/from the Task Gateway

 Notes in the Fiori My Inbox application component CA-INB-FIO

Jocelyn’s personal tip here is to track the list of SAP Notes you are applying somewhere…there can
be quite a few and having to find the note you are looking for in the SNOTE browser is not
fun. Similarly we tracked what OOTB features and functions we tested before and after the initial
installation, configuration, and extension. A simple spreadsheet or project task schedule
highlighting what’s working and what’s not helps you coordinate team efforts on what still needs to
be done.

Don’t forget to capture your URL links for accessing the app(s) directly and the Fiori Launchpad itself
internally and externally. These are a pain to keep typing in, especially on mobile devices. Much
easier to copy and paste into an email or dropbox or similar and share them between desktop and
device that way.

Deliver: Maximise use of the delivered Fiori app

It’s important to understand that most of the functionality provided by MyInbox App is out of the box.

Even OOTB, an Approver can see all their work items in the inbox and action them. That includes
adding notes and attachments and all the other usual workflow features that My Inbox supports.

We made the most of the available configuration including the BADI exits. Just using the configuration
we were able to significantly adjust the inbox in the following ways:

 Assign positive/green and negative/red colours to certain buttons

 Adjust the subject text of the work items using a BADI

 Create a Submit button for the Approve Shopping Cart tasks

 Assign an action to buttons we wanted to support in Multi-Select mode – such as Mass Approval
for financial journals and for shopping carts

Mass approval is OOTB for User Decision tasks such as the Approve Financial Journal. Even the
buttons are created automatically.

For Shopping carts we needed to use the BADI to associate the underlying code with the relevant
button. Because we had implemented the Approve Shopping Carts app we were able to largely
reuse one of its functions for this. We created Approve All Items and Reject All Items buttons for
multiselect mode of Shopping Carts. We also added a Submit button that we would later use to
submit the line item approvals for the extension.

All the available BADI’s are listed in Fiori My Inbox extensibility help It’s easier to use the logic in these
BADI’s to customize the UI rather than changing them either in the OData service methods or the SAPUI5
project.

BADI (/IWPGW/BADI_TGW_TASK_DATA) let’s you change the Task subject.

BADI (/IWWRK/BADI_WF_BEFORE_UPD_IB) lets you add code against the multiselect actions for Tasks.
We recommend the SCN collaborative document on SAP Fiori – My Inbox was very useful in supporting
the official SAP Library and Fiori Apps Reference Library help for the My Inbox app. Between these
resources it is easy to find both instructions and examples of configurations.

Make the most of the My Inbox Extensibility Cookbook

and Extension Guides
The My Inbox Extensibility Cookbook can be found in SAP Note 2118812 How to Extend SAP Fiori
My Inbox.

The cookbook uses Shopping Cart Approvals as an example – showing how to tailor the Task Detail
screen to add item approvals. We used the Cookbook both as a starting point and as a reference. The
cookbook even shows how to reuse some of the APIs from the Approve Shopping Cart app.

For example, we had to show Shopping Cart Items in the Task Detail of an Approve Shopping Cart
task complete with options to approve or reject individual items. The information we need to show
was a subset of the information seen in the specific Approve Shopping Cart app. We actually
needed to show more than was given in the My Inbox Extensibility Cookbook, but less than the
Approve Shopping Cart app. So it was good to see how the details were exposed in the OData
Services behind both apps to guide our final solution.

We used a similar approach for adjusting the financial journals display.

One big lesson learned here was to look under the covers of the existing OData Services for
best practice clues.

First iteration of the financial journals we used a function module to get the work item details. When
we cross-checked with the Approve Shopping Carts OData Services we realised we should instead
use classes such as CL_WAPI_MOBILE_API and CL_WAPI_MOBILE_INBOX. These classes
allowed us to apply some of the secondary features efficiently – such as filter/sort/group by.

We didn’t have to change any of the existing custom workflows or do any sort of changes in
how the workflow found the end users as recipients.

The workflows had already been running successfully for many months. W e were able to extract what
we needed to show, or to derive what we needed to show, from the existing container elements of the
work item. Because this information was already a part of the workflows we didn’t need to modify any of
the workflows.

In the end we really didn’t add much functionality apart from the Task-specific detail displays, the
item level approval, and the master list changes. Based on the design workshops it was more
important to simplify the inbox by hiding buttons and tabs that were superfluous to
requirements. We removed most of the buttons and only kept Accept/Reject/Submit buttons we had
configured and the out of the box Send email button.
Since there is an extension required for the Standard My Inbox App, create a custom OData service
redefining the standard service and likewise create a custom SAPUI5 project which extends the
standard My Inbox App. There are plenty of resources available on SCN which will help you in
extending standard Apps.

It’s very important to plan how you extend the Fiori App. Since MyInbox App can handle multiple task
types from several systems, you need to come up with an elegant way of extending it. That’s important to
make sure the app remains easy to support and maintain as more task types are added. Below is the
approach we took based on the cookbook recommendations, but there are other ways of achieving the
same ends. We would have liked more time to explore some alternative approaches – already some of
the latest information on Smart Templates and Annotations shows promise.

For each Task type, we created a separate detail view. Based on the type of Task selected in the
master list (S2), the corresponding set of views are loaded in the detail section using the routing
rules. In other words every time you add new task type you create a Task-specific detail view for the
new Task type. The Task-specific detail view is displayed when the a matching task is selected in
the master list (S2).

Test the application across devices through the eyes

of a real user
Once the My Inbox app configuration and extension is complete, make sure you test it in various
browsers and devices which are allowed for the user base.
Test the app in each device as if you were the end user.

In our first iteration since we had been extending the app and testing it using a desktop, the layouts were
not perfect when viewed on a mobile phone. So we added responsive features to few element to ensure
that the most important fields are shown properly.

For example, on the detail screen we had a table with 5 columns. When using a mobile device in portrait
mode, the table becomes responsive and shows only those columns which are important. You can
reference how to add table popins from SAP Help

Other Tips and Lessons Learned

Consider disabling calls which are not required to improve performance. This may include calls in
both the frontend Gateway OData Services and in the backend business logic called by the OData
Services. For example, if you are hiding the icon tab Processing logs, it’s very easy to hide the control.
But most of us forget to disable the calls related to the Processing logs tab. Remembering to comment
out or skip unneeded calls improves the performance of the app significantly.

Understand your stakeholders. It’s easy to scuttle a project – especially a proof of concept – by
having the wrong conversation with the right people.

 End users don’t need proof of how much you have done to take it from standard inbox to
extension – that just makes it look hard. The conversation with end users should be about
whether it fits the need.
 Business stakeholders need to understand how the solution delivers on the promise of
business outcomes – such as numbers of clicks saved and reduced training needs.
 IT stakeholders needs to know what’s involved in the technical architecture and how to
support it.
If we had our time over … what would we do
differently
Number one priority is: More time with more end users. We would love to have explored ways to
make the accounting objects more comfortable for casual users in particular. This is something we
added into planning for the next stage.

Add metrics to measure UX success. Its easy enough to gather statistics such as the number of
button clicks before/after, but we would have liked to quantify these similar to how this is done in
the UX Value Calculator.

Better prototyping tools definitely. Doing it in PPT was workable but rather tedious. We would
have loved to use BUILD if we had had access to it at the time. If you are keen to know more about
BUILD, you can find it at https://experiencesplash.com . There are also blogs on SCN such as How to
build a UI5 prototype with BUILD and publish to SAP WebIDE and on the SAP UX Design site
at https://experience.sap.com/tag/build/

Rethink the Gateway Service Design. If there’s one area where we think the Extensibility
Cookbook could be improved, it’s in a more scalable Gateway Service Design. Some of the latest
information coming out with respect to Smart Templates and Annotations would have been very
helpful. The way we did it worked… but if you had a lot more tasks to implement a better Gateway
Service Design would be beneficial in scaling the solution to even more tasks.
And of course now Fiori My Inbox 2.0 is here SAP Fiori My Inbox 2.0 : Features… we would love to
have added that functionality as well …

Ah well.. you always have to leave something to look forward to.

We hope we have inspired you to give it a go and wish you all the best for your Fiori My Inbox
project!