RFC

What is RFC?

A Remote Function Call(RFC) is a call to a function module running in a system different from the caller’s. The remote function can also be called from within the same system (as a remote call).The RFC interface provides the ability to call remote functions.
RFC consists of two interfaces :

1. A calling interface for ABAP Programs
2. A calling interface for Non-SAP programs.

Any ABAP program can call a remote function using the CALL FUNCTION…DESTINATION statement. The DESTINATION parameter tells the SAP System that the called function runs in a system other than the caller’s.

Syntax-
CALL FUNCTION ‘remotefunction’
DESTINATION dest
EXPORTING f1 =
IMPORTING f2 =
TABLES t1 =
EXCEPTIONS

Logical Destinations are defined via transaction SM59 and stored in Table RFCDES
Functions of the RFC interface

• Converting all parameter data to the representation needed in the remote system
• Calling the communication routines needed to talk to the remote system.
• Handling communications errors, and notifying the caller, if desired ( using EXCEPTIONS paramater of the CALL FUNCTION).

Types of RFC

1. Synchronous RFC – The calling program continues the execution only after the called function is complete.
2. Asynchronous RFC – The calling program continues the execution without waiting for return from the called function.
3. Transactional RFC - The called function module is executed exactly once in the RFC target system.Each function call is seen as a transaction in the target system. Transactional RFCs use the suffix IN BACKGROUND TASK . Eg : CALL FUNCTION ‘remotefunction’ IN BACKGROUND TASK

How to Code an RFC ?

1.In the function module attributes tab (transaction code SE37), set the processing type as Remote-enabled module to create a remote function module.

2.Write the code for the function module.

3.Define the destination of the RFC server in the RFC client system that calls the remote function ( via SM59 transaction).

4.Declaring Parameters: All parameter fields for a remote function module must be defined as reference fields, that is, like ABAP Dictionary fields.
5.Exceptions: The system raises COMMUNICATION_FAILURE and SYSTEM_FAILURE internally. You can raise exceptions in a remote function just as you would in a locally called function.

Debugging Remote Function Calls

• It is not possible to debug a remote function call to another system.
• However, when testing ABAP-to-ABAP RFC calls, you can use the ABAP debugger to monitor the execution of the RFC function in the remote system.
• With remote calls, the ABAP debugger (including the debugging interface) runs on the local system. Data values and other run information for the remote function are passed in from the remote system.

IDOC:Definition, Architecture, Implementation

What is an IDOC?

IDOC is simply a data container used to exchange information between any two processes that can understand the syntax and semantics of the data.
In other words ,an IDOC is like a data file with a specified format which is exchanged between 2 systems which know how to interpret that data.
IDOC stands for ” Intermediate Document”
When we execute an outbound ALE or EDI Process, an IDOC is created.
In the SAP System, IDOCs are stored in database.Every IDOC has an unique number(within a client).
Key Features

• IDOCs are independent of the sending and receiving systems.(SAP-to-SAP as well as Non-SAP)
• IDOCs are based on EDI standards, ANSI ASC X12 and EDIFACT. In case of any conflict in data size, it adopts one with greater length.
• IDOCs are independent of the direction of data exchange e.g. ORDERS01 : Purchasing module : Inbound and Outbound
• IDOCs can be viewed in a text editor. Data is stored in character format instead of binary format.

Structure of an IDOC

The Idoc structure consists of 3 parts -

1. The administration part(Control Record)- which has the type of idoc,message type, the current status, the sender, receiver etc. This is referred to as the Control record.
2. The application data (Data Record) – Which contains the data . These are called the data records/segments.
3. The Status information (Status Record)- These give you information about the various stages the idoc has passed through.

You can view an IDOC using transaction WE02 or WE05

As seen in screenshot above IDOC record has three parts Control , Data and Status. Lets look into them in detail -
Control Record

• All control record data is stored in EDIDC table. The key to this table is the IDOC Number
• It contains information like IDOC number, the direction(inbound/outbound),  sender, recipient information, channel it is using, which port it is using etc.
• Direction ’1′ indicates outbound, ’2′ indicates inbound.

