RFC

REMOTE FUNCTION CALL

Class 1: 28.07.2011 A Function module is the set of statements which has to be defined once & can be called any number of times. There are two types of function modules. 1).Normal Function Module. 2).Remote Function Module. Normal Function Module: It is client Dependent object which can be called any number of times and any client in the same server. Remote Function Module: This function module can be accessed from remote SAP Server. RFC is the process of executing a function module existing on remote SAP Server. It is similar to RMI Technology in JAVA. RMI: Remote Method Invocation. As the part of RFC process there are two parts involved RFC CLIENT & RFC SERVER. RFC SERVER: Is the system where the remote function module is stored. RFC CLIENT: System where the function module is called. As a part of RFC Client System we need to create an object called RFC DESTINATION. RFC DESTINATION: Is the object which is always created in RFC Client System, Which stores the physical details of remote system. This physical details include IP Address (Host Name) of the remote server, system number of remote server and Log On credentials of remote server (Client, User Name, Password). SM59: T-Code for Creating RFC Destination. RFCDES is the table which stores the RFC Destinations.

1|Pa g e

Santosh P

 Remote function module can be called in three ways or (three types) 1) Synchronous RFC 2) Asynchronous RFC 3) Transactional RFC Note: In Case of Synchronous and Asynchronous RFC the remote SAP Server should be available to receive the request.

In case of Transactional RFC the remote server need not to be available at the time of Communication. In this case the request to the remote function module is executed as background job.
Syntax for Synchronous RFC: Call function <Remote function> Destination <RFC Destination> [Parameters List]. Syntax for Asynchronous RFC: Call function <Remote function> Destination <RFC Destination> Starting New Task <Task Name> Performing<Subroutine> On End Of Task[Exporting Parameters]. Note: In Case of Asynchronous RFC Results from the remote function module should be received separately in subroutine. Syntax for Receiving Results From ARFC: Form <subroutine> Using <Task Name> Receive Results From function <Remote function> [Importing Parameters]. Syntax for Transactional RFC: Call function <Remote function> In Background Task Destination <RFC Destination> [Exporting Parameters]. Note: It is recommended to call only those function module in Transactional RFC mode which doesnt return any value, Because in Transactional RFC mode it is executed in background. In Transactional RFC mode when we sent the request to the remote function module since the remote server is not available the request will be saved in the following tables of RFC Client System. 1).ARFCSSTATE. 2).ARFCSDATA. To execute the Transactional RFC request SAP has provided an executable program RSARFCSE.which will be executing

2|Pa g e

Santosh P

For every 15minuts, to check whether the remote server is available to process the request by default it executes for 20Attempts. SE58: T-Code for checking the status of Transactional RFC. Steps in RFC Server: Create a remote function module. Note: The parameters to the remote function module are always passed by value. Steps in RFC Client: Create a RFC Destination Storing the details of remote SAP Server. Create an executable program to call the remote function module.

STARTING PROGRAM: IN 6.0: SM59: Create an FRC Destination.

In Technical Settings Tab:

3|Pa g e

Santosh P

In Logon & Security Tab:

Remote Logon: If all the details given are correct it will take you to 4.7 Logon. IN 4.7: SE37: Create a function Module: Z915FM1

4|Pa g e

Santosh P

Source Code:
FUNCTION Z915FM1. *"---------------------------------------------------------------------*"*"Local interface: *" IMPORTING *" VALUE(I_X) TYPE I *" VALUE(I_Y) TYPE I *" EXPORTING *" VALUE(E_Z) TYPE I *"---------------------------------------------------------------------E_Z = I_X + I_Y. ENDFUNCTION.

IN 6.0: SE38: Create an Executable Program: ZCALL_915FM1 REPORT ZCALL_915FM1. parameters : p_x type i, p_y type i. data lv_z type i. call function 'Z915FM1' destination '915DEST'

5|Pa g e

Santosh P

exporting i_x = p_x i_y = p_y importing e_z = lv_z. write :/ 'sum is ',lv_z. OUTPUT:

Press Enter

6|Pa g e

Santosh P

Class 2: 29.07.2011

Note: In Synchronous RFC whenever the execution of the RFC Client program starts.SAP creates a Main Thread. This thread is responsible for calling the remote function module. When the remote function module is under execution the main thread will be suspended. During this time the CPU of RFC Client will be idle state. When the remote function module finishes the execution the control will return back to RFC Client. Now the main thread resumes the execution & executes the remaining statements of RFC Client Program. It Means in Synchronous RFC. The idle time of CPU is more, It is not used Efficiently. Asynchronous RFC: In asynchronous RFC when we call the remote module. We need to explicitly create the thread (TASK). This thread is responsible for executing the remote function module. When the new thread is under execution the main thread will continue the execution i.e. bout the threads will be executing parallel. It means main thread doesnt wait for called thread to finish the execution. This is called as parallel processing. We go for ARFC mode. When the RFC Client program doesnt depend up on result of the RFC Service. Note: In case of Synchronous and Asynchronous if the remote server is not available at the time of communication. It leads to run time error. PROGRAM: IN 6.0: ZCALL_915FM2: CASE 1: REPORT ZCALL_915FM2. parameters : p_x type i, p_y type i. data lv_z type i.

7|Pa g e

Santosh P

call function 'Z915FM1' destination '915DEST' starting new task 'T1' performing getdata on end of task exporting i_x = p_x i_y = p_y. write :/ 'sum is ',lv_z. write :/ 'End of rfc client program'. form getdata using T1. receive results from function 'Z915FM1' importing e_z = lv_z. endform. OUTPUT:

8|Pa g e

Santosh P

CASE 2: REPORT

ZCALL_915FM2.

parameters : p_x type i, p_y type i. data lv_z type i. call function 'Z915FM1' destination '915DEST' starting new task 'T1' performing getdata on end of task exporting i_x = p_x i_y = p_y. wait up to 20 seconds. write :/ 'sum is ',lv_z. write :/ 'End of rfc client program'. form getdata using T1. receive results from function 'Z915FM1' importing e_z = lv_z. endform.

9|Pa g e

Santosh P

10 | P a g e

Santosh P

IN 4.7: SE11: TABLE: ZDEPT.

SE37: Z915FM2:

11 | P a g e

Santosh P

Source Code:
FUNCTION Z915FM2. *"---------------------------------------------------------------------*"*"Local interface: *" IMPORTING *" VALUE(I_DEPT) TYPE ZDEPT *"---------------------------------------------------------------------IF I_DEPT IS NOT INITIAL. INSERT ZDEPT FROM I_DEPT. ENDIF. ENDFUNCTION.

IN 6.0: ZCALL_915FM3: REPORT ZCALL_915FM3. data : begin of ls_dept, deptno type i, dname(20) type c, loc(30) type c, end of ls_dept. ls_dept-deptno = 69. ls_dept-dname = 'Finance'. ls_dept-loc = 'Vizag'. call function 'Z915FM2' in background task destination '915DEST' exporting i_dept = ls_dept. COMMIT WORK. OUTPUT: There will be no output because it will be run in background. NOTE: If the remote server is available the data will be reflected in Database table ZDEPT. ELSE

12 | P a g e

Santosh P

COMMIT WORK: Key work which is used for saving the data permanently in Database Table. Note: In Transactional RFC mode when we sent the request to the remote function module since the remote server is not available the request will be saved in the following tables of RFC Client System. 1).ARFCSSTATE. 2).ARFCSDATA. To execute the Transactional RFC request SAP has provided an executable program RSARFCSE.which will be executing For every 15minuts, to check whether the remote server is available to process the request by default it executes for 20Attempts. SE58: T-Code for checking the status of Transactional RFC.

Class 3: 01.08.2011 Calling RFC Back:

13 | P a g e

Santosh P

