What is dsp.how many types of dso's

hi
guys
          what is dsp.how many types of dso's  plz post answer

Hi,
Types of DSO are
1. Standard DSO
2. Direct Update DSO
3. Write Optimized DSO
Standard DataStore object
Data provided using a data transfer process
SID values can be generated
oData records with the same key are aggregated during activation
Data is available for reporting after activation
*Write-optimized DataStore object
Data provided using a data transfer process
SID values cannot be generated
Records with the same key are not aggregated
Data is available for reporting immediately after it is loaded
*DataStore object for direct update
Data provided using APIs
SIDs cannot be generated
Records with the same key are not aggregated
Standard DSO:
zRThe standard DataStore object is filled with data during the extraction and load process in the BI system.
A standard DataStore object is represented on the database by three transparent tables:
Activation queue: Serves to save DataStore object data records that are to be updated, but that have not yet been activated. The data is deleted after the records have been activated.
Active data: A table containing the active data (A table).
Change log: Contains the change history for the delta update from the DataStore object into other data targets, such as DataStore objects or InfoCubes.
Direct Update DSO:
The DataStore object for direct update differs from the standard DataStore object in terms of how the data is processed. In a standard DataStore object, data is stored in different versions (active, delta, modified), whereas a DataStore object for direct update contains data in a single version. Therefore, data is stored in precisely the same form in which it was written to the DataStore object for direct update by the application. In the BI system, you can use a DataStore object for direct update as a data target for an analysis process.
DataStore objects for direct update ensure that the data is available quickly. The data from this kind of DataStore object is accessed transactionally. The data is written to the DataStore object (possibly by several users at the same time) and reread as soon as possible
Write Optimized DSO:
DataStore object that only consists of one table of active data. Data is loaded using the data transfer process.
Data that is loaded into write-optimized DataStore objects is available immediately for further processing.
You use write-optimized DataStore objects in the following scenarios:
● You use a write-optimized DataStore object as a temporary storage area for large sets of data if you are executing complex transformations for this data before it is written to the DataStore object. Subsequently, the data can be updated to further (smaller) InfoProviders. You only have to create the complex transformations once for all data.
● You use write-optimized DataStore objects as the EDW layer for saving data. Business rules are only applied when the data is updated to additional InfoProviders.
The system does not generate SIDs for write-optimized DataStore objects and you do not need to activate them. This means that you can save and further process data quickly. Reporting is possible on the basis of these DataStore objects. However, we recommend that you use them as a consolidation layer, and update the data to additional InfoProviders, standard DataStore objects, or InfoCubes

