This action might not be possible to undo. Are you sure you want to continue?
Q) AS WE USE Sbwnn, sbiw1, sbiw2 for delta update in LIS THEN WHAT IS THE PROCEDURE IN LO-COCKPIT? No LIS in LO cockpit. We will have datasources and can be maintained (append fields). Refer white paper on LO-Cockpit extractions.
Q) Why we delete the setup tables (LBWG) & fill them (OLI*BW)? A) Initially we don't delete the setup tables but when we do change in extract structure we go for it. We r changing the extract structure right, that means there are some newly added fields in that which r not before. So to get the required data ( i.e.; the data which is required is taken and to avoid redundancy) we delete n then fill the setup tables.
To refresh the statistical data. The extraction set up reads the dataset that you want to process such as, customers orders with the tables like VBAK, VBAP) & fills the relevant communication structure with the data. The data is stored in cluster tables from where it is read when the initialization is run. It is important that during initialization phase, no one generates or modifies application data, at least until the tables can be set up.
Q) SIGNIFICANCE of ODS? It holds granular data (detailed level).
Q) WHERE THE PSA DATA IS STORED? In PSA table.
Q) WHAT IS DATA SIZE?
Q) IF THERE ARE 2 DATASOURCES HOW MANY TRANSFER STRUCTURES ARE THERE.The volume of data one data target holds (in no. when ever the table is updated the virtual cube will fetch the data from table and display report Online. of records) Q) Different types of INFOCUBES. In R/3 or in BW? 2 in R/3 and 2 in BW Q) ROUTINES? Exist in the InfoObject. Hierarchy nodes & Characteristic values. FYI. you can create structures. Rows and Columns. sap remote and multi) Virtual Cube is used for example. . update routines and start routine Q) BRIEF SOME STRUCTURES USED IN BEX. transfer routines. Basic..sap.. For designing the Virtual cube you have to write the function module that is linking to table. Formulas. you will get the information : https://www. Virtual (remote.sdn.sdn and search for Designing Virtual Cube and you will get a good material designing the Function Module Q) INFOSET QUERY. Q) WHAT ARE THE DIFFERENT VARIABLES USED IN BEX? Different Variable's are Texts. Hierarchies.. Can be made of ODS's and Characteristic InfoObjects with masterdata. if you consider railways reservation all the information has to be updated online. Virtual cube it is like a the structure.com/sdn /index.
Variable Types are Manual entry /default value Replacement path SAP exit Customer exit Authorization Q) HOW MANY LEVELS YOU CAN GO IN REPORTING? You can drill down to any level by using Navigational attributes and jump targets.X VERSIONS.1 AND 3. Q) WHAT IS THE SIGNIFICANCE OF KPI'S? KPI's indicate the performance of a company. Q) DIFFERENCE BETWEEN 2. which help in retrieving data fastly. These are key figures Q) AFTER THE DATA EXTRACTION WHAT IS THE IMAGE POSITION. Q) WHAT ARE INDEXES? Indexes are data base indexes. After image (correct me if I am wrong) . Help! Refer documentation Q) IS IT NESSESARY TO INITIALIZE EACH TIME THE DELTA UPDATE IS USED? No.
What are you expecting? MultiCube works on Union condition Q) EXPLAIN TRANPSORTATION OF OBJECTS? Dev---àQ and Dev-------àP Q) What types of partitioning are there for BW? There are two Partitioning Performance aspects for BW (Cube & PSA) Query Data Retrieval Performance Improvement: Partitioning by (say) Date Range improves data retrieval by making best use of database [data range] execution plans and indexes (of say . Profile generator Q) WEB REPORTING. What are you expecting?? Q) CAN CHARECTERSTIC INFOOBJECT CAN BE INFOPROVIDER. Etc Q) PROCESS CHAINS: IF U has USED IT THEN HOW WILL U SCHEDULING DATA DAILY. Q) TOOLS USED FOR PERFORMANCE TUNING. ST22. There should be some tool to run the job daily (SM37 jobs) Q) AUTHORIZATIONS. delete indexes before load. Help! Refer documentation. Number ranges.Q) REPORTING AND RESTRICTIONS. Of course Q) PROCEDURES OF REPORTING ON MULTICUBES Refer help.
but only really tells you if the extractor works. it will not tell you how many records should be expected in BW for a given load. To use RSA3. You have that information in the monitor RSMO during and after data loads. You are not modifying anything so what you do in RSA3 has no effect on data quality afterwards. you can also go to display that data. go to it and enter the extractor ex: 2LIS_02_HDR. how many targets were updated. you will not be able to determine what is in the Cube compared to what is in the R/3 environment. From RSMO for a given load you can determine how many records were passed through the transfer rules from R/3.Oracle database engine). A) RSA3 is a simple extractor checker program that allows you to rule out extracts problems in R/3. Since records that get updated into Cubes/ODS structures are controlled by Update Rules. Improves data loading into PSA and Cubes by infopackages (Eg. Then go to BW Monitor to check the number of records in the PSA and check to see if it is the same & also in the monitor header tab. Click execute and you will see the record count. Q) How can I compare data in R/3 with data in a BW Cube after the daily delta loads? Are there any standard procedures for checking them or matching the number of records? A) You can go to R/3 TCode RSA3 and run the extractor. However. B) Transactional Load Partitioning Improvement: Partitioning based on expected load volumes and data element sizes. without timeouts). It is simple to use. It also gives you error messages from the PSA. Q) Types of Transfer Rules? . You will need to compare records on a 1:1 basis against records in R/3 transactions for the functional area in question. It will give you the number of records extracted. I would recommend enlisting the help of the end user community to assist since they presumably know the data. and how many records passed through the Update Rules.
A) Field to Field mapping. which we write in Update rules Q) What is the difference between writing a routine in transfer rules and writing a routine in update rules? A) If you are using the same InfoSource to update data in more than one data target its better u write in transfer rules because u can assign one InfoSource to more than one data target & and what ever logic u write in update rules it is specific to particular one data target. but a return table. Constant. as you like from one data record. Variable & routine. . You can then generate as many key figure values. transfer rules. Q) Update Routine? A) Routines. Q) Types of Update Rules? A) (Check box). you can create a routine in the tab strip key figure calculation. by choosing checkbox Return table. However. The corresponding key figure routine then no longer has a return value. A) Update rules generally only have one return value. Q) Routine with Return Table. which we write in. Return table Q) Transfer Routine? A) Routines.
Y-table = A table to link material SIDs with SIDS for time-dependent navigation attributes. suppose you want to restrict (delete) some records based on conditions before getting loaded into data targets.Q) Start routines? A) Start routines u can write in both updates rules and transfer rules. then you can specify this in update rules-start routine. no: of billing documents as RKF's. .Delete Data_Package ani ante it will delete a record based on the condition Q) X & Y Tables? X-table = A table to link material SIDs with SIDs for time-independent navigation attributes. Ex: . billing value. There are four types of sid tables X time independent navigational attributes sid tables Y time dependent navigational attributes sid tables H hierarchy sid tables I hierarchy structure sid tables Q) Filters & Restricted Key figures (real time example) Restricted KF's u can have for an SD cube: billed quantity.
Q) How to know in which table (SAP BW) contains Technical Name / Description and creation data of a particular Reports. Reports that are created using BEx Analyzer. The number includes the LUWs of the last delta request (for repetition of a delta request) and the LUWs for the next delta request.Q) Line-Item Dimension (give me an real time example) Line-Item Dimension: Invoice no: or Doc no: is a real time example Q) What does the number in the 'Total' column in Transaction RSA7 mean? A) The 'Total' column displays the number of LUWs that were written in the delta queue and that have not yet been confirmed.used list for reports in workbooks (Table RSRWORKBOOK) Titles of Excel Workbooks in InfoCatalog (Table RSRWBINDEXT) Q) What is a LUW in the delta queue? A) A LUW from the point of view of the delta queue can be an . A) There is no such table in BW if you want to know such details while you are opening a particular query press properties button you will come to know all the details that you wanted. Directory of all reports (Table RSRREPDIR) and Directory of the reporting component elements (Table RSZELTDIR) for workbooks and the connections to queries check Where. A LUW only disappears from the RSA7 display when it has been transferred to the BW System and a new delta request has been received from the BW System. You will find your information about technical names and description about queries in the following tables.
In particular.individual document. only the records that are ready for the next delta request are displayed on the detail screen. the LUWs of the previous delta may be confirmed (and also deleted). In the meantime. Both. Q) Why does the number in the 'Total' column in the overview screen of Transaction RSA7 differ from the number of data records that is displayed when you call the detail view? A) The number on the overview screen corresponds to the total of LUWs (see also first question) that were written to the qRFC queue and that have not yet been confirmed. Then. the LUWs must be kept for a possible delta request repetition. Q) Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading? A) Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded to the BW System. the number on the overview screen does not change when the first delta was loaded to the BW System. the records belonging to the previous delta request and the records that do not meet the selection conditions of the preceding delta init requests are filtered out. Q) Why are selections not taken into account when the delta queue is filled? A) Filtering according to selections takes place when the system reads from the delta queue. In the detail screen of Transaction RSA7. a group of documents from a collective run or a whole data packet of an application extractor. Thus. . The detail screen displays the records contained in the LUWs. This is necessary for reasons of performance. a possibly existing customer exit is not taken into account.
to restrict it. Q) Do the entries in table ROIDOCPRMS have an impact on the performance of the loading procedure from the delta queue? A) The impact is limited. then refer to the applicationspecific notes (for example in the CO-PA area.1 the display was changed: the user has the option of defining the amount of data to be displayed. This means that when very large LUWs are written to the DeltaQueue. that LUWs are not split during data loading for consistency reasons. Q) Why does it take so long to display the data in the delta queue (for example approximately 2 hours)? A) With Plug In 2001. the actual package size may differ considerably from the MAXSIZE and MAXLINES parameters. in the logistics cockpit area and so on). to selectively choose the number of a data record.0B Support Package 11. Please note. Q) What is the purpose of function 'Delete data and meta data in a queue' in RSA7? What exactly is deleted? .2 patch 3 the entries in table ROIDOCPRMS are as effective for the delta queue as for a full update. Such a DataSource should not be displayed in RSA7.Q) Why is there a DataSource with '0' records in RSA7 if delta exists and has also been loaded successfully? It is most likely that this is a DataSource that does not send delta data to the BW System via the delta queue but directly via the extractor (delta for master data using ALE change pointers). If performance problems are related to the loading process from the delta queue. This error is corrected with BW 2. to make a distinction between the 'actual' delta data and the data intended for repetition and so on. however. Caution: As of Plug In 2000.
Then you can only request new deltas after another delta initialization. Q) Why is the delta queue not updated when you start the V3 update in the logistics cockpit area? A) It is most likely that a delta initialization had not yet run or that the delta initialization was not successful. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there.2 patch 3. With this patch the performance during deletion is considerably improved. A successful delta initialization (the corresponding request must have QM status 'green' in the BW System) is a prerequisite for the application data being written in the delta queue. from which the delta initialization was originally executed. The deletion function is for example intended for a case where the BW System. Q) Why does it take so long to delete from the delta queue (for example half a day)? A) Import PlugIn 2000. You do not only delete all data of this DataSource for the affected BW System. but also lose the entire information concerning the delta initialization. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs. When you delete the data. the LUWs kept in the qRFC queue for the corresponding target system are confirmed. no longer exists or can no longer be accessed.A) You should act with extreme caution when you use the deletion function in the delta queue. Q) What is the relationship between RSA7 and the qRFC monitor (Transaction SMQ1)? .
Then. Q) Why does button 'Repeatable' on the RSA7 data details screen not only show data loaded into BW during the last delta but also data that were newly added.A) The qRFC monitor basically displays the same data as RSA7. Q) I loaded several delta inits with various selections. This happens in particular during automatic goods receipt posting (MRRS). See Note 417189. Moreover.e. i. the data of a LUW is displayed in an unstructured manner there. This is made up of the prefix 'BW. There is no duplicate transfer of records to the BW system. the short name corresponds to the name of the DataSource. 'pure' delta records? A) Was programmed in a way that the request in repeat mode fetches both actually repeatable (old) data and new data from the source system. The internal queue name must be used for selection on the initial screen of the qRFC monitor. For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001. . the client and the short name of the DataSource. the records are updated directly in the delta queue (RSA7). Q) Why are the data in the delta queue although the V3 update was not started? A) Data was posted in background. This means. a delta for the 'total' of all delta initializations is loaded. For which one is the delta loaded? A) For delta. For DataSources whose name are 19 characters long or shorter.1) the short name is assigned in table ROOSSHORTN. In the qRFC monitor you cannot distinguish between repeatable and new LUWs. all selections made via delta inits are summed up.
Q) How many selections for delta inits are possible in the system? A) With simple selections (intervals without complicated join conditions or single values). After the client copy. make sure that your deltas have been fetched from the DeltaQueue into BW and that no delta is pending. too many 'where' lines are generated in the generated ABAP source code that may exceed the memory limit. Even if no dump 'MESSAGE_TYPE_X' occurs in BW when editing or creating an InfoPackage. Q) Is it allowed in Transaction SMQ1 to use the functions for manual control of processes? . the table will contain the entries with the old logical system name that are no longer useful for further delta loading from the new logical system. it should be only up to 10-20 delta inits. After the client copy.e. you should expect that the delta have to be initialized after the copy. What will happen with may delta? Should I initialize again after that? A) Before you copy a source client or source system. Reason: With many selection conditions that are joined in a complicated way. With complicated selection conditions. Q) I intend to copy the source system. It should not be more. After the system copy. make a client copy. you can make up to about 100 delta inits. Table ROOSPRMSC will probably be empty in the OLTP since this table is client-independent. The delta must be initialized in any case since delta depends on both the BW system and the source system. i. an inconsistency might occur between BW delta tables and the OLTP delta tables as described in Note 405943.
What is the cause for this "splitting"? A) The collective run submits the open V2 documents for processing to the task handler. which processes them in one or several parallel update processes in an asynchronous way. Q) In SMQ1 (qRFC Monitor) I have status 'NOSEND'. others 'RECORDED'. Q) Despite my deleting the delta init. buffer problems may occur: If a user started the internal mode at a time when the delta initialization was still active.A) Use SMQ1 as an instrument for diagnosis and control only. In the table TRFCQOUT. An alternative solution where this problem does not occur is described in Note 505700. it does not contain all documents. What do these statuses mean? Which values in the field 'Status' mean what and which values are correct and which are alarming? Are the statuses BW-specific or generally valid in qRFC? . For this reason. ARFCSSTATE is 'READ'. Only another delta request loads the missing documents into BW. plan a sufficiently large "safety time window" between the end of the collective run in the source system and the start of the delta request in BW. LUWs are still written into the DeltaQueue? A) In general. delta initializations and deletions of delta inits should always be carried out at a time when no posting takes place. This is the case in your system. Make changes to BW queues only after informing the BW Support or only if this is explicitly requested in a note for component 'BC-BW' or 'BWWHM-SAPI'. some entries have the status 'READY'. Q) Despite of the delta request being started after completion of the collective run (V3 update). he/she posts data into the queue even though the initialization had been deleted in the meantime. Otherwise.
Afterwards new delta records were written to the DeltaQueue. or. it shows that some fields were moved. If the extract structure change is not communicated synchronously to the server where delta records are being created. Why are the data displayed differently? What can be done? Make sure that the change of the extract structure is also reflected in the database and that all servers are synchronized. no more deltas are loaded into the BW. However. this does not mean that the record has successfully reached the BW yet. The status EXECUTED in TRFCQOUT can occur temporarily. it means that either a process which is confirming and deleting records which have been loaded into the BW is successfully running at the moment. NOSEND in SMQ1 means nothing (see note 378903). The status READY in the TRFCQOUT and RECORDED in the ARFCSSTATE means that the record has been written into the DeltaQueue and will be loaded into the BW with the next delta request or a repetition of a delta. In this state.A) Table TRFCQOUT and ARFCSSTATE: Status READ means that the record was read once either in a delta request or in a repetition of the delta request. The value 'U' in field 'NOSEND' of table TRFCQOUT is discomforting. We recommend to reset the buffers using Transaction $SYNC. Q) The extract structure was changed when the DeltaQueue was empty. READY and RECORDED in both tables are considered to be valid. if the records remain in the table for a longer period of time with status EXECUTED. Every other status is an indicator for an error or an inconsistency. In any case only the statuses READ. If you see such records. This may have . It is set before starting a DeltaExtraction for all records with status READ present at that time. The same result occurs when the contents of the DeltaQueue are listed via the detail display. The records with status EXECUTED are usually deleted from the queue in packages within a delta request directly after setting the status before extracting a new delta. it is likely that there are problems with deleting the records which have already been successfully been loaded into the BW. the records are written with the old structure until the new structure has been generated. When loading the delta into the PSA.
the next load will be of type 'Repeat'.1. If the request is RED. When the problem occurs. both the number of LUWs is important and the average data volume per LUW. When estimating "smooth" limits. Q) How and where can I control whether a repeat delta is requested? A) Via the status of the last delta in the BW Request Monitor.which is of no practical importance. Q) Are there particular recommendations regarding the data volume the DeltaQueue may grow to without facing the danger of a read failure due to memory problems? A) There is no strict limit (except for the restricted number range of the 24-digit QCOUNT counter in the LUW management table . Delta requests set to red despite of data being already updated lead to duplicate records in a subsequent repeat. the Logistic Cockpit offers various types of update methods. set the request in the monitor to red manually. If you need to repeat the last load for certain reasons. the delta needs to be re-initialized. As a rule. we recommend to bundle data (usually documents) already when writing to the DeltaQueue to keep number of LUWs small (partly this can be . Q) As of PI 2003. however . For the contents of the repeat see Question 14. Which update method is recommended in logistics? According to which criteria should the decision be made? How can I choose an update method in logistics? See the recommendation in Note 505700.or the restrictions regarding the volume and number of records in a database table).disastrous consequences for the delta. if they have not been deleted from the data targets concerned before.
To avoid memory problems. you should at least make sure that the data are fetched from all connected BWs as quickly as possible. a program-internal limit ensures that never more than 1 million LUWs are read and fetched from the database per DeltaRequest. reasons. correct reading is guaranteed in most cases. But for other. however. e. We recommend. in the Logistics Cockpit).g. to try not to reach that limit but trigger the fetching of data from the connected BWs already when the number of LUWs reaches a 5-digit value . BWspecific.set in the applications. The data volume of a single LUW should not be considerably larger than 10% of the memory available to the work process for data extraction (in a 32-bit architecture with a memory volume of about 1GByte per work process. That limit is of rather small practical importance as well since a comparable limit already applies when writing to the DeltaQueue. If this limit is reached within a request. If the number of LUWs cannot be reduced by bundling application transactions. 100 Mbytes per LUW should not be exceeded). If the limit is observed. the DeltaQueue must be emptied by several successive DeltaRequests. the frequency should not be higher than one DeltaRequest per hour.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.