Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

Remarks before you start

The dashboard described requires an installation of SAP NetWeaver Application Server Java 7.40 with usage type BI Java installed and configured to work with your SAP NetWeaver Application Server ABAP 7.40.

1 Business Case

An accounts head of an organization wants to know the pending payments of all the invoices for which the products have been delivered already. The accounts head wants to analyze the payment dues based on various criteria. For example, she wants to see for how long the invoices are open for payment. And, she wants to get an overview of receivables per customer taking the history of business between the customer and the company into account.

In order to draw the correct conclusions and be up-to-date with the latest payments, the accounts head wants to see an up-to-date status reflecting even the most recent changes in the underlying transactional data.

The individual views of the data are described in more detail in the following sections.


1.1 Time Based Analysis

 

The Accounts Head wants to analyze open payments for a particular quarter/month/date. Using this functionality, the Accounts Head can pin point the quarter and month in which larger volume of open payments exists.

The Time Based Analysis in the dashboard illustrates the usage of time hierarchies for the invoice creation date characteristic. The invoice creation date is displayed in the form of quarter, month, and date by using a virtual time hierarchy. It therefore shows aggregated data for a particular month or quarter.

After selecting the quarter/month/date of interest, the search can be further refined by selecting a particular Business Partner.

1.2 Due Date Analysis

   

The Account Heads wants to view the open payments based on the number of days it is open.

For instance, the Accounts Head can now track all the invoices for which the payment dues are pending for more than 90 days and give a legal warning/notice to the customers demanding the payment.

The Due Date Analysis works uses restrictions based on the Open Days characteristic. The dataset is sub-divided for invoices for which the payment is pending for less than 30 days (Quick Payers), between 30 and 60 days (Gradual Payers), between 60 and 90 days (Slow Payers), and greater than 90 days (Dormant Payers).

 

1.3 Detailed Analysis

    

Here the Accounts Head can seamlessly analyze data across multiple dimensions offered via dropdowns. It is possible to filter by Business Partner ID/Company Name, Invoice Creation Date, Sales Order ID, and Currency Code.

For example, the Accounts Head wishes to see the distribution of open payments based on currency. To achieve this, she can select a particular currency code and view the pending invoices for that particular currency code.

Furthermore, the Accounts Head might want to see the open payments for a particular date. She can select a date from the invoice creation dropdown and see the invoices which are open for payments.


1.4 Dunning Analysis

    

The Accounts head can analyze the invoices by selecting a particular customer class and customer dunning level.

Dunning Analysis is an interesting topic which involves quite a bit of calculations. During a dunning run, the customers are classified in to pre-calculated customer classes based on the business history they share with the company. Also, each pending invoice is classified in to pre-calculated dunning levels based on the days due and the amount they have to owe to the company.

The Dunning Analysis categorizes or displays the pending invoices by taking the customer class and dunning level as input.


2 Architectural overview

The following picture describes the high-level architecture used for the Open Items Analytics. Additionally, it lists the technical artifacts that were created on each of the layers.

The dashboard is based on the same SAP HANA artifacts that are used for the transactional screens of the Open Items Analytics scenario. This ensures that the data is always up-to-date with the latest changes in the data.

SAP NetWeaver BW technology is used to create the views on the data required in the dashboard. The data is modeled via BW InfoObjects and InfoProviders and structured for visualization by defining BEx Queries on top.

Lastly, a Web Template of a BEx Web Application visualizes this data in a browser-based dashboard.

This BEx Web Application can interact with the Web Dynpro Floorplan Manager application of the reference scenario.

More details about the components used can be found in the online help at http://help.sap.com.

The design decision that led to the usage of these infrastructure components are described in more detail in the following sections.


3 Design Considerations

3.1 Usage of SAP NetWeaver BW

3.1.1 General considerations

The technical components of SAP NetWeaver BW are part of the SAP NetWeaver Application Server ABAP 7.40 stack. They provide a uniform data access layer – the Analytical Query – that can be consumed by various analytical frontend tools like the Business Objects suite of products or the Business Explorer tools.

At the same time, with the infrastructure enhancements done for SAP NetWeaver powered by SAP HANA a pushdown of calculation intensive operations in the context of analytics to SAP HANA is realized. So, by using SAP NetWeaver BW technology on SAP HANA one can benefit from and leverage SAP HANA. As opposed to the approach for transactional applications where you need to code, SAP NetWeaver BW offers a modeling environment and does the SAP HANA optimizations transparently.

