How many types of mappings in sap xi

hi,
how many types of mappings in sap xi,what are there can u explain me
bye
phenix

hi suresh,
There are 4 types of mapping in XI
1. Graphical
2. XSLT
3. java
4. ABAP.
There is no hard and fast rule for using the mapping techniques. But, I will try to put things in the right perspective for you.
Graphical Mapping is used for simple mapping cases. When, the logic for your mapping is simple and straight forward and it does not involve any complex logic.
Java and XSLT mapping are used when graphical mapping cannot help you.
When the choice is between Java And XSLT, XSLT is simpler than java mapping and easier. But, it has its drawbacks. One among them being that you cannot use Java APIs and Classes in it. There might be cases in your mapping when you will have to perfrom something like a properties file look up or a DB lookup, such scenarios are not possible in XSLT and so, when you want to use some specific Java API's you will have to go for Java Mapping.
Java Mapping uses 2 types of parsers. DOM and SAX. DOM is easier to use with lots of classes to help you create nodes and elements, but , DOM is very processor intensive.
SAX parser is something that parses your XML one after the other, and so is not processor intensive. But, it is not exaclty easy to develop either.
For further info on each of the mapping, refer to these links,
Graphical Mapping,
http://help.sap.com/saphelp_nw04/helpdata/en/6d/aadd3e6ecb1f39e10000000a114084/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/43/c4cdfc334824478090739c04c4a249/content.htm
XSLT Mapping
http://help.sap.com/saphelp_nw04/helpdata/en/73/f61eea1741453eb8f794e150067930/content.htm
http://www.w3.org/TR/xslt20/
Java Mapping
http://help.sap.com/saphelp_nw04/helpdata/en/e2/e13fcd80fe47768df001a558ed10b6/content.htm
DOM parser API
http://java.sun.com/j2se/1.4.2/docs/api/org/w3c/dom/package-frame.html
Also, check this thread for more info,
Different types of Mapping in XI
Regards,
Bhavesh

