SAP Business Suite Powered by SAP HANA

The SAP Business Suite software is an integrated suite of applications designed to optimize, execute, and align business and IT strategies. The software gives you the ability to perform essential end-to-end business processes – with modular applications – in the context of your industry.

Each of the core applications within SAP Business Suite offers functionality to expand, automate, and improve business efficiency. The SAP Business Suite supports a broad range of processes for finance, human resources, manufacturing, procurement, product development, marketing, sales, service, supply chain management, and IT management.

And, you can run your suite on the platform of your choice, including the IN-MEMORY PLATFORM OF SAP HANA.

In early  2006, when the project that would result in SAP HANA  was in its infancy, the team proposed several ambitious goals (dreams, really) for the eventual capabilities of an enterprise-scale in-memory database. The most audacious goal was that this new database architecture would eventually be able to power the largest, most mission-critical enterprise systems in the world. In many ways, this was SAP’s “moon shot” declaration.

On January 10th, 2013, less than two years after the first shipment of SAP HANA, SAP realized the completion of this dream with the announcement of the availability of the SAP Business Suite powered by SAP HANA (SoH). SAP thus became the first software company to provide its customers with an integrated, real-time business process platform that unifies both analytic and transactional data into a single architecture.

Table of Content - SAP Business Suite Powered by SAP HANA

➤ Overview Of SAP HANA  ➤ Architectural Implications of SAP Business Suite powered by SAP HANA ➤ SAP HANA Enhancements Dynamic analytical privileges ➤ Roles as design time objects ➤ Audit logging improvements ➤ High Availability (HA) and Disaster Recovery (DR) scenarios

It might appear that with the delivery of SoH in 2013, SAP had reached the end of its journey. But, just as NASA didn’t stop innovating and exploring after the first moon landing more than 40 years ago, SAP is simply transitioning into its next phase of innovation and renovation.

For the first time ever, SAP has created an exceptionally performant database platform that was engineered to its exact specifications and that provides a myriad of incredible new capabilities that previously were unavailable to its 20,000 programmers. Having created this modern platform to power its flagship applications such as ERP, SAP has begun a multiyear effort to achieve three basic objectives:

1. Become an innovation-driven enterprise: SAP Business Suite powered by SAP HANA will help organizations become an innovation-driven enterprises by allowing you to rethink business processes as and when needed and invent new business models SMARTER.
2. Become a data-driven enterprise: SAP Business Suite powered by SAP HANA will help organizations become a data-driven enterprises by allowing you to collect, consolidate and consume real-time data FASTER.
3. Become a people-driven enterprise: SAP Business  Suite powered by SAP HANA will help organizations become a people-driven enterprises by providing your business users with actionable insights — on any device — to decide and act SIMPLER. In a nutshell, SAP Business Suite powered by SAP HANA enables its customers to drive their business  “smarter, faster and simpler” and do amazing new things that could never be done in a disk-based architecture.

In this segment, we’ll

1. Examine the architectural implications of running a mission-critical SAP Business Suite landscape on SAP  HANA,
2. Discuss several scenarios for adding SAP HANA to SAP Business Suite landscapes,
3. Review some technical and operational aspects of this switch, and
4. Provide some details on several of the enhanced business processes/scenarios that will immediately benefit from the power of SAP.

Overview Of SAP HANA 

SAP HANA is a combination of HANA Database, Data Modeling, HANA Administration, and Data Provisioning in one single suite. In SAP HANA, HANA stands for High-Performance Analytic Appliance.

SAP Business Suite powered by SAP HANA (SoH) delivers a  modern,  integrated suite of business-critical applications that unify analytics and transactions into a single in-memory, real-time data platform. The SAP Business Suite can now provide real-time planning, execution, reporting, and analysis across end-to-end business processes.

It can also provide business users with unified, 360-degree views of real-time information, such as machine sensor data and social media feeds, on many devices, across SAP applications as well as non-SAP systems.

SAP SRM is not included in the scope of applications powered by SAP HANA yet.

Because SAP HANA provides a unique ability to deal effectively with both transactional (OLTP) and analytical workloads (OLAP), companies can rapidly simplify their IT infrastructures — and reduce the total costs of ownership — by consolidating analytics and transactions into a single database.

