msg.Fix My Problem - Presentation Page

Application Requirements

The purpose of this app is to provide the means both for reporters (MSG Employees) and processors (MSG Employees) to describe and resolve problems that concern both MSG household and any administrative problems, for instance requesting an employee attestation.

Any employee that used this application will be assigned one of the following, 4 roles:     
- Reporter: a person that requests a solution to a problem.     

- Processor: a person in charge of providing solution to tickets. Any processor is also a Reporter.      

- Manager: is in charge mainly to organize requests. It does not provide solutions.   

- Admin: in charge of configuring and maintaining the app. It has no abilities to process or change content. Creates categories for instance, gives rights, sets configurations regarding attachments etc.

S/4HANA Architecture

* Source: SAP

The msg.FMP was created using a set of new S/4HANA technologies.

The first layer (the virtual data model) is designed using CDS views. They are useful for read access, such that they are created for each database table that we hold. The main advantage is that, data models are consumed on the database, rather than on the application server.

They are followed by BOPF (Business Object Processing Framework), which is used for CUD operations (Create, Update, Delete). It is very useful, because it requires less implementation efforts, they are highly customizable and they can be reused throughout the application. The Business Objects are created automatically on top of CDS views, using @Annotations.

Having created all that, the data needs to be exposed to the frontend and for that OData Services come into play. Using CDS Views and @Annotations, OData services are generated automatically, and in some cases, it was required that new OData Services (with referenced Data Source) were generated where there were specific requirement which could not be covered by a generated OData service.

Challenging Topics

Attachment Handling

One of the most difficult assignments was the handling of the media files, from upload until download. A custom solution had to be designed, because @Annotation services do not support this type of entities and all generated services cannot be redefined given their final status. For this purpose, a service was developed, referencing an existing CDS view, association, between the Ticket entity and the Attachment entity. This two have a one to many relationship, meaning that each ticket can have one or more attachments, while an attachment can only belong to a ticket.

The main purpose of the service was to be able to define the attachment entity as a Media type, which holds the properties of a stream.

Those properties are Value - a BASE64 string that represents the entire content of the file that is uploaded, and also Mimetype, which is an attribute that contains the necessary information to interpret the BASE64 string, such as PDF, Word, PNG, JPEG and so on.

Other than that, all the CRUD operations had to be also manually coded, which is similar to the already generated services from the @Annotation, with a small difference, being the handling of the stream attributes and ensure that upload and mainly the download of the file work smoothly.

For the subtopic of download, the best way was to design the solution to provide the possibility that at the end of the service link, the parameter ‘/$value’ can to be provided. When called in such a way, the entity is downloaded in any browser, because the BASE64 string is interpreted using the mimetype associated with it. Once downloaded, the user will be able to preview or open the downloaded entity.

If it is not used, the service will only return the raw string (picture below) and additional interpretation would be needed from the frontend perspective

Duplicate Tickets

In order to have a better classification of the existent tickets, a functionality for grouping them as duplicates has been developed. Its importance comes from the need, in the case of some general problem, where many similar tickets might be created and they need to be set as fixed all at once, and they require the same solution.

The solution for grouping them, comes to the making of a complete graph, where for example two tickets that are duplicate, see each other as its duplicate. When extending the graph, the same happens for 3 or more tickets, where one will see the others that are its duplicates, and the others will see him.

The implementation of the graph has to be adjusted to the architecture of the S/4HANA, where a simple insert into a database, even though it will work, it won’t be the correct solution.

In order to respect the S/4HANA programming model, we need to build each graph entry using “Create”, from the BOPF methods that will build us the Business Object keys required for the correct read from the framework. Not using it, each entry will return us a temporary key, that won’t be able to cope with future inserts  in the database and that will offer us a lot of “Duplicate key” database errors that will require further changes to the first ”old-school”  implementation.

The Duplicate Tickets functionality, will allow us some further improvements, such as Mass Assignment, where logically similar tickets, can be easily assigned to a single Processor for solving them, saving a lot of effort and ensuring a better completion rate.

UI

For UI development, SAPUI5 was used.

SAPUI5 is a client UI technology based on JavaScript, CSS and HTML5.

No need to worry about device specifics - SAPUI5 applications run on smartphones, tablets, and desktops. The UI controls automatically adapt themselves to each device`s capabilities.

* Source: SAP

Start Page

From this page, the user can choose what to do next: create a new ticket, show my/all tickets or navigate to one of the user tickets.

UI Elements:

     • TileContainer     
     • List

Create Ticket

From this page user can create a new ticket. User will be required to fill the following fields: Title, Category and Priority. After all fields are filled the user must press the save button in order to create the ticket.   The following fields are automatically filled after the creation: Status (“New”), Processor, Last Changed By, Last Updated, Creation Date and Due Date.

UI Elements:

     • ObjectPageSection      
     • OverflowToolbar      
     • SimpleForm -> Select, Input, MultiInput (Token), DatePicker

My Tickets

The user will see a list of tickets created by himself or tickets that were assigned to him.

He can search based on Category, Title/Description, and Tags.

Sorting/Filtering will be done based on Title, Status, Processor, Priority, Due Date, and Changed By/On.

UI Elements:

     • Table 
     • Toolbar -> SegmentedButton, Switch, MultiInput, SearchField

All Tickets

On this page will be displayed all tickets which have been created.

He can search based on Category, Title/Description, and Tags.

Sorting/Filtering will be done based on Title, Status, Processor, Priority, Due Date, and Changed By/On.

Display a ticket

In this page user can view/edit information about a ticket that was created by himself or assigned to him. User can upload attachments, link to another ticket (duplicate) or add a comment.

UI Elements:
     • ObjectPageSection -> SimpleForm
     • Timeline (for comments)
     • UploadCollection (for attachments)

Use cases

Create ticket

Step 1: Go to create ticket tab.

Step 2: Enter title, select category, priority, due date, and add tags. Show the changes that happen in the header, while filling the fields.

Step 3: Save ticket.

Step 4: Show ticket on at least one of the tickets tabs for a reporter.

Adding an attachment

Step 1: Select ticket.

Step 2: Enter edit.

Step 3: Go to attachment tab.

Step 4: Add attachment from computer.

Step 5: Save Attachment.

Step 6: Visualize how attachment looks in ticket.

Step 7: Download and view attachment.

Adding a duplicate

Step 1: Select ticket.

Step 2: Enter edit.

Step 3: Go to duplicate tab.

Step 4: Add a duplicate from ticket list.

Step 5: Save duplicate.

Step 6: Visualize how duplicate looks in ticket.

Step 7: Go to duplicate ticket and visualize how duplicate tab looks there, as it should also hold a duplicate to the ticket that we used earlier.

Conclusions

The new S/4HANA programming model is a simplified and mainly standardized model that will ensure that development of future apps and projects runs more smoothly. Compared to the old ABAP programming model, using S/4HANA programming model will help us develop more efficient apps, both from a financial and a performance perspective.

Each S/4HANA application can be easily enhanced with more features, even at the bottom level of adding more nodes to the existing Business Object model. All this advantages make S/4HANA the way to go when deciding how to implement desired solutions.

In the end, it is worth mentioning that the msg.Fix My Problem (msg.FMP) application integrates successfully this new programming model, and using the SAPUI5 as its frontend, can highlight how future apps will look and work like in the SAP environment.