Index of the course subjects.

1. Data dictionary 1.1. 1.2. 1.3. 1.4. 1.5. Domines, data elements, structures DB Tables Views Search helps Locking objects

2. Introduction to ABAP/4. 2.1. Declaring variables: constants, single data, structures, internal tables, ranges, parameters, select-options. 2.2. Declaring types. 2.3. How to build an executable program (structure and events). 2.4. How to program on line (module-pools). 2.5. Smaller elements in a program (includes, modules, performs local variables!-). 2.6. Functions (module-functions) 2.7. Calling Other programs and transactions. 2.8. Executing transactions & Batch-input. 3. Programming in HR-Module. 3.1. Definition of infotype. 3.2. Modifications in infotypes. 3.3. Creating an infotype. 4. Modifications in standard. 4.1. Extra includes in standard structures, functions and programs. 4.2. User-exits. 4.3. Direct modifications in the code. 5. Introduction to Sapscript Forms.

CHAPTER 1. Data dictionary

This dictionary can be managed completely from transaction SE11. Here we can find the independent objects that will be needed in the confection of our system (database tables, views, search helps, enqueuing objects). This dictionary is completely integrated in all system R/3 in a way that any object that has been previously activated in the dictionary can be used from everywhere in the system. In this way it has to be said the difference between activated and a non-activated object. The system R/3 has two versions of every object. In the first one, R/3 has stored the last saved version. However this is not the version that is used in the system (but the one that we can see when consulting the object). Once the object has been successfully checked, this version can be stored as active version. The active version is the one that is available in the integrated system R/3. So, the advice is to activate all objects as soon as changed, in a way that the saved version (the one we can consult) is the same than the activated one, and in this way, confusions can be avoided.

1.1.

Domines, data elements, structures.

Variables can be stored as objects in R/3. In this way, in the way to create variables (or structure fields) two main definitions have to be settled for everyone. Semantic definition (data element). Here the meaning of the field is included (all text-descriptions, headlines). It is somehow, the description of the concept (personal number) Technical definition (domine). Is the kind of data that this field is going to support (char1, currency codes) In every structure, some fields can have the same data element and the same technical definition as well. The thing that has to be unique and distinctive in every structure is the technical name. This name is the one that well use when using the field from everywhere else in R/3. Structures: A structure is an object that can be compared with a vector. The object is compound by at least one field (and everyone of this fields is associated to a data element and to a domine). To create a structure we have to accede to the transaction SE11, push

the radiobutton beside the text Structures, make a proposal for the structure name (starting by Y or Z) and push the button create. In a second screen we have to give a description for the structure, and to fill the tablecontrol with the data of the fields. The first column is set to write the technical name of every field. The column beside is to make a proposal for the data element of every field. Domine is also included in the data element definition. The data element that we can propose can be existent or new. In case of a new data element well have to create it. This is made clicking twice on the data element name (whose name will have to begin by Y or Z). In the next screen well propose the text definitions and the domine name as well. In case of creating a new domine, well proceed like explained when creating a data element. On the other hand, it has to be said that any structure can be included into another structure via INCLUDE.

1.2.

Database Tables.

A database table can be taken as two assembled objects. One of this objects is the structure that the table will have (the definition of every field) and in the other side, a place where the data are stored with the same structure than showed in the headline. To create a table is an easy process. First, well access to the transaction SE11, where well keep the database radiobutton active, and propose a name for the database (starting by Y or Z). In the next screen well define the structure of this table as we did in the last chapter and define some new parameters (as, for instance, if the database can be updated from this transaction). An important study has to be the choice for the key-fields. The key-fields is the minimum information to define a unique register. This means that it will be impossible to find two registers with the same values in all key-fields. In the other hand in this king of database we can add check-tables (external keys) to the fields. These are tables where the permitted values for these fields are proposed. Other values are not accepted when updating the table. Moreover, to every field we can propose a search help, in a way that wherever this field is used, the search help will be assigned as default for this field. Creating indexes. An index is an object that can be created for the table to a faster selection of the registers of the table. There are two kinds: primary (contains the key-field of the table made automatically when activating) and secondary (well have to create if the data is acceded often with this fields improvements in speed up to 10%)

