The New SCN SAP NetWeaver Architecture Category - An Introduction

Andy Silvey has fulfilled one of his small personal goals and contributed to the realization of a new Category on the SCN, for everything NetWeaver Architecture and concerning SAP NetWeaver Architects. The new Category can be found here, SAP NetWeaver Architecture Category On the SAP SCN. October 2013

SAP NetWeaver 7.4 is the compatible follow up release of SAP NetWeaver 7.3x. It runs on all database platforms supported by SAP NetWeaver but was optimized for SAP HANA.

Meanwhile SAP NetWeaver 7.4 SP5 was released. SP5 is the to go service release for all SAP NetWeaver customers who can install or upgrade to SP5 immediately.

New! Get an overview of the newest SP5 capabilities: SAP NetWeaver 7.4 SP 5 | SCN

Get an overview of SAP NetWeaver 7.4 capabilities in the newest article:SAPinsider: Innovate Without Disruption

Check SAP NetWeaver 7.4 Presentation Slides | SCN

Please browse the table below to get detailed information on specific spaces and topics on SCN related to SAP NetWeaver 7.4. You will find a detailed description of selected end-to-end scenarios at the end of the page.

ABAP Development on SAP HANA

With SAP NetWeaver Business Warehouse and SAP Business Suite, two major standard SAP applications can run on SAP HANA as primary database.

This allows to benefit from the speed and innovations of the SAP In Memory technology in the context of the proven SAP NetWeaver infrastructure.

SAP NetWeaver AS ABAP 7.4 offers a set of tools, development options, and examples for customers and partners for accelerating and extending their ABAP based solutions on SAP HANA. This includes opportunities to push data intensive calculations to the database (e.g. using views and database procedures) and combining transactional and analytical aspects for the end-user in real-time.

The integrated development environment  in Eclipse based on the SAP HANA Studio and the ABAP Development Tools for SAP NetWeaver support ABAP developers in End-to-End application development from the database access to the user interface.

Combining these capabilities with innovations in ABAP 7.4 that are independent of SAP HANA (such as new capabilities in the development and server infrastructure) creates new opportunities for custom development with SAP NetWeaver AS ABAP.

Explore the ABAP Development on SAP HANA step by step using ABAP for SAP HANA Reference Scenario Open Items Analytics which is an integral part of the SAP NetWeaver AS ABAP 7.4

To test-drive SAP NetWeaver Application Server ABAP 7.4 on SAP HANA, learn more about its new capabilities and the programming language enhancements you can get and run your owntrial instance provided as virtual applianceby the SAP Cloud Appliance Library.

More information: ABAP for SAP HANA

Summary

SAP responds to the needs of its customers to reduce the cost of development and operation and to bring innovation into existing landscapes without disrupting business processes and further minimizing business downtime. SAP has invested significantly in the cloud market, in in-memory technology, and in innovative mobile technology and applications. SAP NetWeaver 7.4 and SAP HANA Cloud form an application infrastructure and technology platform that provides powerful support for these investments. It enables customers to optimize applications for SAP HANA and, using tools based on the popular Eclipse development environment, quickly and easily build lightweight applications that not only run on the cloud, but integrate with SAP Business Suite back-end systems, bringing innovation across your landscape to your mobile users.

In 2007 as part of SAP NetWeaver 7.10, SAP has introduced a new software development kit (SDK) for remote function call (RFC) communications:
SAP NetWeaver RFC SDK. It is the successor to the well-known "classic" RFC SDK for SAP R/3, and you can use it in C/C++-based applications to communicate with SAP back-end systems ranging from SAP R/3 4.0B to the latest SAP NetWeaver systems. The follwoing article has originally been published in 2007 by SAP Professional Journal and appears here with permission of the publisher, Wellesley Information Services. It takes a deeper look at the design of SAP NetWeaver RFC SDK and explains the ideas behind it.

The first part describes how

• metadata (data types, structure definitions, descriptions of function module signatures) is handled by the NW RFC SDK
• data (fields, structures, tables) is handled by the NW RFC SDK
• C/C++ programs can send RFC requests into the ABAP back-end system
• C/C++ programs can process the response or various exceptions returned by the ABAP back-end system

Article in PDF format: NW RFC SDK Part 1: RFC Client Programs

Note: the old links to the sample programs given in the article no longer work. Instead the sample programs can now be downloaded here:

samples.zip