Note: As part of RFC communication we can refer back to the calling system. By using the keyword BACK. PROGRAM: IN 4.7: SE37: Z915FM1

14 | P a g e

Santosh P

SOURCE CODE:
FUNCTION Z915FM1. *"---------------------------------------------------------------------*"*"Local interface: *" IMPORTING *" VALUE(I_X) TYPE I *" VALUE(I_Y) TYPE I *" EXPORTING *" VALUE(E_Z) TYPE I *" EXCEPTIONS *" EXCEPTION1 *"---------------------------------------------------------------------E_Z = I_X + I_Y. call function 'ZFM50' destination 'BACK' exporting x = e_z. ENDFUNCTION.

IN 6.0: SE37: ZFM50

15 | P a g e

Santosh P

SOURCE CODE: REPORT ZCALLRFCBACK.

data m type i. call function 'Z915FM1' destination '915DEST' exporting i_x = 10 i_y = 20 importing e_z = m. IN 6.0: CALL PROGRAM: REPORT ZCALLRFCBACK.

data m type i. call function 'Z915FM1' destination '915DEST' exporting i_x = 10 i_y = 20

16 | P a g e

Santosh P

importing e_z = m. OUT PUT:

17 | P a g e

Santosh P

ALE/IDOCS
ALE: Application Link Enabling. IDOCS: Intermediate Document. ALE is a technology of SAP used for implementing Distributed Process. Distributed Process: It is the process in which a process of a task is performed in multiple systems. By using ALE we can configure distribute & post the IDOCS to multiple receivers from SAP system. These receivers can be either SAP (OR) NON-SAP systems. IDOCS: It is a container of data which can carry the data from one system to another. IDOC is SAPs own format of data which can be understood only by SAP system.

18 | P a g e

Santosh P

XI: Exchange Infrastructure.

IDOCS Related Objects: 1) Logical Systems. 2) RFC Destination. 3) Port Number. 4) Message Type. 5) IDOC Type. 6) Partner Profile. 7) Outbound Parameter. 8) Inbound Parameter. 9) Selection Program. 10) Inbound Program. 11) Process Code. Logical Systems: It is the unique name assigned for a sender & receiver system involved ALE communication. It can also be called Alias provided for IP Address. Logical System is client independent object. Logical System is stored in the table TBDLS & TBDLST. T-Code for creating Logical System SALE, BD54. RFC Destination: It stores the Physical details of receiver system. RFC Destination is stored in the table RFCDES. T-Code for creating RFC Destination SALE, SM59. Port Number: It is unique number used for identifying a Resource on the system. A resource can be a file , Input (OR) output device. Port Number is stored in the table EDIPO. T-Code for creating Port Number WE21. Message Type: It indicates the type of data stored in the IDOC. Message type is client Independent. Message type is stored in the table EDMSG

19 | P a g e

Santosh P

 T-Code for creating Message type WE81.

IDOC Type: IDOC Types is a collection of segments. Segment is a structure which is a collection of fields. T-Code for Segments WE82.

IDOC Type doesnt hold any data it only provides template. The instance of IDOC Type is IDOC.

Partner Profile: It holds the details of the partner system. A partner profile is client dependent object. Partner Profile is stored in the table EDPP1. T-Code for creating Port Number WE20. Outbound Parameters: It is always created in sender system and it is a collection of message type, Receiver Port & IDOC Type. Inbound Parameters: It is always created AT THE Receiver side and it is a collection of message type & Process Code. Selection Program:

20 | P a g e

Santosh P

 It is also called as outbound program. It is responsible for retrieving the data from sender system database, generating the IDOCS & Distributing the IDOCS. It always executes in sender system.

Inbound Program: It is also called as posting program it is always executed in receiver system. It is responsible for reading the incoming IDOC Data & Updating the data to the receiver Database. Process Code: It is an identifier for inbound program. It is usually the first four characters of Message Type. T-Code for creating Process Code WE41 Outbound Process Code. WE42 Inbound Process Code. Note: Inbound is generally a function module (OR) A workflow Task. Class 4: 02.08.2011 Requirement: Distribute materials from one client to another Client. SENDER: 800 Steps at sender side (800). 1) Create two Logical Systems. 2) Assign Logical system to clients. 3) Create RFC Destination. 4) Create Port. 5) Identify the Message type and IDOC Type. 6) Create Model view. 7) Assign Message type to Model view. 8) Create partner Profile for Sender. 9) Assign outbound parameters. Steps at sender side (811). 10) Create Partner profile for receiver. 11) Assign inbound Parameters. RECIVER: 811

21 | P a g e

Santosh P

Steps at sender side (800). 12) Identify the Objects to be distributed. 13) Run the selection program. 14) Check the IDOCS generated. 15) Process the IDOCS if any errors in Distribution. Steps at sender side (811). 16) Check the IDOCS Received. 17) Process the IDOCS if any errors in Posting.

Model view: An object which encapsulates the sender and receiver information along with the message type. PROGRAM: IN Client (800) 1) Create two Logical Systems.

2) Assign Logical system to clients.

22 | P a g e

Santosh P

23 | P a g e

Santosh P

SAVE. 3) Create RFC Destination.

24 | P a g e

Santosh P

25 | P a g e

Santosh P

4) WE21:

Create Port.

26 | P a g e

Santosh P

Note: Transactional RFC Port is always create on top of RFC Destination. 5) Identify the Message type and IDOC Type. Identify the Message Type and IDOC Type.

6) Create Model view.

27 | P a g e

Santosh P

7) Assign Message type to Model view. In the same screen.

28 | P a g e

Santosh P

CONTINUE. SAVE. 8) Create partner Profile for Sender. Note: Partner profile is created on top of Logical system. WE20:

29 | P a g e

Santosh P

9) Assign outbound parameters.

SAVE--------BACK--------SAVE--------BACK IN Client (811): Steps at sender side (811). 10) Create Partner profile for receiver.

30 | P a g e

Santosh P

WE20:

11) Assign inbound Parameters.

IN Client (800): Steps at sender side (800). Note: Check the Materials if available (OR) Create New Materials. 12) Identify the Objects to be distributed.

13) Run the selection program.

31 | P a g e

Santosh P

Hear we will get Messages.

14) Check the IDOCS generated.

32 | P a g e

Santosh P

15) Process the IDOCS if any errors in Distribution. Check for the errors. In the current program there are no errors. Steps at sender side (811). 16) Check the IDOCS Received.

33 | P a g e

Santosh P

17) Process the IDOCS if any errors in Posting. Hence there are no errors in the current program no need of this step. Class 5: 03.08.2011 Note: Every IDOC is a 16Degit Number associated with 3 records. 1) Control Record. 2) Data Record.

3) Status Record. Control Record: A control record is like a envelope of a letter which contains Sender and Receiver Information.

34 | P a g e

Santosh P

 This includes Sender and Receiver Logical System, Port Number, IDOC Type, Message Type and Direction. Control Record Information is stored in the table EDIDC. Data Record: It contains the actual data of IDOC. It is associated with two Sections. 1) Administration Section. 2) Data Section. Administration Section: Administration Section contains segment information like Segment Name and Segment Number. Data Section: Contains the actual section of the IDOC. Data record information is stored in the table EDID2. The actual contents of the IODC are stored in the field SDATA it is of type LCHR. Status Record: It contains the status of the IDOC during its journey from sender to receiver. Status Record information is stored in the table EDIDS. For every status there is an associated status code. The status code can be accessed using the T-Code WE47.

