Wednesday, May 27, 2015

SAP ABAP ALE IDOC 2

SAP ABAP  ALE IDOC 2
  1. Steps to create a ALE system:
    1. Go to transaction SALE.
    2. Name a logical system. (<server_name>CLNT<client_number>)
      • S21CLNT800
    3. Assign logical system to the client.
      • Sender S21
    4. DO both the above steps in target system too. create a logical system and assign this to a client.
    5. Go to transaction SM59 in source system, to create an RFC connection to the target system.
    6. Test the connection and test remote login.
    7. Create a Port using transaction WE21.
    8. Goto transaction BD64 to create model view. (only if you have two different systems)
      • Add message type
      • create partner peofile
    9. GO to transaction BD10 to send a material (MATMAS)
    10. in target system goto transaction BD11 and check the same material you going to receive.
    11. BD12 to send a customer.
    12. BD13 to get a customer.
    13. BD87 to process Idocs which are in error.
    14. WE19 is a test tool for Idocs.
    15. WE09 to search data in Idoc segment.
    16. Function Module MASTER_IDOC_DISTRIBUTE to create an outbound Idoc in your system.
=============================================================
Common steps :

1) Define Logical system @ sender (SALE)  : S21CLNT811
   S21CLNT800

In any distributed environment, each participating system must have a unique ID to avoid confusion. In SAP, the name of the logical system is used as the unique ID. This name is assigned explicitly to one client in an SAP system.

2) Assign Logical system to Client (SALE) : Client 811 IDES-ALE: Production
           Client 800 Sender S21
3) Configuration of RFC connection (SM59) : RFC Destination     S21CLNT811 
   RFC Destination     S21CLNT800
4) Test Connection (SM59).
5) Creating RFC ports (WE21): A000000077
A000000079
=============================================================

=============================================================

For example two clients in the same R/3 instance.

Client 900 = 800 source system   table ZDC_HBHT_IDOC_2 with data

Client 800 = 811 reciever system table ZDC_HBHT_IDOC_2 without data


To transfer the data between two clients the table structures and their data types should be match.  

In this example, Client 900 is Source system, and Client 800 is destination system.

In Client 900 I have created a customized table and inserted some records.

In Client 800 I have created only table. 
=============================================================


Steps in Client 800:
1) Create Segment ( WE31 )      : ZSEG_HT
2) Creating Basic IDOC Type ( WE30 )      : ZIDC_HB 
3) Realease Basic Type IDOC ( WE30 Menu ) : 
4) Creating message Type   ( WE81 )      : ZMSG_HT
5) Assign Message Type to Basic IDOC Type (WE82) :   
6) Creating Model View and Distributing and Generating Partner profile (WE20) (BD64): ZMV_HBHT 
Target system S21CLNT811                  
Model view ZMV_HBHT has been created
7) Partner : S21CLNT811

8) Create reportZ_HBHT_TEST_IDOC_SENDER      : Idoc Generated 0000000001037851

=============================================================
Steps in Client 811:
1) Create a function module      : Z_HBHT_IDOC_RECIEVER
2) Assign FM to Logical Message (WE57): Z_HBHT_IDOC_RECIEVER Function module ZIDC_HB ZMSG_HT Inbound Message Type
3) Define Input Method for Inbound Function Module              (BD51): Z_HBHT_IDOC_RECIEVER 2
4) Creating Process Code: (WE42): ZPCD
5) Generating the Partner Profile (BD64): Partner No. S21CLNT800
6) Transferring the IDOC control records from Client 900 to 800      : Idoc Generated 0000000001037852 in sender 
======================================================================


