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:
- Here's the standard Fiori My Inbox functionality and where we can extend it
- Here's an example of a tailored screen for approving shopping carts
- Let's talk about how we merge these together
- Let's talk about what you would need to see for approving journals
- 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. We 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. :smile:
We hope we have inspired you to give it a go and wish you all the best for your Fiori My Inbox project!
- SAP Managed Tags:
30 Comments
