Building a CRUD Application with SAPUI5 and ICF REST/JSON Service – Part 1

Introduction

If you, like me, don’t have a system with the UI Add-on and Netweaver Gateway but still wants to learn SAPUI5, you may find this blog series useful. This blog series explains how to create a simple CRUD application from scratch using SAPUI5 and an ICF Service based on REST and JSON.

 

Table of Contents

Part 1

Prerequisites

Overview

SAPLink Nuggets and Eclipse Project download

References

SAPUI5

SAPLink

SAPLink plugins (SCN Code Exchange)

CL_TREX_JSON_SERIALIZER bug fixes

Extending SAPUI5 JSON Model

Creating the ICF REST Service

Creating the custom handler class

Creating the ICF node

Retrieving the request method and the parameters passed in the URL

Part 2

Implementing the REST Service

Model and DDIC objects

Implementing the Create method (POST HTTP verb)

Implementing the Read method (HTTP GET verb)

Implementing the Update method (PUT HTTP verb)

Implementing the Delete method (DELETE HTTP verb)

Part 3

Creating the User Interface

Creating the project

Setting up the SAPUI5 bootstrap and required libraries

Creating the view components

Creating the BSPs to deploy the application and the SAPUI5 framework.

Implementing the Controller’s methods

Create

Read

Update

Delete

Find

Prerequisites

• You have installed the SAPUI5 Application Development Tool into your Eclipse
• UI Development Toolkit for HTML5 Version SAPUI5 1.8.4
• SAP NetWeaver ABAP 7.01 Stack Level 7 (oldest version where i’ve tested the application) or later
• SAPLink
• Copy of the class CL_TREX_JSON_SERIALIZER with the necessary bug fixes

Overview

This document shows how to create a simple CRUD application using SAPUI5 and ICF REST/JSON service. The frontend applications will be developed using the SAPUI5 framework by using the SAPUI5 Application Development Tool (Eclipse-based tool). The communication will be based on a REST service built here from scratch in ABAP on top of the ICF (Internet Connection Framework). All responses will be JSON based.The application will maintain a simple contact list that will be persisted in a table with the following structure.

Field	Key	Data Element	Data Type	Length	Description
MANDT	X	MANDT	CLNT	3	Client
EMAIL	X	AD_SMTPADR	CHAR	241	E-Mail Address
FIRSTNAME		AD_NAMEFIR	CHAR	40	First name
LASTNAME		AD_NAMELAS	CHAR	40	Last name

SAPLink Nuggets and Eclipse Project download

All objects developed in the ABAP system except the BSPs are available here for download in a .nugg file. To import the objects into your system you need to have the SAPLink installed with the following plugins:

• DDIC
• SICF Nodes

The SAPUI5 eclipse project is available here for download.

References

SAPUI5

• http://scn.sap.com/community/developer-center/front-end
• Get to Know the UI Development Toolkit for HTML5 (aka SAPUI5)
• How to Build a SAP HTML5 Application Using MVC with the SAPUI5 Application Development Tool

SAPLink

http://code.google.com/p/saplink/

SAPLink plugins (SCN Code Exchange)

https://cw.sdn.sap.com/cw/groups/saplink-plugins

CL_TREX_JSON_SERIALIZER bug fixes

http://scn.sap.com/community/mobile/blog/2012/09/24/serialize-abap-data-into-json-format

Extending SAPUI5 JSON Model

http://scn.sap.com/community/developer-center/front-end/blog/2012/11/20/extending-sapui5-json-model

Creating the ICF REST Service

Creating the custom handler class

The first thing we have to do is to create a custom handler to enable us to handle the REST interface requests. The class must be created inheriting from the interface IF_HTTP_EXTENSION.

Go to SE24 and inform the class name ZCL_SCNBLOG2.

Fill in the description and hit the save button.

Now go to the Interface tab and inform the interface IF_HTTP_EXTENSION.

Now go to the methods tab and double click the method HANDLE_REQUEST.

For testing only, insert the code below in order to check if the service is working properly.  Don’t forget to save and activate it.

METHOD if_http_extension~handle_request.

  CALL METHOD server->response->set_cdata( data = ‘Service Ok!’ ).

ENDMETHOD.

Let’s create the ICF service now.

Creating the ICF node

Go to transaction SICF and hit the execute button.

Expand “default_host” and “sap” nodes. Right click the “bc” node and select the New Sub-Element option in the context menu.

Fill in the name of the service (zscnblog2).

Fill in the service description, select the Handler List tab and inform the class ZCL_SCNBLOG2, the custom handler class.

Save the changes, go back to the previous screen, scroll it down, select the service zscnblog2, right click it and select the Activate Service option in the context menu.

Now let’s test the service. Right click it and select the Test Service option in the context menu. If the SAP GUI Security popup appear select the option “Always allow”.

Your default browser will open requesting your SAP username and password. Be aware that you have to inform the credentials of the correct client. As a result you should see the text “Service Ok!” in your browser.

Retrieving the request method and the parameters passed in the URL

The first thing that the handle_request method must do is identify what is being requested. To do so, we need to retrieve two basic informations: the request method (HTTP verb) and  the parameters passed in the URL. The request method describes the action to be performed. The parameters passed in the URL have the information about the resource where the action should be performed.

METHOD if_http_extension~handle_request.

* Variables

  DATA: l_verb      TYPE string,

        l_path_info TYPE string,

        l_resource  TYPE string,

        l_param_1   TYPE string,

        l_param_2   TYPE string.

* Retrieving the request method (POST, GET, PUT, DELETE)

  l_verb = server->request->get_header_field( name = ‘~request_method’ ).

* Retrieving the parameters passed in the URL

  l_path_info = server->request->get_header_field( name = ‘~path_info’ ).

  SHIFT l_path_info LEFT BY 1 PLACES.

  SPLIT l_path_info AT ‘/’ INTO l_resource

                               l_param_1

                                l_param_2.

* Only methods GET, POST, PUT, DELETE are allowed

  IF ( l_verb NE ‘GET’ ) AND ( l_verb NE ‘POST’ ) AND

     ( l_verb NE ‘PUT’ ) AND ( l_verb NE ‘DELETE’ ).

    ” For any other method the service should return the error code 405

    CALL METHOD server->response->set_status( code = ‘405’

      reason = ‘Method not allowed’ ).

    CALL METHOD server->response->set_header_field( name = ‘Allow’

      value = ‘POST, GET, PUT, DELETE’ ).

    EXIT.

  ENDIF.

  CASE l_verb.

    WHEN ‘POST’.   ” C (Create)

     

      “TODO: call method CREATE of the model

     

    WHEN ‘GET’.    ” R (Read) 

     “TODO: call method GET of the model

     

    WHEN ‘PUT’.    ” U (Update)

     

      “TODO: call method UPDATE of the model

     

    WHEN ‘DELETE’. ” D (Delete)

      “TODO: call method DELETE of the model

     

  ENDCASE.

  “For testing only

  CALL METHOD server->response->set_cdata( data = l_verb ).

ENDMETHOD.

To test the service we need a REST client. Here we will use the chrome extension POSTMAN.

The service must accept GET, POST, PUT and DELETE and return the error code 405 for any other method. Let’s check it out.

Before executing our tests it is necessary to fill in the basic auth and refresh the headers.

GET

POST

PUT

DELETE

For any other HTTP verb the expected response is the return error code 405 with the message “Method Not Allowed”. Let’s try PATCH.

PATCH

In the Part 2 we will see the implementation of the Create, Read, Update, Delete methods.