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 SAPUI5 and Fiori - Week 1 to find out about the scope of the project.
When I last checked in with you, our team had had a successful demo with the project sponsor, and were about to begin developing a gateway service to pull data through from the client’s backend systems. So what’s happened in week 4?
Gateway services and ABAP are pretty new to everyone on the grad team. ABAP formed part of the graduate training but we haven’t touched it since. As such, we were expecting week 4 to be a bit of an uphill struggle.
Because of the complexity of our app and the nature of the data that the app will display, we needed some pretty complex ABAP to do the job. This meant we needed a lot of input from Lindsay to guide us through every step of the way. After all, although this is a graduate project, with the purpose of giving us the chance to learn, it’s also a client-facing project, and we have a timeline to stick to and an end product to deliver. Lindsay’s input meant that we could strike the right balance between learning as much as possible, and keeping the project on-track.
At the same time, we also had some issues to fix on the frontend: namely, the issue of navigating between a split-app and a full-screen app. Additionally, we wanted to revisit the code that we’d written for the UI. It needed tidying up, partly because we’d been pushed for time to complete the demo, and partly because we had a mixture of code we’d written and code we’d used from the SAPUI5 SDK. As such, the formatting needed re-work so the code would be easier to read.
It was essential that the code was left in such a state that the next person who comes along to use it can easily pick it up, understand it and edit it as and when they need to. This meant we had to spend time fixing our code to make it easier to deal with. This best way to do this was essentially to start all over again, using just the parts of code that we knew we needed, and nothing more. This left us with something clean, efficient and easy to read.
As I mentioned in last week’s post, we agreed with the project sponsor to demo the app again, incorporating the changes we’d made and using more representative sample data. This demo took place on Tuesday and also included four people from the client who hadn’t seen anything of the app previously.
Previously, we’d worked almost exclusively with the project sponsor and the in-house project manager. This meant that we had a great understanding of what these individuals wanted the app to be. We hoped that the new people would be on the same page.
One the one hand it was good to get a fresh perspective and new insight into the way that the app could and should work. On the other hand, it was pretty late in the game to be demoing to four new people: at this point, we’d hoped that there would be minimal changes to the app, and we’d be able to move along smoothly into the next stage of development. Capturing all these new requirements and ideas with just two weeks to go put a lot of pressure on us, and gave us very little time to deliver. That’s not to say that we received negative feedback. On the contrary, everyone seemed to think that what we’d built was great: they just had a lot of new ideas for us, and we had to be selective about what we agreed to deliver.
By Thursday afternoon, the frontend was ready and the gateway system was almost complete. As such, our next step was to start data binding: making the frontend communicate with the gateway system we’d built, and assigning the individual pieces of data to the right elements on the app. Again, this was something completely new to each of the grads, and it’s something that even Lindsay confessed to finding difficult.
This is partly because UI5 is still in its infancy, and changes a lot. The documented methods of executing data binding vary greatly, as newer versions of UI5 are rolled out and different development environments become available. We spent a full day researching and trying out different methods of data binding, but nothing we tried seemed to work.
On this front, development ground to a bit of a halt, and we realised we needed to reach out to others in the Bluefin community for help. However, by this point it was Friday, and a bit late in the day for reaching out for help. Additionally, we knew that in week 5 we’d have another Bluefin consultant on- site with us, who is familiar with data binding, so we decided to continue to try our hand at data binding until he could give us some guidance.
All systems down (?)
As I mentioned last week, we also had the issue of the systems going offline for an intensive data cleansing exercise. We met with key figures in IT who will be managing the systems during this time, and thankfully, they were very accommodating. They agreed to give us access to the systems for the entire week, as long as we can prove that our project won’t impact upon their data cleansing mission.
This was great news for us! We were worried that we’d lose a whole week due to the systems being offline, but as we still have access to the systems, development can continue as planned and we should be on track. Success!
Overall, where were we by the end of week 4?
It was a bit of a tough one that posed a number of problems: meeting new people and getting their opinions on the app; starting to write the gateway system with limited understanding of ABAP; trying to execute data binding with almost no idea how to go about it. However, we also learned a huge amount, both about how to make an app work from the backend, and about managing a client relationship. Hopefully, we can transfer this learning into next week, which will no doubt come with its own challenges.