Scroll Top

SAP S/4HANA: The Complexity Antidote

SAP S/4HANA: The Complexity Antidote

TAKE NOTE (Insights into SAP solutions and Emerging Technology)

At the time it seemed like a great idea. Take a standard enterprise software package and then add some custom code to enhance functionality or adapt it to work with an existing process or system.

As McKinsey noted in a 2014 report, “Large global organizations have created so much complexity that businesses often struggle to bring good ideas to the marketplace profitably.” Instead, they end up spending much of their time on non-value-added activities including what IT departments often dub ‘keeping the lights on.’

Complexity has become the number one issue for both business and IT leaders. In many cases, these are systems that have been adding in complexity over decades (sometimes as a result of mergers and acquisitions) and now they are nearly impossible to change. So for me, one of the most exciting features of the new SAP S/4HANA suite, officially launched this week, is that it offers a clear path for enterprises to simplify their IT infrastructure and remove the redundancy and complexity resulting from old customized code.

Implementing SAP S/4HANA provides the opportunity to take out all the complexity, get rid of all the redundancies, eliminate the unused custom code, massively reduce the data footprint, and gain more throughput. The key to this is the architecture of SAP S/4HANA. The new suite is designed to accommodate the requirements of most businesses without the need for (code) modification to the core code.

But obviously not all functionality is available as standard: some companies will need specific features that are not supported by the core ERP system. SAP is enabling this flexibility through an extension framework (SAP HANA extensions) within SAP S4/HANA and via the open SAP HANA Cloud platform to introduce advanced applications – for example predicting, recommending, simulating – while protecting existing investments.

 

Reduce the data footprint

Rather than customizing the core code, modifications are put in a “safe” place so that innovation packages can be easily applied. The core ERP system remains ‘clean’ and can be quickly and easily updated when new features or functionality are added – in just the same way that consumer apps are updated on a regular basis.

From an IT perspective, SAP S/4HANA creates unique opportunities to dramatically simplify the landscape and reduce total cost of ownership. Enterprises will now be able to significantly reduce their data footprint and work with larger data sets in one system (reintegrating ERP, CRM, SRM, SCM, and PLM in one system) to save hardware costs, operational costs, and time.

SAP S/4HANA has also been designed to natively connect to people, devices, and business networks in real-time, making the Internet of Things and Big Data accessible to any business. By eliminating the need for extensive batch processing (which can take hours or even days,) the S/4HANA should enable business users to gain insight from business data in real time and make faster and more informed decisions.

For end users, SAP S/4HANA’s simple user experience runs on any device – eliminating the complex, and often confusingly different, UIs associated with older enterprise apps – and that is something I’m sure we can all applaud.

This story originally appeared on SAP Business Trends. 


UNDER DEVELOPMENT(Information for ABAP Developers)

ABAP Dynamic Programming Techniques

We have all seen it…..

Some of us have been around 20+ years and still don’t REALLY understand it. Imagine how a fresher feels when they encounter this form of code. Now I can hear the old timers here screaming it just NOT necessary to code this way and what does it buy you anyway? Well, this is exactly what I intend to look at in this series. All manner of DYNAMIC ABAP and DYNAMIC OPEN SQL. If nothing else it will be a good place for freshers to look when they encounter this madness… lets go!

Dynamic Programming Concepts and Benefits

What exactly is ABAP dynamic programming, and why is it so beneficial? Fundamentally, dynamic programming is used in almost every program, but the extent varies. Most programs consist of both dynamic and static parts. In this sense, programs are rarely black and white — most are shades of gray. Perhaps the best way to answer that question is to contrast dynamic with static programming.


Q&A (Post your questions to Facebook or Twitter and get the answers you need)

Q. I was debugging a SELECT/ENDSELECT block, and experienced an application crash with a DBIF_RSQL_INVALID_CURSOR runtime error, why does this happen?

A. The real underlying question you are asking is to explain the difference between an Exclusive vs. Non Exclusive debugging session. Let’s first examine the latter…

What is a non-exclusive debugging session?

If you run a normal transaction, your user context is rolled out of a work process if a screen is displayed, and rolled into the next free work process after the next user action. Because the database connection is linked to the work process, and a roll-in/roll-out may direct you to another work process, the database connection is closed during roll-out and is reopened during roll-in. Therefore, in order to preserve a consistent state, a standard roll-out is always connected to a database commit before the database connection is closed. If you debug a SELECT/ENDSELECT block, this commit introduced by the debugger closes the database cursor, and you receive the runtime error DBIF_RSQL_INVALID_CURSOR during the next fetch from the database. Especially when you are debugging the update functionality of a transaction, these database commits can lead to inconsistent application data, because a subsequent rollback in the application cannot roll back the database changes that were committed by the debugger.

For these reasons, there needs to be a better and safer way to debug code, especially productive code. This is where exclusive debugging sessions come into play.

What is an exclusive debugging session?

If you run an exclusive debugging session, the work process is locked for your debugging session. This means that no other user can use this work process, and as a consequence, there is no need for the system to close the database connection after a debugger roll-out because the roll-in will reenter the same work process. Therefore, in an exclusive debugging session, there are no debugger-introduced database commits, making it safe for you to debug updates and SELECT/ENDSELECT blocks.

On a final note, The New ABAP Debugger also allows you to switch explicitly from a non-exclusive to an exclusive session via the main menu path Debugger → Exclusive Debugging mode switch on.

Pin It on Pinterest

Share This

If you enjoyed this post, why not share it with your friends!