Importance of the client (MANDT). This field is usually added to the structure of every table to be able to isolate the data for every client. Otherwise, changes made in one client will be also affect to the rest of clients. Before activating, the technical attributes will have to be set. For this we have a screen where theyll have to be proposed. This data is set to get a better storage of the data. Logic data kind. Master data: Information that will be seldom changed. Transaction data: Information that will be often changed (stocks). Organization data: Information set when customizing and almost never changed. System data. Information needed in R/3. Size Data storage. Relationship with the buffer and the intermediate memory. Problems when modifying a table. When modifying a table that has already registers, some problems will be found, due to inconsistency of data and structure. Once the changes have been made in the structure of the table, this will not be activated because of these problems of adaptation between the structure and the data. To solve this problem we have two chances: Deleting all data in the table and activating afterwards. Converting the data to a new structure Using the standard utility for data conversion. Creating a standard program for inclusion in view-maintenance (SM30). This is an option which will make automatically the process to create a program to update the data from this table from the transaction SM30 via tablecontrol. The problem is that the program is generated with all fields and their characteristics, so future changes are not displayed. With this it is mean that everytime that the structure of the table is changed, the program will have to be regenerated, in a way that the changes made in the structure were displayed also in the program. To execute this program from code, the function VIEW_TABLE_MAINTENANCE should be called with the determined parameters.

1.3.

Views.

A view is an object which can show data from tables. It is mainly formed by an structure and links between tables. From other places in R/3, when reading these views are in sum equivalent to tables, but the main difference is that they cannot store any data, it can only show the target as a link between tables. Sometimes theyre needed to show data from different tables as if they were from an unique table.

To create them we have to acceed to the transaction SE11, click in the view-radiobutton, propose a name (starting by Y or Z) and pushing the button create. In the next screen well have to declare the tables that are involved, the joins between them, the fields that this view will have, and the conditions that the registers will have to accomplish.

1.4.

Search help objects.

A search help (or matchcode) object can be created and substituted in any program. To create them it has to be made from the transaction SE11. There we have to propose a name (starting by Y or Z) and push the button create. In the next screen well have to declare how the search help is going to look like. A search help can be thought as an input/output list. So in this way we have two chances. We can create a simple object (elementary search help) or one object which involves other simple objects (complex matchcode). The declaration of the search help will be: Selection method (table or view where the data can be taken from). Fields from the selection method that will be included in this object (import, export) Nature of the field (input and output) Order in the input (selection) screen . Order in the output list. Kind of search list (show data immediately, show first a selection-screen with the input parameters). When creating a complex search help, well have to declare which elementary search help objects are included in this one.

1.5.

Locking objects..

In some programs, to avoid that the same register from a table is changed simultaneously, we need to lock the registers. When creating a lock-object, two standard functions are generated, one to lock (ENQUEUE_xxxx, where xxxx is the name of the locking object) and another to unlock (DEQUEUE_xxxx). These functions will have to be included into the code from the program in a right way to guarantee a right control on the inserting/updating data.

CHAPTER 2. Introduction to ABAP/4.

2.1. Declaring variables: constants, single data, structures, internal tables, ranges, parameters, select-options.
In ABAP programs all variables that will be used have to be previously declared. When declared, variables are abled for the whole unit of code. This means that in case that the declaration is on the top of the program (global variable), it will be abled for the whole program, wherever. However, when de declaration is in the top of an smaller programming unit (for instance, subroutines), the variables will only have the identity inside of this unit, so when leaving, theyll lose the identity. On the other hand,, we have different kinds of variables, and everyone of them will have to be declared in different way. Simple field data (variables). Theyre simple variables which can support only single fields (1). During the program their value can be changed. DATA: d_carrid LIKE spfli-carrid, d_counter TYPE i value 1, d_date like sy-datum. d_counter = d_counter + 1. COMPUTE: d_counter = d_counter + 1. MOVE LH TO d_carrid. d_date(6) = d_datum(6). d_date = 1st day of the current month. d_date=6(2) = d_datum+6(2). This variable can be declared with different standard types. The most interesting of these types are the next: P(n): packed number of n bytes (2*n 1 positions). We can define from these positions how many of them are decimals (default: 0 decimals). I: integer number (4 bytes). Appropiate for counters. C(n): String of n characters. D: Type date. It is important to know that ABAP is formating dates as 8 numbers corresponding to YYYYMMDD (YYYY = year; MM = month; DD = day)

 T: Type time. It is important to know that ABAP is formating times as 6 numbers corresponding to HHMMSS (HH = hours; MM = minutes; SS = seconds)