In this integrated scenario, companies can utilize SAP HANA as their primary database for SAP Business Suite applications and provide real-time analytics on live transactional data. Employing the same database to address a company’s analytical and transactional needs eliminates the necessity to replicate data and/or integrate additional reporting/analytics landscapes.

The SAP HANA platform provides the foundation for companies to dramatically increase both the performance of their existing SAP Business Suite applications and to continue to innovate without disrupting their current systems by leveraging a new generation of real-time applications natively built on the platform. It is the perfect starting point to begin taking advantage of a true real-time data platform.

Architectural Implications of SAP Business Suite powered by SAP HANA

Over the years, technical limitations in the database layer have forced companies to build two separate software/hardware landscapes to provide both OLTP and OLAP systems to address two different business needs: transaction processing and reporting/analysis.

It was simply impossible for disk-based databases to efficiently handle both row-based transactional “writes” and column-based analytical “reads” at the same time. As a result of this “performance dichotomy,” database management systems currently on the market are typically optimized for either transactional workloads or analytical workloads, but not both.

Compounding this problem is the fact that data have to be copied between the two systems. This inefficiency not only generates significant costs, but it forces organizations to adopt measures to ensure data integrity and usability between multiple systems. A final issue is the inevitable lag time that occurs when transactional data are exported to analytical systems on a daily or weekly basis.

SAP HANA is the first commercial database system that successfully eliminates this false performance dichotomy as well as the resulting need to develop and maintain separate OLTP and OLAP systems. Because SAP HANA can process transactional and analytical workloads fully in memory, it combines the best of both worlds. You don’t need to take the time to load data from your transactional database into your reporting database, or even to build traditional tuning structures to enable that reporting.

As transactions are happening, you can report against them live, from the same database tables. By consolidating two landscapes (OLAP and OLTP) into a single database, SAP HANA provides companies with massively lower TCO (Total Cost of Ownership) in addition to mind-blowing speed. With all the relevant transactional and analytical data integrated into a single system that is updated in real-time, companies can truly become “real-time businesses.”

Related Article: SAP HANA Interview Questions

Beyond the architectural simplification and cost savings that SAP HANA can bring to enterprise architectures, another, more transformational shift is underway. Nearly every application in operation today was constructed in a programming approach where data is transmitted from the database to the application, where they are then transformed for calculation by the application logic or algorithm.

This “bring the data to the algorithm” approach was necessary because a disk-based DBMS has very limited capability to do anything more complex than rudimentary calculations

In contrast, SAP HANA enables application developers to completely flip that model on its head and begin to leverage the system’s incredibly powerful engines inside the database. Developers can now extract data-intensive operations and algorithms from the application layer and insert them into the database layer for execution.

Applications thus become much “leaner,” and they focus on business logic. In essence, the database becomes a “data engine” that spits out the “answers” whenever they are needed, rather than simply serving up chunks of data to the apps.

This new “bring the algorithm to the data” approach is much more elegant than the old way of programming, and it significantly reduces the amount of data being moved in and out of the database. Not only do these new apps increase performance by having fast access to data in memory, but they also gain additional exponential speed by executing core application logic and algorithms inside the database, on the raw data. This is when companies begin to realize process performance increases of 50,000 to 200,000  times.

Going forward, SAP will deliver “HANA-fied” versions of multiple transactions in the SAP Business Suite through regular Enhancement Packs. Not every transaction will receive this treatment because not every transaction will be able to take the advantage of these new database capabilities or the value of renovating the transaction won’t be justified by the performance improvements. Significantly, SAP has made the migration to SAP HANA as painless as possible.

All “HANA-fied” reports and transactions can be activated via the switch framework, so they will not modify the existing business logic when a company adopts the new system. Going further, all of these switches are reversible and can be activated independently. These features ensure maximum flexibility in the consumption of these optimizations while minimizing business disruptions for the companies that implement them.

Here are a few of the benefits this new architecture provides to existing SAP Business Suite customers:

Applications

You no longer have to run dialog processes in batch (i.e., “Batch is dead”).