Similar Messages

  • How many types of tables exists and what are they in data dictionary?

    hi,
    How many types of tables exists and what are they in data dictionary?
    regards.

    Hello Liu,
    Please search in forum before posting any question .
    anyhow check the below link :
    http://web.mit.edu/sapr3/dev/sap_table_types.htm
    Thanks
    Seshu

  • How many types i can import as file in FLA and what's the differences ??

    Hello
    How many types i can import as file in FLA and what's the differences ??

    you wouldn't import a .as file. 
    you could open it in the flash ide (or any text editor) and edit it.
    you could  create a fla and assign a document class which flash will compile into your swf.
    you could create a library object in a fla, tick export for actionscript and assign a class that flash will compile that class into your swf.
    you could instantiate a class object (using the "new" constructor) in a flash movieclip timeline or in another class file and flash will compile that class into your swf.
    for Workers to extend a class use something like:
    package
    import Citizens;
          public class Workers  extends Citizens
           protected var baseSalary:Number = 1000;
               public function Workers()
                   super();
              public function receivePayment():Number
                    return this.baseSalary;

  • How many types of messages are there what are they?

    How many types of messages are there? what are they?

    Hi,
    Refer the Demo program this iwll help
    <b>DEMO_MESSAGES</b>
    1. MESSAGE xnnn.
    2. MESSAGE ID id TYPE mtype NUMBER n.
    3. MESSAGE xnnn(mid).
    Effect
    Sends a message. Messages are stored in table T100, and can be maintained using Transaction SE91. They are fully integrated in the forward navigation of the ABAP Workbench.
    The ABAP runtime environment handles messages according to the message type specified in the MESSAGE statement and the context in which the message is sent. There are six kinds of message type:
    A (Abend)
    Termination
    E (Error)
    Error
    I (Info)
    Information
    S (Status)
    Status message
    W (Warning)
    Warning
    X (Exit)
    Termination with short dump
    Messages are used primarily to handle user input on screens. The following table shows how each message type behaves in different contexts. The numbers are explained at the end of the table.
    A E I S W X
    PAI module 1 2 3 4 5 6
    PAI module at POH 1 7 3 4 7 6
    PAI module at POV 1 7 3 4 7 6
    AT SELECTION-SCREEN ... 1 8 3 4 9 6
    AT SELECTION-SCREEN at POH 1 7 3 4 7 6
    AT SELECTION-SCREEN at POV 1 7 3 4 7 6
    AT SELECTION-SCREEN ON EXIT 1 7 3 4 7 6
    AT LINE-SELECTION 1 10 3 4 10 6
    AT PFn 1 10 3 4 10 6
    AT USER-COMMAND 1 10 3 4 10 6
    INITIALIZATION 1 11 3 4 11 6
    START-OF-SELECTION 1 11 3 4 11 6
    GET 1 11 3 4 11 6
    END-OF-SELECTION 1 11 3 4 11 6
    TOP-OF-PAGE 1 11 3 4 11 6
    END-OF-PAGE 1 11 3 4 11 6
    TOP-OF-PAGE DURING ... 1 10 3 4 10 6
    LOAD-OF-PROGRAM 1 1 4 4 4 6
    PBO module 1 1 4 4 4 6
    AT SELECTION-SCREEN OUTPUT 1 1 4 4 4 6
    reward if this helps.

  • What is buffer? how many types of buffers r there?

    how many types of joins r there?
    thank u.

    Whenever an Open SQL statement is used to read a record,
    the data buffer is checked first to see whether it is there. If not, the data is read from the database.
    If the table's attributes indicate that the data should be buffered,
    the record is saved in RAM on the application server in data buffers.
    Later, if that record is read again, it is read from the buffer instead of the database.
    By buffering data, you increase performance in two important ways:
    The programs using the buffered data run faster because they don't have to wait for it to come from the database. This reduces delays waiting for the database and the network that connects it.
    The other programs that need to access the database run faster because there is less load on the database and less traffic on the network.
    Three types of buffering are possible:
    Full Buffering
    With full buffering, either the entire table is in the buffer or the table is not in the buffer at all. All
    the records of the table are loaded into the buffer when one record of the table is read.
    In this example, a program reads the record highlighted in red from table
    SCOUNTER. If the table is fully buffered, all the records of the table are loaded into
    the buffer.
    Application server
    The buffered data records are sorted in the buffer by table key. Accesses to the
    buffered data can therefore only analyze field contents up to the last specified key
    field for restricting the dataset to be searched.
    The left-justified part of the key should therefore be as large as possible in such
    accesses. For example, if you do not define the first key field, the system has to scan
    the full table. In this case direct access to the database can be more efficient if the
    database has suitable secondary indexes [Page 61].
    When Should you Use Full Buffering?
    When deciding whether a table should be fully buffered, you should take into account the size of
    the table, the number of read accesses, and the number of write accesses. Tables best suited to
    full buffering are small, read frequently, and rarely written.
    Full buffering is recommended in the following cases:
    BC - ABAP Dictionary SAP AG
    Full Buffering
    36 December 1999
    • Tables up to 30 KB in size. If a table is accessed frequently, but all accesses are read
    accesses, this value can be exceeded. However, you should always pay attention to the
    buffer utilization.
    • Larger tables where large numbers of records are frequently accessed. If these mass
    accesses can be formulated with a very selective WHERE condition using a database
    index [Page 61], it could be better to dispense with buffering.
    • Tables for which accesses to non-existent records are frequently submitted. Since all the
    table records reside in the buffer, the system can determine directly in the buffer whether
    or not a record exists.
    SAP AG BC - ABAP Dictionary
    Generic Buffering
    With generic buffering, all the records in the buffer whose generic key fields match this record are
    loaded when one record of the table is accessed. The generic key is a part of the primary key of
    the table that is left-justified.
    In this example, the record highlighted in red is read by a program from table
    SCOUNTER. If the table is generically buffered, all the records read whose generic
    key fields (MANDT and CARRID) agree are loaded into the buffer.
    Application server
    When Should you Use Full Buffering?
    A table should be buffered generically if only certain generic areas of the table are normally
    needed for processing.
    Client-specific, fully-buffered tables are automatically generically buffered since normally it is not
    possible to work in all clients at the same time on an application server. The client field is the
    generic key.
    Language-specific tables are another example where generic buffering is recommended. In
    general, only records of one language will be needed on an application server. In this case, the
    generic key includes all the key fields up to and including the language field.
    How Should you Define the Generic Key?
    In generic buffering, it is crucial to define a suitable generic key.
    BC - ABAP Dictionary SAP AG
    Generic Buffering
    If the generic key is too small, the buffer will contain a few very large areas. During access, too
    much data might be loaded in the buffer.
    If the generic key is too large, the buffer might contain too many small generic areas. These can
    reduce buffer performance since there is an administrative entry for every buffered generic area.
    It is also possible that too many accesses will bypass the buffer and go directly to the database,
    since they do not fully define the generic key of the table. If there are only a few records in each
    generic area, it is usually better to fully buffer the table.
    Only 64 bytes of the generic key are used. You can specify a longer generic key, but the part of
    the key exceeding 64 bytes is not used to create the generic areas.
    Access to Buffered Data
    It only makes sense to generically buffer a table if the table is accessed with fully-specified
    generic key fields. If a field of the generic key is not assigned a value in a SELECT statement, it
    is read directly from the database, bypassing the buffer.
    If you access a generic area that is not in the buffer with a fully-specified generic key, you will
    access the database to load the area. If the table does not contain any records in the specified
    area ("No record found"), this area in the buffer is marked as non-existent. It is not necessary to
    access the database if this area is needed again.
    SAP AG BC - ABAP Dictionary
    Single-Record Buffering
    With single-record buffering, only the records that are actually read are loaded into the buffer.
    Single-record buffering therefore requires less storage space in the buffer than generic and full
    buffering. The administrative costs in the buffer, however, are greater than for generic or full
    buffering. Considerably more database accesses are necessary to load the records than for the
    other buffering types.
    In this example, the record highlighted in red is read by a program from table
    SCOUNTER. If single-record buffering is selected for the table, only the record that
    was read is loaded into the buffer.
    When Should you Use Single-Record Buffering?
    Single-record buffering should be used particularly for large tables where only a few records are
    accessed with SELECT SINGLE. The size of the records being accessed should be between 100
    and 200 KB.
    Full buffering is usually more suitable for smaller tables that are accessed frequently. This is
    because only one database access is necessary to load such a table with full buffering, whereas
    several database accesses are necessary for single-record buffering.
    Access to Buffered Data
    All accesses that are not submitted with SELECT SINGLE go directly to the database, bypassing
    the buffer. This applies even if the complete key is specified in the SELECT statement.
    BC - ABAP Dictionary SAP AG
    Single-Record Buffering
    40 December 1999
    If you access a record which is not yet buffered with SELECT SINGLE, there is a database
    access to load the record. This record is marked in the buffer as non-existent if the table does not
    contain a record with the specified key.

  • 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 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

  • 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 Queues exists and how to identify them.

    Hello
    can anyone say How many types of Queues exists and how to identify them.
    What does R3R* and CSA* stands for.
    Regards,
    divya

    Hi Divya,
        The queues R3* and CSA* that you have specified are qRFC queues. qRFC queues are data queues which transport data to and fro different systems.
    There are also the tRFC queues which are triggered whenever you make RFC calls to connect to another system.
    Queues with prefix R3AD* - for delta download from R3->CRM
    Queues with prefix R3AU* - for data upload from CRM->R3
    Queues with prefix R3AR* - used to transfer data during request load from R3->CRM
    Queues with prefix R3AI* - for initial load from R3->CRM
    Queues with prefix CSA* - these are validation object specific queues used for processing/persisting data in CRM tables in a serialized manner. E.g. CSABUPA* for business partner,CSA_ORDER* for sales order etc.
    You can administer and monitor the queues in trax. SMQR,SMQS.
    Hope this helps you! Pls. do not forget to reward me some points.
    Regards,
    Sudipta.

  • How many types of dunning not levels

    hi how many types of dunnig

    Hi
    Dunning is a reminder to the customer or vendor to make payment on outstanding invoices. It typically consists of a letter that summarizes the invoices that are past due and politely requests payment to be made. When you customize dunning you have to create dunning area like at what level you want to use the dunning, like business area level or company code level. After that you have to make settings for dunning procedure, in that you have to define no of due dates and no of dunning levels. there are maximum 9 levels are there.
    the dunning wizard keeps track of a customeru2019s u201Cpayment behavioru201D in the database to deliver this important information to appropriate organizations.
    The dunning system covers the following documents:
    ·        Open A/R invoices, including invoices that are partially credited or partially paid
    ·        Invoices that include installments
    ·        A/R credit memos
    ·        Incoming payments that are not based on invoices
    with regards,
    ramanuja chary

  • 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 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 requests are there

    hai,
    how many types of requests are there plz explain it plzzzzzzzzzzz
    thanks and regards,
    pg babu

    Hi ,
    We are not at all clear about your query here. Please let us know what kind of requests you are telling about. Is it regarding data base requests?
    Regards,
    Abhisek

Maybe you are looking for