Constants. Theyre, as their name menctions, fixed values. During the program theyll keep the assigned value. Thus, in contrast to variables defined with the DATA statement, you cannot change the value of a constant once it has been defined. They are declared as follows: CONSTANTS: c_carrid LIKE spfli-carrid VALUE LH. Parameters. Theyre, in fact, a kind of variables. The difference between variables and parameters is that parameters are included in the selection screen as a field. This field can be from different types depending on definition of parameter. One field: (PARAMETERS: p_carrid LIKE spfli-carrid). They can support data like the reference field. Theyre also importing all their caracteristics (texts, domines...). Checkbox. (PARAMETERS: p_carrid AS CHECKBOX). Theyre boxes that can be active (value X) or inactive (then value ). Radiobutton (PARAMETERS: p_carrid RADIOBUTTON GROUP group). Theyre similar to checkbox, but with the difference that theyre assigned to a group and only one box from the group can be active.

Structures: Theyre complex variables that can afford different fields. Actually, they could be taken as vectors. The behavior of everyone of the fields is identic to the one that a variable would present, so they could also be processed as a group of single variables. They could be declared in different ways. 1. Declaring a element with the same fields than an existing structure in the dictionary (or declared in the program previously). DATA: e_element1 LIKE spfli. 2. Declaring preciously a type to refference it. TYPES: BEGIN OF t_type1, carrid LIKE spfli-carrid, connid LIKE spfli-connid, END OF t_type1. DATA: e_element2 TYPE t_type1. 3. Direct fields declaration.

DATA: BEGIN OF e_element3, carrid LIKE spfli-carrid, connid LIKE spfli-connid, END OF e_element3.

4.Declaring ans structure as an existing structure, but adding new fields. DATA: BEGIN OF e_element4. INCLUDE STRUCTURE spfli. DATA: fldate LIKE sflight-fldate, num type i, END OF e_element4. As special case, we should tell that when declaring a table in a program (TABLES: spfli.) what were doing is not to make it ready to read (to tables we can always access, no matter if theyre declared or not), but were declaring a scructure with the fields (headline from the table). So, when making a direct select to these tables were pasting the registers into this structure. On the other hand, all fields are processed as single variables: element4-num = element4-num + 1. Move LH to element4-carrid. SELECT SINGLE * FROM spfli WHERE... Spfli-cityfrom = NEW YORK. Move-corresponding spfli to element1. The instruction MOVE-CORRESPONDING is inserting the fields from one structure to another comparing field names. It is because of this that we have to be sure that the fields with the same name are corresponding one to each other (that the target could support the values from source...) Internal tables. They can be taken as a group of one/two objects. A matrix where data can be saved and a structure where we can process the lines (headline, advisable to declare itabs with it). These internal tables are not directly readable, and they usually need an object where to paste the line before were able to read anything. Theyre declared like elements, but adding the command OCCURS 0 [WITH HEADER LINE] . DATA: itab LIKE SPFLI OCCURS 0 WITH HEADER LINE. Most usual commands when using itabs:

1. APPEND: Saves the data from the headline (or the marked structure) into a new line from the itab. 2. COLLECT: Tries to accumulate as many fields as possible fields (and saving directly into the itab). The fields that cannot be accumulated, theyre taken as key. For instance, when making a collect into a table Lines in the original table UNO ROJO 7 UNO VERDE 1 TRES VERDE 2 Headline just before collecting CASE 1: UNO VERDE 3 CASE 2: DOS VERDE 3 Lines in the table after command COLLECT itab. HEADLINE CASE 1 HEADLINE CASE 2 UNO VERDE 3 DOS VERDE 3 ITAB CASE 1 ITAB CASE 2 UNO ROJO 7 UNO ROJO 7 UNO VERDE 4 UNO VERDE 1 TRES VERDE 2 TRES VERDE 2 DOS VERDE 3 3. MODIFY: Updates a register from the itab. 4. LOOP ... ENDLOOP. Its executing what its between loop and endloop for everyone of the lines in the itab. In this place, the fields in the headline will have taken the values from the corresponding line. Example: LOOP AT itab. WRITE itab. NEW-LINE. ENDLOOP. 5. READ TABLE itab WITH KEY. It is taking a corresponding line from the itab into the headline. 6. DELETE. Deletes lines from a itab. 7. SORT: Makes an order between the lines corresponding to a marked criteria. 8. CLEAR: Cleans the work area from the table (only the headline).

