Prerequisites:

1. Proficiency in JavaScript and JSON: Custom widgets in SAC are developed using JavaScript and defined using JSON files. Ensure that you have a good understanding of these languages and their syntax.
   
2. Development Environment: Set up a development environment with the necessary tools for JavaScript development, such as a code editor (e.g., Visual Studio Code) and a web browser for testing.
   
3. SAP Analytics Cloud Tenant: Access to an SAC tenant where you can create and test custom widgets. This may require coordination with your SAC administrator or IT department.
   
4. Access to Documentation and Resources: Familiarize yourself with the official SAP documentation and resources related to custom widget development in SAC. This includes the SAC Developer Guide, API reference documentation, and any relevant tutorials or guides provided by SAP.
   
5. Understanding of Widget Lifecycle and Events: Gain an understanding of the lifecycle of custom widgets in SAC, including initialization, rendering, data binding, and event handling. Understanding how widgets interact with the SAC environment will be crucial for developing robust and efficient solutions.
   
6. Testing Environment: Set up a testing environment where you can deploy and test your custom widgets in a controlled environment before deploying them to production. This could be a sandbox or development environment within your SAC tenant.

Why Custom Widgets?

SAC provides a rich set of pre-built visualizations and functionalities. However, there are instances where users may require specialized visualizations or interactions that aren’t available out-of-the-box. This is where custom widgets shine. By creating custom widgets, users can tailor their analytics applications to address unique business requirements, enhancing decision-making and driving business outcomes.

Developing a Custom Widget

Developing a custom widget in SAC is a straightforward process. It begins with defining the widget’s properties and behaviours using a JSON file. This file specifies the widget’s appearance, data binding, interactions, and any custom logic required. Once the JSON file is defined, it can be uploaded to SAC, where it is rendered as a fully-functional widget within the application.

During the development process, I found the documentation provided by SAP to be comprehensive and user-friendly, guiding me through each step with clarity. Additionally, the SAC community forums proved to be an invaluable resource, offering insights and solutions to common challenges encountered during widget development.

Step 1:

Download the git bash using the below commands

Step 2:

Download the git angular file using the below command in git bash

Step 3:

Go into your file location and execute “npm i”

Step 4:

Once you installed the angular ,execute “node server.js” to enable localhost 3000

Step 5:

Execute “ngrok http 3000”

Step 6:

Copy the forwarding link from output and add “static/googleGauge.png” and “static/googleGauge. js” and paste in 7th and 15th line like in the below image

Step 7:

Search “Google gauge chart cdn” go to the link in the src from the below image and copy the js code

https://www.gstatic.com/charts/loader.js

Step 8:

Remove the selected lines in the below image and paste the code in googleGauge.js

Now your JSON file is ready.

Step 9:

Login to your SAC in Chrome/Edge

And open analytical application.

Step 10:

Navigate to Custom widget and use that ‘+’ icon to add your JSON file.

Step 11:

Once your JSON file successfully imported, again navigate to analytical application and create a new analytical application.

Note: As Classic Design Experience mode is deprecating, prefer optimised mode for better experience.

Step 12:

Go to insert -> custom widget -> choose your desire JSON file.

Step 13:

Once you added that JSON file the design you build in VS code will be replicated here. Then add input field, two buttons for plus and minus.

On-Initialise Code:

Minus Button Code:

Add Button Code:

Canvas Code:

Output:

I gave ‘123’ as Label and checked ‘+’, ‘-‘ buttons were working fine.

Limitations:

1. Limited Browser Support: Custom widgets are rendered using web technologies such as HTML, CSS, and JavaScript, which may not be fully supported across all web browsers. Ensure compatibility with supported browsers, as specified by SAP, to avoid potential rendering issues for end-users.
   
2. Performance Considerations: Custom widgets may introduce performance overhead, especially if they involve complex calculations or data processing. Be mindful of performance implications and optimize your custom widgets accordingly to ensure a smooth user experience.
   
3. Dependency on SAC Updates: Custom widgets may rely on SAC APIs or underlying platform features, which could be subject to change with platform updates. Regularly review SAP’s release notes and announcements to stay informed about any changes that may impact your custom widgets.
   
4. Limited Debugging Tools: Debugging custom widgets can be challenging, as SAC provides limited debugging tools compared to traditional web development environments. Utilize browser developer tools and logging mechanisms within your custom widgets to aid in troubleshooting and debugging.
   
5. Security Considerations: Custom widgets execute within the SAC environment and have access to sensitive data. Ensure that your custom widgets adhere to best practices for security, such as data encryption, input validation, and protection against common web vulnerabilities like cross-site scripting (XSS) and injection attacks.
   
