SAP Community - OData

Using SAP Datasphere Consumption APIs in SAP Build - A 3-legged Authorization Flow Setup

2024-02-26T08:51:25.688000+01:00

One of the challenges of data-driven decision making is to present complex and diverse data in a way that is easy to access and understand to act upon. SAP Datasphere delivers seamless and scalable access to mission-critical business data from multiple sources, accessing this data everywhere has the power to ease decision making and speed up business processes. In this context, SAP Build plays vital role to accelerate the apps development and making data accessible on the go. In this blog post, you will learn how to create an SAP Build app that integrates with SAP Datasphere as a centralized data source. This is achieved through the use of SAP Datasphere Consumption oData APIs. SAP Build benefits from SAP Datasphere's authentication model using a centralized Identity Provider (IdP) to grant access to the app and its contents. The blog post will guide you through the following steps:

Understanding the authentication flow
Developing the BTP Authorization Backend
Creating OAuth Client & Destination
Modeling an SAP Datasphere view to be used on SAP Build
Configuring SAP Build Authentication
Setup SAP Build App Data Model

1. Understanding the authentication flow

The most complex and crucial step in integrating these two systems is the authentication process. SAP Datasphere Consumption APIs necessitate a three-legged OAuth2.0 flow with the "Authorization Code" grant type, which needs manual user interaction with the configured Identity Provider (IdP). For more information on the protocol, please refer to our reference page here.

However, SAP Build does not natively support this type of authentication, neither using SAP BTP authentication type. The solution for such problem can accomplished by starting the App login step in a browser based view (aka: WebView) in the App opening to the SAP Datasphere authorization URL. This will initiate communication with the configured IdP in your SAP Datasphere (such as SAP ID, Office 365, etc), displaying its login page. Upon successful provision of user credentials, the OAuth Client redirect URI will be invoked.

For the entire process to operate securely and correctly, the OAuth Client redirect URI must be configured for the backend application API. Within the scope of this blog post, a BTP application will be created for this specific purpose. This backend application will utilize the OAuth Client ID and secret to generate the SAP Datasphere access token, which will then be sent back to the SAP Build Application.

The image bellow illustrates this flow:

This authentication process is inspired on the one described in the SAP Build Samples GitHub. To avoid the Client ID and Secret to be stored on device the "Authorization Backend" was introduced, so sensitive information could be stored into the BTP Destination Service.

2. Developing the BTP Authorization Backend

The "Authorization Backend" was introduced to ensure sensitive information is securely stored on the server. This blog post will detail the deployment of a new BTP application in NodeJS as an example, but the same steps can be applied to any new or existing backend service running on BTP or in another cloud environment.

The application need to realize 3 main tasks:

Receive the redirect URI API call and extract the authorization code
Handle OAuth2.0 token request
Return the access token to the client

2.1. Receive the redirect URI API call and extract the authorization code

Receiving the Redirect URI call in the service requires exposing an unauthenticated route that matches the path used in the OAuth Client configuration (Step 3.1). In this example "/oauth/callback" (<callback-api-path>) will be used.

The authorization code, generated once the IdP login is successful, will be received as the "code" query parameter on the callback route, it will be used later for OAuth token request.

Redirect URL Example:

https://auth-backend.hana.ondemand.com/oauth/callback?code=lxuC1347ZLcNg3gjqFHKjAc6gT4iB0hp

NodeJS Code sample:
[File: index.js]

import express, { Request, Response } from "express";
const port = process.env.PORT || 3000;
const app = express();

app.get("/oauth/callback", async (req: Request, res: Response
  try {
    const code = req.query.code as string;
  } catch (e) {
    res.status(500).json(e.message);
  }
});

app.listen(port, () => {
console.log("Server listening on " + port);
});

2.2 Handle OAuth2.0 token request

After obtaining the authorization code, the next step in the OAuth protocol is requesting the access token. On this blog post the SAP BTP Destination Service will be used for storing the OAuth Client ID and Secret, as well as for requesting the access token. Some dependencies to this process such as BTP destination and Client ID and Secret will be explained and later created on section 3.

The process for requesting the access token uses the "Find Destination" API from SAP BTP Destination Service. It requires the authorization code received earlier, the destination name (set up as an environment variable), It is crucial that the BTP Application is linked with the destination service. Instructions for these steps are also detailed on the SAP Help pages [1][2][3], used as reference for this blog post.

The outcome of this request is the access and refresh tokens which will be used for authenticating all Consumption API request. The code snippet bellow shows how to configure such request in as part of the App created.

[File: destination-service.js]