Processing the error IDOC: Whenever an IDOC is generated (OR) receive is error status. As a developer we need to analyze the error and identify. Weather it us functional issue (OR) Technical issue. If it is a functional issue the functional consultant need to configure functional settings and after this ABAP-consultant is responsible for processing the error IDOC by using the T-Code BD87 (OR) WE19. T137: Table which stores the Industrial Sector. BD87: This T-Code Process the existing IDOC, without generating the new IDOC. WE19: Ignores the error IDOC & generates new IDOC. PROGRAM: IN Client 800: Create a material in (800) with material type which does not exist in (811). 915MA4 BD10:

35 | P a g e

Santosh P

WE02:

36 | P a g e

Santosh P

IN Client 811:

Double Click on the IDOC.

37 | P a g e

Santosh P

Double Click on Status 51.

To check the error Click on Application Log

38 | P a g e

Santosh P

To solve this error go to SPRO

39 | P a g e

Santosh P

BD87 (OR) WE19. BD87:

Choose the node and Execute.

40 | P a g e

Santosh P

The status of the errors will change from 51 to 53.

IDOC Filtering: It is the Process of filtering IDOCS at various levels, IDOC filters are of 3 types. 1) Data Level Filtering. 2) Segment Level Filtering. 3) IDOC Reduction. Data Level Filtering: This is configured at sender level at Model View Level. Note: Whenever a selection Program is executed depending on the range of the objects given. The selection program returns the corresponding data from sender database and generates the Application Number of Master IDOC. This Master IDOCS are stored at Operating System Level and they are sent to ALE Layer. ALE Layer executes the data filter conditions maintained at Model View Level and generates the appropriate number of Communication IDOC. These Communication IDOCS stored at database level, which are then distributed to the communication Layer. This Communication Layer is responsible for distributing the communication IDOCS. Data Level Filtering: PROGRAM: Create Some Materials.

41 | P a g e

Santosh P

BD64

Select the Particular Model View, Expand it and Double Click on No Filter Set.

42 | P a g e

Santosh P

Click Create filter group.

43 | P a g e

Santosh P

Double Click on Material Type

Continue. Continue. Save. BD10:

44 | P a g e

Santosh P

Hear we can see only 3 IDOCS are created and 2 IDOCS are communicated.

45 | P a g e

Santosh P

IN Client 811: Check the receiver status. WE02:

46 | P a g e

Santosh P

We can check in it in SE11 in MARA TABLE

47 | P a g e

Santosh P

Class 6: 04.08.2011 Segment Level Filtering: It is the Process of filtering a Segment whenever a IDOC is generated between Sender and Receiver. T-code is BD56: Pre-requisites: Sender and Receiver Partner Profile should be available at the sender system. Mandatory Segments cannot be filtered. A segment filtering is always configured at Sender side. PROGRAM: BD56:

Continue. New Entries.

48 | P a g e

Santosh P

Sender and Receiver Partner Profile should be available at the sender system, so we must create the partner profile. WE20:

49 | P a g e

Santosh P

SAVE. BD56.

50 | P a g e

Santosh P

Now the Segment filter is Created. BD10.

WE02:

51 | P a g e

Santosh P

Double Click on the error and check the status of the error.

52 | P a g e

Santosh P

Click on status record 29.

By observing the above Process we came to know that Segment filtering cannot be done on mandatory segments, so we can do the segment filtering only on Non-Mandatory fields. To know the status of the segments go to SW30.

53 | P a g e

Santosh P

BD10:

54 | P a g e

Santosh P

Execute.

WE20.

55 | P a g e

Santosh P

Change Pointer: Change Pointers are used for tracking the changes made to master data. To track these changes, change pointer must be activated at 3 levels. 1) Globally (BD61). 2) Message Type Level (BD50). 3) Field Level (BD52). Once the change pointers are activated the changes made to master data will be tracked in fallowing tables. 1) CDHDR 2) CDPOS 3) BDCP 4) BDCPS We can distribute the changes in two ways. 1) Using Program RBDMIDOC. 2) Using T-Code BD21.

PROGRAM: Globally: BD61

56 | P a g e

Santosh P

Message Type Level: BD50

Field Level: BD52

57 | P a g e

Santosh P

BD21:

Once again check the status by T-Code.

58 | P a g e

Santosh P

Now create some materials and make changes in some materials.

Made Changes in 800MAT10 BD21:

Change Pointer at Field Level:

59 | P a g e

Santosh P

Then make changes at the field level in the Material field MAKTX. BD21:

Class 7: 05.08.2011

CUSTOM IDOCS: We go for custom IDOCS whenever we want to distribute custom specific data to the receiver, This customer specific data will be stored in custom tables.

60 | P a g e

Santosh P

Sender ------800

Receiver -----------811

Steps for creating the custom IDOCS: Sender Side Client (800): 1) Create two logical systems. BD54 (0R) SALE.

61 | P a g e

Santosh P

2) Assign Logical System to client. SCC4 (OR) SALE.

62 | P a g e

Santosh P

3) Creating RFC Destination. SM59 (OR) SALE.

63 | P a g e

Santosh P

SAVE. 4) Create TRFC Port. WE21.

SAVE.

As in the above figure we must create Segment, IDOC Type and Message Type. 5) Create Segment. (7 Characters) WE31.

64 | P a g e

Santosh P

SAVE. Qualified Segment: If this checkbox is selected, the segment will prefix with value of the primary key field when the IDOCS are displayed. Back to initial Screen.

65 | P a g e

Santosh P

After selecting Set Release.

6) Create IDOC Type. (8 Characters) WE30.

66 | P a g e

Santosh P

Now put the cursor on IDOC Type and Create Segment.

67 | P a g e

Santosh P

SAVE. Back to initial screen.

Yes. 7) Create Message type.(6 Characters) WE81.

68 | P a g e

Santosh P

CONTINUE.

SAVE. 8) Link Message Type to IDOC Type. WE82.

69 | P a g e

Santosh P

SAVE. 9) Create Model View. BD64 (OR) SALE.

CONTINUE. 10) Assign Message Type to Model View.

70 | P a g e

Santosh P

CONTINUE. SAVE. 11) Create Partner profile for Sender. WE20.

12) Assign the outbound parameter. In The Same Screen.

71 | P a g e

Santosh P

SAVE.

72 | P a g e

Santosh P

Receiver Side Client (811): 1) Create Partner profile for Receiver. WE20.

SAVE. 2) Assign Inbound Parameters. Note: To receive a profile we must assign inbound parameters at receiver side, to assign the inbound parameters we need message type and process code. Process code is assigned with function module IDOC_INPUT_MATMAS01.this function module is responsible to read the message type. by reading the message type the receiver it will decrypt the idoc(segments) In the current we are creating custom idoc so we need custom function module. a) Creating the custom function module. SE37. Note: Function module is not client dependent so we can create it anywhere.

73 | P a g e

Santosh P

Copy. Delete the total source code. SAVE. b) Linking the function module with message type & IDOC Type. WE57.

74 | P a g e

Santosh P

c)

Registering Function Module as Inbound Parameter.

Note: If we forget to register the function module with inbound parameter, this function module is not available to link with the process code. BD51.

75 | P a g e

Santosh P

d) Creating inbound process code and Link with inbound function module. WE42.

76 | P a g e

Santosh P

77 | P a g e

Santosh P

Note: Now we are eligible to assign the inbound parameters to receiver system. Assign Inbound Parameters. WE20.

Class 8: 06.08.2011 Note: At the Sender side create a database table for storing the customer specific data.

78 | P a g e

Santosh P

Sender Objects: Logical System RFC Destination Segment IDOC Type Message Type Port Number Model View Partner Profile Receiver Objects: : METSEND : METDEST : ZMETSEG : ZMETIDOC : METMSG : A000000264 : METMODEL : METREC

Logical System : METREC Partner Profile : METSEND Function Module : ZMET_READ_DEPARTMENT Process Code : METM Sender Side Client (800): Process for Selection Program: 1) 2) 3) 4) Generate the selection screen for accepting the range of business objects, Message and receiver logical system. Prepare the control Record. Prepare the Data Record. Generate and Distribute the IDOC by calling the Function Module MASTER_IDOC_DISTRIBUTE.