Similar Messages

  • How many types of projects exist in sap bw

    i heard that there are two types of projects
    1.implementation project
    2.support project
    and what about up gradation project, migration project, and i want to know what all the projects exists and there processes..
    if not possible please provide the link to navigate me to there

    sb92075 wrote:
    how many types of searching is in dbms ?42(What was the question, again? ;-) )
    Learn something new every day. I thought there were only 2 - successful (aka correct) and failed (aka wrong).

  • How many types of inbound process r there

    how many types of inbound process r there for a inbound idoc?

    Hi,
    Creating an Inbound Process Code
    The inbound process code, that is, its attributes, indicates how an inbound IDoc is processed. A process code has the following attributes:
    ·        Processing type (for example, should the inbound function module be called immediately, or should a workflow or work item be started?);
    Standard: "ALE, function module called directly"
    ·        Name of inbound function module;
    ·        Error processing attributes (objects and events; see the section on objects, and so on, for error handling);
    ·        Application object type used for ALE links;
    ¡        the object type created or changed by the inbound function module. Example: An inbound ORDERS IDoc, containing a customeru2019s purchase order, creates a customer order in the receiving SAP System. Here the application object type is BUS2032, the object type for customer orders in the BOR (Business Object Repository).
    ·        The application event to be triggered (dealt with in the section on advanced techniques) is not generally used.
    For an example, have a look at the process code MATM used for material master data.
    Reward If Helpfull,
    Naresh

  • How many types of transactions in ABAP

    How many types of transactions in ABAP

    Hi,
    Transactions
    The normal way of executing ABAP code in the SAP system is by entering a transaction code. Transactions can be accessed via system-defined or user-specific, role-based menus. They can also be started by entering their transaction code (a mnemonic name of up to 20 characters) in the special command field, which is present in every SAP screen. Transactions can also be invoked programmatically by means of the ABAP statements CALL TRANSACTION and LEAVE TO TRANSACTION. Transaction codes can also be linked to screen elements or menu entries. Selecting such an element will start the transaction. The term "transaction" must not be misunderstood here: in the context just described, a transaction simply means calling and executing an ABAP program. In application programming, "transaction" often refers to an indivisible operation on data, which is either committed as a whole or undone (rolled back) as a whole. This concept exists in SAP but is there called a LUW (Logical Unit of Work). In the course of one transaction (program execution), there can be different LUWs.
    Letu2019s have a look at the different kind of transactions:
    Dialog transaction
    These are the most common kind of transactions. The transaction code of a dialog transaction is linked to a Dynpro of an ABAP program. When the transaction is called, the respective program is loaded and the Dynpro is called. Therefore, a dialog transaction calls a Dynpro sequence rather than a program. Only during the execution of the Dynpro flow logic are the dialog modules of the ABAP program itself are called. The program flow can differ from execution to execution. You can even assign different dialog transaction codes to one program.
    Parameter transaction
    In the definition of a parameter transaction code, a dialog transaction is linked with parameters. When you call a parameter transaction, the input fields of the initial Dynpro screen of the dialog transaction are filled with parameters. The display of the initial screen can be inhibited by specifying all mandatory input fields as parameters of the transaction.
    Variant transaction
    In the definition of a variant transaction code, a dialog transaction is linked with a transaction variant. When a variant transaction is accessed, the dialog transaction is called and executed with the transaction variant. In transaction variants, you can assign default values to the input fields on several Dynpro screens in a transaction, change the attributes of screen elements, and hide entire screens. Transaction variants are maintained in transaction SHD0.
    Report transaction
    A report transaction is the transaction code wrapping for starting the reporting process. The transaction code of a report transaction must be linked with the selection screen of an executable program. When you execute a report transaction, the runtime environment internally executes the ABAP statement SUBMITu2014more to come on that.
    OO transaction
    A new kind of transaction as of release 6.10. The transaction code of an OO transaction is linked with a method of a local or global class. When the transaction is called, the corresponding program is loaded, for instance methods an object of the class is generated and the method is executed.
    Reward Points if found helpfull..
    Cheers,
    Chandra Sekhar.

  • How many types of reports we can see in BI..?

    Hi
    I am new to BI
    How many types of reports we can see in BI..?
    I got some here like
    1) COPA reports
    2) Costbased reports
    3) Artist p& L
    4) HMF test...export active sheet....export shole wb..
                          Upload
    PABEL
    NPS...
    i wanted to know what is PABEL
    NPS...etc..? how many are there...?
    please help me guys..
    thanks for any information,,
    praveen.

    Hello,
    Not sure what all of those are so you likely need to post your question to one of the classic SAP Forums:
    http://forums.sdn.sap.com/index.jspa?categoryID=1#16
    Or
    http://forums.sdn.sap.com/index.jspa?categoryID=1#44
    Thank you
    Don

  • How many types of rfc there

    hi guru
    how many types of rfc there
    thanks
    subhasis

    Hi Subhasis  ,
      There are 5 types of RFC.
    Here is a link to a very good documnet on RFC
    <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f078394a-4469-2910-c4bf-853c75674694">RFC Document</a>
    Regards
    Arun

  • How many types of RFC's?

    how many types of rfc's wat r they?

    hi
    A remote function call 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).
    RFC consists of two interfaces : A calling interface for ABAP Programs and 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.
    RFC CLIENT and RFC SERVER
         RFC client is the instance that calls up the Remote Function Call to execute the function that is provided by an RFC server.
         The RFC Interface takes care of :-
      -  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).
    You can use the CALL FUNCTION statement to call remote functions by including an additional DESTINATION clause.
    CALL FUNCTION ‘remotefunction’
              DESTINATION dest   
                   EXPORTING f1 =
                 IMPORTING  f2 =
               TABLES t1 =
               EXCEPTIONS
    The field ‘dest’ can be either a literal or a variable. Logical destinations are defined in the RFCDES table via transaction SM59 or via the menu path: Tools ->Administration,Administration->Network->RFC destinations.
    Calling remote functions locally :-
    ( i.e. call a remote function within the same system )
    The two options to do this are –
    CALL FUNCTION...DESTINATION = 'NONE'
    CALL FUNCTION... [no DESTINATION used]
    Calling remote function modules BACK :-
        The remote function can invoke its own caller (if the caller is itself a function module), or any function module loaded with the caller.
        You can trigger this call-back mechanism   using
        CALL FUNCTION... DESTINATION 'BACK‘.
    Synchronous RFC – The calling program continues the execution only after the called function is complete.
    Asynchronous RFC - The calling program continues the execution without waiting for return from the called function.
           Eg: CALL FUNCTION ‘remotefunction’ STARTING NEW TASK ‘taskname’.
    Transactional RFC - The called function module is executed exactly once in the RFC server 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
    regards
    vijay
    reward points if helpfull

  • How many types of user defined functions are there?

    how many types of user defined functions are there?

    Hi Ramakrishna,
    A user-defined function is only visible in the message mapping in which you created it. You can insert the function in the data-flow editor as a standard function by using the User-Defined function category.
    You can use the following user-defined functions:
    1.Simple functions, which can process individual field input values for each function call. Simple functions therefore expect strings as input values and return a string.
    2.Advanced functions, which can process several field input values for each function call. You can import either all field values of a context or the whole queue for the field in an array before calling the function. For more information, see Advanced User-Defined Functions.
        go through :
    http://help.sap.com/saphelp_erp2004/helpdata/en/22/e127f28b572243b4324879c6bf05a0/content.htm
         Advanced user-defined functions, which can process more than just individual field values.Instead, you can import a complete context or an entire queue for a field as an array before your function is called
        go through :
    http://help.sap.com/saphelp_erp2004/helpdata/en/f8/2857cbc374da48993c8eb7d3c8c87a/content.htm
    *Pls: Reward points if helpful*
    Regards,
    Jyoti

  • Re:How many types of application servers r there........

    Hi All,
        im  ramkumar new to SAP.pls tell me How many types of application servers r there........

    Hi ramkumar,
    refer this link
    http://help.sap.com/saphelp_nw2004s/helpdata/en/69/c24e034ba111d189750000e8322d00/frameset.htm
    /* reward points if it is useful */
    regards,
    kanagaraj.

  • How many types of internal tabels?

    hi all,
    how many types of internal tbels ,
    how they are differetiate ?
    regards.
    raj

    Hi,
    Three Types of Internal Table:
    1.Standard Table
    2.Sorted Table
    3.Hashed Table
    Standard Table - the most commonly used type of table.
    The key access to a standard table uses a sequential search. The time required for an access is linearly dependent on the number of entries in the internal table.
    You should usually access a standard table with index operations.
    You can sort and resort this table anytime. You can have duplicate records in them. Recommend that when accessing these tables, you sort them by a key and then READ via a BINARY SEARCH - better performance. When you write to this table the record is "appended" to the end of the table. In order to maintain the sort sequence (if any) you must use the SORT command again.
    Sorted table - this table has a defined sort sequence. You cannot resort. You can have duplicates.
    The table is always stored internally sorted by its key. Key access to a sorted table can therefore use a binary search. If the key is not unique, the entry with the lowest index is accessed. The time required for an access is logarithmically dependent on the number of entries in the internal table.
    Index accesses to sorted tables are also allowed. You should usually access a sorted table using its key.
    When you READ these tables, SAP automatically tries to use a BINARY SEARCH. Because you use a Binary Search, the retrieval time isexpodential to the number of records. When you write a record to this table the table is resorted.
    Hashed Table - this table has a defined key.
    The table is internally managed with a hash procedure. All the entries must have a unique key. The time required for a key access is constant, that is it does not depend on the number of entries in the internal table.
    When you write to the table it uses a hashing algorithm to identify where the record is stored (think if this as writing the location of a page in an index of a book). When you READ this table the system looks up this "index" and retrieves the record. Because of this the retrieval time is constant. Writing to this type of table takes the most time as it needs to calculate the hashing algorithm.
    Personally I generally use Standard Tables as they are the most flexible table available. It lets me resort my data anyhow I like any time I like. I very rarely use a Sorted Table.
    I use Hashed Tables as "buffer" tables. Let's say for example I want to retrieve HR data for a number of sales reps. To get HR data I need to use FM 'HR_READ_INFOTYPE'. This takes time. So what I do is read my hashed table to see if I have already got the data (very quick). If I don't have the data, I hit the FM and update my hashed table for next time. By using the hashed table in this way I reduce the number of FM calls I need to make.
    /people/harry.dietz/blog/2005/10/28/performance-improvement-hints-3-internal-table--fill-and-read
    http://www.sap-img.com/abap/what-are-different-types-of-internal-tables-and-their-usage.htm
    http://help.sap.com/saphelp_erp2005/helpdata/en/fc/eb35de358411d1829f0000e829fbfe/frameset.htm
    Regards,
    Padmam.

  • HOW MANY TYPES OF transportable requests?

    HOW MANY TYPES OF transportable requests?

    Hi,
    In R/3 Release 4.0, SAP has introduced the Change and Transport System (CTS), comprising the following tools:
    1. Change and Transport Organizers(CTO)
    2. Transport management system(TMS)
    The Change and Transport Organizer (CTO) provides functions for organizing software development projects. It is designed to support projects of all sizes, whether they are carried out centrally or in a distributed environment.
    The Transport Management System (TMS) organizes, monitors, and performs transports for allR/3 Systems within a system landscape. In addition, TMS is used to configure and manage the setting up of R/3 Systems and transport routes within a system landscape.
    The Transport Management System (Transaction STMS) enables you to:
    1. Define an R/3 System's role within a system landscape or transport domain
    2. Configure the transport routes using either a graphical editor or hierarchical editor
    3. Configure the transport tool transport control program tp.
    4. Display the import queues of all R/3 Systems in the transport domain
    5.Decide whether the quality assurance testing was successful in the QA System
    6.Start the import of change requests in an import queue
    The transports request can be of two types :
    1. Customizing
    2. Workbench
    Customizing adapts the R/3 software to meet a company's individual business requirements by setting up the business transactions the company requires in R/3.  Most Customizing is client-specific and affects only a particular client.
    Workbench - Development changes are saved to Workbench change requests. Workbench change requests concern changes to R/3 Repository objects, such as ABAP programs, screens, data dictionary objects and global documentation.
    To access the Workbench Organizer, use Transaction SE09
    For more details go through the following link :
    http://help.sap.com/erp2005_ehp_03/helpdata/EN/57/38e1824eb711d182bf0000e829fbfe/frameset.htm
    Thanks,
    Nitesh Jain

  • How many types of roadmaps?

    Hi
    How many types of roadmaps are there?
    What is the use of roadmaps?
    What are the substructures of the each phase?
    Message was edited by:
            Neni

    Hi Neni,
    all of the information you are looking for is here.
    http://service.sap.com/roadmaps
    Also, in the system if you create a project in SOLAR_PROJECT_ADMIN, click on the scope tab and the the Roadmap select tab and you can see what Roadmaps are available for you. The ST-ICO component determines which ones you have.
    The purpose of a roadmap is to give you an idea of the items you need to accomplish, milestones and accelerators to help you perform the task at hand.
    Look through the link above and then ask questions if you need more detail.
    regards,
    Jason

  • How many types of function modules are there

    hi gurus,
    how many types of function modules are there...
    what type of function module bapi  is....
    i don't know much about that...
    pls help me...
    regards,
    praveen

    hi
    hope it will help you.
    <REMOVED BY MODERATOR>
    Function Modules Used in Script:
    In the Driver Program we must use all or some of the function modules that are listed below to transfer the data.
    • Open_Form
    • Close_Form
    • Start_Form
    • Write_Form
    • Write_Form_Lines
    • End_Form
    • Control_Form
    • Read_Form_elements
    • Read_Form_Lines
    Any driver program must contain Open_Form, Close_Form and Write_Form. Other function modules are optional.
    OPEN_FORM: This function module opens layout set printing. One must call this function module before he uses any of other layout set function modules like Write_Form, Start_Form, Control_Form etc., You need specify a layout set name in the export parameters of this function module. If nothing is passed to Open_Form then one should use Start_Form function module to open layout set before starting the output. The layout set opened by Open_Form should be closed by Close_Form function module, other wise output doesn’t appear. We can use any number of Open_Form, Close_Form functions in one single program. But Close_Form must be there for every Open_Form in the program.
    Some of the important export parameters we have to pass to Open_Form function module.
    Form: Enter the Layout set name here, which then controls the output formatting. If nothing is specified then we must use Start_Form for opening layout set.
    Language: Layout sets are Language dependent. Enter the desired language here. If the entered layout set is not in that language, then the function tries to open the Form entered in its original language. The default value is SY-LANGU.
    Device: SAP Script can format a text on different device types. The device can be ‘PRINTER’ or ‘TELEX’, ‘TELEFAX’, ’ABAP’ and ‘SCREEN’.
    Dialog: Use parameter DIALOG to determine whether to display a dialog box before printing, in which the user can set several spool parameters for print formatting. Possible values: SPACE displays no print parameter screen. 'X' display print parameter screen. Default value: 'X'
    Options: Use parameter OPTIONS to set several options for print formatting. The parameter has the structure ITCPO. The user can change some of the defined settings on the print control screen. The default value for Options is ‘ ‘. We will discuss about ITCPO structure in detail later.
    Other Export, Import and Exceptions are self-explanatory.
    Close_Form: The function module closes the layout set opened using OPEN_FORM. The system executes any terminating processing steps for the last opened layout set. No Export parameters for this Function Module.
    Start_Form: In-between the function modules OPEN_FORM and CLOSE_FORM, we can use different layout sets. This allows us to combine several different layout sets into one print output. However, we can combine only those layout sets that have the same page format. To switch layout sets, use the function module START_FORM. If another layout set is still open, we must close it first using END_FORM. If we specify no layout set name when calling START_FORM, the system restarts the last open layout set. If after OPEN_FORM no layout set was activated yet, the system leaves the function module with the exception UNUSED. Some of the important export parameters for this function module are
    Form: The parameter contains the name of the layout set you want to use for printing. If you specify no layout set here, the system restarts the last active layout set.
    Language: Layout sets are language-dependent. Enter the desired language here. If the layout set does not exist in this language, the system tries to call the layout set in its original language. If the parameter LANGUAGE is empty, the system uses the language of the last active layout set.
    Startpage: Usually, SAP script starts with the page specified as start page in the layout set definition. If we want to start output with another layout set page, enter the name of the desired layout set page here. If the desired page is not defined, the system uses the start page defined in the layout set.
    Program: To replace program symbols, SAP script must know which active program contains the work areas for the values to be passed. If we omit the parameter, the system searches for the field values in the program that was specified in the parameter OPTIONS (field TDPROGRAM) of OPEN_FORM. If we enter a program name, the system replaces the program symbols with the values from this program up to the next END_FORM.
    Exceptions and other Export, Import parameters are self-explanatory.
    Write_Form: The system outputs the layout set element specified in parameter ELEMENT into the currently opened layout set. In the parameter WINDOW we can specify the name of a window for the output. Remember that the layout set element must be defined in this window. The parameter FUNCTION specifies how to merge the text lines to be output with any existing contents in the window. In this case, there are differences between the different window types or areas. Some of the important export parameters used in Write_Form.
    Element: Specify the name of the text element you want to output into the layout set window specified in the parameter WINDOW. The element must be defined in that layout set window. If you specify no element, the system uses the default element, if one is defined in the layout set.
    Window: Specify the name of the window into which you want to output the layout set element specified in the parameter ELEMENT. Default value for Window is ‘MAIN’.
    Function: The parameter determines how to output the text element into the respective window. The output type depends on the window type and area:
    Window Type: MAIN Area: BODY
    SET/APPEND: Appends to previous output.
    Window Type: Main Area: Top/Bottom and
    Window Type: Other than Main and all areas
    SET : Delete the old element contents and prints the new elements
    APPEND: Appends the new content to existing elements.
    Type: The system interprets this parameter only for output to the main window. The parameter determines the area of the main window into which we want to output the element. Possible values: 'TOP' header area
    'BODY' main area
    'BOTTOM' footer area
    Default value: 'BODY'
    Write_Form_Lines: This function module outputs the text lines in table LINES into the specified layout set window. The text lines must have the SAP script ITF format. From the data in the text header, the system uses only the field TDSTYLE to apply the formatting attributes defined in the specified style for this text. If the field is empty, the system uses the identically named formatting attributes (character and paragraph formats) of the layout set.
    Use parameter WINDOW to specify into which of the windows defined in the layout set we want to output the text. We can specify any window used in the layout set. The parameter FUNCTION determines how to merge the text lines to be output with any existing contents in the window. There are differences between the different window types or areas.
    Header: This parameter contains the header of the text module we want to output in the current layout set. For the formatting process, the system uses only the entries in the header fields TDSTYLE and TDFORM. Structure: THEAD
    WINDOW: Enter the name of the window into which we want to output the layout set element specified in parameter ELEMENT. Default value: 'MAIN'
    FUNCTION: This parameter determines how to output the text element into the respective window. The output type depends on the window type and area: Window type MAIN, area BODY: 'SET' append to previous output 'APPEND' same as SET. DELETE' no effect. Window type MAIN, areas TOP and BOTTOM; all other windows: 'SET' delete old window or area contents and output the element 'APPEND' append the element to the existing elements 'DELETE' no effect Default value: 'SET'
    TYPE: The system interprets this parameter only for output to the main window. The parameter determines the area of the main window into which you want to output the element. Possible values: 'TOP' header area 'BODY' main area 'BOTTOM' footer area Default value: 'BODY'
    END_FORM: END_FORM ends the currently open layout set and executes the required termination processing. After calling this function module, no more layout set is active. For further output, we must start a new layout set using START_FORM. No Export parameters.
    CONTROL_FORM: Use this function module to pass SAP Script Control Commands to the layout set. The Control command is passed through the export parameter ‘COMMAND’ in quotes.
    READ_FORM_ELEMENTS: This function module fills a table with all text elements that appear in one layout set. If we specify no layout set name, the system includes all elements of the currently open layout set. If we specify a layout set, the system uses the information about the active version of the layout set, retrieved from the database. Here we have two export parameters, Form and Language and a table parameter Elements.
    READ_FORM_LINES: Use this function module to transfer the lines of a layout set element into an internal table. If we specify no layout set name, the system transfers the text lines of the currently open layout set. If we specify a layout set, the system uses the text lines of the active version of the layout set from the database. The Export parameters are Form, Language, Window and Element. If we pass these 4 parameters the function module returns a table with the lines from layout set.
    Function modules are one element. There are no types. However sometimes an RFC enabled function module is referred to as RFC Function module, but really it is just a function module. Also BAPIs are function modules, but are usually referred to as just BAPI as opposed to BAPI Function module.
    There is no different function module types , but calling the function module will be different.
    check this function calls syntax
    1. Calls a function module:
    CALL FUNCTION func.
    2. Call a function module in a different mode (asynchronous Remote Function Call):
    CALL FUNCTION func STARTING NEW TASK taskname.
    3. Call a function module in the update task:
    CALL FUNCTION func IN UPDATE TASK.
    4. Call a function module in a remote system (Remote Function Call, RFC ):
    CALL FUNCTION func DESTINATION dest.
    5. Asynchronous call to a function module with transactional processing (transactional Remote Function Call):
    CALL FUNCTION func IN BACKGROUND TASK.
    qRFC with output queue
    6. Call a function module that can be activated in the context of enhancements:
    CALL CUSTOMER-FUNCTION func.
    Cheers,
    Chandru
    Edited by: Alvaro Tejada Galindo on Feb 27, 2008 11:53 AM

  • How many types of rfcs are there

    Hello,
    Can any body explain about how many type of rfcs are there. give the difference also.
    Thanks.

    Hi,
    Check this info.
    These are the types of RFC
    Asynchronous RFC (aRFC)
    Synchronous RFC (sRFC)
    Transactional RFC (tRFC)
    Queued RFC (qRFC)
    Parallel RFC (pRFC)
    Asynchronous RFC :
    This is used when you need to increase the performance of ABAP program by having system call more than one function module in parallel than forcing the program to wait for results .
    Transactional RFC
    This let you group one or more function module call together o tRFC LUW and ensure that fucnction module within LUW is called once . In contrast to aRFC and sRFC the tRFC belonging to tRFC LUW are executed in order .
    tRFC is always used if a function is executed as a Logical Unit of Work (LUW). Within a LUW, all calls are
    1.Executed in the order in which they are called
    2.Executed in the same program context in the target system
    3.Run as a single transaction: they are either committed or rolled back as a unit.
    Implementation of tRFC is recommended if you want to guarantee that the transactional order of the calls is preserved
    Asynchronous remote function calls (aRFCs) are similar to transactional RFCs, in that the user does not have to wait for their completion before continuing the calling dialog. There are three characteristics, however, that distinguish asynchronous RFCs from transactional RFCs:
    • When the caller starts an asynchronous RFC, the called server must be available to accept the request.
    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.
    • The calling program can receive results from the asynchronous RFC.
    You can use asynchronous remote function calls whenever you need to establish communication with a remote system, but do not want to wait for the function’s result before continuing processing. Asynchronous RFCs can also be sent to the same system. In this case, the system opens a new session (or window). You can then switch back and for between the calling dialog and the called session
    RECEIVE RESULTS FROM FUNCTION Remotefunction is used within a FORM routine to receive the results of an asynchronous remote function call. The following receiving parameters are available:
    IMPORTING
    TABLES
    EXCEPTIONS
    The addition KEEPING TASK prevents an asynchronous connection from being closed after receiving the results of the processing. The relevant remote context (roll area) is kept for re-use until the caller terminates the connection.
    Transactional RFC (tRFC) and Queued RFC (qRFC).
    tRFC is used mainly to transfer ALE Intermediate Documents (IDocs).
    Transactional RFC:
    If an error occurs during a synchronous remote function call, the system cannot tell at what point the error occurred (most crucially, whether the function module was actually processed in R/3 before the operation failed). Restarting a failed call is therefore a dangerous thing to do, since you risk duplicating a completed function call.
    To alleviate this problem, you can use transactional RFC, which guarantees that each function call you issue will only be executed once, even if you submit it repeatedly to the R/3 System. The system implements this safeguard by assigning a unique transaction ID (TID) to each transaction that you submit. When you attempt to process the transaction, the system checks whether that TID has already been processed. If it has, the transaction is ignored.
    Disadvantages of tRFC
    - tRFC processes all LUWs independent of one another. Due to the amount of activated tRFC processes, this procedure can reduce performance significantly in both the send and the target systems.
    - In addition, the sequence of LUWs defined in the application cannot be kept. Therefore, there is no guarantee that the transactions are executed in the sequence dictated by the application. The only guarantee is that all LUWs are transferred sooner or later.
    Queued RFC:
    When you use transactional RFC, you cannot guarantee the order in which the function calls will be processed in the system (it is quite possible that one call might overtake another). For cases where you need to specify a particular processing order, you can use queued RFC, which is an extension of transactional RFC. In qRFC, you place each function call in a logical queue. A function call cannot be executed until all of its predecessors in the queue have been processed. Queued RFC calls are processed asynchronously
    Therefore, Queued RFC is better than Transactional RFC.
    Remote Function Call:
    RFC is an SAP interface protocol. Based on CPI-C, it considerably simplifies the programming of communication processes between systems.
    RFCs enable you to call and execute predefined functions in a remote system - or even in the same system.
    RFCs manage the communication process, parameter transfer and error handling.
    http://help.sap.com/saphelp_47x200/helpdata/en/22/042860488911d189490000e829fbbd/frameset.htm.
    Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. The RFC calls a function to be executed in a remote system.
    Synchronous RFC:
    The first version of RFC is synchronous RFC (sRFC). This type of RFC executes the function call based on synchronous communication, which means that the systems involved must both be available at the time the call is made.
    Transactional RFC (tRFC) and Queued RFC (qRFC). tRFC is used mainly to transfer ALE Intermediate Documents (IDocs).
    Transactional RFC:
    If an error occurs during a synchronous remote function call, the system cannot tell at what point the error occurred (most crucially, whether the function module was actually processed in R/3 before the operation failed). Restarting a failed call is therefore a dangerous thing to do, since you risk duplicating a completed function call.
    To alleviate this problem, you can use transactional RFC, which guarantees that each function call you issue will only be executed once, even if you submit it repeatedly to the R/3 System. The system implements this safeguard by assigning a unique transaction ID (TID) to each transaction that you submit. When you attempt to process the transaction, the system checks whether that TID has already been processed. If it has, the transaction is ignored.
    Queued RFC:
    When you use transactional RFC, you cannot guarantee the order in which the function calls will be processed in the system (it is quite possible that one call might overtake another). For cases where you need to specify a particular processing order, you can use queued RFC, which is an extension of transactional RFC. In qRFC, you place each function call in a logical queue. A function call cannot be executed until all of its predecessors in the queue have been processed. Queued RFC calls are processed asynchronously
    For more information on RFC, please go through the link.
    http://help.sap.com/saphelp_nw04/helpdata/en/6f/1bd5b6a85b11d6b28500508b5d5211/content.htm
    Have a look at this link.
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE2/BCFESDE2.pdf
    http://help.sap.com/saphelp_47x200/helpdata/en/22/042860488911d189490000e829fbbd/frameset.htm.
    Rewords some points.
    Rgds,
    P.Nag

  • How many  types of joins are there?

    how many  types of joins are there?
    Edited by: Alvaro Tejada Galindo on Feb 21, 2008 4:58 PM

    Hi,
    Joins are used to fetch data fast from Database tables:
    Tables are joined with the proper key fields to fetch the data properly.
    If there are no proper key fields between tables don't use Joins;
    Important thing is that don't USE JOINS FOR CLUSTER tableslike BSEG and KONV.
    Only use for Transparenmt tables.
    You can also use joins for the database VIews to fetch the data.
    JOINS
    ... FROM tabref1 INNER JOIN tabref2 ON cond
    The data is to be selected from transparent database tables and/or views determined by tabref1 and tabref2. tabref1 and tabref2 each have the same form as in variant 1 or are themselves Join expressions. The keyword INNER does not have to be specified. The database tables or views determined by tabref1 and tabref2 must be recognized by the ABAP Dictionary.
    In a relational data structure, it is quite normal for data that belongs together to be split up across several tables to help the process of standardization (see relational databases). To regroup this information into a database query, you can link tables using the join command. This formulates conditions for the columns in the tables involved. The inner join contains all combinations of lines from the database table determined by tabref1 with lines from the table determined by tabref2, whose values together meet the logical condition (join condition) specified using ON>cond.
    Inner join between table 1 and table 2, where column D in both tables in the join condition is set the same:
    Table 1 Table 2
    A  B  C  D    D  E  F  G  H 
    a1  b1  c1  1    1  e1  f1  g1  h1 
    a2  b2  c2  1    3  e2  f2  g2  h2 
    a3  b3  c3  2    4  e3  f3  g3  h3 
    a4  b4  c4  3    -
    Inner Join
    A  B  C  D  D  E  F  G  H 
    a1  b1  c1  1  1  e1  f1  g1  h1 
    a2  b2  c2  1  1  e1  f1  g1  h1 
    a4  b4  c4  3  3  e2  f2  g2  h2 
    Example
    Output a list of all flights from Frankfurt to New York between September 10th and 20th, 2001 that are not sold out:
    DATA: DATE LIKE SFLIGHT-FLDATE,
    CARRID LIKE SFLIGHT-CARRID,
    CONNID LIKE SFLIGHT-CONNID.
    SELECT FCARRID FCONNID F~FLDATE
    INTO (CARRID, CONNID, DATE)
    FROM SFLIGHT AS F INNER JOIN SPFLI AS P
    ON FCARRID = PCARRID AND
    FCONNID = PCONNID
    WHERE P~CITYFROM = 'FRANKFURT'
    AND P~CITYTO = 'NEW YORK'
    AND F~FLDATE BETWEEN '20010910' AND '20010920'
    AND FSEATSOCC < FSEATSMAX.
    WRITE: / DATE, CARRID, CONNID.
    ENDSELECT.
    If there are columns with the same name in both tables, you must distinguish between them by prefixing the field descriptor with the table name or a table alias.
    In order to determine the result of a SELECT command where the FROM clause contains a join, the database system first creates a temporary table containing the lines that meet the ON condition. The WHERE condition is then applied to the temporary table. It does not matter in an inner join whether the condition is in the ON or WHEREclause. The following example returns the same solution as the previous one.
    Example
    Output of a list of all flights from Frankfurt to New York between September 10th and 20th, 2001 that are not sold out:
    DATA: DATE LIKE SFLIGHT-FLDATE,
    CARRID LIKE SFLIGHT-CARRID,
    CONNID LIKE SFLIGHT-CONNID.
    SELECT FCARRID FCONNID F~FLDATE
    INTO (CARRID, CONNID, DATE)
    FROM SFLIGHT AS F INNER JOIN SPFLI AS P
    ON FCARRID = PCARRID
    WHERE FCONNID = PCONNID
    AND P~CITYFROM = 'FRANKFURT'
    AND P~CITYTO = 'NEW YORK'
    AND F~FLDATE BETWEEN '20010910' AND '20010920'
    AND FSEATSOCC < FSEATSMAX.
    WRITE: / DATE, CARRID, CONNID.
    ENDSELECT.
    Since not all of the database systems supported by SAP use the standard syntax for ON conditions, the syntax has been restricted. It only allows those joins that produce the same results on all of the supported database systems:
    Only a table or view may appear to the right of the JOIN operator, not another join expression.
    Only AND is possible in the ON condition as a logical operator.
    Each comparison in the ON condition must contain a field from the right-hand table.
    If an outer join occurs in the FROM clause, all the ON conditions must contain at least one "real" JOIN condition (a condition that contains a field from tabref1 amd a field from tabref2.
    In some cases, '*' may be specified in the SELECT clause, and an internal table or work area is entered into the INTO clause (instead of a list of fields). If so, the fields are written to the target area from left to right in the order in which the tables appear in the FROM clause, according to the structure of each table work area. There can then be gaps between table work areas if you use an Alignment Request. For this reason, you should define the target work area with reference to the types of the database tables, not simply by counting the total number of fields. For an example, see below:
    Variant 3
    ... FROM tabref1 LEFT OUTER JOIN tabref2 ON cond
    Effect
    Selects the data from the transparent database tables and/or views specified in tabref1 and tabref2. tabref1 und tabref2 both have either the same form as in variant 1 or are themselves join expressions. The keyword OUTER can be omitted. The database tables or views specified in tabref1 and tabref2 must be recognized by the ABAP-Dictionary.
    In order to determine the result of a SELECT command where the FROM clause contains a left outer join, the database system creates a temporary table containing the lines that meet the ON condition. The remaining fields from the left-hand table (tabref1) are then added to this table, and their corresponding fields from the right-hand table are filled with ZERO values. The system then applies the WHERE condition to the table.
    Left outer join between table 1 and table 2 where column D in both tables set the join condition:
    Table 1 Table 2
    A  B  C  D    D  E  F  G  H 
    a1  b1  c1  1    1  e1  f1  g1  h1 
    a2  b2  c2  1    3  e2  f2  g2  h2 
    a3  b3  c3  2    4  e3  f3  g3  h3 
    a4  b4  c4  3    -
    Left Outer Join
    A  B  C  D  D  E  F  G  H 
    a1  b1  c1  1  1  e1  f1  g1  h1 
    a2  b2  c2  1  1  e1  f1  g1  h1 
    a3  b3  c3  2  NULL NULL NULL NULL NULL
    a4  b4  c4  3  3  e2  f2  g2  h2 
    Example
    Output a list of all custimers with their bookings for October 15th, 2001:
    DATA: CUSTOMER TYPE SCUSTOM,
    BOOKING TYPE SBOOK.
    SELECT SCUSTOMNAME SCUSTOMPOSTCODE SCUSTOM~CITY
    SBOOKFLDATE SBOOKCARRID SBOOKCONNID SBOOKBOOKID
    INTO (CUSTOMER-NAME, CUSTOMER-POSTCODE, CUSTOMER-CITY,
    BOOKING-FLDATE, BOOKING-CARRID, BOOKING-CONNID,
    BOOKING-BOOKID)
    FROM SCUSTOM LEFT OUTER JOIN SBOOK
    ON SCUSTOMID = SBOOKCUSTOMID AND
    SBOOK~FLDATE = '20011015'
    ORDER BY SCUSTOMNAME SBOOKFLDATE.
    WRITE: / CUSTOMER-NAME, CUSTOMER-POSTCODE, CUSTOMER-CITY,
    BOOKING-FLDATE, BOOKING-CARRID, BOOKING-CONNID,
    BOOKING-BOOKID.
    ENDSELECT.
    If there are columns with the same name in both tables, you must distinguish between them by prefixing the field descriptor with the table name or using an alias.
    Note
    For the resulting set of a SELECT command with a left outer join in the FROM clause, it is generally of crucial importance whether a logical condition is in the ON or WHERE condition. Since not all of the database systems supported by SAP themselves support the standard syntax and semantics of the left outer join, the syntax has been restricted to those cases that return the same solution in all database systems:
    Only a table or view may come after the JOIN operator, not another join statement.
    The only logical operator allowed in the ON condition is AND.
    Each comparison in the ON condition must contain a field from the right-hand table.
    Comparisons in the WHERE condition must not contain a field from the right-hand table.
    The ON condition must contain at least one "real" JOIN condition (a condition in which a field from tabref1 as well as from tabref2 occurs).
    Note
    In some cases, '*' may be specivied as the field list in the SELECT clause, and an internal table or work area is entered in the INTO clause (instead of a list of fields). If so, the fields are written to the target area from left to right in the order in which the tables appear in the llen in der FROM clause, according to the structure of each table work area. There can be gaps between the table work areas if you use an Alignment Request. For this reason, you should define the target work area with reference to the types of the database tables, as in the following example (not simply by counting the total number of fields).
    Example
    Example of a JOIN with more than two tables: Select all flights from Frankfurt to New York between September 10th and 20th, 2001 where there are available places, and display the name of the airline.
    DATA: BEGIN OF WA,
    FLIGHT TYPE SFLIGHT,
    PFLI TYPE SPFLI,
    CARR TYPE SCARR,
    END OF WA.
    SELECT * INTO WA
    FROM ( SFLIGHT AS F INNER JOIN SPFLI AS P
    ON FCARRID = PCARRID AND
    FCONNID = PCONNID )
    INNER JOIN SCARR AS C
    ON FCARRID = CCARRID
    WHERE P~CITYFROM = 'FRANKFURT'
    AND P~CITYTO = 'NEW YORK'
    AND F~FLDATE BETWEEN '20010910' AND '20010920'
    AND FSEATSOCC < FSEATSMAX.
    WRITE: / WA-CARR-CARRNAME, WA-FLIGHT-FLDATE, WA-FLIGHT-CARRID,
    WA-FLIGHT-CONNID.
    ENDSELECT.

Maybe you are looking for

  • NW 2004S and ECC 6.0 - ESS Quota Overview does not simulate

    Dear all, we are upgrading from 4.6C to ECC 6.0 and from the standalone ESS solution to the ESS in EP NW 2004s. In the old ESS we used service pz09 which allows EE's to simulate their future absence quota. In the new ESS in EP we are testing the appl

  • 9.0.3 "Bug" report regarding paths, compiling, and running

    I don't know if this is a bug or some kind of strange feature but it caused me to lose about an hour and a half of work before I figured out what was going on. BACKGROUND: I have a project UVDebug.jpr. It's full pathname is : C:\My Documents\OracleJD

  • SAP retail service orders

    Can you please explain the process flow in SAP retail specific service orders? When do we close the service order? How do we receive the notification after the service is carried out? Franc

  • "Unknown Error" message when I try to do a backup

    When I  try to do a backup with the destop software, it finishes with an "Unknown Error" message.   I can't seem to figure out why and I really really want to do a backup. Thanks. edit:  It gets hung up on "firewall options" and then shows the "unkno

  • BIOS for DV9627CL

    Could someone from HP send me a download link to the latest BIOS for a DV9627CL laptop? Thanks!