The remaining batch processes run faster, essentially turning them into “on-demand” jobs.

For details on SAP HANA optimized ABAP programs, please see the latest release notes for SAP HANA Live Operational reports, which now run in real-time in the SAP Business Suite.

The new architecture removes the need for Operational Data Stores. It eliminates the necessity to transfer (ETL) for performance reasons. It eliminates the need to reconcile source data with copies.

Interactive reports allow users to trigger OLTP transactions from the report.

Next-generation Applications

Embedded Analytics can now be performed on a single system.

Custom ABAP code

Existing core code modification limitations apply (i.e., “bad code is still bad code, it just runs faster”).

Regression tests for custom code are recommended after SAP HANA migration.

By now, it should be obvious that adding SAP HANA to an SAP BUSINESS SUITE landscape provides several major benefits, ranging from the increased performance to reductions in cost and complexity. In simplistic terms, there really isn’t much more involved in migrating to the landscape than copying the data from your old database into SAP  HANA and then turning on the new system.

SAP has invested a huge amount of effort and resources to ensure that the migration process is as painless and risk-free as possible. The company has even provided a one-step migration wizard and an RDS package to manage the entire process.

The new deployment approach, provided within the Rapid Database Migration of SAP Business Suite to SAP HANA package, leverages out-of-the-box accelerators and predefined scope that will help accelerate your adoption of SAP HANA to supercharge the SAP Business  Suite.

Migrating to SAP Business Suite powered by SAP HANA is similar to any other migration project, but with a few additional technical options and new tools.

The simplified process eliminates any migration guesswork and uncertainties regarding the realization timeline, due to automation of steps as well as planning security due to standardization of the approach.

One-Step-Migration via SAP HANA Migration Wizard (HMW)

Several of the features of your existing system remain the same:

Configuration: IMG stays the same.

Customization: Stays the same.

ABAP Workbench: Stays the same.

Modification: Same upgrade requirements as with any new release. BADIs are still supported.

Connectivity: Stays the same.

Security: Stays the same, with enhancements.

SAP HANA Enhancements Dynamic analytical privileges

In dynamic analytic privileges, you use a database procedure to dynamically obtain the filter condition string at runtime. You can provide the database procedure value within the CONDITION PROVIDER clause.

You can use only procedures, which achieve the following conditions to define dynamic SQL analytic privileges.

1. DEFINER procedures.
2. Read-only procedures.
3. The procedure with no input parameters
4. The procedure with only one output parameter of type VARCHAR or NVARCHAR for the filter condition string.
5. Procedures are executable by _SYS_REPO. This means that _SYS_REPO is either the owner of the procedure or the owner of the procedure has all privileges on the underlying tables/views with GRANT OPTION and has granted the EXECUTE privilege on the procedure to the _SYS_REPO user.
6. Reuse of same analytic privilege for several users with different restrictions
7. Support for complex logic and situational security derived at runtime

Roles as design time objects

1. Roles in SAP HANA are defined using the SAP HANA Studio.
2. Roles defined in one environment –development, cannot be migrated to another. They have to be recreated manually in other environments – test, production, etc. 
3. If a lot of roles are required manually creating and maintaining them across multiple servers in the landscape is a tedious and error-prone process. 
4. Offering full lifecycle management capabilities

New “Support Role”

• Secure and enhance the compliance process for productive systems.

Audit logging improvements

SAP HANA audit policy tells the actions to be audited and also the condition under which the action must be performed to be relevant for auditing. Audit Policy defines what activities have been performed in the HANA system and who has performed those activities at what time.

• New audit events (e.g., ALTER USER)
• Data  access logging
• Audit configuration in SAP HANA Studio

Transports: Effective management of content changes across an SAP HANA-based system landscape requires a transport management system. CTS stays the same

• Delivery via standard transport tools, SAP HANA specifics as  TLOGO objects (ABAP based)
• CTS+ transport integration ready for custom SAP HANA code

Monitoring: DBACockpit and Solution Manager stay the same

SAP Solution Manager offers a complete solution for operations