13) Create selection program. ZMATSENDERDEPT :( Program) REPORT ZMATSENDERDEPT. DATA : P_DEPTNO TYPE Z915DEPT-DEPTNO. " SELECTION SCREE FOR ACCEPTING THE INPUT

SELECTION-SCREEN BEGIN OF BLOCK B1 WITH FRAME TITLE TEXT-001. SELECT-OPTIONS : SO_DEPNO FOR P_DEPTNO. PARAMETERS : P_MESTYP LIKE EDMSG-MSGTYP OBLIGATORY DEFAULT 'METMSG', P_LOGSYS LIKE TBDLST-LOGSYS. SELECTION-SCREEN END OF BLOCK B1. * PREPARING CONTROL RECORD DATA : LS_CONT_REC TYPE EDIDC. IF P_LOGSYS = SPACE. LS_CONT_REC-RCVPRT = SPACE. ELSE. LS_CONT_REC-RCVPRT = 'LS'. ENDIF. LS_CONT_REC-RCVPRN = P_LOGSYS. LS_CONT_REC-MESTYP = P_MESTYP. LS_CONT_REC-IDOCTP = 'ZMETIDOC'. * END OF CONTROL RECORD

79 | P a g e

Santosh P

* PREPARING DATA RECORD TYPES : BEGIN OF TY_DEPT. INCLUDE STRUCTURE Z915DEPT. TYPES END OF TY_DEPT. DATA : LT_DEPT TYPE STANDARD TABLE OF TY_DEPT, LS_DEPT TYPE TY_DEPT. DATA : LS_DEPT_SEG TYPE ZMETSEG. DATA : LT_DATA_REC TYPE STANDARD TABLE OF EDIDD, LS_DATA_REC TYPE EDIDD. DATA : LT_COMM_IDOC TYPE STANDARD TABLE OF EDIDC, LS_COMM_IDOC TYPE EDIDC. *READING THE APPLICATION DATA FROM ADATBASE SELECT * FROM Z915DEPT INTO TABLE LT_DEPT WHERE DEPTNO IN SO_DEPNO. IF SY-SUBRC EQ 0. LOOP AT LT_DEPT INTO LS_DEPT. " PREPARING MASTER IDOC LS_DEPT_SEG-DEPNO = LS_DEPT-DEPTNO. LS_DEPT_SEG-DEPNAME = LS_DEPT-DNAME. LS_DEPT_SEG-DEPLOC = LS_DEPT-LOC. LS_DATA_REC-SEGNAM = 'ZMETSEG'. LS_DATA_REC-SDATA = LS_DEPT_SEG. APPEND LS_DATA_REC TO LT_DATA_REC. "TRANSFERING THE CONTROL RECORD AND CONTROL RECORD TO ALE SERVICE LAYER CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE' EXPORTING master_idoc_control = LS_CONT_REC tables communication_idoc_control = LT_COMM_IDOC master_idoc_data = LT_DATA_REC. IF SY-SUBRC EQ 0. COMMIT WORK. REFRESH LT_DATA_REC. ENDIF. ENDLOOP. ENDIF. IF LT_COMM_IDOC IS NOT INITIAL. LOOP AT LT_COMM_IDOC INTO LS_COMM_IDOC. WRITE :/ LS_COMM_IDOC-DOCNUM. ENDLOOP. ENDIF. EXECUTE.

80 | P a g e

Santosh P

MESSAGE.

Process of Inbound Program: As Part of the inbound program. We need to use the parameter IDOC_DATA. This parameter carries the actual data of the IDOC. We need to use the internal table parameter, Extract the data stored in SDATA field and update the same to corresponding database table. Writing the code in Function Module: (ZMET_READ_DEPARTMENT) Source Code: FUNCTION ZMET_READ_DEPARTMENT. *"---------------------------------------------------------------------*"*"Local Interface: *" IMPORTING *" VALUE(INPUT_METHOD) LIKE BDWFAP_PAR-INPUTMETHD *" VALUE(MASS_PROCESSING) LIKE BDWFAP_PAR-MASS_PROC *" VALUE(NO_APPLICATION_LOG) LIKE SY-DATAR OPTIONAL *" VALUE(MASSSAVEINFOS) LIKE MASSSAVINF STRUCTURE MASSSAVINF *" OPTIONAL *" EXPORTING *" VALUE(WORKFLOW_RESULT) LIKE BDWF_PARAM-RESULT *" VALUE(APPLICATION_VARIABLE) LIKE BDWF_PARAM-APPL_VAR *" VALUE(IN_UPDATE_TASK) LIKE BDWFAP_PAR-UPDATETASK *" VALUE(CALL_TRANSACTION_DONE) LIKE BDWFAP_PAR-CALLTRANS *" TABLES *" IDOC_CONTRL STRUCTURE EDIDC *" IDOC_DATA STRUCTURE EDIDD *" IDOC_STATUS STRUCTURE BDIDOCSTAT *" RETURN_VARIABLES STRUCTURE BDWFRETVAR *" SERIALIZATION_INFO STRUCTURE BDI_SER *" EXCEPTIONS

81 | P a g e

Santosh P

*" WRONG_FUNCTION_CALLED *"---------------------------------------------------------------------DATA : WA_DATA TYPE EDIDD, WA_STATUS TYPE BDIDOCSTAT, WA_DEPT_SEG TYPE ZMETSEG, WA_DEPT_TABLE TYPE Z915DEPT. LOOP AT IDOC_DATA INTO WA_DATA. CASE WA_DATA-SEGNAME. WHEN 'ZMETSEG'. WA_DEPT_SEG = WA_DATA-SDATA. MOVE-CORRESPONDING WA_DEPT_SEG TO WA_DEPT_TABLE. ENDCASE. ENDLOOP. MODIFY Z915DEPT FROM WA_DEPT_TABLE. IF SY-SUBRC EQ 0. WA_STATUS-DOCNUM = WA_DATA-DOCNUM. WA_STATUS-STATUS = 53. WA_STATUS-MSGTY = 'METMSG'. APPEND WA_STATUS TO IDOC_STATUS. ELSE. WA_STATUS-DOCNUM = WA_DATA-DOCNUM. WA_STATUS-STATUS = 51. WA_STATUS-MSGTY = 'METMSG'. APPEND WA_STATUS TO IDOC_STATUS. ENDIF. ENDFUNCTION. WE19:

82 | P a g e

Santosh P

BAPI
BUSINESS APPLICATION PROGRAMING INTERFACE
BAPI: BAPI is a remote function module for an ABAP Consultant and API METHOD for a Legacy programmer. API: Application Programming Interface. BAPIs are used for accessing the SAP business objects from ABAP Application as well as from Legacy Application. All the business objects are stored in BOR. BOR: Business objects Repository. BAPI: Is the T-Code. Every business object is associated with remote function module and an API Method. As long as we access business objects from legacy Application we us API Method and if the access in from SAP. We use BAPI function module. All the BAPI function modules start with naming convention BAPI_.

TOPICS:

Standard BAPIs. Enhance Standard BAPIs. BAPI Modification. Custom BAPI Creation and Access from SAP / NONSAP. LSMW using BAPI. Transporting LSMW.

83 | P a g e

Santosh P

BAPI

84 | P a g e

Santosh P

 In SAP FI/CO, SD, MM data is stored in the form of header data and item data. IN SAP HR in the form of Infotypes and they are stored in the table T777D.

Time Constraints: Xyz12th August 2011 to 20th June 2012---------------Project1 29th July 2011 to 30th September 2012---------------Project2 No Overlapping No Gaps. No Overlapping gaps are allowed No gaps and Overlapping is allowed

