I’ve been spending some time recently looking into extending the Fiori apps for Travel Expense Approvals and Purchase Order Approvals.

I’ve been refering to this document http://help.sap.com/saphelp_fiori/fiori10_extend_en.pdf, which seem to be (correct me if I’m wrong) the latest/only documentation which explains how to extend the standard Fiori apps and the Gateway service behind them.

However, at almost every turn I have hit problems. The examples outlined in the documnetation are all for the leave request apps. For which all of the example (obviously) work fine – and make it look really easy – which I’m sure it is for this particular app.

Unfortunatly my requirement is to adapt/extend/customise Travel Expense Approvals and Purchase Order Approvals.. and this is not nearly so easy.

Redefine the Gateway Service

First I tried this with the Travel Expense Approvals app.

It all looked good to start with: the gateway service builder (SEGW) happily stated there were no errors found, when I performed a consistency check.

However when I geenrated the service I found that I got some warning messages in SEGW:

syntax error DPC.png

“Syntax error” as a warning seemed a little odd – as this is more than just a warning – this is a full blown problem!

On investigation I found the cause: the new service, which redefined the original service SRA008 inherited from the DPC of the standard Fiori service:

DPC inheritance error.png

But CL_SRA008_MGW_RT_TEA is FINAL, and therefore cannot be inherited from.

It is clear to me that this service was never designed/built to be inherited from… but this is the recomended way of extending the Fiori service. After a email to SAP we got the access key for this code, and changed the class to not be final.

After this I though “maybe it will work for PO Approvals”  – so off I went again, and started over with PO apporval service. Don’t get excited. It didn’t work. The issue this time was not that there was attempted inheritence from final classes – no, this time the inheritence was all fine and dandy!

But the issue lay in the service builder (SEGW) – consistency rules are broken in PO approval service. Which says to me that it clearly was NOT built using the service builder, which is fair enough as it was probably built before SEGW existed. However this means it was built a very long time ago… SAP have said that after SP05 you should always use the builder – but this Fiori app clearly didn’t (or I’m missing something..) as one of the properties/attributes of one of the entities has the same name as the entity it belong to – which the service buidler rejects and refuses to generate the code for.

Once I’d had a more detailed look at the PO Approvals service I found that it could be enhanced by the use of BAdIs in some places, but  ther BAdis weren’t always where you wanted them to be so I still had to find a work-around.

No matter, there was another option – back to the Travel Expenses App:

Include the standard service in a new Service

This sounded more hopeful, no inheritence needed, so no issues with the old service classes being marked as final.

So I tried this… And HURRAY – it worked great (for Travel Expense Approvals)! It generated and looked like it was working fine. I could make calls the ther service and it wasn’t erroring – great!

So I thought, let’s test this from the Firoi app – I downloaded the BPS for Trav Ex Apv, and uploaded it again, but changed the line in Descriptor.js to point to my new service .

I first checked the ORIGINAL fiori app – and great, for my userlogin I was getting back my travel expense approval, which was sitting in my inbox.

Now to test my new, supposedly identical copy…. but there was nothing… no approval, just a blank app.

Now as you might imagine I went through a list a mile long of things “I might have done wrong”.

To identify the issue I had set-up traces (/IWFND/TRACES), and seen that my Fiori app seemed to be reaching the backend – original – included service data provider class method. But was wasn’t it returning my approval?

The answer was this: The SY-UNAME was being changed!! I logged in with one username (the user who had approvals waiting in his inbox), but by the time the call has reached the appropriate method the username had changed to DDIC!! Why? I am willing to accept that this could be due to lack of experience on my part, that I didn’t see the coming – but if anyone can explain this to me I’d be very grateful!

So once again, the mechnism that was provided as a way to extend the apps didn’t work the way it should have!

I was at a loss…

The only way I can get it to work at the moment – the dreaded CODE COPY!

So what have a found that DOES work? You may well ask, and I’m less than happy with the answer I must give – but I hope to be able to carry on working on this and come up with a better solution than this: For Travel Expenses (as the classes are FINAL)

  • By-pass the service builder (not recommended by SAP – why say after SP05 you should use the service builder, but seeing as Fiori wasn’t built using it, why should I use it)
  • Copy to DPC and make my changes in there (yes – I said copy! If I can’t inherit from it what are my other choices?!)

