Project Neon: Reporting with SAPUI5 and Fiori – Week 3

7 November 2014

Abi Ainscough

Abi Ainscough

Consultant

Following an intensive six week graduate training programme, myself and two other colleagues have been placed at a client who provides facilities management services on a massive scale.

We’re building on the work of DJ Adams and Lindsay Stanger, who’ve built a tool which allows users to input data onto timesheets, and then to process these timesheets so that employees get paid as accurately and efficiently as possible. You can read Project neon: Reporting with SAP UI5 and Fiori - Week 1 to find out about the scope of the project.

At the end of my last blog post, we were battling with the SAP Web IDE in order to build a fully-navigable app for a demonstration to the project sponsor by the following Wednesday. Did we make it?

Development

By Monday, although both the Web IDE and UI5 were becoming more familiar to us, we were still learning a lot about them as the day progressed, so development was still not moving quite as fast as we would have liked. This meant that a relatively late night on Monday in order to tick off everything on our to-do list: specifically, we were working on the tiles that we wanted to use on the home screen. We needed seven different, individual tiles that each provided a link to a new page of the app, and we wanted them to be different sizes, and to contain different visualisations. This proved quite difficult. Finally, we made it work, and left the office feeling relieved and confident that we’d have a successful day on Tuesday.

Tuesday was spent setting up the navigation. We wanted to be able to navigate between a master-detail view and a full screen view and this has to be ready for the demo the following day. The bulk of it was completed, with only minor changes to make the following morning.

Demo day

On Wednesday morning, we arrived at the office knowing that we still had a few changes to implement prior to the demo. Thankfully, most of these were superficial, and very few of them required us to go deep under the bonnet of the app to tinker with the machinery. This meant that we actually had the app ready for the demo in good time, with plenty of time to prep for the meeting and add any last-minute finishing touches.

Finally, the demo came around. The purpose of the demo was to show the project sponsor how the app will work when it’s finished, and to stimulate further discussion about potential functionality. We projected the app up onto the big screen and walked the project sponsor through each page, justifying the choices we’d made about formatting and functionality. The client liked it. In fact, the client loved it. We made it clear that, at this stage, the app was in its infancy and could be torn to pieces if so required, but in fact, the client requested very few changes. What’s more, the changes and requests that were made were almost entirely superficial: a few extra columns needed to be added to our tables, for example. The project sponsor was excited about what we delivered and gave us some great feedback, and we were proud that all our hard work had paid off.

The client requested that we demo the revised app next Tuesday with real data pulled in from the backend, but pulling through data to an app is a massive and complex task, especially if you’ve never done it before. As a result, we managed expectations by agreeing that we would instead demonstrate the changes we’d made to the app with some representative data hard-coded into it.

Back to development

Moving forwards, then, we had two main targets. Our immediate target was to implement the changes to the UI that the client had requested, in order to demo these changes next Tuesday. However, as set out in our project timeline, we also needed to start looking into the backend systems and developing a gateway service that would pull out the data we needed. This meant we established two work streams which ran simultaneously on Thursday and Friday. We also had Lindsay on-site with us, and she is a self-confessed ABAP devotee, so she taught us a lot and set us off on the right path.

Moving forward

Once again, we face a number of challenges moving forward. Completing the UI of the app shouldn’t be too much of a challenge, as by now we’re familiar with the development environment and UI5 itself. However, when it comes to developing a gateway service and coding in ABAP, we’re right back at square one, as it’s something we’ve never done before. Luckily, we’ve got Lindsay on-site with us at least three days a week most weeks, so she can provide us with some guidance as and when we need it.

However, our major issue presented itself in a conversation with Lindsay on Wednesday. We had planned that week five of our project would be spent on setting up and testing connections between the app and the backend systems. Unfortunately, during week five, the systems that we would be using to develop and test are being cleansed: they’ll be offline for pretty much the entire week, and anything that we’ve built within them will be wiped. As of yet, it’s unclear how we’re going to work around this situation and mitigate its impact, but it’s certainly an interesting challenge to have to deal with, so  stick around to find out what happens!

View comments

Comments

Blog post currently doesn't have any comments.

Bluefin and SAP S/4HANA - welcome to the one horse race