Moreover, using SAP NetWeaver BW allows using all of its advanced business features like time dependent hierarchies, variable exits, zero suppression, etc. Also here SAP NetWeaver BW decides internally which parts of a query can be pushed down transparently to SAP HANA for processing and which parts have to be run on the Application Server ABAP. Accessing SAP HANA via SAP NetWeaver BW enables all ABAP users to have access to the dashboard without the need to create additional SAP HANA users.


Note that the usage of SAP NetWeaver BW technology within the same system the operational data is residing is generally called an “Embedded Usage”. As opposed to the “Hub Usage” where SAP NetWeaver BW is set up as a separate data warehouse system to consolidate data coming from various operational systems, the “Embedded Usage” focuses on using SAP NetWeaver BW technology to operate on data residing in the same system.


3.1.2 Virtual InfoProviders

Technically, Virtual InfoProviders based on BW InfoObjects are built to consume the data from the SAP HANA artifacts. The reasons for choosing Virtual InfoProviders were:

  1. Virtual InfoProviders are transportable BW objects and can be delivered as BI Content.
  2. Virtual InfoProviders can be modeled by adding appropriate Dimensions and Key Figures corresponding to the attributes in the SAP HANA views. This allows more flexibility in deciding how and what data should be part of data projection.
  3. Virtual InfoProviders are easy to maintain. Changes on any SAP HANA attributes requires only modification of the InfoObjects that are used in construction of the Virtual InfoProvider rather than doing changes directly to the Virtual InfoProvider directly.
  4. Virtual InfoProviders are more closely linked to SAP HANA artifacts, next to Transient Providers since direct mapping of Virtual info cube attributes are done to SAP HANA attributes. Hence changes are reflected real-time between data in SAP HANA artifacts and Virtual InfoProvider.

3.1.3 BEx Queries

BEx Queries are consuming this data one level up from the Virtual InfoProviders. They are used as the data provisioning layer for the BI Dashboard. They provide an additional modeling layer and are close to the representation of the data to the end user in the dashboard. As mentioned before, the BEx Query is the central object that many Business Objects and Business Explorer frontend tools can consume.

3.2 Usage of BEx Web Applications


3.2.1 General Considerations

BEx Web Applications are a standard part of an SAP NetWeaver installation. Therefore, this technology is used in this reference scenario instead of the SAP Business Object tools which provide much more sophisticated options of working with analytical data. This is why it is generally recommended for real life scenarios to check if SAP Business Objects products can be used to serve the end user’s needs much better.

BEx Web Applications require the installation and configuration of an Application Server Java running the usage type BI Java.

BEx Web Application Designer, the design tool to build BEx Web Applications supports defining an application in either a visual or textual representation. The XML dialect it offers make customization of applications easy for developers having skills that are very common in a Web environment today: XML, HTML, and JavaScript.

From a functionality perspective, BEx Web Applications allow to consume the functionalities BEx Queries are offering. Additionally, BEx Web Applications have a broad range of user interface controls and visualization options for data. Data can be displayed in tabular form, as chart and it can be bound to various controls that are in turn affecting the data displayed when users are interacting with them. BEx Web Applications also supports the export of dashboards page to external file types like PDF, XLS, and CSV etc. Moreover, there’s various way to layout the dashboard, for example using tab pages that are used in the dashboard. Things that are not possible using the standard controls can be achieved by using HTML and JavaScript.

BEx Web Applications can communicate with other external Web-based applications through the Report-Report-Interface technology which allows passing filter values as parts of a URL to call the external Web-based application. An exemplary use case is the navigation to a Web Dynpro Floorplan Manager Application taking the currently selected business partner as a pre-defined entry for the filter criteria of the Web Dynpro Floorplan Manager application.


3.2.2 Using Business Partners for Report-Report-Interface Navigation

For enabling the Business Partner Characteristic for Report-Report-Interface (RRI) navigation has special consequences on how the characteristic is modeled.

Any characteristic can have a key and text associated with it. The SAP HANA Attribute View which carried both the key and text of the InfoObject is assigned and mapped to the corresponding fields which need to be displayed as key and text.

The main purpose of including the business partner ID in the dashboard is to pass the value of this parameter to an external Web-based application using the RRI command. By having the business partner ID as key of the characteristic and company name as associated text, the display of both parameters in one dropdown list and passing the business partner ID through the RRI command is possible.



2 Comments