In 2007 as part of SAP NetWeaver 7.10, SAP has introduced a new software development kit (SDK) for remote function call (RFC) communications:
SAP NetWeaver RFC SDK. It is the successor to the well-known "classic" RFC SDK for SAP R/3, and you can use it in C/C++-based applications to communicate with SAP back-end systems ranging from SAP R/3 4.0B to the latest SAP NetWeaver systems. The follwoing article has originally been published in 2008 by SAP Professional Journal and appears here with permission of the publisher, Wellesley Information Services. It takes a deeper look at the design of SAP NetWeaver RFC SDK and explains the ideas behind it.

The second part describes how

• C/C++ programs can receive and process RFC requests from an ABAP back-end system
• C/C++ programs can return normal responses or various exceptions to the ABAP back-end system

Article in PDF format: NW RFC SDK Part 2: RFC Server Programs

Note: the old links to the sample programs given in the article no longer work. Instead the sample programs can now be downloaded here:

samples.zip

In 2007 as part of SAP NetWeaver 7.10, SAP has introduced a new software development kit (SDK) for remote function call (RFC) communications:
SAP NetWeaver RFC SDK. It is the successor to the well-known "classic" RFC SDK for SAP R/3, and you can use it in C/C++-based applications to communicate with SAP back-end systems ranging from SAP R/3 4.0B to the latest SAP NetWeaver systems. The follwoing article has originally been published in 2008 by SAP Professional Journal and appears here with permission of the publisher, Wellesley Information Services. It takes a deeper look at the design of SAP NetWeaver RFC SDK and explains the ideas behind it.

The third part describes how

• transactional, queued and background RFC can be used
• metadata can be hard-coded, instead of using metadata dynamically retrieved from the back-end DDIC
• RFC Callback works in client as well as server programs
• SSO and SNC can be used

Article in PDF format: NW RFC SDK Part 3: Advanced topics

Note: the old links to the sample programs given in the article no longer work. Instead the sample programs can now be downloaded here:

samples.zip

callback.zip

Business Drivers and Overview of SAP NetWeaver Information Lifecycle Management (ILM)

Legal requirements and internal processes are the commercial driving forces for a solution such as SAP NetWeaver Information Lifecycle Management. SAP NW Lifecycle Management is a new component that provides end-to-end support in the administration of your information over its entire lifecycle. It orientates your information to your business processes by administrating policies and service levels in relation to applications, metadata, information and data.

SAP NetWeaver Information Lifecycle Management is a component that requires the acquisition of a license. Once you receive this license you need to activate it using the Switch Framework (transaction SFW5). The minimum prerequisite is the installation of SAP NetWeaver 7.0 Enhancement Package 1. You can find other requirements in the documentation for the various basic modules of SAP NetWeaver Information Lifecycle Management that are listed in the Scope Of Functionality section in the official documentation.

Demand for Information Lifecycle Management has risen strongly in the last few years as a result of internal and external factors. In particular, these factors include the requirements from legal regulations and the risk management this entails, the increasing trend towards harmonizing and consolidating system landscapes and the aspect of total cost of ownership (TCO).

SAP NetWeaver Information Lifecycle Management

The SAP NetWeaver Information Lifecycle Management is based on three pilars:

• Data Archiving.
• Retention Management.
• System Decommissioning.

All pilars will be explained in greater detail in the following concepts.

SAP NetWeaver Information Lifecycle Management – Data Archiving

With the archiving objects that are provided by SAP applications, you write data from the application tables in files in the file system within the framework of SAP data archiving. Naturally, during this process the writing programs use business criteria to decide whether data can be removed from the database. As soon as data from concluded processes can be securely saved in files, it can be deleted from the online system database with a delete program.

These files can be transferred from the file system to another storage medium for long-term storage and access. For this you use the SAP ArchiveLink interface as standard and save the data on DVDs or CDs.

The data archiving module forms the core of SAP NetWeaver Information Lifecycle Management. In SAP NetWeaver Information Lifecycle Management, these "classical" functions have been extended to allow you to link to the other two basic modules. The conventional archiving programs now support data destruction and the creation of snapshots in addition to data archiving for SAP NetWeaver Information Lifecycle Management.

SAP NetWeaver Information Lifecycle Management – Retention Management

This module contains new functions and is orientated towards scenarios at the end of the data lifecycle. It encompasses various tools and methods for all aspects of data retention – from the creation of data to its destruction. Legal requirements and other rule sets are taken into consideration.