Data Record

• Data record contains application data like employee header info, weekly details, client details etc
• All data record data is stored in EDID2 to EDID4 tables and EDIDD is a structure where you can see its components.
• It contains data like the idoc number, name and number of the segment in the idoc, the hierarchy and the data
• The actual data is stored as a string in a field called SDATA, which is a 1000 char long field.

Status Record

• Status record are attached to an IDOC at every milestone or when it encounter errors.
• All status record data is stored in EDIDS table.
• Statuses 1-42 are for outbound while 50-75 for inbound

IDOC Types

An IDOC Type (Basic) defines the structure and format of the business document that is to be exchanged. An IDOC is an instance of an IDOC Type , just like the concept of variables and variables types in programming languages. You can define IDOC types using WE30

What is a Segment?

Segment defines the format and structure of a data record in IDOC. Segments are reusable components.
For each segment SAP creates

• Segment Type (version independent)
• Segment Definition (version dependent)
• Segment Documentation

The last 3 characters is the version of the segment
Definitions keep changing as per the version but the segment type remains the same.
Transaction :WE31

What is Extension IDOC type ?

An IDOC is of 2 types:-

1. Basic
2. Extension

SAP provides many a pre-defined Basic IDOC Types which can not be modified. In case you want to add more data to these restricted basic type  you may use an extension type. Most of the times you will NOT use extension.

Documentation

Each IDOC are thoroughly documented in transaction WE60

Message Type

A message represents a specific type of document that is transmitted between two partners Ex. Orders,orders responses,invoices etc
An idoc type can be associated with many message types
Also a message type can be associated with different idoc types. Transaction WE81

IDOC Views

An IDOC type can be used for more than one message type, which results in IDOCs containing more fields than required for a particular message type.
IDOC views are used to improve performance in generating IDOCs to ensure only the relevant segments are filled with data. IDOC Views are important only for Outbound Processing.

Partner Profiles

A partner is defined as a business partner with whom you conduct business and exchange documents
In the partner profile of a partner that we exchange Idocs with, we maintain the parameters that are necessary for exchanging the data. The transaction used is WE20.

Port

The port defines the technical characteristics of the connection between your SAP system and the other system you want to transfer data with (subsystem). The port defines the medium in which data is exchanged between the 2 systems.
There are different types of ports. The 2 most commonly used are the TRFC ports used in ALE  and File ports which EDI uses.
For TRFC ports we have to give the name of the logical destination created using SM59.
When using file port you can specify the directory where the IDOC file should be placed. The other system or the middleware will pick up the file from here. The Function module can be used to generate a file name for the idoc. While testing you can use “Outbound file” to specify a constant file name. The tab “outbound trigger” can be used to supply information if we want to trigger some processing on the subsystem when an idoc is created at this location. We have to specify the command file name and the directory which has to be run.

This is so CONFUSING!

Lets understand the process of creating an IDOC with an example -

• Whenever a Purchase Order (PO) is created we want to send the IDOC to a vendor.
• The PO is sent in the form of an IDOC to the vendor (partner). That partner has to be EDI enabled in that system. SAP should realize that it could send doc to this vendor electronically.
• The PO sent as an outbound idoc by the customer will be inbound idoc for the vendor. The SAP system on the vendors side can process this to create an application document (a sales order) on their system.
• Quotation, RFQ, PO, SO, Invoice, delivery note etc are some of the commonly exchanged documents through IDOC

The process of data transfer out of your SAP system is called the Outbound process , while that of data moving into you SAP system is called Inbound process. As a developer or a consultant who will be involved in setting up theses process for your organization. Here are the steps how to set them up-

The Outbound Process

Steps Involved -