6. Lack of Official Support for Third-Party Libraries: While SAC allows you to use third-party libraries within custom widgets, SAP does not officially support or guarantee compatibility with all libraries. Exercise caution when incorporating third-party dependencies and thoroughly test their compatibility with SAC.
   
7. Limited Accessibility Features: SAC custom widgets may lack built-in accessibility features, such as keyboard navigation and screen reader support. Ensure that your custom widgets adhere to accessibility standards to provide an inclusive user experience for all users.
   
8. Development Complexity: Developing custom widgets requires proficiency in web technologies such as JavaScript, HTML, and CSS. Additionally, understanding SAC’s widget API and platform-specific nuances adds to the development complexity. Invest time in learning and mastering these technologies to effectively develop and maintain custom widgets.

The post Unleashing the Power of Custom Widgets in SAP Analytics Cloud first appeared on ERP Q&A.

What is NSE ?

HANA SPS 04 version has introduced the NSE. NSE is used to store the warm data. HANA was used to store the hot data in memory but as data growth occurred in some of the organization the need for another store came into picture and SAP came out with a solution to introduce the another store called as warm store which in turn called as NSE.

Please refer the below block diagram by SAP :

Customers implementing the SAP NSE solution:

Customers who are planning to think about implementing the NSE should closely monitor the data growth. They need to compare the total memory size vs the used size.

In our system we found the database growth of 61.91% per year so we moved towards implementing the NSE.

In-Memory/Hybrid/On-Disk – NSE has the feature to store the data in disk-based column store and Hana has the feature to store the data in in-Memory column store.So it has a hybrid column store approach.

NSE integration is based on the Hana Persistence layer in close connection to Page Access and Resource Manager.

Buffer Cache (BC) is required for performance access to pages on disk.The buffer cache should avoid redundant I/O operations by keeping pages which are access frequently in memory rather than reading them from the disk repeatedly.The Buffer Cache uses LRU (Last Recently Used) and HBL (Hot Buffer List) strategies and reuses the pages from the internal pools instead of allocating/deallocating pages via HANA memory management.

NSE Advisor:

With the help of the NSE Advisor the objects (tables, partitions or columns) that are suitable to be converted to page loadable (to save the memory space) or to column loadable (to improve the performance) can be identified within the recommendations result view.

NSE Functional Restriction:2

Consider the following when storing large data sets in NSE on servers with limited memory capacity

• HANA as an in-memory database executes queries with allocating transient data and interim results in memory. Queries do not page interim results or parts of interim results from memory to disk.
• HANA keeps NSE data in memory in a buffer cache. Low hit rates in the buffer cache can cause insufficient query performance due to high number of disk reads.
• SAP provides general guidelines about the buffer cache sizing in the SAP HANA Administration Guide for SAP HANA Platform. Deviations from the guidelines require application based sizing or proof of concepts with workload simulations.
• Users can store warm data in NSE instead of on Dynamic Tiering. In contrast to Dynamic Tiering, the query execution in the HANA service, storing the NSE data, creates transient data and interim result in memory only. Thus, the memory requirement for a comparable workload can be higher with NSE. A solution to migrate data from Dynamic Tiering to NSE in on the road map for SAP HANA.
• SAP HANA NSE is for scale-up systems. For scale-out systems, SAP HANA does not check if users create tables with page-loadable columns or convert tables to page-loadable.
• SAP HANA NSE supports partition load units for heterogeneous partitions but does not support partition load unit for non-heterogeneous partitions.
• Specifying partition-level load unit is supported for the following partitioning schemes:
-Unbalanced range
-Unbalanced range-range
For all other partitioning schemes used in SAP NSE tables, load units can be specified only on column, table, and index.

NSE Advisor Usage:

1. Identify representative workload of your system
2. Optionally configure the NSE Advisor
3. Enable the NSE Advisor
4. Run the representative workload
   a. Monitor the performance of statements
   b. Monitor the memory usage
   c. Monitor the duration of processes
5. Disable the NSE Advisor
6. Evaluate and save the recommendations of the NSE Advisor
7. Migrate the objects selected from the recommendations
8. Run the representative workload
   a. Monitor performance of statements
   b. Monitor the memory usage
   c. Monitor the duration of processes
9. Iterate your tests, e.g. restart from step 2, until you have a proven set-up, which fits your requirements.

Configure NSE Advisor :