The second pilar is Retention Management:

The tools and methods include the management of policies and rules, ILM-conformant integration of storage systems, destruction of data at the end of its lifecycle as well as the functions of Legal Case Management such as setting legal holds and performing e-discovery drilldown reporting. With these functions it is possible to completely map and control the lifecycle of the data.

Retention Management is principally orientated towards the "end-of-life data" business scenario.

You can define policies and rules according to different criteria with the aid of IRM. For example, you can specify how long the retention period should be for a particular object type, in which storage location the data should be retained and when it can be (or must be) destroyed. Policies can be based on (external) legal requirements or (internal) Service Level Agreements (SLAs) and and can encompass structured and unstructured data.

The Information Retention Manager (IRM) provides you with a new policy engine that you can use to create and administrate retention policies and rules for all data types in your business environment – including non-SAP data and even paper documents. This gives you a central access point in your system for the administration of all your retention rules. When archiving SAP data the retention properties of the rules are derived and then transferred to an archive hierarchy along with the archived data.

For transaction data a rule is defined with the specification of the minimum retention period, the maximum retention period, the unit for the retention period, the start of the retention period and the desired storage location for archiving.

Storage is a key aspect of the ILM solution and enables the SAP NetWeaver Information Lifecycle Management to cover the entire lifecycle of the data. ILM-capable storage means that the storage system is connected to the application by means of a WebDAV-based interface and is able to adopt the retention properties received from the application and use them.

Since April 2008, SAP has been offering an official ILM certification for hardware partners. We recommend using a certified storage product that is similar to WORM to ensure your ILM strategy has the best possible security.

When storing archived data, an archive hierarchy is set up in accordance with the rules determined in IRM. The hierarchy ensures that that archived data is clearly structured, which makes search functions and other ILM processes, such as data destruction possible.

The new function of Legal Case Management supports the administration of specific data in the context of legal operations. You can create a legal case and find all data related to this case using search criteria that you enter. You can then use the legal hold function to "freeze" the data relating to this legal case.

Thanks to the close interlinkage between data archiving, IRM and ILM-capable storage, the data that is subject to a legal hold is not deleted until the legal hold is reversed – even if the retention period has already elapsed and the data could actually be released for destruction.

SAP NetWeaver Information Lifecycle Management – System Decommissioning

This module contains new functions and is orientated towards scenarios at the end of the system lifecycle. It provides a standardized method for decommissioning legacy systems. The process is handled in two phases by the corresponding functions: system decommissioning and auditing and reporting.

The third pilar is System Decommissioning:

In the first phase, new functions and tools are used to remove all of the data from the system to be decommissioned and it is then stored in a Retention Warehouse. The corresponding system is then rendered dormant. In the second phase, the archived data is prepared and transferred to an SAP NWBW environment where it remains available for reporting and audit purposes. Local Reporting is possible also.

The old system is decommissioned and the data is stored in an archive. The original system is no longer available. If a check is announced involving the data that was stored in the dormant system and that is now stored in the archive:

1. The archived data is selected and a bundle is created.

2. The necessary infrastructure is generated in SAP NetWeaver BW and the bundled data is transferred to BW.

3. New queries can be created or predefined queries can be used.

As soon as the auditors have performed an audit on the data and left the company, the SAP NetWeaver Information Lifecycle Management administrator can delete the objects again in SAP BW.

The Business Usage of SAP NetWeaver Information Lifecycle Management

SAP Data Archiving, which is part of the standard system provided by SAP solutions, enables you to ensure system availability and system performance at a high level. It keeps response times small and system resources are efficiently used.

SAP NetWeaver Information Lifecycle Management Retention Management supports the entire lifecycle of archived data: creation – retention – destruction. Centralized Retention Management facilitates automated processes and reduces the risk of cases of dispute and e-discovery costs.

You can avoid the costs incurred in maintaining legacy systems that are no longer used with the deployment of the SAP NetWeaver Information Lifecycle Management Retention Warehouse.

The ROI sinks significantly with every additional decommissioned system. After the fifth system it is estimated to be less than 6 months.

Business Drivers and Overview of SAP NetWeaver Information Lifecycle Management (ILM)