1. Create segments(WE31)
2. Create an idoc type(WE30)
3. Create a message type (WE81)
4. Associate a message type to idoc type(WE82)
5. Create a port(WE21)
6. If you are going to use the message control method to trigger idocs then create the function module for creating the idoc and associate the function module to an outbound process code
7. Otherwise create the function module or stand alone program which will create the idoc
8. Create a partner profile(WE20) with the necessary information in the outbound parameters for the partner you want to exchange the idoc with.Trigger the idoc.

The Inbound Process

Steps Involved-

1. Creation of basic Idoc type (Transaction WE30)
2. Creating message type (Transaction WE81)
3. Associating the Message type to basic Idoc type (Transaction WE82)
4. Create the function module for processing the idoc
5. Define the function module characteristics (BD51)
6. Allocate the inbound function module to the message type(WE57)
7. Defining process code (Transaction WE42)
8. Creation of partner profile (Transaction WE20)

What is EDI ,ALE and iDOC?

EDI, stands for Electronic Data Interchange, is the electronic exchange of structured business data between different applications.
EDI Architecture

EDI Architecture consists of -

1. EDI-enabled applications :They support the automatic processing of business transactions.
2. The IDoc interface: This was designed as an open interface. The IDoc interface consists of IDoc types and function modules that form the interface to the application.
3. The EDI subsystem: This converts the IDoc types into EDI message types and vice versa. This component of the EDI architecture is not supplied by SAP.

Advantages of EDI process

• Reduced data Entry Errors
• Reduced Processing cycle time
• Availability of data electronic form
• Reduced Paper Work
• Reduced Cost
• Reduced Inventories and Better Planning
• Standard Means of Communicating
• Better Business Processes
• Competitive Advantage

What is ALE ?

ALE supports the distribution of the business functions and process across loosely coupled SAP R/3 systems (different versions of SAP R/3). Connections from R/2 and non SAP systems is also supported.
ALE supports-

• Distribution of applications between different releases of R/3 Systems
• Continued data exchange after a release upgrade without requiring special maintenance
• Customer-specific extensions.
• Communication interfaces that allow connections to non-SAP systems.
• Coupling of R/3 and R/2 Systems.

Difference between ALE and EDI ?

ALE is used to support distributed yet integrated processes across several SAP systems whereas EDI is used for the exchange of business documents between the systems of business partners (could be non-SAP systems)
ALE is SAP’s technology for supporting a distributed environment whereas EDI is a process used for exchange of business documents which now have been given a standard format
Both ALE and EDI require data exchange. An Idoc is a data container which is used for data exchange by both EDI and ALE processes.

What is IDOC?

IDOC is simply a data container used to exchange information between any two processes that can understand the syntax and semantics of the data.
In simple words , an idoc is like a data file with a specified format which is exchanged between 2 systems which know how to interpret that data.
IDOC stands for ” Intermediate Document”
When we execute an outbound ALE or EDI Process, an IDOC is created.In an inbound ALE or EDI process, an IDOC serves as input to create an application document.In the SAP System, IDOCs are stored in database.Every IDOC has an unique number(within a client).
IDOCs are based on EDI standards, ANSI ASC X12 and EDIFACT. In case of any conflict in data size, it adopts one with greater length. IDOCs are independent of the direction of data exchange e.g. ORDERS01 : Purchasing module : Inbound and Outbound.IDOCs can be viewed in a text editor. Data is stored in character format instead of binary format.IDOCs are independent of the sending and receiving systems.(SAP-to-SAP as well as Non-SAP)

SAP BDC – Batch Data Communication

This tutorial will cover the following topics-

1. Introduction to BDC.
2. Method of Batch Input.
3. Batch Data Procedures.
4. Writing BDC programs.
5. Creating Batch input Session.
6. Batch Input Recording.

Lets Begin!

Introduction to Batch input

Batch input is typically used to transfer data from non-R/3 systems to R/3 systems or to transfer data between R/3 systems.
It is a data transfer technique that allows you to transfer datasets automatically to screens belonging to transactions, and thus to an SAP system. Batch input is controlled by a batch input session.
Batch input session
Groups a series of transaction calls together with input data and user actions . A batch input session can be used to execute a dialog transaction in batch input, where some or all the screens are processed by the session. Batch input sessions are stored in the database as database tables and can be used within a program as internal tables when accessing transactions.
Points to note

