GRC
HR
SCM
CRM
BI


Article

 

How to Get the Most Out of ABAP and Java in the Context of SAP Technology: Part 1

by Dr. Thomas Weiss and Martin Jaekle | SAPinsider

July 1, 2011

Is ABAP better than Java? Or is Java better than ABAP? This first article in a two-part series shows you that it isn't a question of which development language is better; the choice depends on the situation, and sometimes the answer is both. This article offers three questions to consider at the start of your decision-making process, and then looks at a scenario in which ABAP is the best option.
 

So you are an SAP customer planning a custom development project, or an SAP partner that wants to develop an add-on — which technology and which development language should you choose? Is ABAP better than Java? Or is Java better than ABAP? Is ABAP the past and Java the future? (See sidebar.)

This two-part article series shows you that it isn’t a question of which language is better than the other. The choice depends on the situation, and sometimes the answer is both. It’s like asking which means of transportation is best: There is a big difference between going somewhere in your town and journeying to a distant continent, not to mention mitigating factors like time and cost.

We’ll show you how to create a mental map to evaluate your options and make this decision by walking through some example scenarios that illustrate the questions you need to answer for your project’s unique situation and conditions.

In this first article in the series, we look at a scenario in which ABAP is best suited for the project. In the second article, we will explore two examples that illustrate a Java-driven approach. While the scenarios demonstrate sample decision paths, the direction that you choose depends on the various, and often specific, requirements of your particular project.

After reading the article series, anyone involved in the decision-making process — such as project leads, IT managers, and architects — will be well equipped to determine which language and technology is the best fit, how to best profit from SAP’s offerings, and how to leverage the strengths of these complementary technologies.

3 Considerations for Any Project

While choosing the right technology depends on your specific situation, there are some considerations that are relevant to any project. We recommend asking these questions at the very beginning of your decision-making process.

1. Are you keeping development to a minimum? The less you develop, the lower your costs. If you do not develop anything, you don’t need to design, debug, or support it. You can simply use SAP Modification Justification Check, which is a free service for SAP Enterprise Support customers that will check if the functionality you need is available in an SAP standard application. You will learn if there is a user exit or a business add-in (BAdI) that you can implement to get the functionality, or if there is a workaround or process reengineering that might do the job for you.

2. Are your existing systems and stacks sufficient? It is pivotal that you preserve your existing investments. Introducing a new technology with a new development language in your landscape may increase both TCO and TCD. Try to capitalize on the existing knowledge in your company.

3. Are you adhering to basic design principles? These principles are crucial to the success of all IT projects: Develop as locally as possible, minimize the calls between systems, and reduce the data volume transported from one system to another.

Once you have looked at these basic considerations, you are ready to evaluate your options. In the next sections, we will outline some additional questions you need to ask to make the right technology choice for your project by walking through an example scenario. While, in this particular example, the conditions and criteria lead to an ABAP solution1, the best choice for your project can only be determined by looking at your own concrete requirements (see sidebar).

Example Scenario: Adding New Process Steps After a Company Merger

You are likely no stranger to company mergers and the challenges that can accompany the integration of technologies, processes, and business needs into a cohesive whole. For instance, imagine that a merger of two companies requires additions to the standard SAP ERP order-to-cash scenario in the form of add-on functionality — in particular, the implementation of additional accounting procedures, more checks that necessitate more user interactions, and additional calculation steps.

To make matters more complex, other departments and subsidiaries of the merged organization need to adapt this scenario to their own needs; millions of record sets are involved, new database tables are necessary, and different roles that permit different authorizations for viewing information in the new user interfaces (UIs) are required. Plus, the add-on functionality must be developed quickly. And the existing landscape is a mixed bag with SAP Business Suite, SAP NetWeaver Application Server (SAP NetWeaver AS) Java, and legacy systems.

What is the best technology for developing add-on functionality that addresses the needs of a scenario like this? Let’s look at the questions you should consider.

1. Can You Achieve What You Need by Enhancing an SAP Standard Application?

Generally speaking, the less you develop, the lower your TCD and your maintenance and support costs are. So, if you can achieve what you need by customizing, adapting, or enhancing the ABAP-based standard solutions that already exist in your SAP ERP or SAP Business Suite implementation, you should do it. If you can make do with a few minor or midsize additions to an existing ABAP program, just enhance that program.

Of course, the downside to this approach is that you are less flexible with your add-on and it is more difficult to exchange the add-on later because your enhancements and the original SAP Business Suite code may be closely interwoven. Enhancing an SAP-based application may also mean some adjustment effort after an upgrade or the installation of a support pack or enhancement package. If you use the new Enhancement Framework, the adjustment costs are far lower than with the classic modification technology — you have to adjust only the development objects in which the underlying objects of the SAP standard application have been changed in an incompatible way. Transaction SPAU_ENH also provides tool support by showing you which development objects you have to adjust and helping you adjust them.