85 | P a g e

Santosh P

PA30: T-Code Used for maintaining HR Master Data. P0006: Table which captures the employee addresses details.

USRID_LONG --- CHAR (241): It stores the Email ID. Flat File :( With tabbed space)

86 | P a g e

Santosh P

Requirement: Uploading Employee Communication details to SAP using BAPI. BAPI:

Business Object Name Object Type

: :

EmplCommunication. EMPLCOMM.

Note: Every business object will be associated with different types of operations. Create Change, Delete and Retrieval.

Method Function Module

: :

Create. BAPI_EMPLCOMM_CREATE.

87 | P a g e

Santosh P

Note: If an ALV Message Type is associated with BAPI. Then we can use that BAPI with LSMW integration. Every BAPI is a Remote Function Module. But every remote function module may not be a BAPI.

Note: Every BAPI function module contains a returning parameter of type BAPIRETURN1 (OR) BAPIRETURN (OR) BAPIRET1 (OR) BAPIRET2.

88 | P a g e

Santosh P

PROGRAM: REPORT ZCNUBAPI1. *PROGRAM : ZCNUBAPI1 *AUTHOR : CNU *START DATA : 12.08.2011 *PURPOSE : Bapi To Upload Employee Communication Details. *OPERATION : BAPI TO UPLOAD EMPLOYEE COMMUNICATION DETAILS. *COPIED FROM : NA (or) REF.PROGRAM ******************************************************************************************** DATA : LT_FILETABLE TYPE FILETABLE, LV_FILETABLE TYPE FILE_TABLE. DATA : LV_RC TYPE I. DATA : FNAME TYPE STRING. TYPES : BEGIN OF TY_COMM, PERNR TYPE PA0105-PERNR, BEGDA TYPE PA0105-BEGDA, ENDDA TYPE PA0105-ENDDA, USRID_LONG TYPE PA0105-USRID_LONG, END OF TY_COMM. DATA : LT_COMM TYPE STANDARD TABLE OF TY_COMM, LS_COMM TYPE TY_COMM. DATA : LS_RETURN TYPE BAPIRETURN1. CALL METHOD cl_gui_frontend_services=>file_open_dialog CHANGING file_table = LT_FILETABLE rc = LV_RC. IF LT_FILETABLE[] IS NOT INITIAL. READ TABLE LT_FILETABLE INTO LV_FILETABLE INDEX 1. IF SY-SUBRC EQ 0. FNAME = LV_FILETABLE-FILENAME. CALL METHOD cl_gui_frontend_services=>gui_upload EXPORTING FILENAME = FNAME FILETYPE = 'ASC' HAS_FIELD_SEPARATOR = 'X' CHANGING data_tab = LT_COMM[]. ENDIF. ENDIF. IF LT_COMM IS NOT INITIAL. LOOP AT LT_COMM INTO LS_COMM. PERFORM LOCKEMPLOYEE.

89 | P a g e

Santosh P

IF LS_RETURN-TYPE NE 'E'. PERFORM CREATEEMAIL. WRITE :/'Employee No:',LS_COMM-PERNR, / LS_RETURN-TYPE, / LS_RETURN-MESSAGE. SKIP 2. PERFORM UNLOCKEMPLOYEE. ENDIF. ENDLOOP. ENDIF.

form CREATEEMAIL . CLEAR LS_RETURN. CALL FUNCTION 'BAPI_EMPLCOMM_CREATE' EXPORTING employeenumber = LS_COMM-PERNR subtype = '0010' validitybegin = LS_COMM-BEGDA validityend = LS_COMM-ENDDA COMMUNICATIONID = LS_COMM-USRID_LONG IMPORTING RETURN = LS_RETURN. endform. " CREATEEMAIL form LOCKEMPLOYEE . CLEAR LS_RETURN. CALL FUNCTION 'BAPI_EMPLOYEET_ENQUEUE' EXPORTING number = LS_COMM-PERNR validitybegin = '19000101' IMPORTING RETURN = LS_RETURN. endform. " LOCKEMPLOYEE form UNLOCKEMPLOYEE . CALL FUNCTION 'BAPI_EMPLOYEET_DEQUEUE' EXPORTING number = LS_COMM-PERNR validitybegin = '19000101' IMPORTING RETURN = LS_RETURN. endform. " UNLOCKEMPLOYEE

90 | P a g e

Santosh P

OUTPUT:

Uploading the bank details using BAPI.

BAPI_TRANSACTION_COMMIT: Execute external Commit when using BAPIs. PROGRAM: *PROGRAM : ZCNUBAPI2 *AUTHOR : CNU *START DATA : 13.08.2011 *PURPOSE : Uploading Bank Details Using BAPI. *OPERATION : UPLOADING BANK DETAILS USING BAPI. *COPIED FROM : NA (or) REF.PROGRAM ******************************************************************************************** REPORT ZCNUBAPI2. PARAMETERS : P_BCTRY TYPE BAPI1011_KEY-BANK_CTRY, P_BKEY TYPE BAPI1011_KEY-BANK_KEY. DATA : LS_BADDR TYPE BAPI1011_ADDRESS. DATA : LS_RETURN TYPE BAPIRET2. CLEAR LS_BADDR. LS_BADDR-BANK_NAME = 'SBI571 bank'.

91 | P a g e

Santosh P

LS_BADDR-REGION = '01'. LS_BADDR-STREET = 'MALAKPET'. LS_BADDR-CITY = 'HYDERABAD'. CALL FUNCTION 'BAPI_BANK_CREATE' EXPORTING bank_ctry = P_BCTRY BANK_KEY = P_BKEY bank_address = LS_BADDR IMPORTING RETURN = LS_RETURN. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'. WRITE:/ LS_RETURN-TYPE, LS_RETURN-MESSAGE. Note: Before executing the Program check number of entries in the table.

Execute.

92 | P a g e

Santosh P

Note: Check number of entries in the table.

Check For the entry.

93 | P a g e

Santosh P

Changing the Bank Details.

Note: Some of the Change BAPIs are associated with the Update flag Parameter. This parameters ends with X. As part of these parameters we need to set the flag for the field which needs to be updated. PROGRAM: REPORT ZCNUBAPI3. *PROGRAM : ZCNU_ALV2 *AUTHOR : CNU *START DATA : 18.07.2011 *PURPOSE : Using BAPI To Update Bank Details. *OPERATION : USING BAPI TO UPDATE BANK DETAILS. *COPIED FROM : NA (or) REF.PROGRAM ******************************************************************************************** DATA : LV_BCTRY TYPE BAPI1011_KEY-BANK_CTRY VALUE 'IN', LV_BKEY TYPE BAPI1011_KEY-BANK_KEY VALUE 'CBB', LS_BADDR TYPE BAPI1011_ADDRESS, LS_BADDRX TYPE BAPI1011_ADDRESSX, LS_RETURN TYPE BAPIRET2. LS_BADDR-BANK_NAME = 'Central Bank of Bodhan'. LS_BADDR-STREET = 'Bodhan'. LS_BADDRX-BANK_NAME = 'X'. LS_BADDRX-STREET = 'X'. CALL FUNCTION 'BAPI_BANK_CHANGE' EXPORTING bankcountry = LV_BCTRY bankkey = LV_BKEY bank_address = LS_BADDR bank_addressx = LS_BADDRX IMPORTING RETURN = LS_RETURN. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'. WRITE : / LS_RETURN-TYPE, LS_RETURN-MESSAGE. Execute.

94 | P a g e

Santosh P

Check number of entries in the table.

Uploading the master data using BAPI: 1) Accepting the parameter of type IBIPPARMS-PATH.

PARAMETERS : P_FILE TYPE IBIPPARMS-PATH. Execute and check.

