SAP applications are a world unto themselves, offering unique challenges, unusual surprises, and an orthodoxy all their own. The SAP R/3 system has much in common with other ERP platforms, but it also has many unique features that heavily influence application development.
The developmental tools and languages available to the developer for SAP apps have a great deal of overlap with other OOP/fourth-generation facilities, and also have many characteristics specific to the SAP way of doing things.
In approaching any SAP application, the developer must remember that the SAP system’s handling of data has two central goals: to integrate it and to make it mobile. To this end, SAP R/3 may be conceptualized as a vast superdatabase, melding disparate smaller databases and external data sources into one huge, flexible, accessible library of information.
In addition, the SAP system is event-driven, mustering all that data into user-friendly business objects and providing all manner of transportation of those objects between the functional divisions within a business, and between a business and its partners.
This broad and sweeping picture cannot help but redefine the application development process for the developer moving into SAP work. In the SAP environment, most acts of data creation or modification, whether by users or passive systems, automatically set other processes in motion. The SAP developer does not simply take advantage of this capability, which does, in fact, become the core of application design.
Second in a series
This is the second installment in an occasional series on ABAP/4 and SAP. The first article on this topic argued that ABAP/4 is likely a developer’s best choice for SAP applications.
SAP’s native language and its dictionaries
It’s important to realize that SAP’s various business modules include a huge array of applications, so the task of application development is, more often than not, a case of extending an existing application rather than developing one from scratch.
Because this is so, the best application platform is often SAP’s own in-house language, ABAP/4 (the proprietary Advanced Business Application Programming language, fourth generation). The SAP system itself is written in this language, which is by definition friendly to the data-handling philosophy that “governs” SAP applications. Though other languages may be used with good results (Java is the standout), ABAP/4 cannot be matched for flexibility and convenience in customizing SAP applications.
It’s not enough, however, to simply pick up ABAP/4 as yet another 4GL in your consultant’s toolbox. To really excel at SAP application development, you need to acquire the mindset behind SAP’s structuring and accessing of data, and become familiar with its infrastructure and specific programming conventions.
Nothing beats the dictionary
Writers, including SAP application writers, depend on the dictionary. With such a mountain of data to deal with and with the necessity of handling those data as discrete logical business objects, it is absolutely crucial that you have some convenient means of keeping data types straight, giving you the full power of attributes and inheritance available for your application. SAP’s integrated ABAP/4 Dictionary gives you this capability.
In addition to the handling of conventional data types (as you’d find in any similar language), ABAP/4 allows you to define customized types and to pass their attributes via inheritance through the dictionary. That is, you can generate complex types and data objects—such as customized internal table structures—put them into the dictionary, and then generate new instances of these types as needed for your application as well as for future applications.
Because tabling and the creation of virtual objects (customized data aggregates) are cornerstones of SAP data structure, the integrated dictionary will become your best friend.
Setting the table
SAP keeps all of its databases straight so you don’t have to. It works like this: The actual databases are accessed through application- or module-specific mappings into logical databases, and the logical databases can be conveniently remapped into your application for efficient use as internal tables. Because ABAP/4 has Open SQL built in, this is achieved with remarkable ease. This allows you to map the keys to complete lists of data objects (all of your client’s customers, for example) at run time. This is done with only those data items in the referenced objects that are of use to your application, setting aside those data items that aren’t. And, of course, you can store the internal table mapping you’ve created for use in other applications.
A logic all your own
The essence of logical databases in SAP is not simply the creation of business objects from related data items, but it’s also about tying together disparate data items that go into those business objects from physically separate databases, which can be on altogether separate platforms.
This powerful concept sets ABAP/4 apart from most of its 4GL cousins. Pulling data items together is simply database management, and many systems can do it. But ABAP/4 is equipped to simplify the access process, despite the often harrowing physical and logical complexity of the actual storage in a company’s server network.
A logical database is, in SAP terms, nothing more than a stored retrieval plan for the information needed to build your app’s business objects. You have several tools at your disposal here: a view of the data within the source database, the specifics of how the data will be accessed from the source database, and a screen that allows you to specify the data’s selection criteria.
You can fine-tune the access methods of your logical database as you please, until the reports and user dialogs in your app are as fast as it is possible for them to be. And you can store your work, meaning that this well-tuned, rapid access is now available for other apps to make use of. (In fact, any change to a logical database will immediately take effect in all apps using it.)
Calling other systems
Another piece of SAP core technology available to the developer through ABAP/4 is the remote function call (RFC). While database access is central to the handling of data in SAP, the sending and receiving of that data between systems is equally important, and RFCs facilitate that communication.
Essentially, RFCs, instantiated as Business Application Programming Interfaces, are SAP’s bridges between systems. One of ERP’s major features is the steady flow of data between systems, and ABAP/4 permits the use of RFCs to execute this communication, whether between SAP systems, a SAP system and a non-SAP system, or between SAP and external applications.
In short, ABAP/4 offers the developer RFCs as the primary component for integrating systems. Both synchronous and asynchronous protocols are supported, so RFCs relieve the developer from dealing with protocols and other cumbersome details. As a building block for distributed applications, RFCs could scarcely be more convenient, and ABAP/4 makes them fully accessible.
As powerful as these features are, they can only take life within the hands of the developer, who must have a clear understanding of how best to handle the language itself.
http://www.techrepublic.com/article/abap4-fundamentals-for-sap-application-development/5034224
No comments:
Post a Comment