Legal requirements and internal processes are the commercial driving forces for a solution such as SAP NetWeaver Information Lifecycle Management. SAP NW Lifecycle Management is a new component that provides end-to-end support in the administration of your information over its entire lifecycle. It orientates your information to your business processes by administrating policies and service levels in relation to applications, metadata, information and data.

Image provided by SAP

SAP NetWeaver Information Lifecycle Management is a component that requires the acquisition of a license. Once you receive this license you need to activate it using the Switch Framework (transaction SFW5). The minimum prerequisite is the installation of SAP NetWeaver 7.0 Enhancement Package 1. You can find other requirements in the documentation for the various basic modules of SAP NetWeaver Information Lifecycle Management that are listed in the Scope Of Functionality section in the official documentation.

Demand for Information Lifecycle Management has risen strongly in the last few years as a result of internal and external factors. In particular, these factors include the requirements from legal regulations and the risk management this entails, the increasing trend towards harmonizing and consolidating system landscapes and the aspect of total cost of ownership (TCO).

SAP NetWeaver Information Lifecycle Management

The SAP NetWeaver Information Lifecycle Management is based on three pilars:

• Data Archiving.
• Retention Management.
• System Decommissioning.

All pilars will be explained in greater detail in the following concepts.

Image provided by SAP

SAP NetWeaver Information Lifecycle Management – Data Archiving

With the archiving objects that are provided by SAP applications, you write data from the application tables in files in the file system within the framework of SAP data archiving. Naturally, during this process the writing programs use business criteria to decide whether data can be removed from the database. As soon as data from concluded processes can be securely saved in files, it can be deleted from the online system database with a delete program.

These files can be transferred from the file system to another storage medium for long-term storage and access. For this you use the SAP ArchiveLink interface as standard and save the data on DVDs or CDs.

The data archiving module forms the core of SAP NetWeaver Information Lifecycle Management. In SAP NetWeaver Information Lifecycle Management, these "classical" functions have been extended to allow you to link to the other two basic modules. The conventional archiving programs now support data destruction and the creation of snapshots in addition to data archiving for SAP NetWeaver Information Lifecycle Management.

Image provided by SAP

SAP NetWeaver Information Lifecycle Management – Retention Management

This module contains new functions and is orientated towards scenarios at the end of the data lifecycle. It encompasses various tools and methods for all aspects of data retention – from the creation of data to its destruction. Legal requirements and other rule sets are taken into consideration.

The second pilar is Retention Management:

The tools and methods include the management of policies and rules, ILM-conformant integration of storage systems, destruction of data at the end of its lifecycle as well as the functions of Legal Case Management such as setting legal holds and performing e-discovery drilldown reporting. With these functions it is possible to completely map and control the lifecycle of the data.

Retention Management is principally orientated towards the "end-of-life data" business scenario.

You can define policies and rules according to different criteria with the aid of IRM. For example, you can specify how long the retention period should be for a particular object type, in which storage location the data should be retained and when it can be (or must be) destroyed. Policies can be based on (external) legal requirements or (internal) Service Level Agreements (SLAs) and and can encompass structured and unstructured data.

Image provided by SAP

The Information Retention Manager (IRM) provides you with a new policy engine that you can use to create and administrate retention policies and rules for all data types in your business environment – including non-SAP data and even paper documents. This gives you a central access point in your system for the administration of all your retention rules. When archiving SAP data the retention properties of the rules are derived and then transferred to an archive hierarchy along with the archived data.

For transaction data a rule is defined with the specification of the minimum retention period, the maximum retention period, the unit for the retention period, the start of the retention period and the desired storage location for archiving.

Storage is a key aspect of the ILM solution and enables the SAP NetWeaver Information Lifecycle Management to cover the entire lifecycle of the data. ILM-capable storage means that the storage system is connected to the application by means of a WebDAV-based interface and is able to adopt the retention properties received from the application and use them.

Since April 2008, SAP has been offering an official ILM certification for hardware partners. We recommend using a certified storage product that is similar to WORM to ensure your ILM strategy has the best possible security.

When storing archived data, an archive hierarchy is set up in accordance with the rules determined in IRM. The hierarchy ensures that that archived data is clearly structured, which makes search functions and other ILM processes, such as data destruction possible.

Image provided by SAP

The new function of Legal Case Management supports the administration of specific data in the context of legal operations. You can create a legal case and find all data related to this case using search criteria that you enter. You can then use the legal hold function to "freeze" the data relating to this legal case.