For PO Approvals (as the service builder cannot be used)

  • By-pass the service builder again – it can’t be used with the way that the entities were set up
  • Create new MPC and DPC classes and inherit the orginials

Ok, so this will work. But what happens when SAP release updates for TEA? My gateway service will be a copy, with no reference back – so won’t benefit from any improvements.

Also, the fact that both the apps have to be enhanced differently is rather unfortunate: rather than using one standard way I have to use two – ok so I could do the Copy mechanism for both – but I don’t like that I have to do this at all.

Anyway, these are my thoughts.

I’d be really interested to hear what anyone else thinks, and anything from anyone involved in the development of these apps, just to know how they inteded for the Gateway Service to be extended.

As for the front end… well that’s for another blog and another time! I’ve been trying to enchance it and at the moment am having caching/buffering issue which mean I can’t see my changes – but that is another story!

Please comment, and share you opinions – and feel free to tear this appart and tell me I’m wrong πŸ™‚ What doesn’t kill me only makes me stronger!

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Erich Schulzke


      You are correct, there are a couple of apps which are not built with segw.

      – ERP MM services for Approve Purchase Orders, Requistions, and Contracts

      – SRM service for Shopping Cart Approval.

      Especially those have extensibility BAdI’s in place, which allow for straightforward and easy field extensibility – without the need of segw.

      The how-to is described in the link provided by Masayuki.

      The documentation on the BAdI’s is available here:

      http://help.sap.com -> SAP Business Suite -> SAP Fiori -> Installation, Upgrade,Deployment -> Installation Guide.

      Regarding the classes of TEA marked as final – I consider this as a bug. I forwarded this info to the responsible dev team.

      Thank you for your thorough analysis,


  1. Lindsay Stanger Post author

    Thanks to everyone for their comments/input.

    Shortly after I posted this my colleage Ron Sargeant  taught me about Enhancing code – this looks like a preferable way to maybe make the enhancments I need – so I will be looking into this – rather than copying, which I simply can’t bring myself to do as it break all the links!

    Thanks for all your input everyone – if anyone come up with anything more consistent over all apps please let me know πŸ™‚


  2. Mark Teichmann

    Thank you very much for this detailed blog. It is very valuable to get a hint of the problems in the real world that happen in this area.

    The Howto Guide from Masayuki Sekihara seems like a good answer to many questions.

    I heard also from other sources that the first wave of Fiori apps seem to be released to the customer a bit early without a ramp-up phase. The whole Fiori / SAPUI5 thing is evolving quite fast. Therefore the first adopters will surely suffer quite a lot. Let us hope that the next wave will have a more solid design and also an improved documentation.

    Compared to Dynpro development I think I still prefer Fiori with all of its Kinderkrankheiten.

    1. Clement Selvaraj

      se80 works for applications that have enabled extensibility thru BAdI provisioning like the PO Approval app explained in Masa’s how to document

      segw was a tool that was pretty new while fiori wave 1 was being developed. Hence many apps did not use the segw tool.

      segw in general should work for all apps if they have entities bound to DDICs containing extension includes. And most importantly, if the MPC and DPC classes are not final. They are not marked final if the apps had used the segw tool and I agree that these need to be fixed.

  3. Lindsay Stanger Post author

    Hi all,

    For those of you reading this now, I’d like to make some alterations (if I may!)

    I wrote this at the start of a new project in which we (my colleaguse and I) we’re set the challenge of extending two of the standard Fiori applications. At this time I was supprised and (as you may have niticed) somewhat frustrated with what faced me.

    But now I can make a comment with the benefit of hindsight!

    I have a few points:

    • The apps are all faily new, and bug fixes and new releases are being released all the time – they’ve come a long way since I wrote this blog even, so I think it was unfair to criticise so early on in the process
    • The documentation for extending the services is growing as we speak! and there are new tools available too
      • SAP Fiori Toolkit – I’ve not had a change to play with this yet, but it sounds great!
      • Extensibility guide – in fact I’d never really used help.sap.com before, but there is a wealth of information available there if you know where to look!
    • We did it! We managed successfully to extend two fiori apps to include a history tab, filters, and custom fields! So it was by no means impossible.

    This is just a brief explanation of where I am now – I will be writing a follow-up blog to this one… watch this space.

    And thank you to those at SAP for taking on board what I have said!

    Best Wishes,


    1. Mark Teichmann

      Hi Lindsay,

      I read recently that the Wave I Fiori apps will be raised to the new design (and be available then as Version X01) so that they are designed in the same way as the new ones.

      Did you change the first version apps or did you upgrade to the X01 versions?

      What happens if you change the Wave I apps and later try to upgrade to version X01?

  4. Sergio Ferrari

    Thank you for the post Lindsay.

    It’s nice and you have got interesting comments too.

    You’ve reported about Gateway but what about the SAPUI5 part? Is it well structured and well commented?

    I have the feeling it could also be a side that can be improved to simplify the life to the “enhancers”, and you?


    1. Lindsay Stanger Post author

      Hi Sergio,

      Since writing this blog I have not had some experience in enhancing the UI side of the apps too. This was in some resepcts easier, but again had it’s difficulties.

      In order to edit the UI you first download the code and set it up in your local enviornment (a bit of a fiddle but I have a colleage who knows what he’s doing to help set all this up).

      The Purchase Order Approvals application is much more complicated than the travel expense approvals app to enhance, as it is much more complicated to understand. It is clear that PO Approvals was written with the intention that other apps could be built using the fundamental structure, and therefore it is much more complicated that simply code which created the UI. But once you’ve found the bit you need to change (i.e. add in a field, change the UI) it’s not too tricky. It’s finding the correct section of code that can be difficult! Also with POs the controllers for the various views have a debug version and a minified version – so you have to make changes in both of these places. Also with the underlying structure of the app, if you want to make changed to this you have debug js files, minified versions of the same files, then a library debug file and a minified library debig file: all of which will need updating. This means when you make a change in one of the debug files and run the app with the suffix “sap-ui-debug=true” you will see the changes, but when you run it wihtout that suffix you need to make sure you have copied your changes accross.. it’s tricky to dexcibe, but that’s because it was quite tricky to get my head around! But I think I’ve got to grips with it now! It would be good, however, if SAP could provide the tool they used to create all the sub-documents – so when you make a change to a debug js file, you can then run a script which updates all the other dependent files.. but maybe they are taking out this functionality, so it’s not a big issue πŸ™‚

      As for Travel Expense approvals UI it is much more simple. Although it countains much of the skeleton structure of POs, it doesn’t seem to use it, so it is fundamentally more simple, with much mroe straighforward views, and controllers. Finding where to make changes is much easier, and you only need to make them in one place (unlike POs) for it to work.

      My questions is that with the changes we made to these two apps, there would be noway of applying an upgrade to them now – other than my hand. The only way to upgrade that I can see would be to apply the upgrades to the original UI BSP application on SAP, download it, and compare it to the enchanced app, and then copy accross the changes. Because in order to make changes to the UI you need to directly modify views/controllers, and there were no extension points. However this being said, I believe this is eomthing that will exist in future apps based on this reference https://sapui5.netweaver.ondemand.com/sdk/#docs/guide/Customization.html

      Anyway, thank you for your question, I hope this answers it a bit. It’s all just experience really, getting used to the apps! And from what I can tell they are still changing quite a bit.



      1. Sergio Ferrari

        Thanks Lindsay,

        I’m with you about the minified version of the JavaScript files. I’m still wondering about the best practice to create the minified versions and keep updated with the debug ones.

        I can be wrong, I think SAP Fiori Toolkit will address those topics but I believe it requires XML views and is targeting wave 2.


        1. Lindsay Stanger Post author

          Ah yes, I haven’t had a chance to use the SAP Fiori Toolket yet, but it sounds great!

          On a slight tangent: I really much prefer the XML views to the standard HTML ones – it’s so much easier to write and undertstand! I’m looking forward to getting my hands on wave 2 already!


        1. Lindsay Stanger Post author

          Hi Clement, I was extending wave 1 apps, so I understand that with wave 2 came some significant improvements, and in future apps there will be extension points built in, which will make upgrading much easier πŸ™‚ Unfortunatly we were working with Fiori before wave two,, but I’m very excited to have a go with the wave two apps to see how they all work! Lindsay


Leave a Reply