• BDI works by carrying out normal SAP transactions just as a user would but it execute the transaction automatically.All the screen validations and business logic validation will be done while using Batch Data Input.
• It is suitable for entering large amount of data.
• No manual interaction is required

Methods of Batch Input

SAP provide two basic methods for transferring legacy data in to the R/3 System.

1. Classical Batch Input method.
2. Call Transaction Method.

Classical Batch Input method
In this method an ABAP/4 program reads the external data to the SAP System and stores in a batch input session.
After creating the session, you can run the session to execute the SAP transaction in it.
This method uses the function modules BDC_ OPEN, BDC_INSERT and BDC_CLOSE
Batch Input Session can be process in 3 ways

1. In the foreground
2. In the background
3. During processing, with error display

You should process batch input sessions in the foreground or using the error display if you want to test the data transfer.
If you want to execute the data transfer or test its performance, you should process the sessions in the background.
Points to note about Classical Batch Input method

• Asynchronous processing
• Transfer data for multiple transactions.
• Synchronous database update.
• A batch input process log is generated for each session.
• Session cannot be generated in parallel.

Call Transaction Method.
In this method ABAP/4 program uses CALL TRANSACTION USING statement to run an SAP transaction.
Entire batch input process takes place online in the program

Points to Note:

• Faster processing of data
• Synchronous processing
• Transfer data for a single transaction.
• No batch input processing log is generated.

Batch Input Procedures

You will typically observe the following sequence of steps to develop Batch Input for your organization

1. Analysis of the legacy data. Determine how the data to be transferred is to be mapped in to the SAP Structure. Also take note of necessary data type or data length conversions.
2. Generate SAP data structures for using in export programs.
3. Export the data in to a sequential file. Note that character format is required by predefined SAP batch input programs.
4. If the SAP supplied BDC programs are not used, code your own batch input program. Choose an appropriate batch input method according to the situation.
5. Process the data and add it to the SAP System.
6. Analyze the process log. For the CALL TRANSACTION method, where no proper log is created, use the messages collected by your program.
7. From the results of the process analysis, correct and reprocess the erroneous data.

Writing BDC program

You may observe the following process to write your BDC program

1. Analyze the transaction(s) to process batch input data.
2. Decide on the batch input method to use.
3. Read data from a sequential file
4. Perform data conversion or error checking.
5. Storing the data in the batch input structure,BDCDATA.
6. Generate a batch input session for classical batch input,or process the data directly with CALL TRANSACTION USING statement.

Batch Input Data Structure
Declaration of batch input data structure

DATA : BEGIN OF < bdc table>
OCCURS <occurs parameters>.
INCLUDE STRUCTURE BDCDATA.
DATA:END OF <bdc table>.

Field name            Type       Length          Description
PROGRAM              CHAR          8                         Module pool
DYNPRO                 NUMC        4                         Dynpro number
DYNBEGIN            CHAR         1                          Starting a dynpro
FNAM                      CHAR         35                       Field name
FVAL                       CHAR         80                       Field value
The order of fields within the data for a particular screen is not of any significance
Points to Note

• While populating the BDC Data make sure that you take into consideration the user settings. This is specially relevant for filling fields which involves numbers ( Like quantity, amount ). It is the user setting which decides on what is the grouping character for numbers E.g.: A number fifty thousand can be written as 50,000.00 or 50.000,00 based on the user setting.
• Condense the FVAL field for amount and quantity fields so that they are left aligned.
• Note that all the fields that you are populating through BDC should be treated as character type fields while populating the BDC Data table.
• In some screens when you are populating values in a table control using BDC you have to note how many number of rows are present on a default size of the screen and code for as many rows. If you have to populate more rows then you have to code for “Page down” functionality as you would do when you are populating the table control manually.
• Number of lines that would appear in the above scenario will differ based on the screen size that the user uses. So always code for standard screen size and make your BDC work always in standard screen size irrespective of what the user keeps his screen size as.