Thanks to the close interlinkage between data archiving, IRM and ILM-capable storage, the data that is subject to a legal hold is not deleted until the legal hold is reversed – even if the retention period has already elapsed and the data could actually be released for destruction.

SAP NetWeaver Information Lifecycle Management – System Decommissioning

This module contains new functions and is orientated towards scenarios at the end of the system lifecycle. It provides a standardized method for decommissioning legacy systems. The process is handled in two phases by the corresponding functions: system decommissioning and auditing and reporting.

The third pilar is System Decommissioning:

In the first phase, new functions and tools are used to remove all of the data from the system to be decommissioned and it is then stored in a Retention Warehouse. The corresponding system is then rendered dormant. In the second phase, the archived data is prepared and transferred to an SAP NWBW environment where it remains available for reporting and audit purposes. Local Reporting is possible also.

Image provided by SAP

The old system is decommissioned and the data is stored in an archive. The original system is no longer available. If a check is announced involving the data that was stored in the dormant system and that is now stored in the archive:

1. The archived data is selected and a bundle is created.

2. The necessary infrastructure is generated in SAP NetWeaver BW and the bundled data is transferred to BW.

3. New queries can be created or predefined queries can be used.

Image provided by SAP

As soon as the auditors have performed an audit on the data and left the company, the SAP NetWeaver Information Lifecycle Management administrator can delete the objects again in SAP BW.

The Business Usage of SAP NetWeaver Information Lifecycle Management

SAP Data Archiving, which is part of the standard system provided by SAP solutions, enables you to ensure system availability and system performance at a high level. It keeps response times small and system resources are efficiently used.

SAP NetWeaver Information Lifecycle Management Retention Management supports the entire lifecycle of archived data: creation – retention – destruction. Centralized Retention Management facilitates automated processes and reduces the risk of cases of dispute and e-discovery costs.

You can avoid the costs incurred in maintaining legacy systems that are no longer used with the deployment of the SAP NetWeaver Information Lifecycle Management Retention Warehouse.

Image provided by SAP

The ROI sinks significantly with every additional decommissioned system. After the fifth system it is estimated to be less than 6 months.

Data Structure of SAP Systems

A client is a unit within an SAP system that is self-contained in terms of business, organization, and data. A client is characterized by its own business-data environment, as well as master, transaction, and user data. This data in a client is known as client-specific data. All types of client-specific data depend on each other in various ways. For example, business application data is checked for consistency against the Customizing settings for the client when the data is entered and rejected.

When an SAP system is prepared for use, customizing is done for each client. The Customizing settings are used to define the organizational structures of customers, such as distribution channels and company codes. The Customizing settings are also used to set the parameters for SAP transactions so that they reflect customer-specific processes. In addition to the client-specific customizing settings, there are settings that need to be made only once for all clients in the SAP system. These cross-client Customizing settings include the public holiday calendar, for example, and settings for the system change option.​

image provided by SAP

Repository

The repository is where objects are accessed using the ABAP Workbench. The repository is a cross-client store containing all Dictionary objects (tables, data elements, and domains) and all ABAP programs, menus, and screens. If we develop or change any repository object in one client, an SAP system uses the same form of the object in every other client.

Repository objects are grouped together to form packages. Packages are containers for semantically-linked development objects (programs, tables, and so on). The ABAP Repository contains packages from all software components.

Three-System Landscape

In a three-system landscape, you can set up several SAP systems on one license. However, you may use only one of these systems as a production system. Each three-system landscape contains a working client and other clients. To facilitate the consistency of Customizing settings, three working clients can have the same identification number. In practice, however, the development, test, and productive clients sometimes have different numbers.

Corresponding changes of program coding and/or Customizing data could be critical and may need to be tested beforehand. The changes also demand detailed logging of transport requests.

In addition, ABAP Repository objects are client independent, which means that the changes made in one client immediately affect all other clients of the same SAP system. Customizing settings must not be configured directly in the productive systems in most cases.  Special client settings can be set up to prevent any changes in Customizing settings.

image provided by SAP

Process Involved in Three-System Landscape

In a three-system landscape, you perform the required customization of the SAP standard processes in the development system. You also develop programs on the development system. All Customizing settings and changes (developments, corrections, or modifications, if required) to the repository are then transferred to the quality assurance system (or “test system” for short) to be checked without influencing production.

After testing all objects and settings imported into the test system, you can transfer them to one or more production systems.

