Blog series overview
During this blog series I’ll walk you through creating a real transactional sales order Fiori app with draft handling using Fiori Elements and the new ABAP Progamming Model. The final result will be a working proof-of-concept, this will not be a finished product. (although with some additional work it could be)The end result can very easily be adapted to fit your own requirements. The principles explained throughout the blog series can be applied to other legacy objects as well.
What we’ll cover during these blog series:
- Identifying minimal set of fields required in the actual classic transaction
- Building the virtual data model using ABAP CDS
- Building the consumption layer using ABAP CDS and Metadata Extensions
- Exposing the consumption layer as an oData Service
- Generating a Fiori Elements App
- Adding custom determinations
- Implementing create, change and delete functionality
- Implementing durable locking
Prerequisites
To follow this guide you’ll need:- Access to a backend system
- A working Eclipse setup for ABAP Development
- Access to a trial (or productive) SAP Web IDE using a SAP Cloud Platform Account
- A working SAP Cloud Connector setup
- A destination configured to connect to your backend
Interesting documents
If you should run into issues during this blog series, be sure to check out following documents. These are the ones I used to prepare this proof-of-concept.- Official ABAP Programming Model documentation
- Transactional Apps with Draft Capabilities using standard tables (blog)
- Locking in S4HANA via the Durable Locks & CDS View ObjectModel.Lifecycle annotation
- Navigating the BOPF: Part 1 – Getting Started (blog)
- Navigating the BOPF: Part 2 – Business Object Overview (blog)
- Navigating the BOPF: Part 3 – Working with the BOPF API (blog)
- Navigating the BOPF: Part 4 – Advanced BOPF API Features (blog)
- Navigating the BOPF: Part 5 – Enhancement Techniques (blog)
- Navigating the BOPF: Part 6 – Testing & UI Integration (blog)
Identifying the minimal set of fields
To determine which fields we’ll use for our Sales Order App, we’ll go through the standard order creation transaction VA01. This example is based on a best practice system. Based on customizing in your system minimal fields for entering a sales order might differ from this example.In the first screen we can identify some important fields:
- Order type
- Sales organization
- Distribution channel
- Division
- Sales office (optional)
- Sales group (optional)
In the actual order entry screen we can identify following important header fields:
- Sold-to party
- Ship-to party
- Customer reference
- Net value
- Currency
- Item number
- Material
- Item description
- Order quantity
- Sales unit of measure
- Net value
- Currency
Throughout this blog series we’ll add some more informative fields like:
- Created by
- Created on
- Created at
- Changed on
Desired end result
Our final application will consist out of a list report / object page from which we’ll be able to:- Search for existing / draft Sales Orders
- Display, change and delete existing Sales Orders
- Create new Sales Orders
Detail screen for display, change and create functionality (object page layout):
Same detail screen in change / create mode (with draft handling):
Item detail screen:
Now that we’ve run through the minimal requirements and know how our app should look like, we can continue with the next part of this blog series and build the virtual data model.
Quick navigation
- Part 1: Overview
- Part 2: Virtual Data Model & Consumption views
- Part 3: Defining the UI & Creating the Fiori Elements App
- Part 4: Implementing locking & delete functionality
- Part 5: Adding determinations
- Part 6: Converting the draft instance into an active instance & wrap-up
Nenhum comentário:
Postar um comentário