Tutorial: Build Your Own SAP Fiori Approve Purchase Order App – Part 6
This is the sixth part of a tutorial series about how to build your own SAP Fiori Approve Purchase Order app.
The purpose of this tutorial is to show you step-by-step how to build your own SAP Fiori Approve Purchase Orders app and provides additional insights into why certain aspects have been developed as they are.
Please see the introductory post (Tutorial: Build Your Own SAP Fiori Approve Purchase Order App) for background information regarding this tutorial.
Previously posted chapters can be find here:
In this chapter, we set up the app using the SAP Web IDE and ran the app using mock data.
In this chapter, we adapted the list screen of the app.
In this chapter, we adapted the detail screen of the app.
In this chapter, we enabled approve and reject buttons.
In this sixth part, we’re going to set up a new model that stores the global app state.
Set up a new model that stores the global app state
With the approval functionality, our application needs to handle different states. For example, once we call the business logic in the backend, we need to ensure that the purchase order instance is locked to prevent the user from clicking the approve button again. If the user uses swipe to quickly approve a purchase order, we don’t want the list to be blocked. So we need to find a place to store this state information that can be accessed within our controller logic and can be easily consumed in XML views via data binding. There are already two models defined in model/model.js to store global information. We’ll use the same mechanics for our new model to discuss what the template wizard already did for us and to get a consistent model usage within our app. So let’s define our new model in model/model.js too.
File: model/model.js
createFLPModel: function() {
[…]
} ,
createGlobalModel: function() {
var oModel = new JSONModel({
isBusyApproving: false,
isSwipeRunning: false,
preferredIds: [],
currentPOId: null
});
return oModel;
}
The model contains three properties. isBusyApproving stores the information as to whether the purchase order currently displayed in the detail view is waiting for the business logic to finish.
isSwipeRunning indicates that a service call triggered via swipe is pending for return.
preferredIds will be used later in this document. It’s used to calculate a list of purchase orders after the current purchase order is removed from the list.
CurrentPOId stores the ID of the purchase order in the detail screen. This is not essentially necessary since we could recalculate this ID, but it’s simpler to store the ID in a model for later use.
Next, we need to create the model. For the device and FLP model, this is done in the Component.js code. This was generated for us by the template wizard, and we’ll use the same mechanic for our model.
File: Component.js
init: function () {
// set the device model
this.setModel(models.createDeviceModel(), “device”);
// set the FLP model
this.setModel(models.createFLPModel(), “FLP”);
// set the global Model
this.setModel(models.createGlobalModel(), “globalProperties”);
The new model is now available via the name globalProperties.
I hope the sixth part of the tutorial has sparked your interest in the chapters to come. Next time, we’ll encapsulate approve / reject service calls.