2) Getting the F4 Help Functionality for the field P_FILE in the Program.

95 | P a g e

Santosh P

PARAMETERS : P_FILE TYPE IBIPPARMS-PATH. AT SELECTION-SCREEN ON VALUE-REQUEST FOR P_FILE. CALL FUNCTION 'F4_FILENAME' EXPORTING PROGRAM_NAME = SYST-CPROG DYNPRO_NUMBER = SYST-DYNNR IMPORTING FILE_NAME = P_FILE. Execute and check.

Flat File: Data.

96 | P a g e

Santosh P

3) Extracting data from flat file. PARAMETERS : P_FILE TYPE IBIPPARMS-PATH. DATA : FNAME TYPE STRING. TYPES : BEGIN OF TY_LEGACY, STR(100) TYPE C, END OF TY_LEGACY. DATA : LT_LEGACY TYPE STANDARD TABLE OF TY_LEGACY, LS_LEGACY TYPE TY_LEGACY. START-OF-SELECTION. FNAME = P_FILE. CALL FUNCTION 'GUI_UPLOAD' EXPORTING filename FILETYPE tables data_tab

= FNAME = 'ASC' = LT_LEGACY[].

AT SELECTION-SCREEN ON VALUE-REQUEST FOR P_FILE. CALL FUNCTION 'F4_FILENAME' EXPORTING PROGRAM_NAME = SYST-CPROG DYNPRO_NUMBER = SYST-DYNNR IMPORTING FILE_NAME = P_FILE.

4) Split the data in to the local table. TOTAL CODE: REPORT ZCNUBAPI4. *PROGRAM : ZCNUBAPI4

97 | P a g e

Santosh P

*AUTHOR : CNU *START DATA : 13.08.2011 *PURPOSE : Upload Material Data Using BAPI. *OPERATION : UPLOAD MATERIAL DATA USING BAPI. *COPIED FROM : NA (or) REF.PROGRAM ******************************************************************************************** PARAMETERS : P_FILE TYPE IBIPPARMS-PATH. DATA : FNAME TYPE STRING. TYPES : BEGIN OF TY_LEGACY, STR(100) TYPE C, END OF TY_LEGACY. DATA : LT_LEGACY TYPE STANDARD TABLE OF TY_LEGACY, LS_LEGACY TYPE TY_LEGACY. TYPES : BEGIN OF TY_MATERIAL, MATERIAL TYPE BAPIMATHEAD-MATERIAL, IND_SECTOR TYPE BAPIMATHEAD-IND_SECTOR, MATL_TYPE TYPE BAPIMATHEAD-MATL_TYPE, MATL_GROUP TYPE BAPI_MARA-MATL_GROUP, BASE_UOM TYPE BAPI_MARA-BASE_UOM, LANGU TYPE BAPI_MAKT-LANGU, LANGU_ISO TYPE BAPI_MAKT-LANGU_ISO, MATL_DESC TYPE BAPI_MAKT-MATL_DESC, END OF TY_MATERIAL. DATA : LT_MATERIAL TYPE STANDARD TABLE OF TY_MATERIAL, LS_MATERIAL TYPE TY_MATERIAL. DATA : LS_MATHED TYPE BAPIMATHEAD, LS_BAPI_MARA TYPE BAPI_MARA, LA_BAPI_MARAX TYPE BAPI_MARAX, LS_RETURN TYPE BAPIRET2. DATA : LT_MAKT TYPE TABLE OF BAPI_MAKT, LS_MAKT TYPE BAPI_MAKT . START-OF-SELECTION. FNAME = P_FILE. CALL FUNCTION 'GUI_UPLOAD' EXPORTING filename FILETYPE tables data_tab

= FNAME = 'ASC' = LT_LEGACY[].

IF LT_LEGACY[] IS NOT INITIAL. LOOP AT LT_LEGACY INTO LS_LEGACY. SPLIT LS_LEGACY-STR AT ',' INTO LS_MATERIAL-MATERIAL LS_MATERIAL-IND_SECTOR LS_MATERIAL-MATL_TYPE LS_MATERIAL-MATL_GROUP

98 | P a g e

Santosh P

LS_MATERIAL-BASE_UOM LS_MATERIAL-LANGU LS_MATERIAL-LANGU_ISO LS_MATERIAL-MATL_DESC. APPEND LS_MATERIAL TO LT_MATERIAL. ENDLOOP. ENDIF. IF LT_MATERIAL[] IS NOT INITIAL. LOOP AT LT_MATERIAL INTO LS_MATERIAL. LS_MATHED-MATERIAL = LS_MATERIAL-MATERIAL. LS_MATHED-IND_SECTOR = LS_MATERIAL-IND_SECTOR. LS_MATHED-MATL_TYPE = LS_MATERIAL-MATL_TYPE. LS_MATHED-BASIC_VIEW = 'X'. LS_BAPI_MARA-MATL_GROUP = LS_MATERIAL-MATL_GROUP. LS_BAPI_MARA-BASE_UOM = LS_MATERIAL-BASE_UOM. LA_BAPI_MARAX-MATL_GROUP = 'X'. LA_BAPI_MARAX-BASE_UOM = 'X'. REFRESH LT_MAKT. LS_MAKT-LANGU = LS_MATERIAL-LANGU. LS_MAKT-LANGU_ISO = LS_MATERIAL-LANGU_ISO. LS_MAKT-MATL_DESC = LS_MATERIAL-MATL_DESC. APPEND LS_MAKT TO LT_MAKT. CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA' EXPORTING headdata = LS_MATHED CLIENTDATA = LS_BAPI_MARA CLIENTDATAX = LA_BAPI_MARAX IMPORTING RETURN = LS_RETURN TABLES MATERIALDESCRIPTION = LT_MAKT. CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'. WRITE : / / / / / ENDLOOP. ENDIF. LS_MATERIAL-MATERIAL, LS_RETURN-TYPE, LS_RETURN-ID, LS_RETURN-NUMBER, LS_RETURN-MESSAGE.

AT SELECTION-SCREEN ON VALUE-REQUEST FOR P_FILE. CALL FUNCTION 'F4_FILENAME' EXPORTING PROGRAM_NAME = SYST-CPROG DYNPRO_NUMBER = SYST-DYNNR IMPORTING FILE_NAME = P_FILE.

99 | P a g e

Santosh P

OUTPUT:

CUSTOM BAPIs: PROCEDURE: 1) Develop a function module by fallowing BAPI standards. 2) Release the function module. 3) Create the business object referring to BAPI function module. BAPI FUNCTION MODULE STANDARDS: 1) Function module should be remote enabled. 2) The Parameters to the function module must be passed by value. 3) Function module mane must start with BAPI_. 4) The return type of the function module should be of type structure BAPIRETURN (OR) BAPIRET2 (OR) BAPIRET1. 5) The parameter references of the function must start with BAPI. 6) Commit & Rollback statement should not be used; instead we need to use the function BAPI_TRANSACTION_COMMIT (OR) BAPI_TRANSACTION_ROLLBACK.

modules

REQUIRMENT:

100 | P a g e

Santosh P

IN 4.7 Server Client (800): SE11: PROGRAM: 1) Create a Database table.SE11.

2) Create a function Module.SE37. Attributes Tab:

101 | P a g e

Santosh P

Import Tab:

Export Tab:

Source Code:

102 | P a g e

Santosh P

Save. Activate. Releasing the Function Module.

SWO1: T-code for creating the business object builder.

103 | P a g e

Santosh P

104 | P a g e

Santosh P

105 | P a g e

Santosh P

Note: The Colure of the method will change.

106 | P a g e

Santosh P

Same step for other method also. After redefining all the methods, Choose the method and CLICK on PROGRAM

107 | P a g e

Santosh P