In the example scenario, it is possible to enhance an existing ABAP-based application to achieve the needed functionality.

2. Do You Need Close Integration Between Your Add-On and an SAP Application?

Sometimes enhancing an SAP standard application is not just an option, but the easiest, or sometimes only feasible, way to achieve the level of integration you need with your SAP ERP or SAP Business Suite implementation.

Imagine you need to add some processing steps within the scope of an existing database transaction. The best way to do so is to enhance the code of this database transaction and to organize the database access in the same way as the original SAP program. This ensures that you safeguard the transactional logic of the program and that a rollback really rolls back all the steps in the transaction. The same is true if there is no interface that offers access to all the data fields that you have to change. In this case, the only option you have is to enhance the development object that contains the data you need.

In the example scenario, we need to add new steps to existing database transactions within SAP Business Suite. So enhancing the code of these SAP development objects is the best way, or may even be the only way, to achieve the needed functionality.

3. Does Your Add-On Need Features of a Classic Business Application?

Sometimes, enhancing your existing SAP Business Suite logic isn’t enough because you need additional functionality. In this case, you would need to develop the features yourself by creating new development objects and writing your own applications on SAP Business Suite.

There are certain features typically required for “classic business applications,” including:

  • Profiles and roles with different authorization objects, and tools to manage them and integrate them smoothly into the source code
  • Easy and frequent access to database tables — ideally with SQL as part of the programming language (so that static code checks of the SQL are possible) and with an existing framework available for table buffering and table locking
  • The ability to write vendor-independent SQL
  • Built-in support for broad, complex database transactions
  • The option to import data from legacy systems
  • A framework to easily archive data or integrate archiving solutions
  • A structure that supports the management and transport of a complex project through a large, complex landscape

In many languages, you may have to either develop these features yourself, or integrate different tools and libraries to meet your needs. With SAP NetWeaver AS ABAP, these features are included — prebuilt and free — saving you the time and effort of developing them from scratch. For example, Open SQL is integrated into ABAP, and using it frees you from writing vendor-specific SQL statements because Open SQL is understood by all databases supported by SAP NetWeaver AS ABAP. You have built-in transaction handling,

SAP Legacy System Migration Workbench (transaction LSMW), SAP ArchiveLink, and the archive development kit. The ABAP change and transport management functionality offers advanced lifecycle management features, including the option to transport much of the customizing of the server itself through the whole landscape without fear of taking a wrong turn.

In our example scenario, in addition to the functionality that can be realized by enhancing existing SAP development objects, we need to develop typical business application features, such as integrated database access, interfaces for data migration, and automatic archiving. ABAP provides functionality to support all of these needs.

4. Is Mass Data Processing Important for Your Application?

If your organization is like most, you process a large amount of data daily. SAP NetWeaver AS ABAP includes comprehensive mass data processing functionality that you can build into your application.

ABAP has a data type of its own that is optimized for efficient and high-performing processing of mass data: the internal table, which is also available as a sorted table and a hashed table. A huge internal table has better performance and needs less memory than millions of objects spread across the system’s memory, and a sorted or hashed internal table allows very fast access to the data by using up to 15 different indexes for one internal table. In fact, using an internal table, you can search the data sets almost as comfortably as searching in the database, only it is much faster because an internal table is part of the program and requires no database access to read and write data in it.

Mass data processing can take quite some time. The best way to cope with this is to parallelize your work, and ABAP provides strong tools and framework support for this. Using the asynchronous or the parallel Remote Function Call (RFC) or the PV tool in the BC_ABA layer (in the package BANK_PP_JOBCTRL), you can easily parallelize, manage, and synchronize large amounts of data that need processing. You can keep track of the processing and, in case of an error, restart it from the point where the failure occurred. This framework is very stable and reliable for mass data processing.

At times, you may need to process mass data — from Java-based systems, .NET-based systems, or other ABAP-based systems — in your ABAP-based SAP ERP system. Using RFCs and related connectors (SAP Java Connector and SAP .NET Connector), you can create high-performing connections to other systems.

In our example scenario, we need to compute a lot of mass data — we need to get the data from the database, sort it, and combine it with data from different database tables. With ABAP, we can take advantage of the internal table data type for this, and we can also benefit from parallelizing the processing of mass data. In addition, we can leverage the high data throughput of SAP Java Connector to get data stored in a Java-based add-on into SAP Business Suite.

5. Do You Need to Easily Adapt, Enhance, and Change Your Add-On Application?