========================================================================
To communicate with each other. SAP has designed for R/3 systems its own communication tool IDocs, it is even possible, using a middle ware EDI system, to have R/3 system communicate by Idocs on its side, with an open system by XML files on the other side,

    1. Idoc segment  : A segment is a record, defined as such in the database vocabulary. There is no hierarchical structure within the segment.
    2. Sections: An Idoc is made of three sections. control data and status. control section have only single segment, whereas other two sections may have one or more segments.
      • Status section is not transported with the Idoc, only control and data sections are. status is taken from the last segment in the idoc status section.
        • Status
        • Message
      • Control section represents the header section of an Idoc, it contains information about both sender and receiver systems.
        • Idoc Number
        • Direction (1 for outbound , 2 for inbound)
        • Status : current status of Idoc.
        • Basic Type
        • Extension Type
        • Message Type
        • Sender or Receiver information
        • Port
        • Partner number
        • Partner Type (LS, KU, Vendor, ...)
        • SAP Release version number of the Idoc.
        • Output Mode : 2 for immediate sending , collective sending.
      • Data Section :it contains one or many segments which are arranged in hierarchical order. there is a concept of child and parent segment,  a child segment may not exist if there is not the parent segment.
        • Every segment of the data section must have character field format.
    3. Structure of interface:
      • A view of the distribution mode
      • No, one or many filters
      • A sending system
      • A receiving system
      • A message Type
      • For outbound process:
        • A port to emit to
        • An output mode
        • A packet size
        • A basic IDoc type
      • For inbound interface
        • A process code
    4. View of the distribution model is only obligatory if filters need to be applied. BD64.
    5. Message Type and Basic Idoc Type:
      • A message Type is conceptually represents nature of the Idoc.
      • MATMAS is a message type which belong to many Idoc Type Like MATMAS01, MATMAS02 etc..

    6. Partner profiles: Dealing with every interface which do not have filters.
========================================================================
Idoc Important tables:
  • EDCIM : extension Type
  • EDCIMT : Description for the Idoc Type
  • EDADMDEB : Storage of debugger setting
  • EDBAS : Basic Idoc Types
  • EDBAST : store the description for the basic Idoc Type
  • EDE1T : text table fro outbound process code
  • EDE2T : text table for inbound process code
  • EDE5T : Text table for error processing process code
  • EDE6T: text table for process code for inbound process code
  • EDID4 : Idoc data record fro ECC 4.0
  • EDIDD_OLD : Idoc data record
  • EDIDOT : Short description for I doc Type
  • EDIFCT : IDoc: Assignment of FM to log. message and IDoc type
  • EDIMSG : Output types and assignment to Idoc types
  • EDIPOA : Table for ALE port definition
  • EDIQI : Rfc queue for inbound Idoc
  • EDIQO : Rfc queue for outbound 
  • EDISDEF : Segment Definition for Idoc
  • EDP12: 
  • EDP13: Partner profiles (outbound ) 
  • EDP21 : Partner profiles ( Inbound ) 
  • TEDE1: Process code for output type
  • TEDE2: Process code for input type
========================================================================
Customizing an outbound Interface:
  1. Creation of a new segment type WE31
  2. Creation of new Idoc Basic Type WE30
  3. Creation of new message type WE81
  4. Association with message type to Idoc type : WE82
  5. Launch BD64 (display Distribution Model ) 
    1. Create distribution model
    2. Distribute the distribute model view
    3. Generate and manage partner profile
  6. BD59 : 
Integration of an inbound Idoc :
  1. BD51  : used to register to a function module.
  2. WE57 : function module integrated to a message type.
  3. WE42 : used to inbound process code integration 
  4. WE41 : used to outbound integration
4.1 Useful transactions for IDocs
BD87 : Status Monitor for ALE Messages
SALE : Display ALE Customizing
WE02 : Display IDoc
WE05 : IDoc Lists
WE09 : Search for IDoc in Database
WE19 : Test tool