9. REFRESH: Deletes all lines from the itab. Ranges: This kind of object will be used to declare intervals. Theyre internal tables with four fields (SIGN, OPTION, LOW and HIGH). Theyre declared as RANGES: r_carrid FOR spfli-carrid (the reference field will have to be previously declared). To compare with values well use as follows: SELECT OPTION * FROM spfli WHERE carrid IN r_carrid. To declare the range well have to fill the lines of this range as if a normal itab it would be, with the next values: 1. Field SIGN: It will be a declaration in the line. In this field we can purpose a value of two characters between EQ (equal), NE (nonequal), BT (between)... 2. Field OPTION: I (included) or E (excluded). 3. Fields LOW and HIGH. The values to compare (limits in the interval). SELECT-OPTIONS: It is to ranges what parameters are to variables.

2.2. Reading data from DB tables.

To read data from DB tables we have the command SELECT. This command is appending the values of one line from the DB into a marked target. This line can be conditioned by the instruction WHERE, and needs a ENDSELECT as a conclusion from the loop (the process between SELECT...ENDSELECT will be repeated for everyone of the targets in the DB table. The target can be the headline from the same table (if, then it has to be declared previously), or other targets. When declaring the target (INTO...), we can choose and take only those fields that we need, and not all, in a way that the search will be faster. On the other hand, after the endselect well get an answer from the system telling us if this select was successful or not. If successuful, then SY-SUBRC = 0, otherwise = 4 (when no line is accomplishing the marked conditions). Example. Program that is printing in the screen all flights from connexion LH 400. *Direct search to the headline. TABLES: spfli. SELECT * FROM sflight where carrid = LH and Connid = 0400. WRITE: /3 sflight-carrid, sflight-connid, sflight-fldate.

ENDSELECT. *Search when declaring target. Select having into account all fields. SELECT * FROM sflight INTO CORRESPONDING FIELDS OF elem where carrid = LH and Connid = 0400. WRITE: /3 elem-carrid, elem-connid, elem-fldate. ENDSELECT. *Search when declaring target and desired fields (the fastest). SELECT carrid connid fldate FROM sflight INTO (elem-carrid, elem-connid,elem-fldate) where carrid = LH and Connid = 0400. WRITE: /3 elem-carrid, elem-connid, elem-fldate. ENDSELECT. Specific cases for instruction select: When the target is only one line well use the same instruction but adding SINGLE after SELECT. In this case ENDSELECT will not be appearing and the answer SY-SUBRC will be given after the instruction SELECT SINGLE. It has to be said that this instruction usually needs to be taken with care, because in case that the select was unsuccessful, the target will keep the data that it had before the instruction. Thats why often after this instruction well find a source code according to the following. SELECT SINGLE carrid connid fldate FROM sflight INTO (elem-carrid, elem-connid,elem-fldate) where carrid = LH and connid = 0400 and fldate = 19950228. IF sy-subrc NE 0. CLEAR elem. ENDIF. On the other hand, this instruction is only able to find one target, so in case of many lines accomplishing the conditions, it will only take the first found in the DB table. When we want to get diferent combinations between fields well use the intruction SELECT DISTINCT. This is working the same way that the usual SELECT but with the difference that is not taken lines with the same combination of the marked fields. SELECT DISTINCT carrid connid FROM sflight

INTO (elem-carrid, elem-connid,elem-fldate) where carrid = LH and Connid = 0400. WRITE: /3 elem-carrid, elem-connid. ENDSELECT. IF sy-subrc NE 0. WRITE There is no LH-0400 flight registered. ENDIF. Direct lines input from a DBtable into an itab. Theres a way to purpose the instruction select that is directly loading the targets into an internal table, with no need to use any work area (headline) for this. It is a direct input, that is appropiate when we want to get the fields from one (only one) internal table. This instruction is also returning the system variable sy-subrc the same way than the select single was doing. DATA: BEGIN OF i_tab, carrid LIKE spfli-carrid, connid LIKE spfli-connid, END OF i_tab. PARAMETERS: p_carrid LIKE spfli-carrid. SELECT carrid connid FROM spfli INTO TABLE i_tab WHERE carrid = p_carrid. IF sy-subrc NE 0. MESSAGE S000(zgroup1) WITH p_carrid. ENDIF. Special control-commands and system-variables important when using the Select instruction (also working with loops, do...enddo, while...endwhile,...). SY-INDEX. It is the number of loop that the system is executing. EXIT. It is finishing the looping process (goes out from the system Select...endselect). If it is used outside the looping process, the instruction will abort the program execution. CONTINUE. It is going directly to the next loop. CHECK condition. If the condition is successfuly checked, the system will go on as if this instruction were not there. If it is unsuccessfully checked, then is jumping to the next loop. Actually, this instruction is equivalent to: LOOP AT itab. | | LOOP AT i_tab. CHECK condition. | | IF NOT condition. | = | CONTINUE. | | ENDIF. ( ... ) | | ( ... )

ENDLOOP.

ENDLOOP.

Logic => If condition is accomplished => execute ( ... ) If condition not >> => next register from itab.

2.3. Updating DB tables.

By source code we can change the data in the DBtables. For this effect we have different instructions: INSERT: This instruction is used to save the data from a work area into a new line. It is interesting to know that in case that the combination of key fields in the work area were already existing in the DBtable, the new line could not be inserted. In this case, the system will return us a sy-subrc different from 0. UPDATE. This instruction is saving the data from the work area into an existing line (with the same values in the key). In case that this line is not existing, the data could not be saved, so a sy-subrc different from 0 is returned. MODIFY: This instruction is equivalent to the next code. INSERT dbtab. IF sy-subrc NE 0. UPDATE dbtab. ENDIF. DELETE FROM dbtab WHERE. This instruction is deleting from the DBtable all the registers that are accomplishing the marked conditions. TRUNCATE. To delete completely all data in a DBtable. It is not usual to find, but when needed it can be usable. EXEC SQL. TRUNCATE TABLE dbtable ENDEXEC.

2.4. Programs in ABAP.

In ABAP we can find different kind of programs, everyone with an own structure and way to program, depending on their nature. In this way, we will differenciate between the next kind of programs. Executable program. These programs are usually structured by events. Theyve already an own identity and they can be executed without the need of any transaction. Module-pools. These programs are usually structureb by dynpros. They have an identity, but they cannot be executed by their own. For this, they need a transaction where it is marked the program and the starting dynpro as well. These programs have some objects related, and the application source code is found in includes. Function Groups (if creating them, better to do it from transaction se37). These are programs which are including the code needed for the corresponding functions. Usually theyre compounded by 2 includes. In the first one (...TOP) the global data declaration and often also the common performs. In the second one, well find the includes where the code from the function is found (1 include for each function). These functions groups have more than one identity (from every function that they contain) and are not executable. Includes. They can be though as just source code containers. They have not identity (they are not self programs but a part of them), and are neither executable. They are just programs where the code from bigger programs is settled. All of these programs can be modifyed and created from transaction SE38 (ABAP editor), excepting function groups (it is advisable to create them from transaction SE37 Functions editor- ).

2.4.1. Programming a Report (executable program). These programs are structured by events. One event is the piece of application code that will be executed in a determined moment. The order of execution between the events is fixed. The most usual events are shown below. INITIALIZATION. Is the first event to be executed. It is executed even before the selection screen is displayed, so it will be the right place where, for instance, get default values on the selection screen (gets, sets, selects...), or where we can give values to the execution parameters. AT SELECTION-SCREEN. Is the application code corresponding to a dialog process between the user and the selection screen. It will be executed everytime when a change in the selection screen is set (also after executing any option there). In this event we can include, for instance, the verification of the values in every field of the selection screen. START-OF-SELECTION. It is the place where the main application is set. It is finishing usually with an END OF SELECTION.

TOP-OF-PAGE. This is a typical event in reports (lists). Every time that the system is going to start a new page when printing into screen, this event is going to be executed previously. It is the usual point where to put, for instance, the source code corresponding to the print of the headings in lists. END-OF-PAGE. Similar to TOP-OF-PAGE, but executing always just after finishing with one page. So, this will be the right point where to program the writting of footlines. AT USER-COMMAND. Some programs, after being executed, they have options (created an status with user options). When executing any of these options, this event will be working. This is, for instance, the point where to study and to add the code for every one of the values in the CASE SY-UCOMM. AT-LINE-SELECTION. Some lists are programming to be interactive. So this event will be executed everytime that the user click twice over the same line. For this, in the start-of-selection event, the intruction HIDE should be written.

2.4.2. Programming module-pools. Module pools are special kind of programs. These programs are structurated by screens (called dynpros). Every screen has declared a PBO (process before output) and a PAI (process after input), where some modules are declared. Modules are smaller code elements where we can include the source code. One screen is working as follows. First step. Before the screen is displayed, the PBO from this screen is executed. So, this will be usually the right place where to ask for the settings of this screen (set the status, give the fields the values that we are interested to give...). Then the scren is displayed with the given settings. Last step. PAI is executed. Here were usually finding the source code for the application. When finished with this, if the code is not asking to leave somewhere else (any other screen), the process will go on with the PBO again.

Some typical commands in module-pools. LEAVE TO SCREEN xxxx. Leaves the current code and starts with the PBO from the marked screen xxxx. SET STATUS xxx. Loads the marked status bar xxx. LOOP..ENDLOOP. In the logic of the PBO and PAI from pages. This is useful and necessary for the communication in table-controls between the feeding itab and the table in the screen. To create or modify an screen, we can go to transaction SE38 (ABAP editor), and navigate through the objects until we reach the page (=>screen painter), or directly to transaction SE51 (screen painter).

2.4.3. Smaller program units. In ABAP we can create smaller units than a program, where to develop an part of the whole code. These groups are: MODULE. Theyre calls to a part of the code. Theyre used mostly when assigning code to dynpros. The way co call the is MODULE xxxxxx. This is executing the code than is between MODULE xxxxxx OUTPUT. ( ... ) ENDMODULE. " MODULE xxxxxx OUTPUT Subroutines. Theyre the part of the code that we need to execute when writing PERFORM xxxx. These subroutines can have local variables when declared inside of them. This means that the variables will only be able to be used in the code between FORM...ENDFORM. The same way, when calling a subroutine we can also have communication variables between the program and the subroutine. Example: In the next subroutine-call will export the parameter and the structure 1, and export-import the parameter the structure and the internal table 2. PERFORM xxxxx USING parameter1 structure1 CHANGING parameter2 structure2 TABLES itab2

In the other side, the subroutine will receive the values of the parameters, structures and tables parameter1, structure1, parameter2, structure2 and itab2 into the parameters, structures par3, struct3, par4, struct4 and itab4 in this order. Afterwards, par4 struct4 and itab4 will be exported into parameter2 structure2 and itab2. FORM xxxxx ( ... ). ENDFORM. USING par3 struct3 CHANGING par4 struct4 TABLES itab4.

Important things to remember when passing fields to performs: Local data need to be transferred, because theyre loosing identity outside the unit subroutine. In the communications, the number of parameters exported have to be consequent to the ones that the subroutine is expecting to receive. Keep the order between the communication parameters. INCLUDES. Sometimes, we can need a packet of objects (subroutines in different programs. Then, what could be interesting is to create these common subroutines not in the same program, but in another, whose kind will be include. In this way, everytime that this include is called in any program, all object defined there will be available, and we wont need to develop them more than once.

2.4. Functions.
A Function is an object which includes a code. Functions are normally used to develop applications that can be used in different programs. In this way, a function is usually importing variables with the objects which are calling them (programs, subroutines, other functions,...), theyre using them to execute the process for which they were created, and exporting variables to the program. Functions are created / displayed / modified from transaction SE37. When creating a function the communication data will have to be declared separately. We have different kinds: Importing. Variables or structures whose value will be transported from the program to the function (theyre the data that the functions needs to be executed). They can be optional (if the corresponding checkbox is activated) or obligatory. Exporting. Variables or structures structures whose value will be transported from the function to the main program (usually theyre the answer, the result). Changing. Variables or structures which have both importing and exporting dialog. Tables. Internal tables. Theyre first imported and then exported. They could be optional or obligatory.

 Exceptions. In some cases, when the program finds an error, it is possible to return a sy-subrc different than 0. From the source code of the function, this exception is called with the dialog RAISE excname. From the main program, the answer is a sy-subrc different from 0. On the other hand, functions are build inside of groups. These groups are programs that contain includes. Inside of these includes we could find the source code from all functions in the group. The first include in the function group will be a so called TOP include. Inside of this include global data is defined. The data that has been declared inside of every function will be, in this way, local data, which can not be directly used outside from the function (not even in the subroutines which are called from the function).

2.5. Calling programs and transactions from source code.

2.5.1. Calls to other programs. From one program it is possible to execute other programs. Actually, there are many programs that are not directly executable. They have been thought to be executed from other programs. A program is called by the instruction SUBMIT. This instruction has also the chance to receive values, and modes with different extensions. Find below the most usual extensions. SUBMIT report AND RETURN. This calls the program REPORT, executes it, and afterwards is coming back to the original program, just to the point where this instruction is put. SUBMIT report WITH p op f. Like this we can execute the report with values on the selection screen to both parameters or select-options. P will be the name of the field in the selection screen, op will be the operator (EQ, NE, GE, LT...) and f the value that we want to refer to this field. SUBMIT report TO SAP-SPOOL. List output to the SAP spool database. Important: When calling another program, the global data from the original program have no sense neither identity in the called report. So, however, their behaviour when changing the program of control is similar to what we found with local variables and subroutines. On the other hand, theres a SAP standard system data that can inform us in every moment which is the current program that is being executed (Be careful: not to confuse with the control program). This is SY-REPID.

2.5.2. Calls to transactions. A transaction is an object whose action is running an executable program (report) or the first screen in a module-pool. This action is made with the instruction CALL TRANSACTION tcode. On the other hand, theres a SAP standard system data that can inform us in every moment which is the executed transaction of control. This is SY-TCODE. To create / display / modify transactions, we can access through transaction SE93.

2.6. Batch-input and data loading interfase.

As we told in the chapter 2.3, database tables can be directly uploaded from source code. However, often this is not a sefe way to update tables, due to the fact that many of the data have to be inserted to different tables, passing through different checks, ... An example for this could be a integrated system as the system of infotypes is. When we are inserting data to an infotype, the data is often uploaded in more than one table, and checking the data with the already existing lines in the tables. In case of direct imputation to the tables, we should be really careful to insert all data consequently to the phylosophy SAP. This is not only dangerous, but also difficult. So, the safest way to insert the data in these kind of systems would be manually, with the transactions and programs that have been made for this purpose. However, SAP has an application that allows to simulate a manual input of data. This kind of applications are called batch-input. Well find two kinds of batch-input. Executing a transaction with a path. This is making the process of uploading the data to only one register. To execute this well need the use of a itab with the structure of BDCDATA (see below to know how to fill it) and fill it with the path to follow and the values to insert in every field of every dynpro. The mode of execution of this transaction can be a (visible), n (in background) or e (visible only when errors). Then were executing the updating like: CALL TRANSACTION tcode USING itab MODE m.

 BDC-SESSIONS: These programs are not creating the entries in the data base. What theyre doing is to create a data group, which will be stored in a kind of spool (transaction SM35), waiting to be executed. After executed, the data will have been updated, and a log generated. To program this were using this structure: Informing the system were opening a session. CALL FUNCTION BDC_OPEN_GROUP EXPORTING CLIENT = <mandt> GROUP = <session name> USER = <user> Creating a new itab like BDCDATA (see below to know how to fill it) for every one of the registers to update and inserting them into the session. LOOP AT I_DATA. REFRESH I_BDC. PERFORM CREATE_I_BDC. like BDCDATA CALL FUNCTION BDC_INSERT EXPORTING TCODE = <transaction> TABLES DYNPROTAB= I_BDC ENDLOOP. Informing the system to close the group. CALL FUNCTION BDC_CLOSE_GROUP. It is possible to execute the bdc-session automatically making a submit to the standard report RSBDCSUB. 2.6.1. How to fill the internal table structure BDCDATA in a batch-input. This internal table will have to be declared with the same structure than BDCDATA. DATA: i_bdc LIKE bdcdata OCCURS 0 WITH HEADER LINE. This structure is formed by 5 fields: DYNBEGIN: X means the start of a new step. PROGRAM: when dynbegin = X, here well write the name of the program. DYNPRO: when dynbegin = X, here well write the dynpro id.

FNAM: : when dynbegin = , here well write the name of the field to fill in. FVAL: : when dynbegin = , here well write the value to fill in in the marked field. To propose the line well use the ABAP standard recorder (transaction SHDB). Then well translate the values into lines of code. For this something that will be really useful is the next subroutine. PERFORM fill_i_bdc TABLES i_bdc USING: X ZRES01 0100. FORM fill_i_bdc TABLES i_tab USING CLEAR i_tab. IF par1 = X. i_tab-dynbegin = X. i_tab-program = par2. i_tab-dynpro = par3. ELSE. i_tab-fnam = par2. i_tab-fval = par3. ENDIF. APPEND i_TAB. ENDFORM. par1 par2 par3.

CHAPTER 3. Programming in HRModule.

3.1.Definition of infotype.
An infotype can be defined as a group of linked objects which has involved some structures (for instance P0022), some tables (PA0022), a module-pool for maintenance (MP002200), and the respective communication interfaces. The group of infotypes are linked between themselves in a way that the whole group can be taken as a fully integrated system. Thus, it has to be declared that changes in one register can cause changes in registers from other infotypes. In the HR module from SAP we use to work with infotypes. In the standard packet of applications there are some infotypes already created, that are usually the most important (to work with them we can access through the transactions PA20-view data- or PA30updating-). This standard infotypes are already ready to be customized by functional consultors. However, often this packet is not deep enough to satisfy the clients needs, so new infotypes have to be developed, or existing ones have to be modified.

3.2. Modifications in infotypes.

It is not advisable to make sensible modifications on infotypes, due to the fact that theyre engaged by a group of communication interfases to other objects that could be changed. Thats the reason why well usually keep limited almost exclusively to small changes like texts in dynpros (trans. SE51), In this way well make changes only when theyll not influence to the system internal behaviour. In case that harder changes should be mad, it is advisable to create new infotypes.

3.3. Creating Infotypes.

To create a new infotype well access to the transaction PM01. From there well have to give an identification to the new infotype (ids from developed infotypes are an string of 4 numbers that should start by 9). From this transaction well be able to create the corresponding structures and interfases between objects. When pushing the button create all the system will lead us through a route to create all the designed objects. This route starts with the own fields structure that all tables and structures will include.

In this structure we should append the specific fields that this infotype is going to use. In these words, other standard fields, as PERNR, SUBTY, BEGDA, ENDDA are not going to be declared, because the system will include them as default fields. Afterwards the inclusion of this infotype into the table T582A (infotypes table) will have to be made, with the right customizing parameters. With this process the infotype will have been created. The next step to do is to modify the dynpros in a way that they could show efficiently the desired appearance and behaviour (including new fields). To make this the best way is to go to the transaction SE38 (ABAP editor), and editing the program (its name will be MPxxxx00 where xxxx is the number of infotype). From there well make the pertinent modifications as we could make with an usual module-pool. It is important to remember that this program is a part of a big integrated system, so well have to be careful to avoid disturbing the links between objects. Once saved and activated, the program and dynpros will have the developed function in a way that the infotype will have been successfully created.

CHAPTER 4. Modifications in standard.

The standard packet of SAP is compounded by a big amount of standard object that are already ready to be customized by functional consulters. However, really often this is not enough to cover the clients exigencies and some modifications have to be carried on to change the initial behavior from this standard objects into the desired one. To get this aim we can use several different ways.

4.1. Extra includes in standard structures, functions and programs.

Standard objects are often foreseeing future ampliaciones. In these words, two different cases have to be studied (structure and code). Extra includes in structures. Some standard structures (tables) have includes from other structures. It happens that sometimes, foreseen a future addition of new fields, one of these structures can be developed (for instance, see table CATSDB). The developing structures have names starting by Z and initially theyre not created, so clicking twice over their name we can create them first and add the extra fields. Extra includes in text. The same way that we could see in structures, in source code sometimes we can find that standard programs are calling other programs (usually includes) that can be developed. This includes are usually called by the intruction INCLUDE Z and are initially not created. When clicking twice we can create them. This is the typical way we can find in user-exits, that are standard functions whose source code is only calling an developing include. The way to develop this includes is the same that we used when creating any other developed object.

4.2. USER-EXITs.
A user-exit is a function that has been designed from the initial stage in the programming of standard programs as a forecast to future changes in the initial behavior of the program. In other words, theyre exits, gates from the program that have been positioned to add new source code. This functions are called from the standard program as follows:

CALL FUNCTION 001 IMPORTING ... When clicking twice over 001 the system will lead us to the function that is supporting this user exit, where were supposed to add the new code. This is a standard function (thus, not modifiable), in which the only existing line in the code is the call to a still-notcreated include program, as follows . FUNCTION USER_EXIT_001. INCLUDE ZINCLUDE1. ENDFUNCTION. When clicking twice over the name of the include, this will be automatically created. Inside of this include well be able to add the desired code for the program. It is important to know that every user-exit has an own designed use (checking new fields), due to the fact that theyre exchanging certain variables with the main program. Once saved and activated, the user exit will have been successfully created. However, it will still not be ready to work. For this, well have to include it into a project. Every project has some own user-exits to be active and so, these will have to be declared (transaction CMOD). It is also important to know that when adding a new user-exit into a pre-existing project, well have to deactivate the project, and activate it again (otherwise the new user-exit would not have been active in the project).

4.3.Direct Modifications.
Theyre not advisable. If they can be avoided, they should be avoided, and in case that they could not be avoided, well have to be really sure that the changes made in the code wont affect the right function of the program, and from other objects as well. To modify a SAP object, well have to access to the object, and also to know the password to make it. This password can be asked to the administrator.