Every company has its own particular processes and corporate identity rules, and one of the strengths of SAP software is the extent to which you can customize it to fit your organization’s unique and changing needs. Users of your add-on application will need — and expect — the same level of flexibility; for example:

  • Back-end functionality that can be customized
  • UIs that can be personalized
  • The ability to enhance the add-on application in different layers
  • The ability to switch enhancements

ABAP comes with comprehensive frameworks and toolsets for customization and enhancement that you can use for add-on applications you have built on SAP NetWeaver AS ABAP. Web Dynpro for ABAP also offers many options to create your own UIs that can be customized and personalized by administrators and users. If other subsidiaries and departments of your company need your solution in different flavors, both in the back-end and in the UI, you can use the customizing and enhancement options of ABAP for your business logic and for UIs based on Web Dynpro for ABAP. Plus, all enhancements of the Enhancement Framework are switchable using one UI.

In our example, we need to offer the additional functionality in a way that allows other departments and subsidiaries of the merged organization to customize and adapt the business logic and UIs to their specific needs. The customizing and enhancement options provided by SAP NetWeaver AS ABAP are ideally suited to this need.

6. How Important Is the Speed of Development for Your Project?

Time is often of the essence — especially when your users are waiting for functionality they need.

ABAP, the ABAP server, and the change and transport management functionality of the ABAP server have been optimized for business programming. Because of these (and other) features mentioned so far, the development of business software in ABAP is very fast. Many features and tools needed for business programming are already integrated in the ABAP language, in SAP NetWeaver AS ABAP, and as part of ABAP life-cycle management. Of course, you could develop these features yourself, so you can develop your own database buffering or transaction logic if you wish, but this will take some time. The more features you can use without developing them yourself, the faster you can create an application.

In the context of our example, it is vital to integrate the processes of both companies involved in the merger quickly and smoothly. ABAP can help to ensure a successful merger by enabling IT to adapt to new processes as soon as possible.

Proposed Solution for the Example

The needs of this particular scenario highlight many of the advantages of ABAP:

  • It is possible to enhance an existing ABAP-based application while enabling close integration in the existing business logic.
  • We need features of a classic business application, like integrated database access, interfaces for data migration, and automatic archiving.
  • We have a lot of mass data processing.
  • Our add-on application needs to be adapted by other subsidiaries of the company.
  • We need to complete the development quickly.

Here, the recommended solution is to use ABAP and Web Dynpro ABAP for the development project. We integrate with some existing parts of SAP Business Suite, and we develop some new functionality to benefit from the many features ABAP includes for free when developing a typical business application. We also draw heavily on the advantages ABAP provides for mass data processing. For the UI, we both enhance existing Web Dynpro ABAP UIs and create new ones to take advantage of the many ways to customize and enhance both ABAP business logic and Web Dynpro ABAP UIs.

Remember, there could be other criteria that would overrule this decision. For instance, if you need your add-on to be independent of the SAP Business Suite life cycle (for example, you do not want the add-on to be directly affected when you patch and update your SAP ERP system), and you need access to libraries and tools that are only available in Java, the solution might look different and would probably be a mix of ABAP and Java-based technologies. If decoupling the add-on from SAP Business Suite is more important than the cost of an additional system in your landscape, you could also develop part or all of the new functionality on an additional ABAP application server. There is no simple equation to make the right technology decision for you.

Summary

When considering whether to implement ABAP or Java, the most important thing to remember is that it isn’t a question of which technology is better, and there is no algorithm that leads you to a particular choice automatically. The right answer depends on the details of the situation, the conditions, and the requirements in your company.

To choose the technology that is best for your project, you need to ask a number of questions. We have outlined some of these questions here and, using an example scenario, shown you how certain answers to these questions might lead you to an ABAP-based solution — for example, if you are building a typical business application, an application that should be easily adaptable and enhanceable, or if your application needs to be closely integrated with an ABAP-based application of your SAP ERP system.

In our next article, we’ll complete our journey by reviewing more questions using Java-driven examples. By the end of the series, you’ll be prepared to arrive at the right technology decision for your particular project, and to take advantage of the benefits and strengths of your choice, whether it’s pure ABAP, pure Java, or a mixed solution.

Dr. Thomas Weiss (thomas.weiss@sap.com) joined the SAP NetWeaver Product Management Training team in 2001. He is now a member of the SAP TIP Core Product Management team. His areas of focus include ABAP, the Enhancement and Switch Framework, and connectivity.

Martin Jaekle (martin.jaekle@sap.com) joined SAP in 2008 to contribute to strategic decisions focusing on SAP NetWeaver Java and related topics, after having been responsible for various aspects of software development and product management at different companies.

 1 We’ll look at Java-driven solutions, along with additional questions to consider, in the second article in the series. [back]

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