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 conceptualised as a vast super-database, 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 will 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 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 realise 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 customising SAP applications. It's not enough, however, to simply pick up ABAP/4 as yet another 4GL in your 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 customised types and to pass their attributes via inheritance through the dictionary. That is, you can generate complex types and data objects -- such as customised 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 (customised 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.