The systems in a three-system landscape must have unique three-character descriptions, such as Development (DEV), Quality Assurance (QAS), and Production (PRD).

The system identifier (SID) is always three characters long and starts with a letter, but it can consist of letters and numbers. SAP reserves some of the SIDs. The SID SAP cannot be used to install an SAP system. For further details, check the installation guide of the SAP software that you would like to install.

ABAP

ABAP is a programming language developed by SAP. Most of the business applications of an SAP system are written in ABAP. An ABAP program consists of individual statements beginning with a keyword and ending with a period.

Example program:

REPORT first report.

WRITE 'My first ABAP report!'.

The example program contains two statements, one on each line. The keywords are REPORT and WRITE. The program displays a list. In this case, the list contains the line: My first ABAP report!

The figure shows an excerpt from an ABAP program. You can use special commands or keywords in ABAP programs to create selection screens (keyword PARAMETERS), to print lists (keyword WRITE), and to access table content (for example, using the keyword SELECT). The ABAP statement CALL SCREEN calls a screen (consisting of a screen image and its flow logic) defined in the Screen Painter screen.

ABAP uses Open Structured Query Language (SQL) commands to access the database. Open SQL consists of a set of ABAP statements that execute operations on the central database of the SAP system. Open SQL is used in an identical way for all supported database platforms on SAP systems, based on AS ABAP, meaning that the type of database used has no effect on the development of a program.

image provided by SAP

The characteristics of ABAP are as follows:

• Multilingual capability (text elements, such as list headers and input field texts, are stored separately for each supported language)
• Simple and effective development of graphical user interfaces
• Object-oriented programming (ABAP Objects)
• Platform independence (using Open SQL and the database interface)
• Efficient access to data structures, such as tables, data elements, and so on

ABAP Workbench Tools

In AS ABAP, you use the ABAP Workbench, a graphical programming environment, to write application programs. The ABAP Workbench enables you to use programming tools, pushbuttons, the context menu (right mouse click), and forward navigation (double-click an object name). An ABAP application is, for example, a transaction or a report.

You can access a range of tools, including the following tools:

• ABAP Editor (transaction SE38 or SE80) to write ABAP programs
• ABAP Dictionary (transaction SE11) to define and describe tables, data elements, lock objects, and so on
• Screen Painter (transaction SE51 in the User Interfacesubdirectory) to create interactive user interfaces
• Function Builder (transaction SE37) to create and manage function modules (these are independent modules of ABAP code with defined input and output interfaces)

The individual Workbench tools combine to form an integrated system. If, for example, you are working with program objects in the ABAP Editor, then the editor also recognizes objects created using other tools. A specific tool for editing an object starts when you select the object and double-click it.

You can find the ABAP Workbench tools on the SAP Easy Access screen by choosingTools→ ABAP Workbench→Development. When working in the Workbench, you come across development objects and packages. Development objects, such as reports, transactions, or screen definitions, are objects that you can edit using the ABAP Workbench. A package contains logically-related development objects, such as all objects for a specific application.

SAP provides the Object Navigator to help you organize your development processes using the ABAP Workbench. This enables simple, uniform access to repository objects and their corresponding development tools. You can access Object Navigator by using transaction SE80, or you can also chooseTools→ ABAP Workbench→ Overview →Object Navigator.

image provided by SAP

Access to ABAP Source Code

SAP delivers the source code for all ABAP programs. You can view the code and use it as a template for your programs, among other things.

In any application, you can choose System→ Status and double-click to navigate to the relevant ABAP Workbench tool. The Workbench displays the selected object in the appropriate tool, provided you have the necessary access rights.

image provided by SAP

Creation of ABAP Programs by Using the ABAP Editor

You can use the ABAP Editor (transaction SE38 or link in the Object Navigator, transaction SE80) to create and edit programs. ABAP programs are stored in the SAP system as entries in database tables.

When you want to create a new program, enter both a program title and attributes for the program. These attributes include the program type (for example, executable program), status (for example, test program), and application component. When saving a program, you also need to assign it to a package.

Once you complete these activities, you can write your own program by using the ABAP Editor.

image provided by SAP

ABAP Editor

The ABAP Editor provides a range of functions, including a syntax check and an option for the capitalization of ABAP keywords. You can also display syntax help for an ABAP keyword by positioning the cursor on the keyword and pressing F1. SAP recommends that you develop ABAP programs by using only the ABAP Editor. Using the ABAP Editor, you can navigate to other tools in the development environment, such as theABAP Dictionary, the Screen Painter, and the Menu Painter, by double-clicking the repository objects in the coding.