import * as xsenv from "@sap/xsenv";
import axios from "axios";
export const findDestination = async (
  destinationName: string,
  code: string,
  redirectHost: string
) => {
  const credentials = xsenv.cfServiceCredentials({ tag: "dest
  const token = await getDestinationServiceToken();
  const response = await axios({
    method: "get",
    url:`${credentials.uri}/destination-configuration/v1/des
    headers: {
      Authorization: `Bearer ${token}`,
      "X-code": code,
      "X-redirect-uri": redirectHost,
    },
  });

  if (!response.data.authTokens || response.data.authTokens.l
    throw new Error(`Failed to fetch destination, ${response.
  }

  const tokenObject = response.data.authTokens[0];
  if (tokenObject.error) {
    throw new Error(`Failed to fetch destination, ${tokenObje
  } else if (tokenObject.expires_in !== "0") {
    delete tokenObject["http_header"];
    return tokenObject;
  }
  throw new Error(`Failed to fetch destination, invalid token
};

const getDestinationServiceToken = async () => {
  const credentials = xsenv.cfServiceCredentials({ tag: "dest
  const response = await axios({
    method: "post",
    url:`${credentials.url}/oauth/token`,
    headers: {
      Authorization: `Basic ${Buffer.from(`${credentials.clientid}:${credentials.clientsecret}`).toString("base64")}`,
      "Content-Type": "application/x-www-form-urlencoded",
  },
    data: {
      client_id: credentials.clientid,
      grant_type: "client_credentials",
    },
  });

  if (response.status !== 200) {
    throw new Error(`Failed to fetch destination service access token, ${req});
  }

  return response.data.access_token;
};

2.3. Return the access token to the client

The last responsibility of the backend application is to return the token back to the client (SAP Build App), which started the authentication flow, in a way it could read and use. In the context of SAP Build Apps which will be using a web browser for all authentication process a straightforward approach is for the server to redirect the request to another URL it has (/oauth/token) in this blog post and provide the access token as part of the query parameters (as implemented in this blog) or within the body.

Some adjustments are required in the index.js file for calling the methods created above

[File: index.js]

import express, { Request, Response } from "express";
const { findDestination } = require("./destination-service");
const port = process.env.PORT || 3000;
const app = express();

app.get("/oauth/callback", async (req: Request, res: Response
  try {
    const code = req.query.code;
    const destinationName = process.env.DESTINATION_NAME;
    const redirectUri = `https://${req.hostname}/oauth/callba
    const datasphereToken = await findDestination(destinationName,code,redirectUri);
    res.redirect(`/oauth/token?access_token=${datasphereToken.value}`);
  } catch (e) {
    res.status(500).json(e.message);
  }
});

app.get("/token", async function (req, res) {
  res.status(200).send();
});

This is an example of how a BTP backend application can be developed to serve as authentication middleware between SAP build, functioning as a client, and the destination service in BTP. The only step missing is to deploy the application to BTP and use it - follow BTP guidance on how to deploy an application.

For the next step we will need some information created on this section save for later:

Host of your BTP application - referenced as <backend-app-host>
Callback API Path - referenced as <callback-api-path>

3. Creating OAuth Client & Destination

The first thing to be realized for allowing integration with SAP Datasphere Consumption APIs involves creating an OAuth Client within the SAP Datasphere. This action generates the "ClientID" and "Client Secret" necessary for subsequent steps.

3.1. Create an OAuth Client in SAP Datasphere

Go to your SAP Datasphre Administration page
Open “App Integration” tab
Create a New OAuth Client to be used later

Set the name of your OAuth Client
In Purpose field set “Interactive Usage”
In Redirect URI field set the URL of the callback API created on section 2, it should be <backend-app-host>/<callback-api-path>

For the next step we will need some information created on this section save for later:

Client ID - referenced as <client-id>
Client Secret - referenced as <client-secret>
SAP Datasphere Authorization URL - referenced as <datasphere-authorization-url>
SAP Datasphere Token URL - referenced as <datasphere-token-url>

3.2. Creating OAuth2AuthorizationCode Destination

The authentication method supported by SAP Datasphere Consumption APIs is the three-legged OAuth2.0 flow with "Authorization Code". However, this authentication method is not supported by BTP Destinations when created via the cockpit, as detailed on this SAP Help Page. In this case, the only viable creation method is through the SAP Destination Service API, as described here. In this blog post we will use a HTTP client (eg: Postman) the request should look like:

URL: https://<destination-service-url>/destination-configuration/v1/subaccountDestinations/
Method: POST
Headers:

Authentication: Bearer <token> - Follow steps here for generating authentication token
Content-Type: application/json

Body:

{
  "Name": "DWC_Sales_OrdersTypeCode",
  "Type": "HTTP", 
  "URL": "<your-datasphere-url>" //Doesn't matter in this case,
  "Authentication": "OAuth2AuthorizationCode",
  "ProxyType": "Internet",
  "tokenServiceURLType": "Dedicated",
  "HTML5.DynamicDestination": "true",
  "clientId": "<client-id>",
  "clientSecret": "<client-secret>",
  "AppgyverEnabled": "true",
  "tokenServiceURL": "<datasphere-token-url>",
  "WebIDEUsage": "true"
}

Note: <destination-service-url> can be found in the binding between any BTP App and the Destination Service in the BTP cockpit (some more details on this SAP Help Page)

4. Modeling an SAP Datasphere view to be used on SAP Build

Upon completing the pre-requirements setup in sections 2 and 3, focus can then be shifted to developing the SAP Datasphere view according to individual business needs. This blog post primarily addresses the integration between SAP Datasphere and SAP Build, hence this section will cover a basic setup of a view intended to be accessed by SAP Build.

The most crucial part of creating an app involves understanding the problem that needs solved, as this will drive how data, views and analytic models should be modeled on SAP Dataspehre. In the context of this blog, for example, the SAP Build app will expose a list of countries and the sales value of each of them, also allowing to drill down into each one to check details of the specific product sales in each country.

On this blog a simple view named "CountrySales" containing 2 measures and 3 attributes. The measures will aggregate the data allowing to extract value from it in later in the SAP Build App, the image bellow shows a bit more about the modeling of the view. Also, don't forget to mark your view as "Exposed for Consumption", as required by Consumption APIs and import data into your base local or remote tables, more details can be found here.

After deploying the view it becomes accessible through the Consumption OData APIs of SAP Datasphere. The a catalog request can be used check all available assets for consumption.

Asset Catalog request: https://<your-datasphere-url>/api/v1/dwc/catalog/assets

There are 2 ways of consuming the exposed view via relational or analytical type of consumption, in this blog post we will use the first one due to some limitations on SAP Build to handle analytical consumption type. An example of the consumption URL that will be used later on is defined bellow - it will be references as <country-sales-consumption-api>

https://<your-datasphere-host>/api/v1/dwc/consumption/<mySpace>/CountrySales/

For learning more about SAP Datasphere consumption APIs, checkout Mirko's blog post.

5. Configuring SAP Build Authentication

To start configuring the SAP Build App the first task to be executed is setting up the authentication and authorization using the Authorization Code flow within the App. To achieve this, we will create a page containing a webview component for an in-app browser experience. This webview will open the <datasphere-authorization-url> to start the authentication process explained on section 1. Once this flow concludes in the browser, we will add specific logic within SAP Build to capture the returned token and assign it to variables for later use.

5.1. Configuring the WebView component

Create a new SAP Build Page, lets call it "Datasphere Auth Page"
Set this page as the initial page of your application
Add a "WebView" component to the empty page just created:
1. Set the URL with pattern (replace parts in red) - in the example a SAP Build variable was used:
  <datasphere-authorization-url>/response_type=code&client_id=<client-id>
  - ```
  https:/your-dwc-tenant.authentication....sap/oauth/authorize?response_type=code&client_id=sb-5a0f6ce9-3ac2-4425-9d27-1d78ce6be785!b13811%7Cclient!b2319
```
- Note: In case you have a bad request error, replace the | (pipe) in the clientID by %7C
2. As outcome of this step when you open your app it should show up the login screen of the Identity Provider (IdP) linked with your SAP Datasphere application.

After the login on the IdP is performed a blank screen should be displayed, which is the redirect page developed on section 2.3.

5.2. Handling After Login action

The concept behind the after login logic is to detect when the page displayed on the webview matches the pattern of the redirect URL used on section 2.3, in this case “/oauth/token?access_token=*” . When this happens the access token can be extracted from the URL query parameter, stored into an App variable and the page redirected to the fist content page of the App.

For the logic setup, open the "Logic Canvas" of the "Webview" component and follow the steps, at the end it should look similar to the image:

Start with the event “Component onLocationChange”
Include some Javascript code to detect the URL pattern and extract the access token:

if(inputs.input1.url.includes('/oauth/token?access_token')){
  var code = inputs.input1.url.split('access_token=')[1].split('&')[0];
  return { code: code, codeAvailable: true } 
}else{
  return { codeAvailable: false, debug: JSON.stringify(inputs.input1) } 
}

Use an "IF" to check if the access token is available
1. In case it is available:
  1. Set it into an App variable – this will be referenced as <app-var-access-token>
  2. Change page to next one
  3. Dismiss the current authentication view
2. In case not available, rise an error

6. Setup SAP Build App Data Model

The last step to make the App usable is to create pages and make request to Datasphere Consumption APIs to fetch the data and make it available on the App screen.

6.1. Creating the Data Model

For that SAP Build data entities need to be configured for each of the assets of SAP Datasphere that will be required in the App. Once the data models are configured they can be easily bound to list, tables and charts on the App. The steps bellow explain how to configure a data model:

Open data tab on SAP Build
Create a data entity of type "OData Integration"
1. As Authorization chose "Bearer Token"
2. Generate an OAuth2.0 Bearer token using the information from SAP Datasphere – this is only required for SAP Build to fetch the model metadata.
3. Provide the Consumption URL of the SAP Datasphere view
4. Click verify URL and the metadata of the view should be available
5. Save the data model, it will be called "CountrySales"

6.2. Using the Data Model

To use the data models created a request for the records need to be added to the life cycle of a page and the authorization token of this request should be set correctly using the <app-var-access-token> as part of the headers.

The steps bellow explain how to create a page, configure the data model and use the filter or parameter capabilities of SAP Datasphere to search for specific data:

Create or use the page redirected after login
Go to the variables tab section
1. Create a Data Variable for storing the model data that will be fetched – lets call it <data-var-country-sales>
2. Create a page variable for storing the search text field value – lets call it <page-var-search>
On the page add some components:
1. Add a “Large Image List Item” component
  1. As “Repeat With” set <data-var-country-sales> variable
  2. As “Title Label” set “current.CountryName” , so the country name will appear as title of the list item
  3. As “Description T ext” set a formula with the following content (to format the monetary information)
    - ```
    "Amount: $" + FORMAT_LOCALIZED_DECIMAL(NUMBER(repeated.current.Weighted_Value), "en", 2)
```
4. As “Image Source” set the formula bellow just make the list a bit prettier (It will render country code as colored image:
  - ```
  "https://ui-avatars.com/api/?rounded=true&background=5F308E&&color=FFFFFF&size=64&name=" + ENCODE_FOR_URL(repeated.current.CountryCode)
```
2. Add a Spinner component to serve as busy indicator for the request

When the App components have been added in the place they belong on the screen. The missing part is to add behaviour and load data to each of them. First when the page loads the data from the Data Model created on the step before needs to be loaded, also some caveat needs to be added for showing a "spinner" during loading time. Follow the steps bellow for setting this.

Add an Event "Page Mounted"
Set an Page Variable <is_loading> to true
Link it to a "Get Record Collection" data block, with settings
1. As Resource Name: Use the "CountrySales" model created on step 6.1
2. As: Bearer token authentication: Use a custom object with, type "Bearer" and token the variable <app-var-access-token>, created on step 5.2.
Link it "Set Data Variable" block to store the request result into the <data-var-country-sales> variable
Link it to a "Set an Page Variable" setting <is_loading> to false, as loading is completed

This finishes the development of a simple SAP Build app fully integrated with SAP Datasphere via its Consumption APIs, a video of an extended version of the App is available bellow.

To conclude, this blog post serves as an exhaustive guide for the integration of an SAP Build app with SAP Datasphere, while also laying the foundational knowledge for applying these steps to integrate other products and clients that support OAuth authentication with Authorization Code grant type. The elaborate instructions encompass crucial processes such as understanding the authentication flow, making effective use of the Consumption oData APIs, shaping the BTP Authorization Backend, setting up secure authentication, creating an OAuth Client & Destination, and establishing the SAP Build App Data Model.

Converting SOAP API to REST API FOR POST METHOD

2024-03-06T15:15:06.197000+01:00

we have soap API in se37 FM - Z_VENDOR_GETDETAILS convert to REST API by Using ODATA.

Advantages :

Using REST endpoints offers simplicity and security.It simplifies API requests, making them quick and easy to manage.
Additionally, security benefits can be achieved through role access functions, allowing control over user access to specific services.

SE37 - SOAP API

Code snippet for SOAP API :

IF ip_lifnr IS NOT INITIAL AND ip_ebeln IS INITIAL.

    CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'
      EXPORTING
        input  = ip_lifnr
      IMPORTING
        output = ip_lifnr.

    SELECT * FROM ekko INTO TABLE et_po_hdr WHERE lifnr = ip_lifnr.
    IF et_po_hdr[] IS INITIAL.
      ep_msg = 'No purchase order found'.
    ENDIF.
  ELSEIF ip_lifnr IS NOT INITIAL AND ip_ebeln IS NOT INITIAL.
    SELECT *  FROM ekpo INTO  table et_po_item WHERE ebeln = ip_ebeln.
    IF et_po_item[] IS INITIAL.
      ep_msg  = 'No purchase order found'.
    ENDIF.
  ENDIF.

We have to import SOAP API by using RFC/BOR interface in SEGW

Once you defined the all entity types make sure that artifacts must be generated.

Once your entities methods are getting generated based on your entities inside DPC_EXT Class so just provide the implementation /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CREATE_DEEP_ENTITY (redefine) method to perform the operation.

We have to call our main entity set and call our own method to read the data.

Code snippet for create_deep_entity method.

METHOD /iwbep/if_mgw_appl_srv_runtime~create_deep_entity.
 CLEAR er_deep_entity.
    CASE iv_entity_set_name.
      WHEN'VendorSet'.
        er_deep_entity = _vendorgetdetails( io_data_provider ).
    ENDCASE.
ENDMETHOD.

Create own method to perform the operation.

import and export parameters of _vendordetails method

To Define the structures and navigation names and calling soap API inside the method _vendorgetdetails

METHOD _vendorgetdetails.

**-- Data Declaration
    DATA : BEGIN OF ls_entity.
             INCLUDE TYPE zcl_zvendor_getdetail_mpc_ext=>ts_vendor.
    DATA :   vendorHeader TYPE zcl_zvendor_getdetail_mpc=>tt_vendorheader,
             vendorItem   TYPE zcl_zvendor_getdetail_mpc=>tt_vendoritem.
    DATA : END OF ls_entity,
    lo_message_container TYPE REF TO /iwbep/if_message_container.

**--constants
    CONSTANTS: lc_type   TYPE bapi_mtype VALUE 'E',
               lc_id     TYPE symsgid VALUE '01',
               lc_number TYPE symsgno VALUE '02'.

**--intialize
    io_data_provider->read_entry_data(
      IMPORTING
        es_data = ls_entity
    ).

**--Raising exception
    IF ls_entity-ip_lifnr IS INITIAL.
      lo_message_container = me->mo_context->get_message_container( ).
      DATA(ls_return) = VALUE bapiret2( type = lc_id
                                        number = lc_number
                                        message = TEXT-010 ).

      lo_message_container->add_message(
        EXPORTING
          iv_msg_type               =   ls_return-type               " Message Type
          iv_msg_id                 =   ls_return-id               " Message Class
          iv_msg_number             =    ls_return-number              " Message Number
          iv_msg_text               =     ls_return-message             " Message Text
      ).

      RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
        EXPORTING
          message_container = lo_message_container.
    ENDIF.

**--Calling existing RFC

    CALL FUNCTION 'ZVENDOR_GETDETAIL'
      EXPORTING
        ip_lifnr   = ls_entity-ip_lifnr
        ip_ebeln   = ls_entity-ip_ebeln
      IMPORTING
        ep_msg     = ls_entity-ep_msg
        et_po_hdr  = ls_entity-vendorheader
        et_po_item = ls_entity-vendoritem.

    copy_data_to_ref(
      EXPORTING
        is_data = ls_entity
      CHANGING
        cr_data = rx_deep_entity
    ).

  ENDMETHOD.

Once you done with your implementation just maintain and activate your service in Gateway Builder.

Click on Register Button it will open new session there provide your package and click on Continue to activate the service.

Once your service Registered successfully select your service and click on SAP Gateway Client.

After Execute you will get vendor header and vendor item details in http response.

Conclusion:

this requirement basically helps in converting SOAP API to REST API to improving performance and web service based also we can use.

Hope I find it will we be helpful. If any queries please welcome on comment sections.

Regards,
Vishnu Teja.

Develop and deploy a HTML (Angular/Vue/React) app on SAP BTP access S/4 OP, Part III

2024-03-11T09:50:37.733000+01:00

See my previous blogs for the context:

Part I: Develop and deploy a HTML (Angular/Vue/React) app ... - SAP Community

Part II: Develop and deploy a HTML (Angular/Vue/React) app ... - SAP Community

This post provides detail step to develop and deploy a HTML app (based on Angular) which deployed to SAP BTP via SAP CAP and access data from one single source:

S/4 On-premise system;

Step 1. Create an Web-API OData Service in S/4 On-premise System.

It is suggested to use RAP for such development in ABAP development world, but it depends on personal choices.

During create service binding, it is recommended to use 'OData V4 - Web API'.

And you can launch the 'Test' button on this API definition, it will launch a Swagger UI as following:

Click on the link 'ABAP Documentation' to show the metadata file. Sometime the linkage itself cannot be opened successfully, copy the link and open the Tab in your browser.

The metadata shall be displayed, save the content to a separate file via 'Save as...'.

Assume the file as `API_DEF.xml`.

Step 2. Create new CAP project (Nodejs based) and Import API.

Refer to Jumpstart & Grow as You Go | CAPire (cloud.sap) for the prerequisites and recommended IDE before creating a new CAP project (Nodejs based).

Using following commands to create a CAP project named 'demoapp':

cds init demoapp

Then, imports the `API_DEF.xml` via following command lines:

cds import API_DEF.xml --force --as cds

Via this importing, the CDS will create an folder named `external` under `srv`:

Step 3. Complete the CAP Service development.

Enhance the CAP project by definition it's service:

using {  API_DEF as external } from '../srv/external/API_DEF';

service MyAPIService @(impl: 'srv/impl/myapi-service.js') 
{
    @readonly
    entity MyAPI as projection on external.MyEntity;
}

Then, update your `myapi-service.js`:

"use strict";

const cds = require('@sap/cds');

class MyAPIService  extends cds.ApplicationService {
    init() {
        this.on('READ', 'MyAPI', async req => {
            const apiodata = await cds.connect.to("API_DEF");
            const { MyEntity } = apiodata.entities;
            const results = await apiodata.run(SELECT.from (MyEntity));
            return results;
        });
    }
}

module.exports = { MyAPIService }

We need specify a destination (defined in your BTP subaccount) to let CAP know where to fetch the data.

In the `package.json`, section `cds`:

      "API_DEF": {
        "kind": "odata",
        "model": "srv/external/API_DEF",
        "csrf": true,
        "csrfInBatch": true,
        "[production]": {
          "credentials": {
            "destination": "MYERP_DEST",
            "path": "/sap/opu/odata4/sap/API_DEF/0001"
          }
        }
      },

The path here refer to the path in your S/4 OP system.

Now, your CAP service will automatically (if your configured your destination and connectivty service correctly) when you fetch a `GET` on the MyAPI.

Step 4. Create your HTML app (in this case, use Angular).

You just need create your HTML app in folder `app` and consume the service in `srv` folder.

Refer to Step 4 in my article Develop and deploy a HTML (Angular/Vue/React) app ... - SAP Community

You don't need additional (for consuming Dest and Conn) logic in `approuter` any more.

Enjoy your coding then.

Inbound Interface to receive the UUID, PDF and XML details through ODATA - MEXICO

2024-03-15T11:00:09.958000+01:00

Requirement

In Mexico, it is necessary that all companies receive tax authority validated XML and PDF files that contain the details of the payment made to vendors.

Its mandatory to extract the UUID number from the file that is received from the vendors and save it in a way that makes it easily accessible, in S4 it would be easier to store it in a custom table.

The importance of this interface is to store UUID in S4 system in order to facilitate users identify which invoices were payed to which vendors as well as reconciliation between EDICOM Portal and S4 system. The risk of not having this interface, is that files (PDF and XML) and UUID data will only be stored in EDICOM Portal and reconciliation to corresponding payments would be time consuming for users.

Technical Requirement

Interaction of SAP with EDICOM portal where SAP CPI is the middleware which sends the XML, PDF to S4. The technical requirement was to create a ODATA which can receive XML and PDF, also should extract UUID details from XML structure and update it to the respective document.

Simple flow chart:

Detailed Flow chart:

Technical Solution

To receive and extract the details from XML file, ODATA interface is developed and the received XML and PDF files are attached to the respective FI document.

XML and PDF files are sent in base64 encoded format from SAP CPI then in S4 we make use of various function modules to convert it and make the attachment.

Created ODATA service in tcode SEGW - ZFI_PAYMENT_COMPLEMENT_002

In Data model the custom table ZFI_IF020_PAYCOM is used to give ODATA the reference structure. The last two fields ZPDF & ZXML are created in RAWSTRING format to store the XML and PDF files.

Regenerate the Runtime Artifact ZCL_ZFI_PAYMENT_COM_01_DPC_EXT

This gives us the class where we can write the required logic, here we have redefined the method PAY_COMPSET_CREATE_ENTITY – holds the logic to validate the inputs received from SAP CPI and the logic to add PDF and XML to the FI document.

FI_DOCUMENT_CHANGE FM is used to update UUID to the respecting FI document.

The above FM is passed with the required importing parameters.

PDF Attachment:

PDF file is sent in Base64 format from CPI to S4.

SCMS_XSTRING_TO_BINARY – using this FM the received base64 format is converted to binary
ARCHIV_CREATE_TABLE – using this FM the converted binary file is attached to the FI document

XML Attachment:

XML is also sent in Base64 format from CPI to S4.

SCMS_XSTRING_TO_BINARY – using this FM the received base64 format is converted to binary
SO_CONVERT_CONTENTS_BIN – to get the binary file in tab format
SO_FOLDER_ROOT_ID_GET – this FM is used to fetch the folder ID
SO_OBJECT_INSERT – used to insert the converted XML file
BINARY_RELATION_CREATE_COMMIT – create relation between attachment and the document (Reference code is attached)

If there is any error in the attachment the file is sent to AL11.

All the received inputs including XML and PDF are saved in a custom table.

Report:

Tcode - ZFI_PAYCOMP_MONITOR

A report is created to display the details received using custom table in which the entries made through ODATA Service and displayed in ALV format.

User can view the error details in description and also can select and reprocess the particular file after updating the missed details.

Created and activated the service ZFI_PAYMENT_COMPLEMENT_002_SRV in following tcode /n/iwfnd/maint_service

The ICF Node should be in active status as shown in the screenshot.

Hope this helps someone! 😊

OData NW ABAP Gateway (OData)

Fiori Analytical List Page using CDS Annotations to Display as Charts

2024-03-15T11:53:44.741000+01:00

Goal

Create an Analytical List Page like the one below.

Development environment

Frontend: BTP
Backend: S/4HANA

Data model

The data model has a simple structure as shown below. The base has a table for recording expenditures (ZMY_EXPENSES) and an expenditure category master (ZEXCATEGORYTEXT). The views used in ALP are the same analytical views used in the query browser. The top view @analytics.query: trueis annotated with , and the base view below it @analytics.dataCategory: #CUBEis annotated with (or FACT, DIMENSION, HIERARCHY depending on the purpose).

ZMY_EXPENSES

The data is in the following format.

ZEXCATEGORYTEXT

For simplicity, we will only have Five Categories.

Steps

Creating a CDS view
Output charts and tables

1. Creating a CDS view

Expense Category View: ZI_Category_Text

Create a view to retrieve expenditure categories.

@AbapCatalog.sqlViewName: 'ZITEXTCAT'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Text Category'


@ObjectModel.dataCategory: #TEXT
@ObjectModel.representativeKey: 'category'
define view ZI_Category_Text as select from zexcategorytext {
    key category,
    @Semantics.language: true
    key language,
    @Semantics.text: true
    text
}

Cube View for aggregation: ZI_Cube_MyExpenses

Create a Cube View for aggregation. I_CalendarDate is a standard view that allows you to convert a date to year, year month, etc. I want to be able to select the year and month with the ALP filter, so I have I_CalendarDate and Association.

ZI_Cube_MyExpenses

@AbapCatalog.sqlViewName: 'ZIMYEXP'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Cube for My Expenses'
@Analytics.dataCategory: #CUBE

define view ZI_Cube_MyExpenses as select from zmy_expenses 
association [0..1] to ZI_Category_Text as _Text
on $projection.Cateogry = _Text.category
association [0..1] to I_CalendarDate as _CalendarDate
on $projection.PostingDate = _CalendarDate.CalendarDate
{
    @ObjectModel.foreignKey.association: '_CalendarDate'
    posting_date as PostingDate,
    @ObjectModel.text.association: '_Text'
    category     as Cateogry,
    @Semantics.amount.currencyCode: 'Currency'
    @DefaultAggregation: #SUM
    amount       as Amount,
    @Semantics.currencyCode: true
    currency     as Currency,
    _CalendarDate._CalendarYear.CalendarYear,
    _CalendarDate._YearMonth.YearMonth,


    _Text,
    _CalendarDate
}

The annotations required for use with ALP are as follows.

@Analytics.dataCategorySet to make it a view for analysis . Category is a combined view of transaction data (expenditures) and master data (expenditure categories) #CUBE.

@Analytics.dataCategory: #CUBE

The analysis view must have items to be aggregated (measures). @DefaultAggregationItems marked with are subject to aggregation.

@DefaultAggregation: #SUM amount as Amount,

Consumption View：ZC_MY_Expenses

Finally, create the top view that will be the source of the OData.

ZC_MY_Expenses

@AbapCatalog.sqlViewName: 'ZCMYEXP'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'My Expenses'

@Analytics.query: true
@OData.publish: true
@Metadata.allowExtensions: true

define view ZC_MY_Expenses as select from ZI_Cube_MyExpenses 
{
    PostingDate,
    @AnalyticsDetails.query.display: #KEY_TEXT
    Cateogry,
    Amount,
    Currency,
    @Semantics.calendar.year: true
    CalendarYear,
    @Semantics.calendar.yearMonth: true
    YearMonth
}

The important thing here @Analytics.query: true is the annotation. This view does not have a key, but it @Analytics.query: true is acceptable without a key.

Another important point is the following annotation.

@Semantics.calendar.year: true

CalendarYear,

@Semantics.calendar.yearMonth: true

YearMonth

The OData type for CalendarYear (year) and YearMonth (year and month) is edm.string. If left as is, it will not be recognized as a time-related item, so @Semantics.calendarit is necessary to add .

2. Output charts and tables

Next, let's create an app by adding the minimum annotations to output charts and tables.
Create a Metadata Extension for ZC_MY_Expenses. First, define the selection field (selectionField) and the table column item (lineItem).

@Metadata.layer: #CORE

annotate view ZC_MY_Expenses

with

{

@UI:{

lineItem: [{ position: 10 }]

}

PostingDate;

@UI:{

selectionField: [{position: 10 }],

lineItem: [{ position: 20 }]

}

Cateogry;

@UI:{

lineItem: [{ position: 30 }]

}

Amount;

@UI:{

selectionField: [{position: 20 }]

}

CalendarYear;

@UI:{

selectionField: [{position: 30 }]

}

YearMonth;

}

Next, set the annotation to display the chart. Add the following above annotate view ZC_MY_Expenses...

This is an annotation that determines the display variant (presentationVariant) and selection variant (selectionVariant) when the app is opened. A qualifier (ID) of 'Default' is specified for each.

@UI.selectionPresentationVariant: [{

qualifier: 'Default',

presentationVariantQualifier: 'Default',

selectionVariantQualifier: 'Default'

}]

The contents of the actual variant are defined below.

presentationVariant indicates how the data is presented, that is, it is displayed as a chart (type:

@UI.presentationVariant: [{

qualifier: 'Default',

visualizations: [{

type: #AS_CHART,

qualifier: 'ChartDefault'

}]

@UI.selectionVariant: [{

qualifier: 'Default',

text: 'Default'

}]

Finally, let's define the chart. Create a stacked bar graph for each year and month and expense category.

@UI.chart: [{

qualifier: 'ChartDefault',

chartType: #COLUMN_STACKED,

dimensions: ['Cateogry', 'YearMonth'],

measures: ['Amount'],

dimensionAttributes: [{

dimension: 'Cateogry',

role: #SERIES

},{

dimension: 'YearMonth',

role: #CATEGORY

}],

measureAttributes: [{

measure: 'Amount',

role: #AXIS_1

}]

The meanings of the items are as follows.

project	explanation
qualifier	Chart ID. Same as qualifier specified in presentationVariant
chartType	Chart type. #COLUM_STACKED is a stacked bar graph
dimensions	Specify the analysis axis. Multiple specifications can be specified depending on the chart type.
measures	Specify the numeric item to be analyzed. Multiple specifications can be specified depending on the chart type.
dimensionAttributes	Specify the role (use) for each analysis axis (*)
measureAttributes	Specify the role (purpose) for each numerical item. Specify which axis

*Meaning of role in dimension

category: Set for the dimension that is the X axis in a bar graph
series: Use when you want to separate classifications (colors) within the same category
category2: Second axis used in heatmap etc.

Creating an ALP with BTP(SAP Business Technology Platform)

Let's make OData public. TR - > ( /IWFND/MAINT_SERVICE )

Select the Analytical List Page template.

Provide the OData Service URL

Specify the qualifier of the selection Presentation Variant set in step 2 in Qualifier.

Next we have to provide the Project Attributes

On the Project2 we have to choose Preview Application here we have to Click on the Start Fiori Run First option in Dropdown.

At this point, the pages section of manifest.json looks like this:-

manifest.json

"pages": {

"AnalyticalListPage|ZC_MYEXPENSES": {

"entitySet": "ZC_MYEXPENSES",

"component": {

"name": "sap.suite.ui.generic.template.AnalyticalListPage",

"list": true,

"settings": {

"condensedTableLayout": true,

"showGoButtonOnFilterBar": true,

"tableType": "ResponsiveTable",

"multiSelect": false,

"qualifier": "Default",

"autoHide": true,

"smartVariantManagement": true,

"keyPerformanceIndicators": {}

}

"pages": {

"ObjectPage|ZC_MYEXPENSES": {

"entitySet": "ZC_MYEXPENSES",

"component": {

"name": "sap.suite.ui.generic.template.ObjectPage"

}

Execution result

Nothing is displayed when it starts up.

When you press Go, the chart and table are displayed.

When you press the Compact Filter button on the top right, the filter items defined in selection Field will be displayed.

Arrange graphs in year/month order

Add sort Order to presentation Variant. Arrange them in ascending order by Year Month and descending order by Posting Date. The reason why I include Posting Date is because this sort order also affects how the table looks, so I want the latest records to be at the First.

@UI.presentationVariant: [{

qualifier: 'Default',

sortOrder: [{

by: 'PostingDate',

direction: #DESC

},{

by: 'YearMonth',

direction: #ASC

}],

visualizations: [{

type: #AS_CHART,

qualifier: 'ChartDefault'

}]

Also add YearMonth to line Item. This is because an error will occur if the item specified in sort Order is not included in line Item.

@UI:{

selectionField: [{position: 30 }],

lineItem: [ { position: 40 } ]

}

YearMonth;

Conclusion.

My impressions after creating ALP for the first time were that it was relatively easy to do in general, but I had a hard time with the small details (default filter, criticality settings, etc.). This time, I envisioned what I wanted to create and researched how to make it happen, so it was good that I realized what ALP can do and its limitations.

Reference

blog

Document

Appendix

Metadata Extension:-

@Metadata.layer: #CORE
@UI.presentationVariant: [{
    qualifier: 'Default',
    sortOrder: [{
        by: 'PostingDate',
        direction: #DESC
     },{
        by: 'YearMonth',
        direction: #ASC
     }],
    visualizations: [{
        type: #AS_CHART,
        qualifier: 'ChartDefault'
    }]
 }]
 
@UI.chart: [{
   qualifier: 'ChartDefault',
   chartType: #COLUMN_STACKED,
   dimensions: ['Cateogry', 'YearMonth'],
   measures: ['Amount'],
   dimensionAttributes: [{
       dimension: 'Cateogry',
       role: #SERIES
    },{
       dimension: 'YearMonth',
       role: #CATEGORY
    }],
   measureAttributes: [{
       measure: 'Amount',
       role: #AXIS_1
    }]
 }]
annotate view ZC_MY_Expenses with 
{
   @UI:{
      lineItem: [{ position: 10 }]
  }
  PostingDate;
  @UI:{
      selectionField: [{position: 10 }],
      lineItem: [{ position: 20 }]
  }
  Cateogry;
    @UI:{
      lineItem: [{ position: 30 }],
      dataPoint: {
          criticalityCalculation: {
              improvementDirection: #MINIMIZE,
              toleranceRangeHighValue: 100000,
              deviationRangeHighValue: 150000
          }
      }
  }
  Amount;
  @UI:{
      selectionField: [{position: 20 }]
  }
  CalendarYear;
  @UI:{
      selectionField: [{position: 30 }],
      lineItem: [ { position: 40 } ]
  }
  YearMonth;
    
}

Graph intro series, part 8: Use Graph With OData v4

2024-03-19T14:21:24.058000+01:00

What you will learn: use OData v4 to fetch data and explore the structure of the connected data model exposed by Graph.

Hello!

In this part of the tutorial on Graph we will focus on the OData protocol that Graph exposes and how to explore the structure of the data model of a business data graph. OData is one of the two data protocols supported by Graph - next to GraphQL.

For an overview of other parts of this series, check out the Information Map.

Graph is built on open standards and technologies. Clients can communicate with Graph using the Open Data v4 Protocol (OData). This is a standardized RESTful HTTP protocol with defined semantics that help promote interoperability between services.

OData is centered around resources (data entities), which are identified by URLs. In Graph, there are for example the Customer, Product, or SalesQuote entities. The structure of these entities is defined in an Entity Data Model (EDM) which can be inspected by clients. OData provides many operations to filter or search in entity collections, to navigate between associated entities and to adapt the response shape.

We will now look at examples on how to formulate OData requests for Graph.

Tutorial Setup

To keep things simple, we will be using the Graph sandbox business data graph (BDG). All you need to use it is your favorite HTTP tool, for example Postman, and your API key from SAP Business Accelerator Hub. To retrieve your API key, log into SAP Business Accelerator Hub, go to settings and copy your API key from the Show API Key button.

To make requests against the Graph sandbox BDG, add your API key as an HTTP header in your requests:
apiKey: <your API key>

Then you can use the Graph sandbox BDG through the following endpoint:

https://sandbox.api.sap.com/sapgraph/

Note: The API key is just used for the purposes of this sandbox endpoint and not relevant in the context of OData requests or productive Graph instances.

Exploring the OData data model

OData defines an Entity Data Model that describes the structure of all known entities. This helps developers and clients alike to reason about the available entities and their structure. The data model and further metadata can be inspected through a special $metadata resource. Graph makes metadata available for each namespace, such as sap.graph for the unified Graph data model.

To retrieve the metadata of the unified data model in Graph, make the following request, which will return an EDMX specification (an XML dialect for describing OData Entity Data Models).

https://sandbox.api.sap.com/sapgraph/sap.graph/$metadata

In the response, we can inspect the structure of all the entities (and sub-entities) that are described as EntityType entries as well as other metadata. Let's have a closer look at the definition of the SalesQuote entity type in this extract from the sales domain metadata:

<EntityType Name="SalesQuote">
    <Key>
        <PropertyRef Name="id"/>
    </Key>
    <Property Name="id" Type="Edm.String" MaxLength="82" Nullable="false"/>
    <Property Name="displayId" Type="Edm.String"/>
    <Property Name="netAmount" Type="Edm.Decimal" Scale="6" Precision="22"/>
    <Property Name="pricingDate" Type="Edm.DateTimeOffset"/>
    <Property Name="netAmountCurrency" Type="Edm.String" MaxLength="5"/>
    <NavigationProperty Name="_netAmountCurrency" Type="sap.graph.Currency"/>
    <NavigationProperty Name="items" Type="Collection(sap.graph.SalesQuote_items)" Partner="up_" ContainsTarget="true"/>
    <Property Name="soldToParty" Type="Edm.String" MaxLength="10"/>
    <NavigationProperty Name="_soldToParty" Type="sap.graph.Customer"/>
    <NavigationProperty Name="_cxsales" Type="sap.cxsales.SalesQuoteCollection"/>
    ...
</EntityType>

We can see that a SalesQuote has several properties of different types, such as String or Decimal, but also more complex structured types like the items property, which is a collection of several sap.graph.SalesQuote_items, that are also defined in the same data model. Furthermore, we see that the id property is referenced as key for this entity type. Navigation Properties allow for navigation to a related entity. The items property is a navigation property because the sap.graph.SalesQuote_items is modeled as a separate entity type in the metadata.

Let's look at an example. Add the following query path to the sandbox endpoint to make the request. This will retrieve one SalesQuote entity (here we add $top=1 to limit the result set to one entity):

/sap.graph/SalesQuote?$top=1

From inspecting the metadata, we have learned that SalesQuotes have items, however when comparing with the response from the example, no items are included in the response.

The reason for this is that OData has a mechanism for the client to control which navigation properties are included as part of the response. This is called expanding a property. By default, Graph returns responses non-expanded if not specified by the client. In addition to expanding the response, OData also allows for restricting it to requested values only. We will have a look at these mechanisms next.

Expanding and restricting the response

OData allows clients to adapt the response format in two ways. Clients can restrict the response to a set of specified properties via $select. And they can expand the response by including referenced entities inline as part of the response via $expand.

If we only require the netAmount of a SalesQuote, we can restrict the response by adding it to the $select query parameter:

/sap.graph/SalesQuote?$top=1&$select=netAmount

This will return only the netAmount property along with the id, as it is the key attribute and therefore always included.

If we also require the items of a SalesQuote, we need to expand the response (as it is a navigation property) by adding it to the $expand query parameter:

/sap.graph/SalesQuote?$top=1&$select=netAmount&$expand=items

This will result in the items array being returned as part of the SalesQuote response as illustrated here:

If we have a look at a response snippet, this is what is being returned:

{
    "@odata.context": "$metadata#SalesQuote(netAmount,id,items())",
    "value": [
        {
            "id": "cxsales~1",
            "netAmount": 890,
            "items": [
                {
                    "itemId": "10",
                    "parentItemId": "",
                    "alternativeToItemId": "",
                    "itemCategory": "AGN",
                    "itemText": "Green Emission Calculator",
                    "product": "P300100",
                    "soldToPartyProductId": "",
                    "quantity": 1,
                    "quantityUnit": "EA",
                    "grossWeight": 0,
                    "grossWeightUnit": "",
                    "netWeight": 0,
                    "netWeightUnit": "",
                    "volume": 0,
                    "volumeUnit": "",
                    "plant": "",
                    "netAmount": 890,
                    "netAmountCurrency": "USD",
                    "pricingProduct": "",
                    "incotermsClassification": "",
                    "incotermsLocation": "",
                    "processingStatus": "1",
                    "cancellationReason": ""
                }
            ]
        }
    ]
}

Note that we do not have to specify expanded properties explicitly as part of $select.

We see that the item in the example above has a property product that references an id. When we inspect the metadata of the items by searching for the EntityType SalesQuote_items. We see that the product property represents the referenced product with a string value and the _product navigation property references the connected sap.graph.Product entity.

<EntityType Name="SalesQuote_items">
    <Key>
        <PropertyRef Name="itemId"/>
    </Key>
    <Property Name="itemId" Type="Edm.String" MaxLength="10" Nullable="false"/>
    <Property Name="itemText" Type="Edm.String"/>
    <Property Name="product" Type="Edm.String"/>
    <NavigationProperty Name="_product" Type="sap.graph.Product"/>
    ...
</EntityType>

To also include this _product as part of the response, we can expand it inside the already expanded items: a nested expand.

/sap.graph/SalesQuote?$top=1&$select=netAmount&$expand=items($expand=_product)

Which will include the _product response inline in the item of the SalesQuote response.

If we also want to adapt the format of the expanded product we can nest a $select query parameter in parentheses after the product. To restrict the nested product to the displayId, for example:

/sap.graph/SalesQuote?$top=1&$select=netAmount&$expand=items($expand=_product($select=displayId))

If we also want to select more properties, such as netAmountCurrency, we can just add them to the $select query parameter targeting the SalesQuote, separated by commas:

/sap.graph/SalesQuote?$top=1&$select=netAmount,netAmountCurrency&$expand=items($expand=_product($select=displayId))

The response for the SalesQuote with included netAmountCurrency, items and _product now looks like this:

{
    "@odata.context": "$metadata#SalesQuote(netAmount,netAmountCurrency,id,items(_product(displayId,id)))",
    "value": [
        {
            "id": "cxsales~1",
            "netAmount": 890,
            "netAmountCurrency": "USD",
            "items": [
                {
                    "itemId": "10",
                    "parentItemId": "",
                    "alternativeToItemId": "",
                    "itemCategory": "AGN",
                    "itemText": "Green Emission Calculator",
                    "product": "P300100",
                    "_product": {
                        "id": "cxsales~P300100",
                        "displayId": null
                    },
                    "soldToPartyProductId": "",
                    "quantity": 1,
                    "quantityUnit": "EA",
                    "grossWeight": 0,
                    "grossWeightUnit": "",
                    "netWeight": 0,
                    "netWeightUnit": "",
                    "volume": 0,
                    "volumeUnit": "",
                    "plant": "",
                    "netAmount": 890,
                    "netAmountCurrency": "USD",
                    "pricingProduct": "",
                    "incotermsClassification": "",
                    "incotermsLocation": "",
                    "processingStatus": "1",
                    "cancellationReason": ""
                }
            ]
        }
    ]
}

Working with collections: filtering, ordering and pagination

When working with collections of entities, we typically want to filter the entities by some criteria or arrange them in a specific order. In OData this is supported via the $filter and $orderby query parameters. With $top and $skip we can additionally define a sliding window over the result to implement pagination.

To continue with our example above, let's remove the $top=1 we added initially to now retrieve a collection of SalesQuotes. Say we want to retrieve all SalesQuotes with a value greater than 100 U.S. Dollars.

The value condition can be formulated with the greater equal operator: netAmount ge 100. For the currency condition we need to compare it with a string (enclosed in single quotes) for equality: netAmountCurrency eq 'USD'. We then combine these conditions with a logical and expression and add it to the example query below. We also define an ordering on the netAmount property with the $orderby query parameter, which is ascending by default.

Note: OData operators are lower-case and space-separated. This requires URL encoding. If you are using Postman for this tutorial you don't need to worry as Postman automatically applies URL encoding.

/sap.graph/SalesQuote?$select=netAmount,netAmountCurrency&$expand=items($expand=_product($select=displayId))&$filter=netAmount ge 100 and netAmountCurrency eq 'USD'&$orderby=netAmount

Note: OData only supports writing filter expressions using a small vocabulary of filter operators. See here for a full list.

As a last step, we will now define a paging-window over all results. This can be achieved with the query parameters $top, which specifies how many result entities should be returned: the page size, and $skip, which defines how many result entities should be skipped from the beginning of the ordering. Hence, we describe the page size with $top and index the single pages with multiples of the page size in $skip. For the second page of five entities each, this would translate to our example as follows:

/sap.graph/SalesQuote?$select=netAmount,netAmountCurrency&$expand=items($expand=_product($select=displayId))&$filter=netAmount ge 100 and netAmountCurrency eq 'USD'&$orderby=netAmount&$top=5&$skip=5

Summary

In this tutorial we had a look at OData, one of the two data protocols used by Graph. We covered all the features that you as a developer working with Graph need to know, like how to:

formulate complex queries
inspect the metadata and structure of the unified data model
expand and restrict responses
work with collections

OData itself offers much more than what we showed in this tutorial. You can read more about it in the standard.

With Graph, you as a developer now have one data protocol you can use together with one API to retrieve data in one unified format, no matter the source system.

---
Florian Moritz

How to enable an OData V4 service for anonymous access?

2024-03-19T21:57:57.546000+01:00

Introduction

This requirement stems from a customer that asked how to publish an OData V4 service in an SAP S/4HANA on premise system such that it could be used on a public web site without the need to provide any authentication.

With OData V2 this requirement can be achieved more easily since here every service has it's own SICF node where it would be possible to store credentials just for this service.

In OData V4 we have only one SICF node, namely /sap/opu/odata4/.

This is obviously a problem since there is no service specific node available in SICF.

Solution

The problem can be solved using the following approach.

Create a role that only contains the S_START authorization for the one single OData V4 service we want to publish ,
help.sap.com/doc/saphelp_nw75/7.5.5/de-DE/c6/dd838722ce4b8d9cc4a0741d93d864/frameset.htm
Create a technical user that has only the authorization to access the single OData V4 service we want to make accessible.
Create an alias in SICF for the node /sap/opu/odata4/
Store the credentials of the aforementioned user in the alias
Test the service

Result

As we can see accessing the service zrap630ui_shop_o4_05a via the alias zodatav4_2 works.

https://10.79.21.221:44301/sap/opu/zodatav4/sap/zrap630ui_shop_o4_05a/srvd/sap/zrap630ui_shop_o4_05a/0001/?sap-client=100

Whereas accessing a second OData V4 service zrap630ui_shop_o4_05b via the alias zodatav4_2 does NOT work

This has been achieved by assigne the follwoing role the technical user which only contains the authorization to start the first service based on the authorization object S_START.

Please note:
Since OData V4 service use the authorization object S_START which is based on the service name it would for example be possible to publish several services that are in the same name range like

zrap630ui_shop_o4_05A, zrap630ui_shop_o4_05B, ... zrap630ui_shop_o4_05Z,

How to section

Create the role

Using PFCG and the role template /IWBEP/RT_MGW_USR we create a role as shown in the screen shot above that only contains the S_START authorization of one OData V4 service called ZRAP630UI_SHOP_O4_05A.

Create the user

As a user we create a technical user whose credentials will be stored in the system alias.

Create the system alias

1. We start by right-clicking on the node opu and choose New subelement.

2. We create a new service element called ZODATAV4_2 and choose the option Alias to an existing service.

3. We choose the tab Target, select the node OdataV4 by double-clicking on it.

4. We navigate to the tab Logon Data, choose Alternative Logon Procedure and enter the credentials of our service user.

5. We navigate down and remove all logon procedures beside Logon using service data.

6. Do not forget to activate the link in SICF.

7. Check the result

Escaping special character in SF OData API

2024-03-21T14:56:42.267000+01:00

While querying the data from SF OData API of the base entity FOCostCenter i did receive the following error -

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
<code>BadRequestException</code>
<message lang="en-US">Invalid quote usage detected, quotes need to be in pairs.</message>
</error>

This did lead me to a spiral of what went wrong, after a bit of head scratching i did figure out my SF OData API query was :


/FOCostCenter?$select=externalCode,name&$filter=externalCode eq 'A & B'

Well, the issue here is with having "&" between A and B. OData API parser by default expect to have a ' after A and before B. In order to handle this we need to escape & symbol. As usual i escaped it by replacing & with & but then it did not work.

Understanding the protocol of OData API i was led to beleive escaping needs to supported by ASCII format which is %26 which helped us to solve the problem.

Updated query condition which solved the problem is here.

/FOCostCenter?$select=externalCode,name&$filter=externalCode eq 'A %26 B'

End of the long story - if you need to escape special characters within filter condition of OData then please use ASCII encoding.

Consuming OData URL in CPI with GET Method

2024-03-21T15:17:20.893000+01:00

In this blog article, we will walk you through the process of consuming an OData service in the SAP Integration Suite, with a focus on configuring the OData adapter.

Before you start the integration process, ensure you have the following prerequisites in place:

SAP Integration Suite: Access to the SAP Integration Suite is necessary.
OData service URL: Know the URL of the OData service you intend to consume.

Firstly, we need to understand what OData is:
OData: The OData adapter allows you to communicate with an OData API using OData protocol. You can use messages in ATOM or JSON format for communication.

Click on "Create" to initiate a new Integration Flow.
Define the integration flow details, such as name and description.

Open & click on edit

As Start event should have an incoming message use Timer event instead of Start Event

Now add a Request reply to consume the OData service.

Now connect your request reply with the Receiver by using the OData V2 as message protocol.

Now, configure the OData adapter with the necessary details:

1. Endpoint: Enter the URL of the OData service you want to consume.

The Service URL for an OData service typically includes the following components:

ODATA URL: https://host:port/sap/opu/odata/sap/ZMM_INVOIC_PEARL_INBOUND_SRV/InvoicerejheadSet?$expand=ASSREJITEM&$format=json

Protocol: https:// This indicates that the communication will be secured using HTTP Secure (HTTPS), which encrypts the data transferred between the client (your browser or application) and the server.
Host: This is the IP address of the server hosting the OData service.
Port: The port number on which the OData service is listening. The default ports are 80 for HTTP and 443 for HTTPS.
PATH: /sap/opu/odata/sap/ZMM_INVOIC_PEARL_INBOUND_SRV: This is the base path for the OData service. It identifies the service and specifies the namespace for the entities exposed by the service. ZMM_INVOIC_PEARL_INBOUND_SRV is likely the name of the OData service, and /sap/opu/odata/sap/ is a common prefix for SAP OData services.
Entity set: InvoicerejheadSet: This is the entity set being accessed. In OData, an entity set is a collection of entities of the same type. Here, InvoicerejheadSet seems to represent a collection of invoice rejection headers.
Sublevel: $expand: a "sublevel" typically refers to the depth of nested entities or related data that can be expanded in an OData query. When you perform an OData query with the $expand option, you can specify which related entities you want to include in the response. Each entity that you expand represents a level of depth in the data hierarchy.

2. Select the proxy type:

Internet: Internet proxy type is suitable when your OData service is externally hosted or available on the Internet. It allows the adapter to communicate with the service over the public network.
On-Premise: The on-Premise proxy type is suitable for scenarios where the OData service is hosted within your organization's network. It allows the adapter to establish a connection within the internal network, ensuring secure and controlled access.

3. Authentication: Specify the authentication method (e.g., Basic Authentication, OAuth) and provide the required credentials.

In the processing tab configure as shown below

Operation Details: Define the specific OData operations (GET, POST, PUT, DELETE) required for your integration scenario.
Resource Path: Set the Resource Path based on the Entity Set and navigation properties relevant to your scenario.

After selecting it will take you to another screen as below. So, don’t change anything in Step 1 keep it as it is.

STEP 1: Connect to System

NOTE: When you access the URL in your step 1, typically the service will respond with metadata about the available entity sets, properties, relationships, and operations exposed by the service. The metadata document describes the structure and capabilities of the OData service, allowing clients to understand how to interact with it programmatically.

In summary, when you access the full URL, you'll receive metadata and information about the available resources and operations provided by the OData service, not just the raw data from the InvoicerejheadSet entity set.

Step-2: Now click on Step-2 and select the Operation as Query as we are fetching Data.

In Entity, search for Entity and select it. Also, check all the checkboxes against all fields, you can also check Generate XML schema Definition if you want xsd of it.

Step 3: Configure Filter & Sorting: These steps help you refine your query to retrieve only the specific data you need. This step is available only for data fetch operations, where you can define the order in which the records are fetched in the response payload and filter for the fields that you require.

After step-3 click on Finish. It will automatically generate a query as below based on our filter conditions.

After all this configuration you will get one EDMX file and an XSD file.

EDMX (Entity Data Model XSD) File: EDMX is an XML-based file that encapsulates the metadata of an OData service. It includes information about entities, properties, relationships, and other aspects of the service's data model.

Leave the remaining fields as empty as they are not mandatory.

Now save and deploy the I-Flow. Always, change the Log level from info to Trace to see all the Message Processing steps.

Once I-Flow gets started you can see the payload at the End of Step.

Managing Recurring Pay Components in SuccessFactors Using Batch Upsert

2024-03-21T15:17:35.137000+01:00

Introduction:

In this blog, we will delve into the intricacies of managing recurring pay components and explore their implications if they persist beyond specific events such as employee rehires. Understanding and effectively managing recurring pay components are crucial for seamless payroll processing and mitigating potential unwanted consequences.

In the realm of integration scenarios, where SuccessFactors Employee Central portlets are managed and updated through third-party systems via Inbound Integration, the utilization of CPI as a middleware can sometimes lead to overlooked compensation updates. This blog addresses the use of CPI to effectively delimit previous non-effective pay components, particularly in the context of rehires.

Why Rehires?

Rehires present unique scenarios where updates to employees' employment, job, or compensation details render previous information obsolete. When records are populated or updated from a third-party system into SuccessFactors, the job or compensation record may be updated with the rehire event, thereby overwriting previous history. However, in the case of recurring pay components, the previous pay component may carry forward to the new event. While the pay components may be valid for the new event in some cases, the automatic propagation of recurring pay components can result in financial discrepancies in payroll processing. This can lead to overpayment or incorrect payment to employees due to the inclusion of both new and previous pay components in the compensation calculation.

The image below illustrates the behaviour of recurring pay components with changes in each event for an employee. If pay components are not end-dated, they continue to forward propagate even after a rehire event, as highlighted in red below. These pay components may become invalid with effective dated changes, yet they persist due to lack of manual intervention or automation. Consequently, managing updates to pay components or delimiting those no longer valid for an employee becomes crucial, especially if payroll is linked with SuccessFactors Compensation Information

Fig 1. Pay Component Recurring with Event Changes

The Delimiting option for Pay Component Recurring is demonstrated in below sections considering CPI (Inbound Integration) as a middleware, source system as Third-Party system and target system for payroll as SuccessFactors.

Problem Statement:

Delimiting and Handling Pay Component Recurring portlet updates and forward propagation.

Resolution:

The resolution for this issue may vary depending on data policies and compliance in SuccessFactors. However, it can be addressed within the integration itself and automated for efficiency. By utilizing event or event reasons from source systems, changes in pay components under Compensation information can be identified. In the case of a rehire scenario, where pay components might be updated, this approach becomes particularly relevant.

To handle compensation and pay component recurring information during a rehire, all pay component recurring records can be delimited. This action wipes out pay components associated with base salary, incentives, variable pay, benefits, bonuses, etc. Subsequently, the rehire panel updates are added to the Compensation information. To illustrate this process, let's refer back to the example introduced in the introduction.

Fig 2. Delimiting Pay Components before Rehire event update

On the left side, we have the event changes for an employee under 'Employee Event Changes,' while the pay component recurring changes, i.e., Compensation Information event changes, are depicted on the right side.

For instance, at the time of termination, the employee had five pay components: Base Salary, Car Allowance, Meal Allowance, Accident Insurance, and Transportation. However, these pay components become non-eligible for future payroll consideration upon rehire, effective as of February 01, 2024. Despite this, due to forward propagation, these pay components may persist and get added with the new event changes in compensation information, as shown in Figure 1.

To address this issue, a batch upsert operation with the DELIMIT operation can be performed. Below is the payload used for the upsert operation

<batchParts>
    <batchChangeSet>
        <batchChangeSetPart>
            <method>UPSERT</method>   <uri>EmpPayCompRecurring(payComponent='CAR_DE',startDate=datetimeoffset'2024-02-01T00:00:00',userId='mjones',seqNumber=1L)</uri>
            <EmpPayCompRecurring>
                <EmpPayCompRecurring>
                    <payComponent>CAR_DE</payComponent>
                    <seqNumber>1</seqNumber>
                    <userId>mjones</userId>
                    <frequency>Monthly</frequency>
                    <paycompvalue>20</paycompvalue>
                    <currencyCode>EUR</currencyCode>
                    <startDate>2024-02-01T00:00:00</startDate>
                    <operation>DELIMIT</operation>
                  </EmpPayCompRecurring>
            </EmpPayCompRecurring>
        </batchChangeSetPart>
    </batchChangeSet>
</batchParts>

Payload for DELIMIT in pay comp recurring via Batch Upsert

Similarly, the payload is prepared for all pay components. After running the Integration in CPI, the pay components are wiped out as shown in the Fig 2.

Fig 4. SF panel after Delimiting Pay Components

Once all the pay components are removed, we can now insert the new ones with Upsert (POST) method in CPI using SuccessFactors ODATA V2 adapter, the payload for the UPSERT is shown below for reference,

<batchParts>
    <batchChangeSet>
        <batchChangeSetPart>
            <method>UPSERT</method>
  <uri>EmpPayCompRecurring(payComponent='BASESAL_DE',startDate=datetimeoffset'2024-02-01T00:00:00',userId='mjones',seqNumber=1L)</uri>
            <EmpPayCompRecurring>
                <EmpPayCompRecurring>
                    <payComponent>BASESAL_DE</payComponent>
                    <seqNumber>1</seqNumber>
                    <userId>mjones</userId>
                    <frequency>Monthly</frequency>
                    <paycompvalue>7000</paycompvalue>
                    <currencyCode>EUR</currencyCode>
                    <startDate>2024-02-01T00:00:00</startDate>
                  </EmpPayCompRecurring>
            </EmpPayCompRecurring>
        </batchChangeSetPart>
    </batchChangeSet>
</batchParts>

Payload example for creating Pay Components in SF via Batch Upsert

After running the Integration in CPI, the new pay components get added to the Rehire panel under Compensation as shown below,

Fig 6. Compensation after adding Pay Components via Batch Upsert

Conclusion:

Updating and maintaining pay components is essential to ensure accurate payroll-related information remains available for clients. In scenarios where SuccessFactors is not the source of data, dependency on other systems for accuracy persists. This blog sheds light on the relationship between compensation events and pay compensation changes, particularly during major event changes, and their impact on salary calculations. Similar approaches can be adopted to address other scenarios not covered here. Thank you for taking the time to read through this blog.

Accessing S4HANA tables via an OData connection from a user-portal

2024-03-25T19:57:51.735000+01:00

Hi Friends,

I am new to OData.

I need to create an OData service (URL) that will allow external users logged in via a portal to access data from an S4 System and pull selected information.

What are the components, and steps? Is there a port involved? Is there a token involved?

If someone can provide a step by step help, that would be great.

Any help would be highly appreciated.

Best,
RS

Integrating with SAP Datasphere Consumption APIs using SAML Bearer Assertion

2024-03-28T14:14:29.084000+01:00

SAP Datasphere facilitates smooth and scalable access to business data, thereby supporting the business data fabric architecture. SAP Datasphere's is committed to data openness and freedom of choice for analytical frontend solutions and allow development of customized applications connected to it.

The Consumption OData API serves as a prime example of this, providing access to all model types from Facts via relational data access to Analytic Models in analytical mode. Some of this was covered by Mirko Link here.

When integrating SAP Datasphere to other applications the authentication methods are vital to deliver a good customer experience. With the use of SAML Bearer Assertion propagation is possible to forward the IdP authentication from a browser based third-party application to SAP Datasphere without any extra user interaction. Leveraging federated data and Data Access Controls applied to any SAP Datasphere model, the only requirement is that the user must be registered in both applications.

This blog post aims to guide you through the setup of integrating a NodeJS application from SAP Business Technology Platform (BTP) with SAP Datasphere using SAML Bearer Assertion destinations. It will cover the following steps:

Configure Identity Provider Custom User Attribute
Establish Trust between BTP Destinations and SAP Datasphere
Create SAP Datasphere OAuth Client
Setup Destination to SAP Datasphere Consumption APIs
Create XSUAA and Destination Service Instances
Develop BTP Application connected to SAP Datasphere

The initial 3 steps detail the necessary requirements for integrating any system with SAP Datasphere using SAML Bearer Assertion principal propagation. Steps 4,5, and 6 specifically address how BTP Apps can be correctly configured for successful integration with SAP Datasphere.

1. Configure Identity Provider & User Attribute Setup

To allow the SAML Bearer propagation attributes to be recognized its is important that the IdP used in your application to configure the user attributes with "Groups" value equal to "sac".

In this blog, we will be using the SAP Identity Authentication Service (IAS). However, the procedure should be similar with any other Identity Provider.

Open the SAP BTP Cockpit on the subaccount level
Go to Trust Configurations
Click on "New SAML Trust Configuration" to trust your IdP on BTP Platform.
More details can be found on this tutorial. After doing this it should look like bellow:
Open Your IAS Administrator panel
Go to Applications & Resources
Select the Application of your subaccount
Open the "Attributes" menu
Add the "Groups" attribute with static value "sac"

2. Establish Trust between BTP Destinations and SAP Datasphere

Another important requirement is establishing trust between SAP Datasphere and SAP BTP Destinations. This specifies which sources SAP Datasphere can rely on and accept the SAML propagated tokens. This requires providing specific sub-account information for the SAML Bearer Assertion principal propagation flow. Follow the steps below to setup:

Open SAP BTP subaccount
Go to "Destinations" tab
Click on "Download IDP Metadata"
This will download a XML file containing the Trust Identity Provider name and signing certificate, copy those 2 fields
Open SAP Datasphere Administration Page
Go to "App Integration" tab
On "Trusted Identity Providers" click on "Add a Trusted Identity Provider"
Give a name to the new trusted IdP and add Provider Name and Signing certificate copied from the XML file

3. Create SAP Datasphere OAuth Client

To setup the connection to SAP Datasphere Consumption APIs it is needed to generate an OAuth Client which contains the information required to authenticate via OAuth2.0 protocol.

Go to your SAP Datasphere Administration page
Open "App Integration" tab
On the OAuth Client section, you will find important URLs for generating the OAuth credentials, save it for later. Later on this blog when there is a reference to the bellow tags replace it by its correspondent:
- <oauth2_saml_token_url>: OAuth2SAMLTokenURL
- <oauth2_saml_audience>: OAuth2SAMLAudience
Create a New OAuth Client to be used later
1. Set the name of your OAuth Client
2. In Purpose field set "Interactive Usage"
3. Redirect URI field can be left blank
4. Click Save
Copy the Client ID (oauth_clientId) and Client Secret (oauth_secret) which appear in the pop and save them somewhere safe. They will be used later.

4. Setup Destination to SAP Datasphere Consumption APIs

Next, we must establish a SAML Bearer Assertion destination. This will manage the authentication propagation and facilitate communication with the SAP Datasphere Consumption APIs.

Open SAP BTP subaccount cockpit on Destinations page
Click "Create Destination" and fill the required information as follows:
- Name: <name> - Provide a name to the destination
- Type: HTTP
- URL: <sap_datasphere_url> - Consumption API URL to be consumed
```
 http://<datasphere-host>/api/v1/dwc/consumption/analytical/<space>/<asset>/<asset>
```
- Proxy Type: Internet
- Authentication: OAuth2SAMLBearerAssertion
- Audience: <oauth2_saml_audience> - OAuth2SAMLAudience copied on step 3
- AuthnContextClassRef: urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession
- Client Key: <oauth_clientId> - OAuth Client ID from step 3
- Token Service URL: <oauth2_saml_token_url> - OAuth2SAMLTokenURL from step 3
- Token Service User: <oauth_clientId> - OAuth Client ID from step 3
- Token Service Password: <oauth_secret> - OAuth Secret from step 3
Save

5. Create XSUAA and Destination Service Instances

In order to ensure the application we develop in the next section properly validates authenticated users, checks permissions, and consumes the destinations, we need to create service instances for XSUAA and Destination Service. These will be bound to our backend and Approuter applications

5.1. Create XSUAA Service Instance

Open BTP Cockpit on sub-account level
Go to "Instances and Subscriptions"
Click "Create" button
Fill the creation form with the following
- Service: Authorization and Trust Management Service
- Plan: application
- Runtime Environment: Cloud Foundry
- Space: <space_name> - The space name where your application will be deployed
- Instance Name: <uaa_instance_name> - The name of the XSUAA instances created to be bound to the future app
Click "Next" and provide the bellow entry in the JSON configuration
```
{
  "tenant-mode": "dedicated"
}
```
Finish clicking "Create" on the dialog

5.2. Create Destination Service Instance

As the previous step, open BTP Cockpit and go to "Instances and Subscriptions"
Click "Create" button
Fill the creation form with the following
- Service: Destination Service
- Plan: lite
- Runtime Environment: Cloud Foundry
- Space: <space_name> - The space name where your application will be deployed
- Instance Name: <destination_instance_name> - The name of the XSUAA instances created to be bound to the future app
Finish clicking "Create" on the dialog

6. Develop BTP Application connected to SAP Datasphere

To finish this blog post we will develop a simple suite of BTP Applications. These will simulate any custom-developed, browser-based app on BTP that can call one or multiple SAP Datasphere Consumption APIs. The applications in development are based on the tutorial "Secure a Basic Node.js App with the Authorization and Trust Management Service (XSUAA)". Some details may be omitted to simplify this blog post's content and focus more on the SAP Datasphere integration rather than the XSUAA setup. For any queries, please refer to the complete tutorial.

The architecture of the sample app comprehends a NodeJS-express based application, which serves as a proxy to consume SAP Datasphere models exposed via the Consumption APIs. A SAP approuter-based application will sit above this, taking responsibility for routing, authorization, and handling frontend UI5 assets.

6.1 Exposing an route to SAP Datasphere in your application

Once you complete the tutorial, which should take approximately 25 minutes, we can start making modifications to facilitate calling SAP Datasphere. For flexibility, we will expose one API designed to forward any requests to the SAP Datasphere Consumption APIs (/datapshere/*). The same logic can be applied for integrating any required business logic.

First we need to install the axios library which will be used to make request to Destination Service and SAP Datasphere

npm add --save axios

On myapp/index.js include de following code expose the SAP Datasphere route and consume Destination Service properly (For the blog, all functions have been placed in the index.js - in a productive code it could be organized properly)

...
app.get('/datasphere/*', checkReadScope, async (req, res) => {
	// Get the user token from the request
	const userToken = (req.headers["authorization"]).split(" ")[1];

	// Get the destination for calling the Datasphere API
    const datasphereToken = await findDestinationSAML(
      "Datasphere_Strakiller_2TAPI",
      userToken
    );

		const path = Object.values(req.params).join("/");
		const response = await axios({
			method: "get",
			url: `${process.env.DATASPHERE_HOST}/${path}`,
			headers: {
				Authorization: `Bearer datasphereToken.value`,
				"Content-Type": "application/json",
			},
		});

    res.status(response.status).json(response.data);
});

async function findDestinationSAML(destinationName, userToken) {
	const credentials = xsenv.cfServiceCredentials({ tag: "destination" });
  const token = await getDestinationServiceToken();

  const response = await axios({
    method: "get",
    url: `${credentials.uri}/destination-configuration/v1/destinations/${destinationName}`,
    headers: {
      Authorization: `Bearer ${token}`,
			"X-user-token": userToken,
    },
  });

  if (!response.data.authTokens || response.data.authTokens.length === 0) {
    throw new Error(`Failed to fetch destination, ${response.data}`);
  }

  return response.data.authTokens[0];
};

async function getDestinationServiceToken() {
  const credentials = xsenv.cfServiceCredentials({ tag: "destination" });

  const response = await axios({
    method: "post",
    url: `${credentials.url}/oauth/token`,
    headers: {
      Authorization: `Basic ${Buffer.from(
        `${credentials.clientid}:${credentials.clientsecret}`
      ).toString("base64")}`,
      "Content-Type": "application/x-www-form-urlencoded",
    },
    data: {
      client_id: credentials.clientid,
      grant_type: "client_credentials",
    },
  });
  if (response.status !== 200) {
    throw new Error(
      `Failed to fetch destination service access token, ${response.data}`
    );
  }
  return response.data.access_token;
};

...

On the manifest.yml file under the backend app include the destination service binding

- name: saml-blog-app
  ...
  services:
    - saml-blog-app-uaa
    - destination

Then deploy the changes running:

cf push

Through these modifications, we have established the /products/datasphere/* route in our backend application, which will forward any content provided in the "*" to the SAP Datasphere Consumption APIs. For this to function correctly, the route pattern should align exactly with the Consumption API routes as detailed in the SAP Help and SAP Business Accelerator Hub. For instance, when the route below is activated, it will list all the SAP Datasphere assets that my user account can access.

https://saml-blog-approuter.cfapps.sap.hana.ondemand.com/products/datasphere/api/v1/dwc/catalog/assets

6.2 SAP Datasphere Model for Products

The tutorial currently pulls product data from a static JSON file stored in the repository. This could be enhanced by consuming an SAP Datasphere model to deliver this information via OData APIs. As such, a View or Analytic Model containing product details could be displayed. We'll use the static JSON data to construct a comparable view within SAP Datasphere.

The Product View can be accessed by invoking the URL mentioned below. To display data from SAP Datasphere, update this URL in the UI5 code and make minor adjustments to the JSONModel.

https://saml-blog-approuter.cfapps.sap.hana.ondemand.com/products/datasphere/api/v1/dwc/consumption/relational/<space>/<asserName>/<assetName>

Conclusion

In conclusion, SAP Datasphere facilitates streamlined and scalable access to business data, supporting the business data fabric architecture and promoting data openness and a freedom of choice for analytical frontend solutions. Through its use, businesses can develop customized applications tailored to fit their unique needs. This blog post provided an in-depth guide on how to set up an integration of an SAP Business Technology Platform (BTP) NodeJS application to SAP Datasphere using SAML Bearer Assertion destinations. Among the crucial steps involved in this process include configuring the identity provider, establishing trust, creating an OAuth client, setting up a destination to SAP Datasphere consumption APIs, and ultimately developing a BTP application connected to SAP Datasphere. With this setup, businesses can enhance their customer experience by uplifting their authentication methods through integrations to other applications.

Fiori Elements: Display Tree-Structure using OData Annotation (Code Based)

2024-04-03T10:48:38.613000+02:00

First of all, I would like to explain some libraries to Display tree

sap: hierarchy-node-for
sap: hierarchy-level-for
sap: hierarchy-parent-node-for
sap: hierarchy-drill-state-for

Requirement

We had a requirement to display the projects and WBS Element information that is created in CJ20N Transaction in the Tree format, it felt quite challenging when I tried the first time. We have to display the WBS elements based on respected projects using OData annotations.

Let’s begin with an example,

I have used simple data to display in a tree

Data base tables: zabdemonode

Define your data base table

@EndUserText.label : 'Node structure of a simple tree'

@AbapCatalog.enhancementCategory : #NOT_CLASSIFIED

@AbapCatalog.tableCategory : #TRANSPARENT

@AbapCatalog.deliveryClass : #A

@AbapCatalog.dataMaintenance : #RESTRICTED

define table zabdemonode {

key mandt : mandt not null;

key node_key : tv_nodekey not null;

relatkey : tv_nodekey;

isfolder : as4flag;

expander : as4flag;

text : text40;

seq_no : abap.char(5);

}

I have prepared some test data statically to display

After defining your CDS view, here I have defined the view using one base view.

@AbapCatalog.viewEnhancementCategory: [#NONE]

@AccessControl.authorizationCheck: #NOT_REQUIRED

@EndUserText.label: 'Hierarchy Display'

@Metadata.ignorePropagatedAnnotations: true

@ObjectModel.usageType:{

serviceQuality: #X,

sizeCategory: #S,

dataClass: #MIXED

}

@Search.searchable: true

define root view entity zc_hierarchy_demo

as select from zi_hierarchy_demo

{

@UI.facet: [{ id: 'ID1',type: #IDENTIFICATION_REFERENCE,position: 10,label: 'Project Details' }]

@UI:{lineItem: [{ position: 20,label: 'WBS Element ID'}],

identification: [{ position: 10,label: 'WBS Element ID' }],

selectionField: [{ position: 20 }]}

@EndUserText.label: 'Project'

@Search:{defaultSearchElement: true,fuzzinessThreshold: 0.9,ranking: #MEDIUM}

key NODE_KEY,

@UI:{lineItem: [{ position: 50,label: 'Relative Key' }],

identification: [{ position: 20,label: 'Reference WBS Element ID' }]}

@Consumption.valueHelpDefinition: [{ entity:{name: 'ZI_hierarchy_view',element: 'NODE_KEY'} }]

@Search:{defaultSearchElement: true,fuzzinessThreshold: 0.9,ranking: #MEDIUM}

RELATKEY

@UI.lineItem: [{ position: 30,label: 'OpenFolder' }]

ISFOLDER,

@UI:{lineItem: [{ position: 40,label: 'ExpanderCheck'}]}

EXPANDER,

@UI:{lineItem: [{ position: 10,type: #WITH_URL,label: 'WBS Element'}],selectionField: [{ position: 30 }],identification: [{ position: 30,label: 'WBS Element' }]}

@EndUserText.label: 'WBS Element'

@Consumption.valueHelpDefinition: [{ entity:{name: 'ZI_Dimension_view',element: 'TEXT'} }]

TEXT as Name,

@UI:{lineItem: [{ position: 50,label: 'Drill Down State' }],identification: [{ position: 40,label: 'Drill Down State' }]}

@Consumption.valueHelpDefinition: [{ entity:{name: 'zi_get_sqno',element: 'Number1'} }]

seq_no as SeqNo,

@UI.lineItem: [{ type: #FOR_ACTION,dataAction: 'View',label: 'View' }

cast('expanded' as abap.char( 285 )) as drill_state

}

Once you activate the view by following the Gateway Builder (SEGW) transaction create your project.

Then define your entities by using CDS view

It asks you the CDS view name in the pop-up screen enter your view click on next then define your key field there and click on the finish button

after you define the entity generate artifacts by clicking the button ‘Generate Runtime Artifacts’

once done open your MPC_EXT class and redefine the Define method to define the annotation code based

Follow the below code to Specifies the hierarchy annotation for a specific field

method define.
super->define( ).

data :lr_entity type ref to /iwbep/if_mgw_odata_entity_typ.
data :lr_property type ref to /iwbep/if_mgw_odata_property.
data :lr_annno type ref to /iwbep/if_mgw_odata_annotation.

lr_entity = model->get_entity_type( iv_entity_name = 'zc_hierarchy_demoType' ).
if lr_entity is bound.

lr_property = lr_entity->get_property( iv_property_name = 'NODE_KEY' ).

lr_annno=lr_property->/iwbep/if_mgw_odata_annotatabl~create_annotation( iv_annotation_namespace = /iwbep/if_mgw_med_odata_types=>gc_sap_namespace ).

lr_annno->add( iv_key = /iwbep/if_ana_odata_types=>gcs_ana_odata_annotation_key-hierarchy_node_for iv_value = 'NODE_KEY' ).

lr_property = lr_entity->get_property( iv_property_name = 'SeqNo' ).
lr_annno=lr_property

>/iwbep/if_mgw_odata_annotatabl~create_annotation( iv_annotation_namespace = /iwbep/if_mgw_med_odata_types=>gc_sap_namespace ).

lr_annno->add( iv_key = /iwbep/if_ana_odata_types=>gcs_ana_odata_annotation_key-hierarchy_level_for iv_value = 'NODE_KEY' ).

lr_property = lr_entity->get_property( iv_property_name = 'RELATKEY' ).
lr_annno=lr_property-

>/iwbep/if_mgw_odata_annotatabl~create_annotation( iv_annotation_namespace = /iwbep/if_mgw_med_odata_types=>gc_sap_namespace ).

lr_annno->add( iv_key = /iwbep/if_ana_odata_types=>gcs_ana_odata_annotation_key-hierarchy_parent_node_for iv_value = 'NODE_KEY' ).

lr_property = lr_entity->get_property( iv_property_name = 'drill_state' ).

lr_annno=lr_property->/iwbep/if_mgw_odata_annotatabl~create_annotation( iv_annotation_namespace = /iwbep/if_mgw_med_odata_types=>gc_sap_namespace ).

lr_annno->add(iv_key=/iwbep/if_ana_odata_types=>gcs_ana_odata_annotation_key-hierarchy_drill_state_for iv_value = 'NODE_KEY' ).

endif.
endmethod.

After Save (Ctlr+s) and Activate (Ctrl+F3) MPC_EXT and Generate your artifacts. Once done register your service and generate the metadata, here in the metadata file, you can notice one thing, the property that you have mentioned for hierarchy should display.

If not, the tree table will not display your hierarchy.

Let’s create a Fiori Application

Before starting the process, make sure to have the extension packages in VS code then only we can create the Fiori app.

Open VS Code Goto view in the menu and click on command palette(ctrl+shift+P), after search

Fiori: Open Application Generator; it will open the template Wizard

Select one template based on your requirement

Then Connect your backend system

If you are not registered you have to register your backend system else you can go with OData service directly.

After providing your OData service name and clicking on the next button

Then select your main entity and provide the project name after clicking on the Finish button

Then it will install some required dependencies for the Fiori Application, once done it will open the application info inside and click on ‘open page map’

Inside that edit your object page then click on the table option. It will open some properties related to the list report page there you have to change the type of your table.

After previewing your application you can see the expected outcomes

Conclusion:

this requirement helps in displaying the Hierarchy format using the Tree table in the Fiori application.

Hope I find it will we be helpful. If any queries please welcome on comment sections.

Note: All the images shown in this blog are the snapshots that are taken from my PC.

Regards,

Srinivasa M R

Integrate C4P-Resource Management with SAP Analytics Cloud or SAP DataSphere

2024-04-04T22:27:35.922000+02:00

Summary

Embarking on the journey of leveraging SAP S/4HANA Cloud for Projects, Resource Management (C4P), this blog simplifies the process of accessing its APIs, with a focus on the Resource Request functionality. Beginning with preparations, where we gather key information like API URL and credentials, we then explore the capabilities of the Resource Request API in the Business Accelerator Hub. We break down how to find the right URL for accessing resource requests and demonstrate how to connect these APIs to tools like SAP Analytics Cloud or SAP DataSphere. By following these steps, users can seamlessly integrate data from C4P into their analytics workflow, enabling better decision-making and operational efficiency.

Preparation Step:

You have to Set Up the API Access for for SAP S/4HANA Cloud for Projects, Resource Management

And at step 7 of Creating a Service Key, please note down all of the information mentioned in the table below. We will use them to fill in the connection information in either SAP Analytics Cloud or SAP DataSphere later.

For example:

{
    "apiUrl": https://resource-management-api-projectscloud.cfapps.eu10.hana.ondemand.com,
    "uaa": {
        "clientid": "sb-............................................................265",
        "clientsecret": "49...............................................................vc=",
        "url": https://cp..........w.authentication.eu10.hana.ondemand.com,
        "identityzone": "cp..........w",

apiUrl: is the main part of the OData Service URL and we will add path to this URL in the later step.

clientid: is OAuth Client ID in SAC OData Service Connection dialog

clientsecret: is Secret in SAC OData Service Connection dialog

url: is the base of token URL. The full token URL should be:

https://cp..............w.authentication.eu10.hana.ondemand.com/oauth/token

In Business Accelerator Hub, you will see four cards. Each of them contains a collection of request methods based on OData API. However, only Assignment and Resource Request contain GET method. Project Experience and Workforce Availability don't support GET method. Hence, only queries from Assignment and Resource Request can be imported and consumed in SAP Analytics Cloud and DataSphere. And this blog will take the Resource Request OData API as an example.

Step1: Check API Reference and Capability

Click on the card of Resource Request > Click on API Reference
You will see the GET method is supported for Resource Request.

However, in the Workforce Availability. Only POST method is supported. This is the reason that we are not able to leverage this endpoint in the Analysis Application

Step2: Find OData Service URL for Resource Request

Click on the card of Resource Request > Click on Try Out
Select /ResourceRequests from the method section > click on Environment: Sandbox > Select Add New Environment
In the prompt window > find Starting URL. By following the format, you can add the path of /ResourceRequestService/v1 to the end of the apiUrl which you noted down at the preparation step. For example, like the screenshot below. (In the same vein, the URL logic also applies to Assignment)

(This apiUrl will be used for connection later.)

Step3: Build Connection in SAC

Now, you have obtained all required the information. And you can build the OData Services Connection in SAP Analytics Cloud or SAP DataSphere. For example, like below screenshot.

OData Service Connection supports scheduling import in SAP Analytics Cloud. You can leverage this feature to update the data in the model.

Tips:

If you have DataSphere, you can use DataSphere to restructure the query and then visualize the data in SAP Analytics Cloud.
If you find the data from one single query is not enough and you don't have DataSphere. You can leverage the data blending feature in SAP Analytics Cloud to combine the data visualization from different sources.

How to develop Customer creation Application in SAP Build Apps with OData service

2024-04-05T16:34:12.935000+02:00

Objective: -

Implementing SAP OData URI to SAP Build and Creating Customers in SAP BUILD which can replicate to SAP System

Business Scenario: -

How to create Customers using SAP Build Apps and OData Service.

Prerequisites: -

-> You Have an SAP BTP account or trial account.

-> Inside the BTP account, go to Instances and Subscriptions and create an instance of SAP Build Apps

-> Now go to Security -> Users Tab and assign Role to the user for SAP BUILD Apps

Now, we have to create the SAP Backend connection to SAP BTP : -

Before mapping data from S4H or our SAP System to Build Apps, we need to create a Destination in the BTP and give the required details of the S4H system with ODATA Uri too which we will consume (BTP->Connectivity->Destination )

Connection is now established to that service.

Now go to SAP Build Apps and navigate to Create to create a project.

Now click on Build an Application to create a Application

Now Click on Web & Mobile Application

Now Give the project name and Description and You are good to go.

Inside the app you are working on SAP Build App go to the Authentication section and implement authentication

Now create an App Variable that holds all fields that are present in our OData service.

Now create a page and install a template from the marketplace which is Basic List and implement your UI for Customer Creation and a home page where all customers are displayed.

Now go to the DATA Section then go to SAP Systems and connect to your s4h System and the service that you called from the destination from SAP BTP will be available to you now.

Now Click on this list go to ‘list resource’ fill in all the fields and configure authentication from Properties

Now Go to the Logic section of List and implement logic like this

Now click on the Create button go to Show logic for Button then implement this logic

Now create another page as shown below and build a form to create Customer Data using input fields.

Now do data binding to all fields by clicking on it and then assigning value to it

Now do a similar mapping for every field

Also, implement a condition to alert that an empty value is not allowed.

Now on the submit button implement logic that submit the data and updates the data to that OData service and thus will be reflected in the database table too

Preview Your Developments: -

Now when everything is done go to the Launch section then Preview your app.

By this, we can preview our application either on the web or can be previewed in Smartphones.

Our Application Now looks like-

When we click on the create button the second page appears

Fill out details and now our customer is created.

So now your customer is created in your database table which you can check by going to se11->KNA1

And you can see your entry got updated in table KNA1

Consuming CAPM Application's OData service into SAP Fiori Application in Business Application Studio

2024-04-16T12:50:31.978000+02:00

OBJECTIVE-:

Consuming OData Service of CAPM Application into SAP Fiori Application in Business Application Studio.

CAPM (Cloud Application Programming Model)-:

It is an open-source framework that uses tools, libraries, and languages to create applications that can be used across multiple SAP products. CAPM is a multi-target application that runs at different times, with the persistence layer running in the HANA DB run time, the server layer running in the Node.js run time, and the UI/UX layer running in the browser run time.

CAPM is one of the approaches to developing cloud applications using the BTP platform. CAPM offers a more structured and seamless framework for data modelling and enhancing integration with services.

Advantage of CAPM over other approaches-:

It enables full-stack development in the same environment. (BAS), eliminating the need to switch between different environments for the backend and frontend development.
It offers flexibility in language selection, allowing developers to work with multiple languages according to their needs. BAS provides easy connectivity to required extensions for this purpose.
Seamless integration with git and other applications via APIs facilitating extension or development of the application.
Automatically handling dependencies to a certain extent, reducing frustration, and improving development speed. For example, handling the OData after exposing all entities and making it easier to consume in the UI.

Prerequisites-:

Create a CAPM project.
Log in to Cloud Foundry Credentials.
Ensure the HANA Database is created and running (I Used it for storage and data creation).

Set up a Dev Space.
Create a SAP Build Work Zone instance to act as a Fiori Launchpad for the CAPM Application

You Have to create a new Destination in BTP (Connectivity -> Destination)-:

This destination will be used for passing system information when creating a Fiori Application.

For the URL, DEPLOY YOUR APPLICATION IN CLOUD FOUNDRY (Cloud Foundry ->Spaces ->Dev (Space Name)->Your Service (here it is CAPMChetan-srv) and copy Application Routes).

This URL will be shown only when you deploy your CAPM Application in Cloud Foundry-> A new blog will be there to deploy the CAPM Application.

For Authorization, use the same authorization as created in the package.json -> a new blog will create a security configuration.

Now that the destination for the service is configured, proceed to create a FIORI APP: -

Open SAP BAS (Business Application Studio).
Open DEV Space where you want to create a Fiori Application.
Go to File -> New Project From template.
Choose a project from the Template (SAP Fiori Application).

Choose any Template of your choice.

In Data Source choose to connect to a system.

Specify the Destination created earlier.

In the service path, specify the service path of the OData service that can be obtained by running the command “cds watch –profile hybrid” in your CAPM Project.

Click on next.

Select any entity from the given list of entities you created in your project.

Customize the project attributes.

Choose the target as Cloud Foundry and select the Destination name among the list of destination names (You can go with either Local CAPM Project API and the name of your destination too).

Now, your FIORI project is created and is ready to use.

Go to run configuration and start the project as usual.

You can now run this Fiori Application which is the result of an Application created from CAPM.

Syniti RDG streamlines creation and configuration of MDC process templates.

2024-05-14T10:41:20.003000+02:00

Syniti Rapid Data Governance (RDG) is an SAP-endorsed Cloud-Based UI5 application built on the SAP Business Technology Platform (BTP). SAP Master Data Governance is a powerful solution to improve the quality and consistency of information across organizations by consolidating and centrally governing master data. Syniti RDG’s MDC tile streamlines the creation and setup of process templates and the configuration of its process steps.

Master Data Consolidation (MDC) refers to the process of combining and centralizing master data from disparate sources into a single System. This ensures that there is a consistent and accurate version of master data, such as customer, product, or supplier information, across an organization.

In SAP, Process Templates are predefined sets of steps and configurations that standardize the master data consolidation process. The Process Template you choose during a consolidation process specifies whether and in what order certain process steps are executed and what configurations apply for each step.

By utilizing process templates, organizations can accelerate the master data consolidation process and maintain data integrity across different systems and business units within the SAP landscape. Additionally, process templates facilitate compliance with regulatory requirements and supports ongoing data governance efforts by establishing standardized procedures for managing master data consolidation activities.

To create a process template, traditionally a user had to follow the standard guide to setup process templates:

Select New Entries.
Enter a Process Type ID, a corresponding Description, select the Business Object Type, and the Workflow Template WS54500001.
In the Process Goal field, select the goal of a consolidation process.
Decide for the Default Template and the Delete Source indicators.
Save your entries.

Then to configure said process template a user would have to follow the standard guide to setup its process steps.

Mark a process type template and choose Process Template Step
Select New Entries.
Enter a Step Number.
Select a Process Step Type using the input help.
Select a corresponding Adapter using the input help.
Select a corresponding Configuration ID.
If you want the process to stop after finalizing this process step set the Check Point indicator.
If you want to assign an Authorization Group to the process step use the entry help to select an authorization group.

Pertinent configurations specific to each step type are identified by the Configuration ID. If a user would like to visualize the details for each configuration or create a new one, they would have to navigate to the MDCIMG t-code and select the activity related to the step type desired to configure.

Then a user would have to navigate the list of configurations and select the config id chosen in the process template and double-click it to visualize its detailed settings.

The Master Data Consolidation (MDC) tile on RDG streamlines this whole process by allowing users to create and delete process templates, process steps and its configurations within a single and intuitive screen and define a specific template that outlines the steps and configurations for executing a master data consolidation process.

STEP 1. On the Main screen click on the MDC Tile.

STEP 2. Click on the plus icon to add a new process template.

STEP 3. Input process template name and description and choose a Business Object Type (BO Type).

STEP 4. Select a process goal and decide for the Default Template and the Delete Source indicators.

Process Goal refer to the specific objectives or outcomes that organizations aim to achieve through the implementation of process templates. Depending on the goal selected the user might need to also select a strategy.

STEP 5. To add a process step click on the Add button, select a step type, input a description and make selections for Adapter, Config ID, Action Control and Authorization Group.

STEP 6. Add extra process steps to meet the business requirement and goal of the consolidation prosses.

STEP 7. If needed, user can create and/or visualize the configurations for steps. To visualize the details of a selected configuration, click on the View Details pencil icon. To create a configuration, select “Custom – Create configuration” from the list of configurations.

NOTE: At the time of publishing this blog, RDG supports configurations for steps of type: Activation, Filter and Remove, Best Record Calculation and Evaluation. More to come in future updates.

Details of a Best Record Calculation configuration:

Details of a Filter and Remove configuration:

Details of an Activation configuration:

STEP 8. Click on save and select a customizing transport from the available list.

Using the MDC Tile users can maintain and create process templates in a streamlined and intuitive manner.

Syniti RDG is a certified SAP BTP solution and is available on SAP App Store.

To know more details about the product, check the blog Partner Add-on Solutions.

Your opinions and feedback are highly appreciated and feel free to post them in comment section.

Please follow and read more interesting blogs on SAP Master Data Governance | SAP | SAP Blogs.

You can also find and post questions about the product here: SAP Master Data Governance Community.

Syniti RDG provides an effortless way to create Data Model extension.

2024-05-16T09:08:22.041000+02:00

In SAP Master Data Governance data can be stored in a staging or active area. Extending the data model with custom attributes or tables involves changes to the data structures in both the active and staging areas and defining a mapping between these data structures.

Traditionally, a user must perform the following steps to assign to do this configuration in SAP MDG System.

Extending active area data model
Extending staging area data model
Generating MDG tables
Defining mapping from Staging to Active area
Defining mapping from Active to Staging area

RDG provides the solution to extend SMT Mapping with an intuitive, user-friendly, and graphical interface.

After a custom attribute is created and activated in either Business Partner or Material data models, an entity table for SMT mapping will be shown if applicable. (SMT mapping is not relevant for attributes created under all entities).

After custom attribute is created and activation is complete mapping table will be shown.
Complete the mapping table by selecting a mapping step and structure to extend for each row. Source and Target will automatically populate. Click

at the end of each row.
Click Done. Processing may take some time to complete. Click Refresh when ready and receive success messages. If running the application using a cloud platform, additional notifications will be given to help you track the process.
Extension, transformation and mapping are created correctly

Syniti RDG is a certified SAP BTP solution on the SAP App Store.

To know more details about the product, check the blog Partner Add-on Solutions.

Your opinions and feedback are highly appreciated, and feel free to post them in the comment section.

Please follow and read more interesting blogs on SAP Master Data Governance | SAP | SAP Blogs

You can also find and post questions about the product here: SAP Master Data Governance Community

How to use the OData-API for exchanging Messages from Logs and the Datastore in Integration Suite

2024-05-16T09:36:10.757000+02:00

In this blog I will show the basic steps and components to access the MessageProcessingLog and the attached messages, wether they are stored in the log itself, in the MessageStore or in the DataStore.

Later in further blogs I will go into details and show some specific implementations and will compare the different types of message-stores. So please be patient and check back for further information.

The starting point is in the SAP Business Accelerator Hub. There is an API package SAP Cloud Integration which offers some OData APIs in Version 2. We are focussing on the Message Processing Logs and download the definition of, what is called here a vdm - virtual data model. I don't want to go deeper in the edmx, only so far, if you search on your fav. search-engine you may get the following statement:

edmx file is an XML file that defines an Entity Data Model (EDM), describes the target database schema, and defines the mapping between the EDM and the database.

On the Business Accelerator Hub you can find tons of documentation about how to use the source code generator in maven, on how to build up (in this case) java-classes, test the API online, with a sandbox or with your own tenant and even code-snippets in many different languages can be downloaded.

In our scenario we build a client in the Netweaver Development Studio. Then maven-support is initially not part of it but can be added. Search for the keyword M2E. A good starting point on how to generate the client classes (vdm - virtual data model) and how to generate a project from a Maven archetype is on sap.github.io .

The overall framework for the implementation here is an OnPremise fat-client, but everything can run deployed on a BTP tenant, only the GUI frontend needs to be changed.

What you get when generating the sources for your client is the following helper-packages and classes and a MessageProcessingLogsService:

There are several steps to consider for enhancing your pom-file: Dependencies and plugins. E.g. here: SAP Cloud Application Programming Model: Deep Insert (5) Consume Remote Service with SAP Cloud SDK

The starting point here is the method getAllMessageProcessingLogs()

Depending on wether the code runs on your local laptop or in the cloud, you have to create a destination first:

import com.sap.cloud.sdk.cloudplatform.connectivity.AuthenticationType;
import com.sap.cloud.sdk.cloudplatform.connectivity.DefaultHttpDestination;
import com.sap.cloud.sdk.cloudplatform.connectivity.HttpDestination;
import com.sap.cloud.sdk.cloudplatform.security.BasicCredentials;

(...)
public DefaultHttpDestination getDestination() throws IllegalArgumentException	{
	if (destination == null)	{
		if (this instanceof BasicAuthentication)	{
			destination = DefaultHttpDestination.builder(tenant.getURL())
				.authenticationType(AuthenticationType.BASIC_AUTHENTICATION)
	   	    	.basicCredentials(new BasicCredentials(((BasicAuthentication)this).getUser(), ((BasicAuthentication)this).getPassword()))
	   	    	.keyStore(keystore)
	   	    	.build();
		}
	}
	return destination;
}

(On your tenant you can use the DestinationService)

With the destination described above we can request all packages and artifacts. As for now the request is sent by getAllIntegrationRuntimeArtifacts(). This includes iFlows but also Rest-APIs and more.

Unfortunately

runtime-artifacts do not point to any package
designtime-artifacts are called from a package-perspective but do not include some types like Rest-APIs.

(Status on 2024-05-24 is a response of HTTP 501 - not yet implemented. the dev is seems still working on putting everything in place)

Hence we have a gap of links between packages and artifacts, in case they are not iFlows (e.g. Rest-Api). The following code puts "everything" together as complete as possible and attaches the artifacts without a link to a package into a virtual package named "<unknown>"

//create Hashtable for storing our version of packages
designPackages = new Hashtable<String, DesignPackage>();

if (authentication != null)	{
	//get url
	String tenantURL = authentication.getTenant().getRuntimeURL();
	
	//create destination
	DefaultHttpDestination destination = authentication.getDestination();
	
	//create the services generated in the vdm
	IntegrationContentService iCS = new DefaultIntegrationContentService().withServicePath("/api/v1/");
	
	//create Hashtable for storing our version of runtime artifacts
	Hashtable<String, IntegrationRuntimeArtifact> ira_table = new Hashtable<String, IntegrationRuntimeArtifact>();
	
	//retrieve all packages, execute the network-request
	try {
		final List<IntegrationPackage> ip = iCS.getAllIntegrationPackages()
				.executeRequest(destination);
		
		//retrieve all runtime artifacts
		final List<IntegrationRuntimeArtifact> ira = iCS.getAllIntegrationRuntimeArtifacts()
				.executeRequest(destination);
		
		//and put them in the table
		for (IntegrationRuntimeArtifact ira_iter : ira)
			ira_table.put(ira_iter.getId(), ira_iter);
		
		//iterate over all packages
		for (IntegrationPackage ip_iter : ip) {
			
			//store it in our Hashtable
			DesignPackage dp = new DesignPackage(ip_iter);
			designPackages.put(dp.getName(), dp);
			
			//get artifacts for this package
			final List<IntegrationDesigntimeArtifact> ida = ip_iter.getIntegrationDesigntimeArtifactsOrFetch();
			
			//set artifacts as child to the package
			for (IntegrationDesigntimeArtifact ida_iter : ida) {
				String url = tenantURL + "/http/" + ida_iter.getId();
				Artifact a = new Artifact(ida_iter, url);
				dp.addArtifact(a);

				//remove from the list of runtime artifacts
				ira_table.remove(a.getId());
			}
		}
		
		//add remaining artifacts not linked to any package
		if (ira_table.size() > 0)	{
			
			//default package
			IntegrationPackage integrationPackage = new IntegrationPackage();
			integrationPackage.setName("<unknown>");
			defaultDesignPackage = new DesignPackage(integrationPackage);
			designPackages.put(defaultDesignPackage.getName(), defaultDesignPackage);
			
			Enumeration<String> t = ira_table.keys();
			while (t.hasMoreElements())	{
				String iraId = t.nextElement();
				Artifact a = new Artifact((IntegrationRuntimeArtifact)ira_table.get(iraId), tenantURL + "/http/" + iraId + "/*");
				defaultDesignPackage.addArtifact(a);
			}
		}
	} catch (com.sap.cloud.sdk.datamodel.odata.client.exception.ODataConnectionException e) {
	} catch (ODataException e) {
	} catch (Exception e) {
	}
}

Having all packages and artifacts in place, we can get a (filtered) set of log-entries:

/**
* Returns an ArrayList of LogEntries. 
* The list is based on the filtering.
* <p>
* This methods processing-time depends on the amount of data requested from BTP.
* The status should be set on the GUI for user-information.
* In future releases this method will work in a background-task.
*
*  authentication object relevant for login and serving a destination based on this creds
*  logListFilter the object for filtering the requested logs, i.e. datetime and number of entries
* @return ArrayList of LogEntries. 
*/
public ArrayList<LogEntry> updateMessageProcessingLog(Authentication authentication, LogListFilter logListFilter)	{
	
	ArrayList<LogEntry> logEntries = new ArrayList<LogEntry>();
	
	if (authentication != null)	{
		MessageProcessingLogFluentHelper mPLFH = mPLS.getAllMessageProcessingLogs();
		
		//logs should be filtered always by artifact-id (which is unique)
		if (logListFilter.getArtifact() != null)
			mPLFH = mPLFH.filter(MessageProcessingLog.INTEGRATION_FLOW_NAME.eq(logListFilter.getArtifact().getId()));
		
		//number of results limited by number?
		if (logListFilter.getCountFilterEnabled())	{
			mPLFH = mPLFH
			.skip(logListFilter.getCountFilterFrom() - 1)
			.top(logListFilter.getCountFilterTo());
		}
		
		//filtered by date?
		if (logListFilter.getDateFilterEnabled())	{
			//set start and end, logListFilter returns a @LocalDateTime 
			mPLFH = mPLFH.filter(MessageProcessingLog.LOG_START.gt(logListFilter.getDateTimeFilterStart()));
			mPLFH = mPLFH.filter(MessageProcessingLog.LOG_END.lt(logListFilter.getDateTimeFilterEnd()));
		}
		
		//the result is always ordered ascending by the LogEnd
		mPLFH = mPLFH.orderBy(MessageProcessingLog.LOG_END, Order.ASC);
		final List<MessageProcessingLog> mpl = mPLFH.executeRequest(authentication.getDestination());
		
		for (MessageProcessingLog mpl_iter : mpl)	{
			logEntries.add(new LogEntry(mpl_iter));
			
			try	{
				List<MessageStoreEntry> messageStoreEntries = mpl_iter.fetchMessageStoreEntries();
				if (messageStoreEntries != null)
					for (MessageStoreEntry mse : messageStoreEntries)	{
						List<MessageStoreEntryAttachment> mSEAs = mse.fetchAttachments();
						//in future releases <do_something> with the MessageStoreEntries and their attachments
					}
			}
			catch(com.sap.cloud.sdk.datamodel.odata.client.exception.ODataResponseException e)	{
				System.out.println("com.sap.cloud.sdk.datamodel.odata.client.exception.ODataResponseException");
			}
		}
	}
	
	return logEntries;
}

The result, shown as a Java-GUI is as following:

The java-object MessageProcessingLog and corresponding ..Attachment is based on the classes automatically created within the generator-plugin:

With that code we can retrieve the payload on any message starting from object MessageProcessingLog retrieve a MessageProcessingLogAttachment with the following code:

import com.sap.cloud.sdk.datamodel.namespaces.messageprocessinglogs.MessageProcessingLog;
import com.sap.cloud.sdk.datamodel.namespaces.messageprocessinglogs.MessageProcessingLogAttachment;

(...)

//the messageprocessinglog returns a java-List of attachments
List<MessageProcessingLogAttachment> mplAttachments = null;
try {
	mplAttachments = messageProcessingLog.fetchAttachments();
	
	//create a Hashtable which we use to store a local object version of attachment, keys derived from the attachment-name
	attachments = new Hashtable<String, LogAttachment>();
	for (MessageProcessingLogAttachment mpla_iter : mplAttachments) {
		LogAttachment logAttachment = new LogAttachment(mpla_iter);
		//use the name as key and put the attachment in the hashtable
		attachments.put(mpla_iter.getName(), logAttachment);
		
		//this logEntry has an attachment
		hasAttachment = true;
	}
	isPrepared = true;

} catch (Exception e) {
	// TODO Auto-generated catch block
	e.printStackTrace();
}

Different to the previous approaches, the attachment itself (payload) is not provided as a java-object, but by an InputStream. It will be stored in a String and returned by a getter:

//the constructor gets the 'mpla' when instantiated
public LogAttachment(MessageProcessingLogAttachment mpla)	{
   this.mpla = mpla;
}

//prepare the payload seperate from the getter (for caching purpose)	
public void preparePayload()	{

    InputStream is;
    try {
	is = mpla.fetchMediaStream();
		
	if ( is instanceof ByteArrayInputStream)	{
	  int n;
	  try {
	    n = is.available();
	    byte[] bytes = new byte[n];
	    is.read(bytes, 0, n);
	    payload = new String(bytes, StandardCharsets.UTF_8);
	  } catch (IOException e) {
	    e.printStackTrace();
	  }
        }
    } catch (ODataException e) {
      // TODO Auto-generated catch block
      e.printStackTrace();
    }
}
//getter for returning the payload as a String 
//Todo for a future release: what happens if a payload is 'big'? Let's say > 10mb. 
//We don't want to store that in memory in a String!?
public String getPayload()	{
	
    if (payload == null)
      preparePayload();
	
    return payload;
}

Based on the code shown in this blog any app can download, show and also re-send the payload to it's origin:

Stay tuned for further blogs describing details. Don't hesitate to request details in which you are interested.

Best regards Jörg Hopmann

Syniti RDG provides a simplified design to create Multi Value Validation and Derivation Rules

2024-05-17T12:35:22.385000+02:00

Syniti RDG is an SAP-endorsed application on the Business Technology Platform (SAP BTP) to facilitate MDG
implementation with intuitive UI and process automation. RDG automates many of the technical configuration
steps that are required to implement SAP MDG and it offers a user-friendly interface to be more relatable
to business users.

A multi-value check rule is for validating multiple attribute values against a logical condition.
A multi value derivation rule is to derive multiple attributes values based on a logical condition.

The below example is used to create Multi value validation to be triggered for a specific Change Request Type
to validate attribute values of Entity ‘BP_CENTRL’ of data model ‘BP’.

Step 1: Create Multi Validation Rule in Syniti RDG

In the main menu, select "Manage Business Rules".

In the business Rules Page, define a New Rule: Start by creating a new rule, select the type of rule as "Multivalue Check Rule" to create.

In the following steps, the user can choose a Change request type from the list and select the entity for which
the rule must be created. The user then needs to select the type of Business Rule that he/she wants to create,
Mutli Value Check Rule to create Validation Rule in BRFPlus and Derivation Rule to create Derivation Rule in
BRFPlus.

Select Data model as ‘BP’, ‘ZBP1P1V1’ CR Type (select relevant CR type as required) , Entity as ‘BP_CENTRL’,
Rule type: Multi Value Validation and then click on an option like "Rule1” to start defining a new validation rule.

Business Scenario: Only Green business partners are allowed to create. Choose the attributes
BP_CENTRL~NAME_ORG1 that needs to be validated. If BP_CENTRL~NAME_ORG1 = ‘RED’, send a warning message ‘Enter name1 as Green’

Click’+’ to create "Rule2” validation rule. If BP_CENTRL~NAME_ORG1 = ‘YELLOW’, send a warning message ‘Enter name1 as Green’

Click’+’ to create "Rule3” validation rule. Define a new condition

If BP_CENTRL~NAME_ORG1 = ‘GREEN’ and BP_CENTRL~NAME_ORG2 != ‘CORP’ , When the conditions are not met, send error message ‘Enter name2 as CORP’

Multi value validation BADI implementation has bee created in the back end automatically to check the multi value validation.

Step 2: Trigger the rule in nwbc application.

The rules created in the previous step are triggered when creating a Change Request of the type for which the rules are created in RDG (ZBP1P1V1).

Validation Rule1 :

Now name1 is entered as GREEN, Error message appears for name 2

Validation Rule3:

After successful verification of Validation Rule1 & Rule 3 , ‘No Errors found’

Below is the Decision table that got automatically generated in BRFPlus through Syniti RDG.

Validation Rules created in FMDM Catalog automatically in decision table format

Multi Derivation Rule: Most of the steps are similar to Multi Validation rules, except here we have to mention
the multiple deriving attributes which is derived based on satisfying certain condition

In the business Rules Page, define a New Rule: Start by creating a new rule, select the type of rule as "Multi Value Derivation Rule" to create.

Step 1 : Select Data model as ‘BP’, ‘ZBP1P1V1’ CR Type (select relevant CR type as required) , Entity as ‘BP_CENTRL’,
Rule type: Multi Derivation and then click on an option like "Rule1” to start defining a new derivation rule.

Business Scenario: For all Green business partners, derive multiple attributes like Salutation, Title, BU search term1,
BU search term2 through multi value validation rules, for the ease of understanding, simple business derivations rules are taken and
explained here, there is no restriction to create multiple rules with multiple condition.

If BP_CENTRL~NAME_ORG1 = ‘GREEN’, following attributes will be derived automatically upon successful validation rules

BP_CENTRL~BU_SORT1, BP_CENTRL~BU_SORT2, BP_CENTRL~TITLE_LET, BP_CENTRL~TITLE_BP

After saving the Mutli value derivation business rule thru RDG, Multi value derivation BADI implementation has been
created / updated in the back end automatically to derive multiple attributes

Step 2: Trigger the rule in NWBC application.

Multi Value Derivation Rules created in FMDM Catalog automatically in decision table format

With the help of Syniti RDG, you can now create multi value validation / derivation rules without the effort of creating
Custom BADI implementation in the backend and it simplifies the way of creating decision tables automatically in BRFPlus.

Syniti RDG is a certified SAP BTP solution and is available on SAP App Store.

To know more details about the product, check the blog Partner Add-on Solutions.

Your opinions and feedback are highly appreciated and feel free to post them in the comment section.

Please follow and read more interesting blogs on SAP Master Data Governance | SAP | SAP Blogs

You can also find and post questions about the product here: SAP Master Data Governance Community