4.2.1 Outbound IDocs statuses
Statut Description
0 Not used, only R/2
1 IDoc generated
2 Error passing data to port
3 Data passed to port OK
4 Error within control information of EDI subsystem
5 Error during translation
6 Translation OK
7 Error during syntax check
8 Syntax check OK
9 Error during interchange handling
10 Interchange handling OK
11 Error during dispatch
12 Dispatch OK
13 Retransmission OK
14 Interchange Acknowledgement positive
15 Interchange Acknowledgement negative
16 Functional Acknowledgement positive
17 Functional Acknowledgement negative
18 Triggering EDI subsystem OK
19 Data transfer for test OK
20 Error triggering EDI subsystem
21 Error passing data for test
22 Dispatch OK, acknowledgement still due
23 Error during retransmission
24 Control information of EDI subsystem OK
25 Processing despite syntax error (outbound)
26 Error during syntax check of IDoc (outbound)
27 Error in dispatch level (ALE service)
28 Not used
29 Error in ALE service
30 IDoc ready for dispatch (ALE service)
31 Error - no further processing
32 IDoc was edited
33 Original of an IDoc which was edited
34 Error in control record of IDoc
35 IDoc reloaded from archive
36 Electronic signature not performed (timeout)
37 IDoc added incorrectly
38 IDoc archived
39 IDoc is in the target system (ALE service)
40 Application document not created in target system
41 Application document created in target system
42 IDoc was created by test transaction

4.2.2 Inbound IDocs statuses
Status Description
50 IDoc added
51 Application document not posted
52 Application document not fully posted
53 Application document posted
54 Error during formal application check
55 Formal application check OK
56 IDoc with errors added
57 Test IDoc: Error during application check
58 IDoc copy from R/2 connection
59 Not used
60 Error during syntax check of IDoc (inbound)
61 Processing despite syntax error (inbound)
62 IDoc passed to application
63 Error passing IDoc to application
64 IDoc ready to be transferred to application
65 Error in ALE service
66 IDoc is waiting for predecessor IDoc (serialization)
67 Not used
68 Error - no further processing
69 IDoc was edited
70 Original of an IDoc which was edited
71 IDoc reloaded from archive
72 Not used, only R/2
73 IDoc archived
74 IDoc was created by test transaction

 ============================================================================================================
configuration of IDoc inbound process:

  • Follow the below steps.
    1. Go to NACE transaction
    2. Select V1 application and select OUTPUT TYPES
    3. Select the requred output type and double click on Processing routines.
    4. Enter Medium as DISTRIBUTION ALE, Program as RSNASTED and Routine as ALE_PROCESSING.
    5. Save it.

    Follow the below steps to configure the condition records:
    1. Go to NACE
    2. Select V1 application and select CONDITION RECORDS
    3. Select the requred output type and click on Condition records
    4. Selection screen will be displayed.
    5. Go for execution. In that screen enter the selection criteria. For eg Conditin record is based on Sales document type then
    Sales doc type = OR
    Funt = SP
    Partner -
    leave it blank. It means there is no restriction on partner numbers.
    Medium = A
    date/time = 4
    Lan = EN.
    Note: patner isleft blank means, the sales order of type OR can be send to all partners.
    6. .save it.

    Hope u did the ALE configuratins








Posted by at No comments:

Tuesday, May 26, 2015

SAP ABAP : ALE IDOC , EDI


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.

SAP ABAP : ALE IDOC , EDI
The interface concept of classical RFC system is based on basically two different strategies : RFC and data exchange through Idoc Message Documents. 
RFC makes direct and Synchronous calls of a program in a remote system.
BAPIs are a subset of RFC enabled functions modules in R/3 especially designed as API to the SAP object, or in other words : Function module officially released by SAP to be called from external world. 

What is an Idoc? Idocs are text encoded documents with a rigid structure that are used to exchange data between R/3 system and a foreign system. instead of calling a function in destination system data is fist packed into an Idoc and then sent to the receiving system, where it is analyzed and properly processed.
Therefore an Idoc transfer is always an asynchronous system. The significant difference between RFC and Idocs is that every action in Idocs is protocolled by R/3 and Idocs can be reprocessed in case of any error  in one of the message steps.