SAVE. Same process for all the methods. Choose each method and implement.

108 | P a g e

Santosh P

Same process for all the methods. Choose each method and Release.

Same process for all the methods. Choose the method and object type component Implemented.

Choose the method and object type component release.

109 | P a g e

Santosh P

Same process for all the Methods. Note: We must get tick marks for all the methods.

Save and back to initial Screen. Implement.

110 | P a g e

Santosh P

Release.

Calling a function module in the program. ZCALLCUSTOMBAPI:

REPORT ZCALLCUSTOMBAPI .

data : ls_dept type zbapidept, ls_return type bapireturn. ls_dept-deptno = 1. ls_dept-dname = 'Sales'. ls_dept-loc = 'Hyderabad'. CALL FUNCTION 'ZBAPI_INSERTDEPT' EXPORTING I_DEPT = ls_dept IMPORTING RETURN = ls_return. if ls_return-type = 'S'. message 'Inserted' type 'I'.

111 | P a g e

Santosh P

else. message 'Failed' type 'I'. endif.

Note:

Once a business object is developed we need to prepare a Technical Spec. Which contains information of the business Objects. This information includes name of the business Object. APT Methods, Method Parameters List, Name of the function Module. To invoke the business object from Legacy Application. The Legacy program makes use of technical spec & develop the Application. As the part of this Application, the legacy program invokes the API Method which internally calls BAPI Function module.

Class X: 17.08.2011 LSMW Using BAPI: Requirement: Migrating Bank details from file to SAP using LSMW Tool.

DIM: Declaring Memory. Note: In LSMW Using BAPI we require only one set of object which are specific to receiver. Steps: 1) Creating Logical System. BD54:

112 | P a g e

Santosh P

SAVE. 2) Assign Client to Logical System.

3) Create file Port.

113 | P a g e

Santosh P

EDI_PATH_CREATE_MESTYP_DOCNUM: It generates a file which is for SAP purpose we never use this file. SAVE. 4) Create Partner Profile.

114 | P a g e

Santosh P

5) Assigning Inbound Parameters.

SAVE. Starting LSMW.

115 | P a g e

Santosh P

1) Maintain Object Attributes.

SAVE.

116 | P a g e

Santosh P

Back. 2) Maintain Source Structures.

SAVE. 3) Maintain Source Fields.

117 | P a g e

Santosh P

SAVE. 4) Maintain Structure Relations.

5) Maintain Field Mapping and Conversion Rules.

118 | P a g e

Santosh P

119 | P a g e

Santosh P

perform ur_CHECKBANKKEY using ZBANKSTR-BANKK changing E1BANK_CREATE-BANK_KEY. end perform. SAVE. SAVE. BACK. 6) Maintain Fixed Values, Translations, User-Defined Routines.

120 | P a g e

Santosh P

SAVE. BACK. 7) Specify Files.

121 | P a g e

Santosh P

SAVE. 8) Assign Files.

122 | P a g e

Santosh P

9) Read Data.

123 | P a g e

Santosh P

BACK. 10) Display Read Data.

ENTER.

124 | P a g e

Santosh P

BACK. 11) Convert Data.

125 | P a g e

Santosh P

12) Display Converted Data.

126 | P a g e

Santosh P

ENTER.

127 | P a g e

Santosh P

13) Start IDoc Generation.

128 | P a g e

Santosh P

14) Start IDoc Processing.

129 | P a g e

Santosh P

Check whether the records are updated (or) not. WE02:

130 | P a g e

Santosh P

Class 1: 18.08.2011

131 | P a g e

Santosh P

Integrating BAPI with ALE: Open the required Method in Business object. BAPI: ZDEPTOBJ:

132 | P a g e

Santosh P

CONTINUE.

133 | P a g e

Santosh P

CONTINUE.

134 | P a g e

Santosh P

BAPI MODIFICATION: It is the process of enhancing the standard BAPI by adding additional functionality. This additional functionality is achieved by adding additional parameters to the standard BAPI function module (or) API method. BAPI:

Business Object

: Company Code

135 | P a g e

Santosh P

APT Method BAPI Function Module Procedure:

: GetList : BAPI_COMPANYCODE_GETLIST

1) Copy the Standard BAPI function module to custom function module. SE37

IMPORT SECTION. Declare some importing parameters.

136 | P a g e

Santosh P

 We must make some changes in the Source Code, Need to write the new selection statement and create and internal table of same table type in the TOP INCLUDE Program. FUNCTION GROUP: ZCROSS INCLUDE: LZCROSSTOP TYPES : BEGIN OF TY_COMPANYCODE_LIST. INCLUDE STRUCTURE bapi0002_1. TYPES END OF TY_COMPANYCODE_LIST. DATA : LM_COMPANYCODE_LIST TYPE STANDARD TABLE OF TY_COMPANYCODE_LIST WITH HEADER LINE. SAVE, CHECK, ACTIVATE.

IN top include declare. TABLES : T001. FUNCTION MODULE: SOURCE CODE SELECT BUKRS BUTXT FROM T001 INTO CORRESPONDING FIELDS OF TABLE LM_COMPANYCODE_LIST WHERE BUKRS >= I_LBUKRS AND BUKRS <= I_HBUKRS. SAVE, CHECK, ACTIVATE.

Declare message in TOPINCLUDE. 137 | P a g e

Santosh P

DATA : BEGIN OF MESSAGE, msgty like sy-msgty, msgid like sy-msgid, msgno like sy-msgno, msgv1 like sy-msgv1, msgv2 like sy-msgv2, msgv3 like sy-msgv3, msgv4 like sy-msgv4, END OF MESSAGE.
SAVE, CHECK, ACTIVATE. INCLUDE: LZCROSSTOP

form check_authority_t001 changing return like bapireturn. tables: tddat. data: activity(2) type c value '03'. select single * from tddat where tabname = 'V_T001'.

138 | P a g e

Santosh P

if sy-subrc ne 0 or tddat-cclass eq space. tddat-cclass = '&NC&'. endif. authority-check object 'S_TABU_DIS' "check by class id 'ACTVT' field activity " 'non classified table'

id 'DICBERCLS' field tddat-cclass. if sy-subrc ne 0. clear message. message-msgty = 'E'. message-msgid = 'FN'. message-msgno = 000. perform set_return_message using message changing return. if 1 = 2. " Fr Verwendungsnachweis Messages message e000(fn). * Keine Berechtigung, Buchungskreise anzuzeigen endif. endif. endform. SAVE, CHECK, ACTIVATE. " CHECK_AUTHORITY_T001 "no authority

139 | P a g e

Santosh P

form set_return_message using value(p_message) like message changing p_return check not message is initial. call function 'BALW_BAPIRETURN_GET' exporting type cl = p_message-msgty = p_message-msgid = p_message-msgno = p_message-msgv1 = p_message-msgv2 = p_message-msgv3 = p_message-msgv4 ='' like bapireturn.

number par1 par2 par3 par4 * *

LOG_NO

LOG_MSG_NO = ' ' importing bapireturn = p_return exceptions others = 1. " SET_RETURN_MESSAGE

endform. SAVE, CHECK, ACTIVATE.

Note: We must release the function module. Go to initial Screen of function module.

140 | P a g e

Santosh P

2) Creating Business Object from the standard business object. SWO1:

141 | P a g e

Santosh P

142 | P a g e

Santosh P

143 | P a g e

Santosh P

144 | P a g e

Santosh P

145 | P a g e

Santosh P

Redefine existence check. Put cursor on existence check and click on Program.

146 | P a g e

Santosh P

Save Back. Generate.

147 | P a g e

Santosh P

148 | P a g e

Santosh P

149 | P a g e

Santosh P

150 | P a g e

Santosh P

Back to initial Screen.

151 | P a g e

Santosh P

BAPI:

152 | P a g e

Santosh P

ENHANCEMENTS
Enhancements: It is a process of enhancing the SAP Transaction without disturbing the SAP functionality. There are 4 Types of Enhancements Techniques. 1) User Exits 2) Customer-Exit 3) BADIS ------------Process Oriented Approach (Subroutines). Process Oriented Approach (Function Modules). Object Oriented Approach (Methods).

4) Enhancement Frameworks. Role of ABAP Consultant in Enhancing Standard SAP Transactions: 1) Identifying the suitable Enhancement (Customer-Exit / BADI) in the standard Transaction. 2) Identifying the required components of the Enhancement (CMOD --- Customer-Exit, SE18 --- BADIS). 3) Read the document (If provided) to understand the process of implementing the Enhancement (CMOD --- Customer-Exit, SE18 --- BADIS). 4) Implement the Enhancement Accordingly. Types of Customer-Exits: 1) Function Exits. 2) Menu Exits. 3) Screen Exits. Function Exits: They are used for providing customer specific validation in a standard SAP Transaction.

153 | P a g e

Santosh P

Menu Exits: Menu Exits are used for adding the additional menu item in the standard SAP menu. For this additional menu items the function codes are provided by SAP itself. Which start with naming convention +. The base for the menu exit is function exit. I.e. the implementation for the additional menu item is done inside a function exit. Screen Exits: It is used for adding additional customer specific fields in standard SAP Transaction. These additional fields should be first added in the corresponding base tables of the transaction. The base for the screen exit if function exit. I.e. the validation specific to the additional fields is implemented in the corresponding function exit. In general a screen exit is associated with two corresponding function exits. 1) PBO Function exit. 2) PAI Function exit. PBO Function exit: Is used for transferring the default values from program to screen. PAI Function exit: Is used for transferring data from screen to program.

Procedure for identifying the Customer-Exits in standard SAP Transactions: Procedure 1: 1) Identify the main program of the Transaction. 2) Identify the package of the main program. 3) Identify the Customer-Exits in the package by using SE84 (OR) SMOD. Procedure 2: 1) Identify the main program of the Transaction. 2) Search for the string CALL CUSTOMER_FUNCTION in the main program. Function Exits: TASK: While creating the customer in XD01. If the country field is IN the industry field must be MANDATORY.

154 | P a g e

Santosh P

Procedure 1: SE93:

It will take you to program.

155 | P a g e

Santosh P

Program Name: SAPMF02D Package: VS Using SE84: (Identifying the Customer-Exit)

156 | P a g e

Santosh P

Using SMOD: (Identifying the Customer-Exit)

157 | P a g e

Santosh P

158 | P a g e

Santosh P

Procedure 2: SE93:

SE38:

159 | P a g e

Santosh P

160 | P a g e

Santosh P

161 | P a g e

Santosh P

We will write the code in INCLUDE. Note 1:

Every function exit is associated with a function module which contains a customer specific include. As part of this include we need to provide the customer specific implementation.
Note 2:

Customer exits are implemented inside a project as part of a project. We can implement any number of enhancements related to different transaction.

CMOD: 162 | P a g e Santosh P

163 | P a g e

Santosh P

164 | P a g e

Santosh P

Activate Enhancement.

After Activation.

XD01:

165 | P a g e

Santosh P

So we must give the Industry.

166 | P a g e

Santosh P

Class 1: 20.08.2011

167 | P a g e

Santosh P

BADIS
BUSINESS ADDINNS
BADIS: Is the enhancement technique used for enhancing the SAP Transactions in object oriented methodology (OR) approach. A BADI is associated with Definition & Implementation. Definition of BADI contains fallowing components. 1) BADI Interface: It starts with naming convention (IF_EX_).It is collection of methods which contains null implementation as a developer we need to identify the appropriate methods & provide the implementation. 2) BADI Class: It starts with naming convention (CL_EX_). This class is initially used by SAP and it contains the list of active and inactive implementation. 3) It contains the implementation link weather a BADI is single used BADI (OR) multiple used BADI. A single used BADI can contain any number of implementations but only one active implementation. Multiple used BADI can contain any number of active implementations. 4) Filter Types: A BADI can be filtered dependent (OR) Independent. BADI Implementation: It starts with naming convention (CL_IM_).It is associated with the implementation class and it is responsible for implementing the BADI interface method. Note: Whenever a BADI is triggered SAP executes all BADIs active implementations one after the other. Procedure for identifying BADIS in a Transaction: Technique 1: 1) Identifying the main program in SAP Transaction. 2) Identifying the package in the main program. 3) In the main program search for (CL_EXITHANDLER=>GET_INSTANCE). 4) It displays the lines where the above method is called, Identify the value of the parameter INSTANCE. Technique 2: 1) Identifying the main program in SAP Transaction. 2) Identifying the package in the main program. 3) Using the T-Code SE84 to identify the BADIS in the package. Technique 3: 1) Using the T-Code ST05 (SQL Trace). 2) Switch on the buffer trace in ST05 and activate the trace. 3) In another session make the changes in the transaction. 4) Come back to ST05 session switch off the trace. 5) Search for the BADIS in the run time view (V_EXT_IMP and V_EXT_ACC). TASK: Enhancing the Transaction (XD01). 168 | P a g e Santosh P

Technique 1: SE38:

Global Search: search for (CL_EXITHANDLER=>GET_INSTANCE).

169 | P a g e

Santosh P

Double click on 14.

Double click on G_ADDITIONAL_DATA. 170 | P a g e Santosh P

To check whether CUSTOMER_ADD_DATA is a BADI (OR) NOT go to SE18.

SE18:

Double click on IF_EX_CUSTOMER_ADD_DATA.

171 | P a g e

Santosh P

It will take u to BADI INTERFACE.

Double click on 67.

Double click on G_ADDITIONAL_DATA_CS.

172 | P a g e

Santosh P

SE18:

Double click on IF_EX_CUSTOMER_ADD_DATA_CS.

It will take u to BADI INTERFACE.

173 | P a g e

Santosh P

Double click on 84.

Double click on G_ADDITIONAL_DATA_CS.

SE18:

174 | P a g e

Santosh P

Double click on IF_EX_CUSTOMER_ADD_DATA.

It will take u to BADI INTERFACE.

175 | P a g e

Santosh P

Technique 2: SE38:

176 | P a g e

Santosh P

SE84:

177 | P a g e

Santosh P

Technique 3: ST05:

178 | P a g e

Santosh P

Open new Session and make changes in the Transactions. T-Code: XD01

179 | P a g e

Santosh P

Enter.

180 | P a g e

Santosh P

Back to ST05 Session.

181 | P a g e

Santosh P

182 | P a g e

Santosh P

Note: Before BADI implementation. We must check for any active implementation. 183 | P a g e Santosh P

SE18:

Implementing Standard BADIs: IN 4.7:

184 | P a g e

Santosh P

BADI Definition BADI Interface BADI Class

: CUSTOMER_ADD_DATA : IF_EX_CUSTOMER_ADD_DATA : CL_EX_CUSTOMER_ADD_DATA

We go through the Documentation.

185 | P a g e

Santosh P

186 | P a g e

Santosh P

SE19: BADI Implementation.

187 | P a g e

Santosh P

In Interface Tab.

Double click on CHECK_ALL_DATA.

BACK. ACTIVATE.

188 | P a g e

Santosh P

XD01:

189 | P a g e

Santosh P

Enter.

190 | P a g e

Santosh P

Note: If the T-code has Customer-Exits & BADI, First Customer-Exit will execute. Whenever a BADI is triggered SAP makes use of BADI Class to identify the list of active and inactive implementation. Based on this information SAP execute all the active implementation one after the other.

191 | P a g e

Santosh P

192 | P a g e

Santosh P