Creating Batch Input Session

1. Open the batch input session session using function module BDC_OPEN_GROUP.
2. For each transaction in the session:
   • Fill the BDCDATA with values for all screens and fields processed in the transaction.
   • Transfer the transaction to the session with BDC_INSERT.
3. Close the batch input session with BDC_CLOSE_GROUP

Batch Input Recorder

Batch input recorder (System > Services > Batch input > Recorder) records transactions which are manually entered and creates a batch input session which can be executed later using SM35.

• Begin the batch input recorder by selecting the Recording pushbutton from the batch input initial screen.
• The recording name is a user defined name and can match the batch input session name which can be created from the recording.
• Enter a SAP transaction and begin posting the transaction.
• After you have completed posting a SAP transaction you either choose Get Transaction and Save to end the recording or Next Transaction and post another transaction.
• Once you have saved the recording you can create a batch input session from the recording and/or generate a batch input program from the recording.
• The batch input session you created can now be analyzed just like any other batch input session.
• The program which is generated by the function of the batch input recorder is a powerful tool for the data interface programmer. It provides a solid base which can then be altered according to customer requirements.

All About ABAP Query

The ABAP Query application is used to create reports not already present in SAP system. It has been designed for users with little or no knowledge of the ABAP programming.
ABAP Query offers users a broad range of ways to define reports and create different types of reports such as basic lists, statistics, and ranked lists.
The ABAP Query comprises four components:

1. Queries
2. InfoSets
3. User Groups
4. Translation of Query

Lets look into them in detail:-

Queries

The Queries component is used by end users to maintain queries. One can create queries,change queries and execute queries. Transaction SQ01

InfoSets

InfoSets are special views of data sources. An InfoSet describes which fields of a data source can be reported on in queries. An InfoSet can be assigned to several roles or user groups.
Advantages-

• By creating InfoSets and assigning them to roles or user groups, the system administrator determines the range of reports that the individual application departments or end-users are able to generate using the SAP Query.
• End-users are able to work only with those InfoSets that are relevant to their particular area, as designated by the role or user group that they are assigned to.

USER Groups

The User Groups component is used to maintain user groups (from a security standpoint).
Users working in the same application are assigned to the same user group.It does not matter who actually defined a query in a user group. Every user assigned to the user group is able to execute the query.
Users in a user group need to have the necessary authorizations before they are able to change or redefine a query.
Every user in a system can be assigned to several user groups.

Translation/QUERY Component

A lot of texts are generated when defining queries, InfoSets, and user groups. These texts are displayed in the language that we chose when we log on to the SAP system.We can compare the text/languages using this component.

Data processing in Queries

Data can be processed and presented in 3 ways:-

1. BASIC LIST – Presents data in the order defined by the functional area ( supports sorting and summation ).
2. STATISTIC – Shows the statistical figures calculated from the basic data.
3. RANKED LIST – A ranked list is a specialization of a statistic. E.x. Top ten customers of a travel agency.

A query can have one  basic list , upto nine statistics and upto nine ranked lists.

CREATING A QUERY

Step 1. Goto SQ01. Give a name to the query and click on the Create button.

Step 2.Give the description of the query in the next screen. Specify the output length and select the processing option from the Further Processing Options box. The data can be displayed in various formats such as table, download to a file, and display in Word etc.

Step3. Click on the next screen, select the field group to be used.

Step4.Click on the next screen, select the fields you want displayed

Step5.On the next screen, select the selection fields and then chose one of the output types ( basic, statistics, ranked ) .
In each of the lists, you can select various options.( eg. Sort order of fields, change output length, column color,totals,page header, page footer etc. ) .

Step5. After providing all the above options you can save the query and execute it .

Note:
Transaction to Create/Maintain Infoset -SQ02
Transaction to Create/Maintain UserGroup -SQ03

User Exits

• User and Customer Exits
• BADI