What is ALE and IDOC and EDI ? While Idocs have to understood as a data exchange protocol, EDI and ALE are typical use cases for Idocs. R/3 uses Idocs for both ALE and EDI to deliver data to the receiving system,
ALE is basically a scheduling mechanism that defines when and between which partners and what kind of data will be exchanged on a regular or event triggered basis. such a set up called ALE scenario. 
EDI  If we send data to an external partner, we generally speak of EDI, while ALE is a mechanism to reliable replicate data between trusting systems to store a redundant copy of the IDoc data.

when there is a conversion of data say a Purchase Order from your system to a sales order in the later system, then we use Idocs (or EDI). But when we wanted to send a Purchase order which is to be the same in the later system then we use ALE or BAPI.

The main difference between EDI and ALE, BAPI is in the transfer of data. For EDI the transfer of data is from IDoc's( Intermediate documents) to a flat file. Where as in ALE and BAPI it is from Memory to memory transfer.

Difference Between ALE and EDI :Normally we refer to EDI technology when a non SAP system is one of the communication channel. ALE communication occurs from the SAP side and EDI from the non-SAP side. IDOCs uses ALE and EDI to deliver the data to the receiving system. If the data needs to be exchanged between two SAP systems, then IDOC uses ALE technology . For the exchange of data between a SAP and Non SAP system, IDOC uses EDI subsystem to convert and deliver the data.

----------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------

What is EDI :
- EDI is electronic exchange of business documents between the computer systems of business partner using a standard format over a communication network.
EDI is also called paperless communication.

Typical EDI/IDOC Scenario:
1) Some ABAP transaction writes data in R/3 tables.
2) An external application request for this data.
3) An Idoc handler creates the Idoc and converts data to ASCII format.
4) An external program converts to international standards.
5) data is sent to the receiver via ftp, isdn etc.



----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

SAP ABAP YOU-TUBE :

Manufacturer ----Idoc--------> Distributor -------Idoc------> Sellers

Control Record/ data : EDIDC
DATA Record : EDIDD (structure) EDIDD_OLD (store data)
Status Record : EDIDS

Transactions:
  • WE02 or WE05 :  transaction for IDOC reporting in SAP ABAP, weather the IDOC is came to SAP or all the details about an IODC statuses.

  
  • How Idoc looks like :





  • Control record:






















  • Data Record and status Record: data send in Idoc is form of small segments. 



process:  Normally an middle ware converts SAP Idoc to XML format and send to the receiver target system.

IDOC_XML_DISPLAY : to display XML for an IDOC. IDOC also store data in hierarchical order as does the XML. so it is easy to have IDOC into XML format.

Why We need Idoc when we have BAPI , RFC :
- To do not have control in non SAP system every time.
- mapping not required in Idoc although it is in BAPI.
- Idoc has a unified structure for data transmission.

GENERAL INFORMATION FOR COMMON IDOC MESSAGE TYPES



IDOC TERMINOLOGIES:

