Download code from GitHub
The chapter is an introduction to the Systems, Applications, Products (SAP) system. You will learn how to organize their daily work, how to act within SAP systems, how to add custom code, and how to change software features of SAP systems. This chapter presents modern techniques of cooperation within a company. Basic knowledge of these issues is required to work with the SAP system. This chapter is an introduction to the more complex and difficult topics contained in this book.
The following topics will be covered in this chapter:
This chapter does not have complex technical requirements. To check the solutions and examples, it is worth having user access to the SAP system. Other information (for example, agile designing the UI) can be better understood by IT employees. However, it is worthwhile for everyone who's interested in working with SAP systems to read the information contained in this chapter.
All the code used in this chapter can be downloaded from the following GitHub link: https://github.com/PacktPublishing/Mastering-SAP-ABAP/tree/master/Chapter01.
There are several ways in SAP to make changes. Some of them are configuration changes, and some are purely programmatical changes.
SAP systems can be enhanced in five ways:
- Customizing: Specific business and functional process configuration according to the implementation guide. The need to make these changes is predicted by SAP and the procedure of implementation has been developed.
- Personalization: Setting up global attributes to display certain fields (such as default values or switching off the display of a field).
- Modification: These are changes SAP Repository objects make at the client side. SAP also can deliver a new version of those objects, and customers need to reflect these changes in the system. Before version 4.0B, customers needed to make this adjustment manually using upgrade utilities. From 4.5A, customers can use the Modification Assistant to automate this procedure.
- Enhancement: Creating a repository object inside a standard SAP program. More details about enhancement will be in Chapter 10, Modification and Customization Techniques.
- Custom development: This means creating objects that are unique to the client repository, which is created in the specified namespace, such as
Y*orZ*, for all new objects.
In your daily work as an ABAP programmer, your most common work is creating custom developments and enhancements. Since we have a chapter on enhancements, we will focus here on custom development.
In custom development, we can create a custom program and dictionary elements. There will be more about creating dictionary elements in Chapter 2, The Basic Structure of ABAP.
As an example, we will show you how to create one of the most basic programs: Hello World.
In the first step, we need to open one of the most commonly used transactions in our daily work—SE80. This transaction is called Object Navigator, and is a transaction where we can create, change, and delete most ABAP objects.
The main window for the SE80 transaction looks like this:
First, to open the SE80 transaction, we need to put the name of the transaction in the search box, as shown in the following screenshot:
Press enter, or click on
.
After opening a transaction, we need to choose the Program option in the drop-down list on the left and enter the name Z_HELLO_WORLD in the window, as shown in the following example, and press Enter:
In the next window, choose Yes:
Confirm the name of a new program in the next window. Click on
or press Enter:
In the next window, define the attributes of the program, and now press Enter or click on
:
After this, choose a package. We need to create a program as a local object, so click on
:
After this, we get a window like this:
Now change the mode to Change by clicking on the
icon or pressing Ctrl + F1. The background color of the window with the code will change to white. Now we put the code there.
To print Hello world on the screen, we just need to add this:
WRITE 'Hello World'.
The program looks similar to the following screenshot:
The program now needs to be activated. To activate it, click on
or press Ctrl + F3. When an object has been activated, a message will be shown:
.
To execute the program, click on
or press F8:
The result of the program is shown in the preceding screenshot.
Design thinking is a method of creative problem-solving. This method is designed to deliver innovative solutions by using a specific work method. The motto of this method is doing, not talking, so going over every detail of the project is changed into a multi stage division of tasks in order to extend and refine subsequent tasks.
The process of design thinking is divided into five steps:
- Empathy: All of the new solutions are created for people. Therefore, the needs of a given group of people should be known, and this is why empathy is the starting point of all projects created by design thinking. To find the optimal solution, we need to see how this solution will help the common user.
- Define the problem: In this stage, we need to define the exact problem to solve. We need to remember not to define problems in too narrow or too wide a range so that the solution will not be limited by rigid frames.
- Ideas: This stage consists of creating as many ideas as possible for solutions relating to the previously defined problem. In this step, a brainstorm is very useful. The important thing is not to stick to your own ideas, and not to judge others. These sessions should be ended by choosing a concrete solution, which will be picked from the previously selected ideas.
- Prototypes: Creating the prototypes is an indispensable step. Building prototypes should not be a very complicated process. The most important thing is to make a preliminary visualization of the idea, because only in that way can the idea be tested naturally. Every subsequent prototype should be created by thinking of the user and answering concrete questions.
- Tests: This step is extremely important. In this step, the product is tested in a real environment, so you can check that it functions correctly. Every prototype can be evaluated by the group (for example, the project group), and the best one will be chosen for further improvements. Testing should be repeated until a satisfactory result is obtained.
LDUF is the process of modeling a small subsystem before coding, and BDUF is also a process of modeling, but in BDUF, the whole system needs to be modeled before implementation. BDUF can also be an anti-pattern for many reasons, but LDUF (or many occurrences of LDUF within a project) is often helpful.
BDUF occurs in one of two categories:
- A document of the high-level architecture, which determines the key features of architecture, but the rest of the things are unspecified and/or unclear.
- General documentation should describe everything from high-level architecture to the smallest detail of the system. These documents are often incoherent as there are no automatic ways to cross-check them.
LDUF can be precise and concise, and many programmers/architects can check/verify LDUF and detect any inconsistencies.
Generating and changing BDUF is often hard and expensive. It requires teams of analysts, consultants, and architects, and support from many layers of management. LDUF is light and informal—often, a programmer can do a mock-up, and if it's checked, it can be checked by a small team.
These are the main aspects of LDUF:
- Highly informal; it can be made by yourself or with a small team of programmers.
- Code is created in a small subsystem, which can be as small as even one class, function, or package.
- Often not prescriptive—the results are to be used as advice, not requirements.
BDUF is prescriptive—the code must be consistent with the paper project; all exceptions require management intervention. Additionally, it is anti-productive for many of the reasons mentioned in the preceding points.
When designing new software, it is not only a matter of creating functional code. The eventual outcome is going to be a product that serves its purpose, but is also possible to improve, is robust, is easily maintained, and can be used for a long time. From the user's perspective, once the product is paid for, it won't require much more cost in terms of funds, man effort, or any other measurable value.
In order to fulfill these goals and achieve user satisfaction, the philosophy of quality engineering was introduced. In principle, it defines product quality as the ratio of the result of efforts and the total cost; however, in detail, it considers various factors, such as reliability, maintainability, continuous improvement, corrective actions, and risk management.
Particularly in software engineering, there is a need to estimate the quality through an end-to-end view. It requires the collaboration of various actors, whose roles are mostly independent—business architects, security officers, project managers, and more.
One of the basic steps in designing for quality is to determine quality objectives that describe the requirements for software quality. The software quality should be considered in two areas:
- How it complies with functional requirements—whether the developed product is actually doing what it is supposed to do
- How it meets the non-functional requirements—whether it reaches its goals in the correct way
Once the objectives are defined, they can be measured with help of appropriate models and various methods, such as Goal Question Metric (GQM), Balanced Scoreboard (BS), or Practical Software Measurement (PSM).
There is no universal way to measure and control the value of quality in all environments. From the vast list of factors, several apply to SAP systems, and should always be considered when developing new code:
- Understandability: Both the code and all the documentation should be readable by peers.
- Conciseness: Not only should the code be kept small, but it also should not process unnecessary data.
- Consistency: The software should follow the notation conventions present in the system.
- Maintainability: It should be well documented and not complex (modularized as needed) to allow for future updates.
- Testability: The software should be written in a way that allows tests to check its correctness and performance.
- Reliability: The code should behave properly (non-erroneously) in all conditions.
- Security: It should always consider preventive measures to avoid unauthorized access to important data.
Depending on the level of interaction with the user, there are several additional factors that should be considered:
- The intuitiveness of the UI
- Ease of use
- Sensibleness of messages, for example, errors
- Responsiveness of the interface
Although these terms tend to be subjective and, in general, hard to determine in the design phase, they have a major impact on the quality of the software as seen by the end user, and therefore, cannot be neglected.
The practical approach of building and implementing user interfaces will be shown in Chapter 7, Building User Interfaces, and Chapter 8, Creating Stunning UI5 Interfaces. There are, however, some ground rules and guidelines that should be followed when designing UIs:
- Use written words: As a rule, the software should be as self-descriptive as possible. Although graphical interfaces use images or any other means of communication, it is still encouraged to give the user appropriate and relevant information with text.
- Use the user's language: All messages, field names, and texts should be defined in the user’s language (if possible).
- Use consistent terminology: The same objects should be named the same way throughout the environment.
Creating a user interface for R/3 transactions requires a few decisions to be taken up front. One of the most important decisions is to determine the basic type of application:
- With screen changes:
- With multiple areas:
Both types have pros and cons, and the choice depends on several criteria—length of processing, the amount of detail required, the user type (such as casual or expert), and the data type (such as a flat structure or volume).
The main goal of the design is to facilitate the user's focus on the current task, while more or less ignoring irrelevant details. In order to do so, use expand and collapse areas and splitters.
When designing R/3 screens in detail, there are several effects—psychological principles—that should be considered to improve the perception of information:
- The effect of proximity: Items that are close together tend to be grouped in our perception.
- The effect of similarity: Items of the same size, shape, or quality are likely to be viewed as a group or pattern.
- The effect of closure: Lines that enclose areas are perceived as units.
- The effect of continuity: Items arranged into a unified layout are perceived as a unit.
Services, in principle, are meant to be consumed by some other part of the system, or even by an external system. It is required to keep in mind that the service may not, and most likely will not, be able to determine where and when it is used. This is why this type of development needs to be particularly robust and reliable, as various areas of the system may depend on its correct functioning.
When designing the services, aside from their scenario-specific implementation needs, there are several things that should be considered in order to minimize upgrade and maintenance costs:
- Keep services singular-task oriented: Even if the service is supposed to perform many actions on the system, one entry point should perform one consistent end-to-end task (for example, creating a business object, or deleting one). Avoid mixing multiple tasks in a single service call.
- Avoid direct database manipulation in services: Delegate all logic to the business logic layer.
- Expect, but check: Do not assume that all the required data is provided by the caller, and always verify its consistency.
- Provide consistent and explanatory responses, especially when errors occur, so the caller can react accordingly.
- Keep the service well documented, so it is clear from the consumer's perspective what to expect when calling a particular part of it.
- If possible, keep the service's interface unchanged: Even small changes to the interface will require adjustments in the consumer's implementation. Utilize optional parameters to keep backward compatibility.
The business logic layer is meant to handle business objects and the interaction between them. Decouple it from the service and database layers—it should know as little about the database access or user interaction as possible, yet exchange information with them as needed using a level of abstraction, such as interfaces or base classes. The business logic should focus on transforming and calculating data, leaving other tasks to other layers.
Minimize the complexity of the business logic itself by separating concerns into different areas. Keep the processing, workflow, and business entities separated and loosely coupled. The separation will make the implementation easier to follow, whereas loose coupling will allow modification with a relatively low cost. Then, make sure you avoid the duplication of functionalities in different areas by reusing common parts of business logic.
Identify the consumers of the business layer so that the data can be exposed in the desired way. This will prevent the additional effort of converting data from one format to another. Having consumers in mind, make sure you have prepared not only the functional logic, but also various auxiliary aspects, such as security requirements, validations, exception management, and concurrency—keep them consistent and manage them centrally if possible.
Do not forget about unexpected situations and audits—use logs to store the history of critical changes or errors, yet without business-sensitive data. Ensure that errors in the logging process itself do not affect the normal functionality of the system—keep it as a separate logical unit. Make sure that the logged information is sufficient to track the root causes of any problems.
Designing the database is an essential part of the company's organization. This is a definition that covers data organization according to the model adopted. Designing the database prepares how data is to be linked in tables. It is also necessary to specify which data should be stored. Designing the database provides easier design, expansion, and maintenance of the SAP system. The correct design of the database greatly influences the optimization and quality of the system.
Creating logical and physical models of the database system is the target in designing databases. It is a complicated and complex process due to the use of relational databases in SAP systems. This architecture has its own great advantages, and a proper design simplifies the implementation of the ABAP language.
The logical model contains information on data storage, but there is no information on how it will be stored. This model makes it easier to analyze the structure of an information system that's unrelated to a specific database implementation. A physical data model enables us to analyze the tables, views, and other objects in a database. The physical data design model includes changing the logical database design to a physical layer. The designer uses software systems for this purpose, such as database management systems (DBMSes). A DBMS is system software for creating and managing databases.
In the SAP system, it is possible to graphically show connections using foreign keys. Using this tool is extremely simple. The user enters the table, for example, through SE11 transactions.
After clicking on the button shown in the following screenshot, the SAP system will display the tool in a separate window:
An example of how to connect to the SFLIGHT table is shown in the following screenshot:
This allows the user to view all the tables that are associated with a foreign key. A double-click on one of the related tables moves the user to this table. Information on the types of relationship between tables is also included here.
In 2001, the Manifesto for Agile Software Development was created. This is an alternative to the cascaded way of generating software. The manifesto describes agile as a philosophy for carrying out various projects, including IT projects.
The basis of the Agile Manifesto includes four basic principles:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The manifesto means that the values described on the left are more important than the ones on the right. It's no coincidence that people are placed first. The success of each project depends on them. If the team has the right skills and a lot of commitment, there is a good chance that each project will be successfully completed. Interactions between team members speed up the work and allow the use of maximally positive aspects of teamwork. The second point indicates what is most important from the point of view of the software recipient. Even the best documentation cannot replace properly working software. The working end product is the basis for considering whether the project has been successful.
A quick response to changes causes the team to be able to deliver the ideal product to the recipient. It builds a sense of professionalism and can contribute to the expansion of business cooperation with the current investor. Agile is a great project management tool that helps to eliminate the likelihood of an IT project failure.
Work based on agile methodologies takes advantage of an iterative and incremental approach. This means that the team of programmers is focused on the fast, cyclic, and orderly delivery of product elements. The result of this is greater flexibility. This is very important due to the high frequency of changes, along with building solutions. Agile methodologies of software development do not have rigid conditions and assumptions regarding every aspect of the project.
DevOps is an organizational culture whose assumption is to combine the work of software development teams and operations teams. DevOps is an innovative approach to software development. The benefits of using this approach are, among others, as follows:
- Time and cost savings
- Shortening the time of product implementation
- Quick changes in products
- Better-fitting functionalities
- More accurate verification of correctness
- Advantage over competitors
- Better team cooperation
DevOps uses iterative work growth in accordance with agile methodologies. This gives the product recipient the opportunity to quickly read the results of the work. DevOps characterizes a fast and visible change in the company's operations. Teams carry out projects that are more suited to the needs of users.
DevOps assumes smooth communication between technical teams and, at the same time, assumes the following:
- The product is built from the perspective of the whole.
- Accurate testing from the initial functionality.
- Relying on reliable data.
- Reducing the time of software development.
Continuous delivery is a concept of software development. It is based on the assumption that software is created in short intervals of time. This approach allows you to create solutions tailored to the current business needs of recipients. A very important feature of this method of sharing the finished product is the need to accept the possibility of running the software on the main (production) system. The remaining elements of the implementation process are automated. The process is also characterized by a repetitive delivery cycle.
Continuous delivery is similar to the method of continuous implementation, in which software is also produced in short cycles, but with the help of an automatic process in terms of production transfer.
This chapter describes how the user can organize their daily work and operate in a broader context. We've looked at some ideas for becoming a more attentive developer or architect. At an advanced level, readers will be able to organize several topics within complex projects, including managing stakeholders. At a basic level, the user should be familiar with the daily activities of a project manager or architect and has learned how to integrate with the complex configuration of the project.
The next chapter will describe the world of modern SAP systems, with a basic outline of the ABAP language and gives you a view on older syntactic data and their equivalents, which are used in modern ABAP systems.
The following questions will allow you to consolidate the information contained in this chapter:
- What are the positive aspects of using agile methods?
- What are the principles of the agile manifesto?
- What is the difference between a logical model and a physical model when designing a database?
- List the possible programming changes in SAP.
- What is the motto of design thinking, and why is it coherent with the design thinking methodology?
- In which categories does BDUF occur?
- What aspects of development impact the quality of the design?
- Why should business logic be loosely coupled?
