Category: SAP

  • SAP Fiori Launchpad Tiles Setup

    Introduction

    SAP Fiori Launchpad is one stop to access all the SAP Fiori Applications. To make your Fiori Application visible on SAP Fiori Launchpad, you need to do Tiles setup. You need to create a tile and a catalogue and configure both of them with your application. In upcoming section we will teach you to do so step by step.

    Steps to do SAP Fiori Launchpad Tiles Setup

    1. Go to Given transaction in your backend system to open Fiori Launchpad: /n/ui2/flp – fiori launchpad. To Open Designer Link: /n/ui2/flpd_cust – designer. It will open a link on your browser. [Raise, if you don’t have]
    2. Go to settings and select customizing TR. Tiles settings
    3. Go to Catalogs, Click the button below:
      tiles tr addition
    • Enter Name [App Name]
    • ID [ZC_*].
    1. Click on tiles, Create tile -> Click on Static Tile
      SAP Fiori Launchpad Tiles Setup
    • Enter Title [App Name], Semantic Object [no special/ space character ( . and _ allowed) à Unique Name], Action[manage] and click on Save
    1. Click on Target Mapping à Create Target Mapping
      1. Enter Same Semantic Object, Action and Title
      2. Application Type à SAPUI5 FIORI APP
      3. ID à Component ID [ID in Manifest.json]
    2. Click Group, create group the way catalogue was created
      1. Name à same as catalogue / App Name/ etc [Visible on FLP]
      2. ID à ZG_*
    3. Click on + button, Give your catalogue name, your tiles under that catalogue will be visible.
    4. Click on + button under that tile, to add it in the group.
  • SAP MTA based UI5 Application

    Preface – This post is part of the SAP Multi-Target Application (MTA)  and UI5 Integration Programs  series.

    Under UI5 App, we will be developing an MVC based app and will be calling the Node.js API, that we have just created. In this way we will be developing SAP MTA based UI5 Application.

    UI5 App Structure

    As it can be seen below, under our App folder Multichain_logon, we have many files and folders. In this section for  SAP MTA based UI5 Application, we will be mainly focusing upon Main.view.xml, Main.controller.js and model.js.

    SAP MTA based UI5 Application 01

    MODEL.JS

    Under this file, we have made a global model which will be used to call the Node.js API, as shown below:

    sap.ui.define([
      "sap/ui/model/json/JSONModel",
      "sap/ui/Device"
    ], function (JSONModel, Device) {
      "use strict";
    
      return {
        createDeviceModel: function () {
          var oModel = new JSONModel(Device);
          oModel.setDefaultBindingMode("OneWay");
          return oModel;
        },
        //UI5 Configuration model
        createAppConfigModel: function () {
          var appData = {
            "protocol": "https://",
            "apiUrl": "9t8mhv7z1qbwm2yjchain-logon-xs-js.cfapps.sap.hana.ondemand.com"
          };
          var oModel = new JSONModel(appData);
          return oModel;
        }
      };
    });
    

     

    To make this model global, we need to set it in the component.js file. Add given code under
    init: function () for the same:

    //set the app Config model
    this.setModel(models.createAppConfigModel(), "AppConfig");
    

    MAIN.VIEW.XML

    This is a sample project for which we have made a logon system. It takes Username, Password and UTC timestamp and saves it in the Multichain with a Multichain Timestamp. The updated data is then shown as a table under the logon controls. The xml view code is mentioned below:

    <mvc:View controllerName="Multichain_logon.Multichain_logon.controller.Main" xmlns:mvc="sap.ui.core.mvc" displayBlock="true" xmlns="sap.m">
      <Shell id="shell">
      <App id="app">
      <pages>
      <Page id="page" title="{i18n>title}">
      <content>
      <HBox>
      <VBox>
      <Text text="Enter your ID"/>
      <Input id="IdUsername" width="50%"/>
      <Text text="Enter your Password"/>
      <Input id="IdPassword" type="Password" width="50%"/>
      <HBox>
      <Button class="sapUiTinyMarginEnd" text="Create Account" enabled="false" press="onCreate"/>
      <Button class="sapUiTinyMarginEnd" text="Logon" press="onLogon"/>
      <Button class="sapUiTinyMarginEnd" text="Delete Logon" enabled="false" press="onDelete"/>
      <Button text="Check History" press="onHistory"/>
      </HBox>
      </VBox>
      <VBox>
      <Text text="Change the API Source Here"/>
      <RadioButtonGroup valueState="Warning">
      <buttons>
      <RadioButton id="RB4-1" text="OData Service Gateway"/>
      <RadioButton id="RB4-2" text="MTA"/>
      <RadioButton id="RB4-3" text="Cloud Foundry"/>
      </buttons>
      </RadioButtonGroup>
      </VBox>
      </HBox>
    
      <!--Table to show Block History-->
      <Table id="idTable" items="{loginData>/results}">
      <headerToolbar>
      <Toolbar>
      <content>
      <Title text="Proof of History" level="H2"/>
      <ToolbarSpacer/>
      </content>
      </Toolbar>
      </headerToolbar>
      <columns>
      <Column width="12em">
      <Text text="User ID"/>
      </Column>
      <Column width="12em">
      <Text text="Password"/>
      </Column>
      <Column width="12em">
      <Text text="Login Timestamp"/>
      </Column>
      <Column width="12em">
      <Text text="Multichain Timestamp"/>
      </Column>
      </columns>
      <items>
      <ColumnListItem>
      <cells>
      <Text text="{loginData>USERNAME}"/>
      <Text text="{loginData>PASSWORD}"/>
      <Text text="{loginData>TIMESTAMP}"/>
      <Text text="{loginData>BLOCKTIME}"/>
      </cells>
      </ColumnListItem>
      </items>
      </Table>
      </content>
      </Page>
      </pages>
      </App>
      </Shell>
    </mvc:View>
    

    MAIN.CONTROLLER.JS

    The view that we have defined earlier will use the given controller.js to implement the Node.js API calls

    sap.ui.define([
      "sap/ui/core/mvc/Controller"
    ], function (Controller) {
      "use strict";
    
      return Controller.extend("Multichain_logon.Multichain_logon.controller.Main", {
        onInit: function () {
          this.onHistory();
    
        },
        onHistory: function () {
          var that = this;
          var oModelAppConfig = that.getOwnerComponent().getModel("AppConfig");
          var sHTTPS = oModelAppConfig.getProperty("/protocol");
          var uri = oModelAppConfig.getProperty("/apiUrl");
          var sUrl = sHTTPS + uri + "/GET_PROOF_HISTORY";
          var settings = {
            "async": true,
            "crossDomain": true,
            "url": sUrl,
            "method": "GET",
            "headers": {
              "cache-control": "no-cache",
              "Access-Control-Allow-Origin": "*",
              "Access-Control-Allow-Headers": "*"
            }
          };
    
    $.ajax(settings).done(function (response) {
    // that.getView().byId("idOutput").setText(response);
    var results = [];
    response = JSON.parse(response);
    response.updates.forEach(function (temp) {
    if (temp.update.USERNAME !== undefined && temp.update.USERNAME !== "") {
    results.push({
    "USERNAME": temp.update.USERNAME,
    "PASSWORD": temp.update.PASSWORD,
    "TIMESTAMP": temp.update.TIMESTAMP,
    "BLOCKTIME": temp.timestamp
    });
    }
    });
    var jsonModel = new sap.ui.model.json.JSONModel({
    results: results
    });
    that.getView().byId("idTable").setModel(jsonModel, "loginData");
    sap.m.MessageBox.success("Login Proof Loaded Successfully!");
    });
    },
    onLogon: function () {
    var that = this;
    var USERNAME = this.getView().byId("IdUsername").getValue();
    var PASSWORD = this.getView().byId("IdPassword").getValue();
    var TIMESTAMP = Date.now();
    var oModelAppConfig = that.getOwnerComponent().getModel("AppConfig");
    var sHTTPS = oModelAppConfig.getProperty("/protocol");
    var uri = oModelAppConfig.getProperty("/apiUrl");
    var sUrl = sHTTPS + uri + "/UPDATE_OBJECT_HISTORY?USERNAME=" + USERNAME + "&PASSWORD=" + PASSWORD + "&TIMESTAMP=" + TIMESTAMP;
    $.ajax({
    "async": true,
    "crossDomain": true,
    "url": sUrl,
    "method": "GET",
    "headers": {
    "cache-control": "no-cache",
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Headers": "*"
    },
    success: function (oResp) {
    sap.m.MessageBox.success("Block Updated Successfully!");
    },
    error: function (oError) {
    sap.m.MessageBox.error("Block Updated Failed!");
    }
    });
    }
    });
    });
    

    UI5 App Output Screen

    As discussed above, the given screen will be the final screen of our UI5 App. As of now, only two buttons are enabled and they are used either to update the block (Logon Button) or to get the proof of history (Check History Button). Also, the sources shown here are only for illustrative purpose and only MTA calls are implemented in the given scenario.

    SAP MTA based UI5 Application 02

  • SAP Node.js Development in MTA

    Preface – This post is part of the SAP Multi-Target Application (MTA)  series.

    Introduction

    To ease the problem of developers, SAP has provided MTA services where we directly call any API under node.js file and this node.js is then utilized by UI5 App as an API. Hence, we neither need any destination setup nor crucial APIs are getting exposed. Thus SAP Node.js Development in MTA is a very important concept.

    SAP Node.js App Structure

    As it can be seen below, under our App folder xs.js we have many files and folders. In this section we will be mainly focusing upon package.json, config.json and server.js.

    PACKAGE.JSON

    This is a file, where we define all the packages/libraries that will be used by our Node.js App. You can find some of them will be already defined/provided by SAP. You need to just add the one that you will be using with its version, as shown below:

    {
      "dependencies": {
        "@sap/xsenv": "^1.2.9",
        "@sap/xsjs": "^4.0.1",
        "express": "~4.15",
        "passport": "~0.3.2",
        "@sap/xssec": "^2.1.11",
        "node-sap-logging": "0.3.0",
        "sap-hdbext-promisfied": "1.0.0"
      },
      "description": "my description",
      "devDependencies": {
        "@sap/xsjs-test": "^3.0.2"
      },
      "files": [],
      "main": "server.js",
      "name": "xs.js",
      "scripts": {
        "start": "node server.js",
        "test": "node testrun.js"
      },
      "engines": {
        "node": "8.x"
      },
      "version": "1.0.0"
    }
    

    CONFIG.JSON

    This is a local JSON file created to store all the calling APIs details. These details are the APIs provided by Blockchain Application Enablement Service.

    {

    “tokenUrl”: “YOUR_TOKEN_URL”,

    “blockServUrl”: “YOUR_BLOCKCHAIN_URL”,

    “authorization”: “Basic YOUR_UNIQUE_API_KEY”

    }

    SERVER.JS

    Under this file we will be writing all the Node.js codes, as shown below [just an example]:

    /*eslint no-console: 0, no-unused-vars: 0*/		
    "use strict";
    var https = require("https");
    var request = require("@sap/xsjs/node_modules/request");
    var xsjs = require("@sap/xsjs");
    var xsenv = require("@sap/xsenv");
    var port = process.env.PORT || 3000;
    var express = require("express");
    var globalBody;
    var app = express();
    var configData = require("./config.json");
    var options, data, token;
    
    // setting Response
    app.set('json spaces', 1400);
    app.use(function (req, res, next) {
      res.setHeader("Access-Control-Allow-Origin", "*");
      res.setHeader("Access-Control-Allow-Credentials", "true");
      res.setHeader("Access-Control-Allow-Methods", "GET,HEAD,OPTIONS,POST,PUT");
      res.setHeader("Access-Control-Allow-Headers",
        "Access-Control-Allow-Headers, Origin,Accept, X-Requested-With, Content-Type, Access-Control-Request-Method, Access-Control-Request-Headers, access-control-allow-origin, cache-control"
      );
      next();
    });
    
    // configure token
    var headeroptions = {
      method: 'GET',
      url: configData.tokenUrl,
      qs: {
        grant_type: 'client_credentials'
      },
      headers: {
        'cache-control': 'no-cache',
        Authorization: configData.authorization
      }
    };
    
    // get proof history
    request(headeroptions, function (error, response, body) {
      if (error) throw new Error(error);
      data = JSON.parse(body);
      token = data.access_token;
    
    var proofoptions = {
        method: 'GET',
        url: configData.blockServUrl + '/logon',
        headers: {
          'cache-control': 'no-cache',
          'Content-Type': 'application/json',
          Accept: 'application/json',
          Authorization: 'Bearer ' + token
        }
      };
      request(proofoptions, function (error, response, body) {
        if (error) throw new Error(error);
        console.log(body);
        globalBody = body;
      });
    
    });
    
    // update proof history
    app.get('/UPDATE_OBJECT_HISTORY', function (req, res, next) {
      var uname = req.query.USERNAME;
      var pass = req.query.PASSWORD;
      var dats = req.query.TIMESTAMP;
      // Get Token
      var tokenoptions = {
        method: 'GET',
        url: configData.tokenUrl,
        qs: {
          grant_type: 'client_credentials'
        },
        headers: {
          'cache-control': 'no-cache',
          Authorization: configData.authorization
        }
      };
        request(tokenoptions, function (error, response, body) {
          if (error) throw new Error(error);
          data = JSON.parse(body);
          token = data.access_token;
        var	dataoptions = {
            method: 'PATCH',
            url: configData.blockServUrl + '/logon',
            headers: {
              'cache-control': 'no-cache',
              'Content-Type': 'application/json',
              Accept: 'application/json',
              Authorization: 'Bearer ' + token
            },
            body: {
              USERNAME: uname,
              PASSWORD: pass,
              TIMESTAMP: dats
            },
            json: true
          };
    
          request(dataoptions, function (error, response, body) {
            if (error) throw new Error(error);
              res.json(globalBody);
          });
      });
    });
    
    // send proof history as response
    app.get('/GET_PROOF_HISTORY', function (req, res, next) {
      res.json(globalBody);
    });
    
    options = {
      anonymous: true, // remove to authenticate calls
      auditLog: {
        logToConsole: true
      }, // change to auditlog service for productive scenarios
    };
    
    // configure token HANA
    try {
      options = Object.assign(options, xsenv.getServices({
        hana: {
          tag: "hana"
        }
      }));
    } catch (err) {
      console.log("[WARN]", err.message);
    }
    
    // configure UAA
    try {
      options = Object.assign(options, xsenv.getServices({
        uaa: {
          tag: "xsuaa"
        }
      }));
    

     

    Once, we are done with the Node.js development we need to run our file, then only we will be able to access it. For that we will run it as shown below:

    Node.js Development in SAP MTA

    Once, we will run it, we will get an API in node.js console and the same will be utilized in the UI5 App.

  • SAP Web IDE Setup for MTA

    Preface – This post is part of the SAP Multi-Target Application (MTA)  series.

    To setup MTA, we will initially need access of SAP Web IDE. Once you have access of the SAP Web IDE, follow the given steps to configure an MTA application:

    Step 01: Open your web IDE and right click on your workspace and click Project from Template under New as shown below:

    MTA Setup step 01

    Step 02: Choose category as All categories, environment as Cloud Foundry and search Multi-Target Application as shown below:

    MTA Setup step 02

    Step 03: Select Multi-Target Application and click Next. Give a project name and its description in upcoming screens and also check mark “Use HTML5 Application Repository” as shown below and click Finish:

    MTA Setup step 03

    This project will be empty as of now with only one .yaml file.

    Step 04: For our UI5 App, we will need an HTML5 Module. Right click on your project and select HTML5 Module under New, as shown below:

    MTA Setup step 04

    Select Category as SAP Fiori Application and search UI5. Select SAPUI5 Application as shown below:

    MTA Setup step 05

    Later, give a Module Name and Namespace for UI5 application. Then proceed to further screens and finish. It will add a HTML module under your MTA application. In our case, we have kept both names same as shown below:

    MTA Setup step 06

    Step 05: For our Node.js App, we will need a Node.js Module. Right click on your project and select Node.js Module under New, as shown below:

    MTA Setup step 07

    Give a module name (xs.js, in our case), a description, and check mark “Enable XSJS support” as shown below, and click finish:

    MTA Setup step 08

    Step 06: Now, we are ready to push our App to Cloud Foundry so that the API that we are going to make is always up and accessible worldwide. For this, we will change the Project Settings so that our project points to the correct cloud foundry settings.

    Right click on your project and click Project Settings under Project as shown below:

    MTA Setup step 09

    Here, you need to click on Cloud Foundry under Project section and just select the available API Endpoint. It will bring all other data as shown below [This will be prefilled unlike the image shown below]:

    MTA Setup step 10

    Now, we are ready to deploy/build our project. For that just click Build as shown below, it will take care of everything by itself.

    MTA Setup step 11

    That’s it. Now, we are ready to work on our coding part of the API.

  • What is SAP MTA: Multi-Target Application

    Preface – This post is part of the SAP Multi-Target Application (MTA)  series.

    Introduction

    A Multi-Target Application (SAP MTA) is a package comprised of multiple libraries, application and resource modules. These have been created using different technologies and deployed to different runtimes but have a common life-cycle. You can bundle different modules together, describe them along with their inter-dependencies to other modules, services, and interfaces, and package them in an Multi-Target Application(MTA) . Please read MTA Documentation by SAP for more info.

    A Multi-Target Application can have both UI5 and other open source app implementation. We can deploy Java, Node.js and all other SAP cloud platform services.

    SAP MTA Architecture

    MTA Architecture
    MTA Architecture

    It is clear from the architecture flow diagram above that using our UI5 App, we will be calling a Node.js API which in return will be calling a Blockchain Application Enablement Service. This Enablement Service will help us to communicate with the Multichain environment. Both this UI5 App and Node.js files will co-exist under MTA Application that we will discuss in upcoming sections.

    Prerequisites and Restrictions

    We need to consider the following limits for the SAP MTA deployment on SAP Cloud Foundry deploy service:

    • Maximum size of the MTA archive: 4 GB
    • Maximum size of MTA module content: 4 GB
    • Maximum size of MTA resource content: 1 GB
    • Maximum size of MTA descriptors (mtad.yaml and MANIFEST.MF): 1 MB

    References

    To learn more about SAP MTA, we recommend to go through following SAP official documentations:

    Topic References
    Multi-Target Application development descriptor Inside an MTA Descriptor
    How to deploy the Multi-Target Application Cloud Foundry Command Line Interface
    Multi-Target Application deployment descriptor Defining MTA Deployment Descriptors for Cloud Foundry
    Multi-Target Application archive Defining Multi-Target Application Archives
    Multi-Target Application extension descriptor Defining MTA Extension Descriptors
    Multi-Target Application module types and parameters MTA Module Types, Resource Types, and Parameters for Applications in the Cloud Foundry Environment
    How to deploy the Multi-Target Application Cloud Foundry Command Line Interface
  • Relational Distributed Database and Blockchain

    Preface – This post is part of the Blockchain Basics series.

    Distributed Database

    A Relational Distributed Database is a database management system which utilizes the Primary Key(PK) and Foreign Key(FK) relationship. Almost every ERP solutions use Relational database. In simple context, this database divides all data based on relations among them. For example, data of employee can be saved into three tables i.e. Employee Details table, Employee Address table and Employee Salary table where each table has Employee ID as a common key.

    Blockchain Ledger

    A Blockchain can be defined as a decentralized database, or simply a decentralized linked list, where list of records (called blocks) are linked via cryptography. By decentralized, we intend that there is no single database where all records are saved rather the same set of data is saved in numerous databases. A block in a Blockchain contains catalogue of records (known as transaction data), a timestamp (i.e. UNIX time) and a cryptographic hash of previous block (hash converts the previous block data into a fixed length of random characters).

    Difference between Distributed database and Blockchain

    Both the database systems mentioned above carry their own advantages and disadvantages. Let us have a look on the basic differences between these database systems:

    Relational Distributed Database Blockchain Ledger
    Controlled by an Admin No Admin, everyone shares same data
    Access limited to view data Anyone can access (public) Blockchain
    Access limited to write data Anyone with right consensus can write
    Relational Databases are fast Blockchain, due to verification process, are slow
    No history trace of edited data unless log table is maintained History of data is maintained via hashing
    High performance & confidentiality High provenance and immutability

    Comparison between Database & Blockchain

  • What is a Database

    Preface – This post is part of the Blockchain Basics series.

    Introduction

    A database (DB) is an organized collection of information, just like a notebook, where you can read, write, update and delete data. It is one of the essential tools of all the organizations using computer technology. A database is also known as ledger. A ledger in accounting stands for a principal book where transactions are saved by date. In digital format these books take form of excel or DB. Going on further, wherever we discuss about ledger, it will stand for database.

    Types of Database

    There are different types of DB which are categorized based on their data saving format and structure. In this section we will discuss following two databases relevant to this paper:

    • Relational Database
      A Relational Database is database management system which utilizes the Primary Key(PK) and Foreign Key(FK) relationship. Almost every ERP solutions use Relational DB. In simple context, this ledger divides all data based on relations among them. For example, data of employee can be saved into three tables i.e. Employee Details table, Employee Address table and Employee Salary table where each table has Employee ID as a common key. The relationship among these tables can be seen below:
      A Relational Database
    • Blockchain
      A Blockchain can be defined as a decentralized database, or simply a decentralized linked list, where list of records (called blocks) are linked via cryptography. By decentralized, we intend that there is no single ledger where all records are saved rather the same set of data is saved in numerous databases. A block in a Blockchain contains catalogue of records (known as transaction data), a timestamp (i.e. UNIX time) and a cryptographic hash of previous block (hash converts the previous block data into a fixed length of random characters). This process of saving blocks is illustrated below (You can make your own blocks here):

      A Blockchain Database
      A Blockchain
  • What is Web Dynpro in SAP ABAP

    Preface – This post is part of the SAP ABAP Web Dynpro series.

    Introduction

    Web Dynpro in SAP ABAP is a standard technology which is used to create web-based applications using ABAP programing language. Web Dynpro includes many graphical development tools which are included in ABAP workbench. Because of the use of a graphical tool, it seems to be more user-friendly.

    Definition and Creation

    Definition

    Web Dynpro applications are built using declarative programming techniques based on the MVC (Model View Controller) architecture. For developing the Web Dynpro entities, the Object navigator (TCODE SE80) is used.

    Creation: Basic steps are:

    Goto SE80 Tcode -> Repository Browser -> Create web Dynpro component -> In the component, the Main view will be created, in that view insert elements as per the requirement. Here we have created just the page header. There are various elements that can be created, for example, dropdown elements, rows, columns, etc.

    After the creation, the whole web Dynpro component needs to saved and activated.

    Creation of Web Dynpro in SAP ABAP

    Steps for all the creations steps are shown below in the picture:

    Step 01:

    web dynpro Object Navigator

    Step 02:

    Create web dynpro App

    Step 03:

    web dynpro Connectivity browser

     

    Step 04:

    web dynpro in SE80

     

    Step 05:

    web dynpro layout

    Step 06:

    web dynpro root

    Step 07:

    web dynpro Insert Element

     

    Step 08:

    web dynpro Create Element

    Step 09:

    web dynpro properties

     

    Step 10:

    web dynpro explorer

    Step 11:

    web dynpro Application

     

    After the creation of the Web Dynpro application, right click on the application and test it. The auto generated URL will open in the internet explorer.

    NOTE: In case the URL is not working then the connection can be checked in SICF Tcode, whether the connection is active in that particular system or not. (By default it is automatically activated in the system).

    Path: SICF (TCODE) -> default_host  -> sap -> public -> bc -> web dynpro

     

    Architecture

    As stated earlier Web Dynpro in SAP ABAP applications are built on the MVC architecture. So now we will explain the MVC design in Web Dynpro.

    1.Model: Model basically means the part which contains data, that means all the business logic will be implemented in the model part only. So in simple word we can say the model is a section which will provide the data.

    2.View: View is the part where the user will be able to see the data.

    3.Controller: The data that is processed in the model, needs to be displayed in the view. But to control the flow between model and view we need this part called a controller.

    Pre-requisites to learn Web Dynpro in SAP ABAP

    1. Core ABAP Programming: Core ABAP programming is prerequisites because as stated earlier in the architecture section the logic for providing data will be written in the model. So the for that ABAP programming skill is required. If one is aware of the ABAP skill then it will be very easy to implement any business logic as per the requirement.

     

    1. Object-Oriented Programming: Oops knowledge is definitely beneficial in web dynpro applications because the as we are talking about the model and controllers these are all nothing but the classes which we implement by creating the objects for it.

     

    1. MVC Architecture: As discussed in the previous section, it is important to know the MVC design pattern to understand the web dynpro application for ABAP. Because the whole point of the application is to model the data and display it to the user which is happening with this design.

    Benefits of Web Dynpro 

    1. There are many benefits of using Web Dynpro as like:
    2. Due to the uses of graphical tools in Web Dynpro , implementation of coding part is reduced.
    3. Use of MVC design ensures the separation of layout and business data.
    4. There is a feature of data binding for the elements created in the view of Web Dynpro, due to which it enables the direct transport of data.
    5. It can run on number of platforms.
  • SAP ABAP Unit Testing Class

    Preface – This post is part of the Object Oriented ABAP series.

    Introduction

    ABAP unit testing is a methodology for software development. Whenever we create a class, it is mandatory to create its test class to check the behavior of our code if it is working exactly as it was expected.  While developing any object, it helps the developer to cover all possible scenarios. With ABAP unit test class, we can also check the coverage of code lines.

    Definition

    ABAP unit test class provides a methodology to test the individual source of code to determine if they are fit to use.

    The global class CL_UNIT_ASSERT contains a method that can be used for testing, the following are the most common methods:

    1. ASSERT_EQUALS – Checks the equality of two data objects.
    2. ASSERT_DIFFERS – Checks for the difference between two data objects.
    3. ASSERT_BOUND – Checks for the validity of the reference of a reference variable.
    4. ASSERT_INITIAL – Checks whether the reference of a reference variable is invalid.
    5. ASSERT_NOT_INITIAL – Checks whether the data object is not having its initial value.
    6. ASSERT_SUBRC – Checks for the specific value of SY-SUBRC.

    Program

    Below is a method ‘GET_ORDER_DATA’ of class ‘ZCL_PROD_ORD_TEST ‘  to fetch the operation details from the production order.

    Note: Local Test Class will get generated automatically through test class generation wizard.

    Method get_order_data

    Figure 1: Method get_order_data

    OSQL test double Framework : To remove the dependency from database tables.

    Unit Test Class

    Figure 2 : Unit Test Class

    Mocking virtual database tables to test the behavior of code.

    Unit Testing of Method GET_ORDER_DATA

    Figure 3: Unit Testing of Method GET_ORDER_DATA

    Advantages

    1. ABAP Unit provides excellent support for test-driven development in ABAP.
    2. You can run tests quickly and easily right from the development environment.
    3. You can navigate back and forth between a test class and the production code.
    4. With ABAP Unit test class, there is no such dependency on availability on test data to test the functionality.
    5. Fewer bugs reported with ABAP unit testing and less time wasted.
  • SAP MM Tables

    Preface – This post is part of the SAP MM series.

    Introduction

    In this section we have discussed SAP MM Tables. We have provided the table name with its description as well as its explanation. Feel free to ask the name of the SAP MM tables that we have missed in the comment section.

    Material master:

    MARA- Material Master: General data

    It is a standard SAP table which is used to store general material data information.

    MAKT- Material Master: Description

    It is a standard SAP table which is used to store material descriptions information.

    MARM- Material Master: Unit of Measure

    It is a standard SAP table which is used to store units of measure for material information.

    MARC- Material master: Plant data

    It is a standard SAP table which is used to store plant data for material information.

    MARD- Material master: Storage location

    It is a standard SAP table which is used to store storage location data for material information.

    MAST- Material link to BOM

    It is a standard SAP table which is used to store material to BOM link information.

    MBEW- Material valuation

    It is a standard SAP table which is used to store material valuation information.

    It will show the stock as on current date. And not period wise details of stock is available.

    MBEWH- Material Valuation: History

    It table is updated whenever there is change in Moving Average Price.

    It is basically the History table for MBEW – Material Valuation table.

    MLGN- Material Master: WM Inventory

    It is a standard SAP table which is used to store Material Data for Each Warehouse Number information.

    MLGT- Material Master: WM Inventory type

    It is a standard SAP table which is used to store Material Data for Each Storage Type information.

    MVKE- Material Master: Sales <Sales Org, Distr Ch>

    It is a standard SAP table which is used to store Sales Data for Material information.

     

    MLAN- Material Master: Tax indicator

    It is a standard SAP table which is used to store Tax Classification for Material information.

    MAPR- Material Master: Forecast

    It is a standard SAP table which is used to store Material Index for Forecast information.

     

    Vendor master:

    LFA1- Vendor Master: General data

    It is a standard SAP table which is used to store Vendor Master (General Section) information.

    LFB1- Vendor Master: Company data

    It is a standard SAP table which is used to store Vendor Master (Company Code) information.

    LFM1- Vendor Master: Purchasing Data (Purchasing organization)

    It is a standard SAP table which is used to store Vendor master record for purchasing organization.

    LFM2- Vendor Master: Purchasing Data (Plant, Vendor subrange)

    It is a standard SAP table which is used to store purchasing data for vendor master record.

     

     

    Purchasing:

    EBAN   Purchase requisition: items

    It is a standard SAP table which is used to store Purchase Requisition information.

    EBKN   Purchase Requisition: account assignment

    EBKN is a standard SAP table which is used to store Purchase Requisition Account Assignment information.

    EKKO   Purchasing document header

    EKKO is an SAP table used to store Purchasing Document Header information.

    EKPO   Purchasing Document: Item

    It is a standard SAP table which is used to store Purchasing Document Item information.

    EKET    Purchasing Document: Delivery Schedules

    It is a standard SAP table which is used to store Scheduling Agreement Schedule Lines information.

    EKKN- Account assignment in purchasing document

    It is a standard SAP table which is used to store Account Assignment in Purchasing Document information.

    EORD- Purchasing Source List

    It is a standard SAP table which is used to store Purchasing Source List information.

    EIPA- Order price history record

    It is a standard SAP table which is used to store Order Price History information.

    EKAB- Release documentation

    It is a standard SAP table which is used to store Release Documentation information.

    EKBE- Purchasing document history

    It is a standard SAP table which is used to store History per Purchasing Document information.

    EKBZ- Purchasing document history: delivery costs

    It is a standard SAP table which is used to store history of delivery costs information per purchasing document.

    EINA- Purchase Info Record: General

    It is a standard SAP table which is used to store purchasing info record for general data information.

    EINE- Purchasing info record: purchasing organization data

    It is a standard SAP table which is used to store purchasing info record for purchasing organization.

     

     

    Inventory Management:

    ISEG- Physical inventory document items

    It is a standard SAP table which is used to store Physical Inventory Document Items information.

    MKPF- Material document: Header

    It is a standard SAP table which is used to store Header: Material Document information.

    MSEG- Material document: item

    It is a standard SAP table which is used to store Document Segment: Material information.

    RKPF- Reservation: Header

    It is a standard SAP table which is used to store Document Header: Reservation information.

    RESB- Reservation: Item

    It is a standard SAP table which is used to store Reservation/dependent requirements information.

     

    Invoice Verification:

    MYMFT- FIFO results table

    It is a standard SAP Table which is used to store FIFO Results Table information.

    MYMP1- Receipt data LIFO/FIFO valuation

    It is a standard SAP Table which is used to store Receipt Data LFIO/FIFO Valuation information.

    RBCO- Document item, incoming invoice account assignment

    It is a standard SAP Table which is used to store Document Item, Incoming Invoice, Account Assignment information.

    RBDIFFKO- Invoice Verification: conditions

    It is a standard SAP Table which is used to store Invoice Verification – Conditions information.

    RBDIFFME- Invoice Verification: quantity differences

    It is a standard SAP Table which is used to store Batch Invoice Verification – Quantity Differences information.

    RBDRSEG- Invoice Verification batch: invoice document items

    It is a standard SAP Table which is used to store Batch Invoice Verification: Invoice Document Items information.

    RBKP- Document header: incoming invoice

    It is a standard SAP Table used to store Document Header: Invoice Receipt information.

    RBTX- Taxes: incoming invoice

    It is an SAP Table used to store Taxes: Incoming Invoice information.

    RBVD- Invoice document: summarization data

    It is a standard SAP Table which is used to store Invoice Document – Aggregation Data information.

    RBVDMAT- Invoice Verification: summarization data, material

    RKWA- Consignment withdrawals

    It is a standard SAP Table used to store Consignment Withdrawals information.

    RSEG- Document item, incoming invoice

    It is a standard SAP Table which is used to store Document Item: Incoming Invoice information.