==========================================
  1. IDOC (BASIC) Types (table EDBAS): (WE30)
    • Basic Types or Idoc Type defines the structure of IDOC. It contains data in other words.
    • It contains exact structure in which sequence data transferred form one system to other,
    • Each basic type describes standard Idoc segments, format of data fields and their size.
    • Basic type also defines number of segments and fields in an Idoc.
    • All the fields which are necessary for transmission of message for a particular business transaction are mapped in different segments. 
    • It also defines the structure and relationship of Idoc segments along with mandatory and optional segments.

  1. IDOC Extension :


    • Basic types contains all the standard fields that are necessary for carrying out a necessary transaction. However if any additional fields need to be sent to the partner we can make use of the Idoc Extension feature.
    • Idoc extension is extension of basic type and contains additional custom Idoc segements ad fields that are not available in the standard Idoc type.
  1. Idoc Segments: 
    • Idoc segments are actually contains data that needs to be send or receive from partner.
    • These segments contains the actual values that are sent as a part of transmission.
    • Parent and Child Segment:
      • Idoc Segments are called parent if it contains its own segment, and the dependent segment called the child segment.

  1. Inbound and Outbound Idoc:




    • Idoc Directions:
      • If the information is sent outside the system then the direction is outbox (1) and when it is received into the system then direction is inbox (2). 


  1. PARTNER:
    • Partner is the business partner with which the exchange of data through Idoc is placed. it can be vendor, customer or any other system. 
    • Depending on the direction of information in which the information is sent it plays the role of either sending partner or receiving partner. 
  1. Partner Type:
    • used to identify partners within the SAP system. 
    • Partner type is KU for customer, LI for VENDOR and LS for logical system.


  1. Message Type : (Table EDMSG) (TCODE WE82/WE81)
    • For which purpose Idoc going to fire.
    • Idoc Processing involves transmission or receipt of document in form of a message, each of which represents a document in SAP.
    • These documents can be Order, Shipment Confirmation, Advance shipping Notification, goods receipt, or invoice.
    • Message Type is associated with the Basic Idoc Type and defines kind of data or the document that is exchanging within the partner.

    • IDOC type defines the structure and format of the data that is being exchanged Message Type determines and process the various Outputs associated with an Application doc.

  1. PROCESS CODE: (WE41 & TEDE1 (Outbound) and WE42 & TEDE2 (Inbound) to display process code details)
    • The process code contains details of the function module that are used for the Idoc Processing. Process code can be linked to the Message type.
    • Process Codes are used in both ALE and EDI framework to identify the corresponding program : 
    • OUTBOUND : Process code acts as Selection programs
      INBOUND     : Process code acts as function modules.
    • Process Code is linked to the Function Module in SAP that converts application data into an IDoc. Standard function modules are provided by SAP for this conversion however these can also be customized as per business needs.
  1. PORT : 
    • IDOC port contains information about the way data is sent between the source and the target system.
    • The type of port defines the information contained within the port.
    • For example:
    •  Port Type Internet : contain IP address of the target system.
    • Port Type file : contains directory or file name information is maintained.
    • Port Type 'tRFC' : conatins the information about RFC destination of the target system.
      • For Idoc transmission using ALE 'tRFC' Port are used.
    1. PARTNER PROFILE MAINTENANCE (WE20) : 
        • Partner Profile must be maintained for all the business partners to whom we want to send or receive Idocs.
        • Partner profiles contain parameters for inbound and outbound processing of Idocs.
        • For each message type we can maintain inbound/outbound options, message control, post processing options and contact information within inbound and outbound parameters.




    1. Outbound Options (Outbound Parameters):
      • This involves sender/receiver port, Output mode and relation to Idoc type, i.e. Basic Idoc Type and Extension.



    1. Message Control (Outbound Parameters): 
      • This contains :
        • application for which IDoc will be created e.g. 'V3' = 'Billing' in Sales and Distribution (SD).
        • The message type of the application that will trigger the Idoc and
        • the process Code that will convert SAP Document to an Idoc.3
        • For example, if PO is to be sent to the Vendor 3018, then in the outbound option of the partner 3018 we need to maintain the message type LPH1 and link it to the Process Code ME14. So when message type LPH1 is triggered in the PO then an IDoc will be created for the partner vendor 3018.
      • Change Message Indicator : 

        • This indicates whether the Idoc is sent as a notification of change.
        • For Example : Purchase order change messages are  sent to vendor using EDI standard message type 860. separate message type should be triggered in the purchase order for PO change. and an additional line must be added in message control tab with change management indicator on.
    1. Inbound Options ( Inbound Parameters) :
      • For inbound options process code maintained in the inbound parameters only.
      • Idoc processing can be triggered by background program or immediately.
    1. POST PROCESSING (Inbound/Outbound Parameters):
      • In this option we have name or position (workflow details) of teh users or positions to which an error notification will be sent if an Idoc Processing fails.
    ===========================================================

    IDOC STRUCTURE AND RECORDS

    1. Structure : 
      • Divided into control record and data record and status record.
      • These records are stored in transparent tables of SAP , these tables are EDIDC , EDID4, EDIDS.
    1. Control record (EDIDC) :
      • It contains information such as :
        • Idoc Number
        • Direction (Inbound or outbound)
        • Status of Idoc
        • Basic Type 
        • Message Type
        • Partner (sSender/Reciever) (Port, Partner number, Partner Type)
        • Tiem Dat eopf creation of Idoc
    2. Data Record (EDID4) : 
      • It contains the details of Idoc segments.
      • Idoc segment has fields that contain the data necessary for posting the documents.
    3. Status Record (EDIDS):

      • Idoc status defines different processing status of the Idoc.
      • Idoc statuses are used to track the IDoc and its various States.
      • Different status numbers represent the Idoc status.
      • current status of teh Idoc present in control record.
      • Initial status number of Idoc is 
      • 64 for inbound and 
      • 01 or 30 for outbound.
      • successful status number is 
      • 53 for inbound and 
      • 16 for outbound Idocs. 

    SENDING AND RECEIVING IDOCS

    1. Triggering an outbound IDoc :

      • Can be triggered from the output message types of purchase orders, deliveries, invoices, Material Documents etc.
      • here are the different statuses of the outbound Idoc:
        • 01: IDoc generation successful
        • 30: IDoc is ready to be processed by IDoc Processing job
        • 03: IDoc data is passed to the Port
        • 18: IDoc successfully triggered EDI subsystem
        • 06: IDoc data translated to EDI format
        • 12: IDoc is dispatched successfully to the partner
        • 16: Partner has received the IDoc successfully


    2. Receiving an inbound Idoc: 
      • The initial status of an inbound IDoc is 64 and successful status is 53.
      • Different validation steps for inbound IDocs are explained below:
        • 50: IDoc received successfully in the system
        • 64: IDoc is ready to be processed by IDoc processing job
        • 53: Application document created and saved successfully. The document number can be found by expanding the status node 53

    IDOC PROCESSING


    1. AUTOMATIC/IMMEDIATE PROCESSING
      • In this case, IDoc are processed immediately as they generated or added in the system. The check “Transfer IDoc immediately” is selected in Outbound Options and “Trigger Immediately” is selected in Inbound Option. These checks are generally used when the real time information exchange is necessary between two systems.
    2. Manual Processing 
      • IDocs can also be manually processed using the TCODE BD87 in SAP.
    3. PROCESSING VIA BACKGROUND JOB
      • IDoc processing by background is the most preferred way of processing the IDocs. Following Programs are used from processing the IDocs using background job:
        • Report RBDAPP01 : Inbound IDocs
        • Report RSEOUT00 : Outbound IDocs
    4. Processing IDocs:

    Testing and Editing Idocs
    1. When an IDoc is edited the original IDoc information(backup) is saved in a New IDoc under status 70 (for inbound) / 33 (for outbound). 
    2. These IDoc stays in the system for reference only and cannot be processed. 
    3. The status of the edited IDoc becomes 69 (inbound) and 32 (outbound).
    4. Debugging of IDocs can be done using by copying the IDocs using TCode WE19.
    5. The newly generated IDoc can also be processed using BD87.

    Changing Idoc status
    1. Report RC1_IDOC_SET_STATUS can be used to change the status of IDoc. Status changes are generally needed to move an IDoc to status 68 – no further processing.
    2. Normally not allowed for all. (for Internal EHS Use Only)
    3. TCODE WE09: SEARCHING DATA IN IDOC SEGMENTS

    IDOC VALIDATIONS, COMMON IDOC ERRORS AND SOLUTION


    1. Though, the IDoc failure may not be related to any of the above mentioned reasons, the best way to find the IDoc error is to compare the existing IDoc with the good example. Good example IDoc can be easily searched with any of the IDoc search methods as described above.


    DOCUMENTATION FOR IDOC TYPES
    IDoc documentation can be found using TCODE WE60 and can be helpful to obtain information of the IDoc Type or its particular segment. It also provides information such as  mandatory and optional segments, minimum and maximum number of segments, etc.


    Archiving Tcode SARI (Archiving explorer).

     Important Transaction:

    1. WE20 : Partner profiles
    2. WE21 : Port in ABAP
    3. WE09 : searching data in Idoc segment


    Posted by at 1 comment:

    Friday, May 8, 2015

    SAP ABAP : RFC and BAPI

    http://www.erpgreat.com/abap/interview-question-on-bapi-rfc-abap-objects-tables.htm


    • BAPI are RFC enabled function modules. and BAPI are business object. you create a business object and then store this to your BOR (business object Repository).
    • BAPIs are provided to outside world so they can interact with SAP from non SAP system like JAVA etc.
    • in case of BAPI there is no direct system call from external system although in case of RFC it is a direct system call,
    • RFC cannot get or store data from/to SAP alone, to do this we must use BAPI,
    • RFC is a protocol used by SAP for remote communication.
    ========================================================================
    Function module  
    Difference between RFC and BAPI: 
    => BAPIs are RFC enabled function module. BAPI stands for business application programming interface. 
    => A BAPI is a function module which can be called remotely using RFC technology. 
    => BAPIs are function modules stored in a repository and released for public use. 
    => RFC is a methodology or protocol to used to call a function in R/3 system from a system external to R/3 and vice versa. 
    => RFC are the function modules which can be written by "programmers" for their particular requirement, these don't come as "package" as in case of BAPIs where they are already available readily. 
    Types of RFC: 
    => Synchronous RFC: RFC call require both the systems to be available at time of the call. calling system wait for the called system to complete its execution before going further to the execution. 
    =>Asynchronous RFC:  
    The called function must be present during the call. 
    Function control returns to the calling program directly after the call. 
    The parameters of asynchronous RFCs are not logged to the database, but sent directly to the server. 
    Asynchronous RFCs allow the user to carry on an interactive dialog with the remote system. 
    When the caller starts an aRFC, the called server must be available to accept the request. 
    The calling program can receive results from the asynchronous RFC. 

    Using aRFC is always a good idea when real-time communication is established with a remote system, where processing in the calling program should not be interrupted until the results of the called function module have been obtained (the term asynchronous is used in this sense here). 

    => Transactional RFC:  
    The remote system need not be available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique transaction ID (TID ). 
    If a call is sent, and the receiving system is down, the call remains in the local queue until a later time. The calling dialog program can proceed without waiting to see whether or not the remote call was successful. If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch. 

    Disadvantage : tRFC uses LUW to process all the request if target system is not available. so we cannot guarantee that all the request should be executed in the same sequence as they are called from the calling system. Many LUW much heavy process. 
    => Queued RFC:  
    To guarantee that multiple LUWs are processed in the order specified by the application, tRFC can be serialized using queues (inbound and outbound queues). This type of RFC is called queued RFC (qRFC). 
    qRFC is therefore an extension of tRFC. It transfers an LUW (transaction) only if it has no predecessors (based on the sequence defined in different application programs) in the participating queues. 
    Implementation of qRFC is recommended if you want to guarantee that several transactions are processed in a predefined order. 

    => Background RFC: 
    bgRFC is the successor to tRFC and qRFC, with significant improvements in terms of performance and functionality. 


    ========================================================================
    Posted by at No comments:
    Subscribe to: Posts (Atom)