Were the Fiori wave 1 apps really designed to be Extended? Here’s what I think…

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” 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:

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!