If you create or change a program (or a development object) and then save it, an inactive version of the program (or development object) is always saved in the ABAP repository, making it possible to continue developing the program without changing the active system. Until you activate the inactive version of the program (or object), all calls to the program (or object) use the last active version instead of the version on which you are working.

You can execute your program in the ABAP Editor by using Direct processing (F8 key). This action executes the inactive version of your program for testing purposes.

ABAP Dictionary

The ABAP Dictionary is a central component of the ABAP Workbench, containing both business and technical definitions and descriptions of SAP data. The ABAP runtime environment, such as the ABAP interpreter and screen processor, accesses the information of the ABAP Dictionary.

The ABAP Dictionary enables all data definitions that the SAP system uses to be described and managed centrally. The ABAP Dictionary is an active dictionary that is completely integrated in the SAP development and runtime environment. The dictionary information is created only once, but is available throughout the system at all times. The ABAP Dictionary (transaction SE11) automatically provides all the information that has been created or modified, ensuring that runtime objects are up-to-date and data is consistent and secure.

The objects of the ABAP Dictionary can be subdivided as follows:

• Database object definitions (tables, views, and so on)
• Type definitions (structures, table types, and so on)
• Service definitions (F1 help, F4 help, lock objects, and so on)

Object Types in the ABAP Dictionary

The different object types are explained as follows:

• TablesThe definition of tables in the ABAP Dictionary is database independent. This definition serves as the basis for the creation of a table with the same structure in the underlying database.
• ViewsThese are logical views of one or more tables. View structures are defined in the ABAP Dictionary. This structure is the basis for the creation of a view on a database.
• Lock objectsLock objects coordinate attempts by several users to access the same dataset. Function modules are generated from the lock object definition in the ABAP Dictionary. Users can use the function modules in application programs.
• DomainsDomains are used to group fields that have similar technical or business purposes. A domain defines the range of values for all table fields and structure components that refer to the domain.

Significance of the ABAP Dictionary

The integration of the ABAP Dictionary into the program flow is based on the interpretative method of the AS ABAP runtime environment. Instead of working with the original version of an ABAP program, the ABAP processor interprets a runtime object generated from the program text before its first execution. Runtime objects are also automatically generated before the execution of a program if a time stamp comparison of the runtime objects reveals that they are no longer consistent with the current status of the ABAP Dictionary.

In the SAP system, the ABAP Dictionary also allows you to manage the database tables that are relevant to the SAP system. You do not need detailed, product-specific database knowledge for application development. The ABAP Dictionary transfers the runtime table definitions to the database level.

The interaction between the ABAP Dictionary and the development or runtime environment is outlined in the figure.

image provided by SAP

Table Definition and the Two-Level Domain Concept

You can define tables in a database independently in the ABAP Dictionary. When you activate the table, a system creates a physical table definition in the database, based on the table definition stored in the ABAP Dictionary. The table definition in the ABAP Dictionary is converted into a definition for the database that is used.

A field is not an independent object because it depends on a table and can only be maintained within the table.

You can use domains and data elements to define fields in a table. A domain is used to technically define a table field. For example, the field length and type, output attributes, and restrictions of possible values (fixed values) are defined in the domain.

Data elements are used to describe the semantic attributes of a field in the context of a table. For example, in a data element, you can define a short description of a table field that is displayed on the screen when you call the F1 help. Using the data element, you can also specify the input field screen text (for example, field label – Destination Airport).

The figure showing a table definition and domain concept uses table SPFLI from the flight data model as an example. This table maintains flights (for example, flight XY from A to B). The table contains fields for the departure airport (AIRPFROM) and the destination airport (AIRPTO) because the departure and destination airports are different things in a business context. Two data elements, S_FROMAIRP and S_TOAIRP, are defined. However, because both columns contain the names of airports, both data elements refer to the same domain, S_AIRPID. The domain has the technical type CHAR and is three characters long.

image provided by SAP

Modeling in the ABAP Dictionary

The figure shows data modeling (entity/relationship between tables) in the ABAP Dictionary. SAP provides data models for some of their applications. These models can be displayed using SD11. The models show entities and their relationships. Entities are tables in the ABAP Dictionary.

image provided by SAP