SAP Solution Manager is a central, integrated orchestration platform that includes the processes, tools, services, and organizational models needed to manage SAP and non-SAP solutions across the entire IT landscape and throughout the complete application life cycle.

• SAP HANA monitoring and alerting integrated into SAP Solution Manager 7.1, Support Package 4.
• End-to-end workload analysis for SAP HANA planned for Support Package 8 in Solution Manager 7.1

High Availability (HA) and Disaster Recovery (DR) scenarios

SAP HANA offers three levels of disaster recovery support – backups, storage replication, and system replication.

• HA and DR scenarios are supported

SP7 includes new features supporting high availability/disaster recovery (HA/DR) deployment, such as replaying logs on snapshots as well as cascading system replication for up to three locations. New unified install/patching tools and enhanced monitoring of operations continue to simplify the administrative experience.

Flexible appliance platform

• Third-party  tools (e.g., agents for monitoring and scheduling, antivirus) are allowed to run on the appliance
• Third-party backup tools supported with SAP HANA  (ongoing)

SAP will continue to provide customers with a choice of database platforms, as it always has. Customers who choose to migrate to SAP HANA must take three steps to incorporate their existing SAP Business Suite on top of SAP HANA:

1. Update to the latest Non-SAP HANA enhancement package and the latest version of the SAP NETWEAVER technology platform
2. Update to the latest enhancement package version for SAP HANA
3. Migrate from any database to SAP HANA

These requirements notwithstanding, however, SAP remains committed to supporting its customers’ choice of database technologies and vendors. The company will continue to offer the SAP BUSINESS SUITE on all currently certified databases and collaborate with its database partners to support continuous innovation of its applications on a variety of databases.

The major downside to staying on an “old” database on your “new” SAP Business Suite, besides the costs and complexity inherent in disk-based databases — is that the “HANA-fied” transactions that SAP delivers with each enhancement package won’t work with your “old”.

You’ll continue to receive new transactions and industry functionality, but they will run much more slowly than they would on the new system. In addition, you won’t be able to use any of the HANA-fied transactions that SAP delivers.

That said, migrating to SoH isn’t an “all or nothing” proposition. Companies can add SAP HANA to their SAP Business Suite systems in several ways. However, a few caveats apply, because not all of the enhanced functions that were designed for SoH are compatible with non-HANA databases due to their disk-based architecture and lack of in-memory capabilities.

General  Requirements

1. Optimizations for SAP HANA require all relevant systems to run on SAP HANA (i.e., Development, Quality Assurance, and Production).
2. Implementing an SAP HANA-based ABAP correction requires an SAP HANA-based correction system.
3. Testing an SAP HANA-based ABAP correction requires an SAP HANA- based test system.
4. SAP HANA-based systems interact with non-SAP HANA-based systems.
5. In mixed ERP landscapes (several ERPs) transports from non-HANA systems into HANA-based systems are supported.

Non-SAP HANA-based development can be transported to SAP HANA- based systems

SAP HANA-based development can be transported into non-SAP HANA-based systems, if the development is activated only after the system is manually activated.

• All optimizations specific to SAP Business Suite powered by SAP HANA require a dedicated Business Function activation to be enabled.
• During the upgrade, all code pertaining to SAP Business Suite, powered by SAP HANA is deactivated and is running smoothly on non-SAP HANA- databases.

Dual-Stack Systems

• SAP Business Suite, powered by SAP HANA is based on SAP NetWeaver 7.40, and it does not currently support dual-stack (ABAP/JAVA) installations.
• Dual-stack systems have to be split prior to an SAP HANA migration. 
• Java stack stays on the current database because Java is not yet supported to run on SAP HANA (in a Business Suite app server).

Minimizing  Downtime

• Near-zero downtime approach: Use additional shadow databases to keep DB downtime to a minimum (available on request; see SAP Note 1680769)
• Several parallel processes for data export and data import, table split for parallelized export of large tables
• Combined Unicode conversion and database migration
• Reduced downtime for system copy (e.g., relevant for Unicode conversion).

Unicode

• SAP HANA runs natively on Unicode only.
• Unicode conversion can technically be performed during the database migration, but certain preparatory steps are required.