ALTER SYSTEM ALTER CONFIGURATION ( ‘indexserver.ini’ , ‘SYSTEM’ ) SET ( ‘cs_nse_advisor’, ‘min_object_size’ ) = ‘XXX’ WITH RECONFIGURE ; —
default value 1048576 = 1 MiB

Enable NSE Advisor:

ALTER SYSTEM ALTER CONFIGURATION ( ‘indexserver.ini’ , ‘system’ ) SET ( ‘cs_access_statistics’,’collection_enabled’ ) = ‘true’ WITH RECONFIGURE;

Disable NSE Advisor:

ALTER SYSTEM ALTER CONFIGURATION ( ‘indexserver.ini’ , ‘system’ ) SET ( ‘cs_access_statistics’,’collection_enabled’ ) = ‘false’ WITH RECONFIGURE;
Evaluate and save the NSE advisor run.

Hana Data Tiering Options are as follows:

• Hot Store

– Persistent Memory

• Warm Store

– Native Storage Extension , Extension Node, Dynamic Tiering

• Cold Store

– Spark Controller

NSE Value Proposition and Use Case:

• Value proposition:
• Increase HANA data capacity at low TCO
• Deeply integrated warm data tier, with full HANA functionality
• Will support all HANA data types and data models
• Simple system landscape
• Scalable with good performance
• Supported for both HANA on-premise and HANA-as-a-Service (HaaS)
• Available for any HANA application
• Complements, without replacing, other warm data tiering solutions (extension nodes, dynamic tiering)
• Use cases:
• Any customer built or SAP built HANA application that is challenged by growing data volumes
• S/4HANA data aging (NSE is an evolution of “paged attributes”)
• BW team currently uses extension nodes, but they communicated in TECH ED 2019 that NSE is certified for BW/4HANA

Specifying data as “page loadable”

• Data may be specified as “page loadable” at table level, partition level, and column level
  
• Data may be converted between “page loadable” and “column loadable”
  
• NSE supports range, range-range, and hash partitioned tables
  
• For hash partitioning the entire table or column must be page loadable or column loadable

NSE Technical Overview:

• The HANA column store and row store each have a buffer cache.
  
• Column loadable data is fully loaded into memory from disk.
  
• Page loadable data is loaded from disk into the buffer cache, page by page as needed.
  
• Converting column/row loadable data to page loadable format moves the data into the buffer cache.
  
• When buffer cache is full, it will eject pages intelligently based on user access patterns.
  
• Warm and hot data are written together from main store to disk during normal save point operations. The write-optimized store is not paged

Tooling:

HANA Cockpit:

• Configure buffer cache size (on-premise only; HaaS will configure this for the user)
  
• Configure tables, columns, and partitions as “page loadable”
  
• Monitor buffer cache usage and capacity
  
• Report on resident memory status for page loadable data
  
• Includes rule-based “recommendation engine” to monitor user data access patterns.
  
• Based on statistics, the engine will advise user on which tables, columns, or partitions would benefit from being converted to “page loadable”

Data Lifecycle Manager (DLM):

• DLM tool will allow user to convert tables, columns, and table partitions between “column loadable” and “page loadable”

Web IDE:

• Visualized query plan will display when warm data is accessed from NSE in order to satisfy the query

On-premise sizing

• HANA system must be scale up (first release)
• Determine volume of warm data to add to the HANA database
• May add as much warm storage as desired – up to 1:4 ratio of HANA hot data in memory to warm data on disk
• NSE disk store should be no larger than 10TB for first release of NSE
• Divide volume of warm data by 8 – this is size of memory buffer cache required to manage warm data on disk
• Either add more HANA memory for buffer cache, or use some of existing HANA memory for buffer cache (will reduce hot data volume)
• Work area should be same size as hot data in memory (equivalent to HANA with no NSE)

SAP HANA Extension Node – Whats New in SPS04

Common characteristics:

• HANA node in the scale-out landscape is reserved for warm-data storage and processing
  
• Supports all HANA operations and data management features
  
• Allows larger data footprint of up to 200% of the node DRAM size
  
• HANA persistent memory is supported

New Features:

• Benefits from new partitioning and scale-out features in SPS04:

–range-hash partitioning scheme

–“pinning” tables on fixed HANA nodes

–partition grouping

Warm Store Options – Getting Started

Cold Store:

Which Data Tier Should I Use ?

I tried to explain the best way of handling the NSE and also show case how to Select the NSE for each customers.In my next article I will try to articulate all the technical changes required for the NSE and also introduce the data aging concepts which is key to NSE.

The post NSE(Native Storage Extension) Data Tiering Options first appeared on ERP Q&A.