Thursday, November 1, 2007

SAP NetWeaver Training Overview - SAP Business Intelligence

SAP NetWeaver Training Overview - SAP Business Intelligence

Whats New with SAP NW 2004s

BW XI Integration - PDF.pdf

BW XI Integration

Periodic Jobs and Tasks in SAP BW

Periodic Jobs and Tasks in SAP BW

Multidimentional Modelling with BI

Multidimentional Modelling with BI

Publishing Reports in SAP NetWeaver BI 2004s

Publishing Reports in SAP NetWeaver BI 2004s

Why do I need a SAP Enterprise Portal when I have BI ?

Sap enterprise portals provides you what you do with BI tools also some more features.

The portal offers a single point of access to SAP and non-SAP information sources, enterprise applications, information repositories, databases and services in and outside your organization—all integrated into a single user experience. It provides you the tools to manage and analyze this knowledge, and to share and collaborate on the basis of it.

With its role-based content, and personalization features, the portal enables users—from employees and customers to partners and suppliers—to focus exclusively on data relevant to daily decision-making processes

Enterprise Portal - Gateway to Your Business World

Upgrading BW 3.X to SAP NetWeaver 2004s BI

Upgrading BW 3.X to SAP NetWeaver 2004s BI

Upgrade BW to Netweaver 2004s from v3.0B

SAP NW 7.0 Upgrade Specifics

SAP Netweaver Business Intelligence Roadmap

SAP Netweaver Business Intelligence Roadmap

Implement SAP BW Faster with SAP Best Practices

BI Integrated Planning in SAP Netweaver 7.0

BI Integrated Planning in SAP Netweaver 7.0

Migration of BW-BPS to BI Integrated Planning

Five Ways to Enhance SAP BI Backend Functionality Using ABAP

Five Ways to Enhance SAP BI Backend Functionality Using ABAP
Modeling Data Transformations in SAP NW Business Intelligence
Performance Optimization in BW Update Rules

Wednesday, October 31, 2007

SAP BI versus SAP BW: What’s in a Name?

A frequent question that we get at SAP events from both customers and partners is, “What is the difference between SAP Business Intelligence (SAP BI) and SAP Business Information Warehouse (SAP BW)?”

Well, the answer to that has changed over time as SAP’s strategy has evolved. In the beginning, we had SAP BW. Shortly after that, SAP BW was bundled with other components, such as SAP Workplace (and later SAP Enterprise Portal) to form a licensed product that was named mySAP Business Intelligence (mySAP BI), to distinguish between the overall solution and the underlying SAP BW component.
With the development of the SAP NetWeaver, it was determined that the business intelligence component should become part of this platform. A decision was made to retain “Business Intelligence” as the name of the underlying component, because this name is more descriptive of the scope of the product, including as it does data warehouse management, extraction, transformation and loading capabilities, business modeling, business content, OLAP analysis, data mining, business insights via alerts and reporting features, and planning functions with the new BW-BPS.

Within SAP BI, SAP BW remains the core product, providing the ability to control, monitor, and maintain all processes connected with data staging and processing. However, this is a technical distinction that is expected to end with SAP BW 3.5, the business intelligence component of SAP NetWeaver ’04. Future releases are planned to have only the “Business Intelligence” designation, such as SAP NetWeaver Business Intelligence 7.0, which is expected to be the name of the component in the next release.
What does this mean to you? You should start thinking of the product as “SAP BI” and try to use the term “SAP BW” only when you are referring to a specific release, such as SAP BW 3.1 Content or SAP BW 3.5. It’s going to be a tough adjustment, but if you start now, it will be easier when the “SAP BW” term goes away completely!

Friday, October 26, 2007

FAQ - Planning in SAP BW

Frequently Asked Questions - Planning in SAP BW

What is SAP's strategy for Planning and Budgeting?
SAP offers an integrated business platform through the mySAP Business Suite, which covers all planning requirements from overall business and financial planning to supply chain planning on the strategic, tactical and operational levels.
Planning and budgeting capabilities reside in different areas. Planning is available in operational context in transactional systems such as R/3 as well as in a more strategic, analytical context within the Business Planning and Simulation component, as of release SAP BW 3.5 part of SAP Business Intelligence (BW-BPS). Supply chain planning takes place in mySAP Supply Chain Management using SAP APO. The results of both business planning and supply chain planning are consolidated in SAP BW, for performance analysis and evaluation purposes.

Why have we decided to move planning to SAP Business Intelligence?
SEM-BPS offers state of the art planning capabilities that address the current needs of customers in regards to data integration on a common platform, usage of Excel and Web as user interfaces, process management and flexible reporting and analysis through SAP BW.
While we understand that the responsibility of business planning often resides in the finance function, we also recognize that the planning concepts implemented in the SEM-BPS planning framework are generic ones that can be reused in many other contexts (CRM, Human Resources, Retail, Consumer Products…). At the same time we realize that planning is becoming a much more integrative process that spans all functions of the enterprise including sales, marketing, production, etc. Our customers have communicated this fact in various product requirement sessions and development influence councils. In fact some customers currently are using SEM-BPS not only for financials but also for sales and marketing planning, headcount planning, purchase planning, travel planning amongst other non-financials types of planning.
Consequently, we want to support the market need and provide an open and flexible planning framework for both financial budgeting and other areas of planning. Therefore, SAP will deliver planning functionality in SAP Business Intelligence in order to provide the desired flexibility that our customers demand.
This step may be compared to the decision to move reporting and analysis to a generic area.
Therefore SAP will leverage the concepts of the SEM-BPS planning framework for the development of BW integrated planning. In addition starting with SAP BW 3.5 SEM-BPS is delivered as BW-BPS and remains in maintenance status.
A comparative view of the evolution of SAP's planning strategy is provided below:



What is a planning application?
Business scenario containing business content
§ Planning and Analysis Services/Planning Functions (e.g. Time lag, financial depreciation)
§ Planning Templates
Examples of planning applications: Sales planning, Financial statement planning, Profitability planning

What are the benefits for the customers?
§ Tightly integrated planning and analysis from one integrated data platform
§ Greater flexibility in creating custom planning applications to meet company-specific or market-specific requirements. Use of SAP BW tools like BEx Analyzer (Alerting, Drilldown Chart Tools, Calculated Key Figures, Hierarchical Data Entry)
§ Reduction of complexity by unique release procedure and reduced number of tools and planning objects
§ Ease of use: Planning and analysis use the same user interfaces
Some of the other features of the planning environment for customers will include improved forecasting algorithms, enhanced process control and status monitoring, simplified, hierarchical data entry, ….
(Please refer to the integrated planning for detailed information about SAP BW integrated planning)

How does this affect SAP Strategic Enterprise Management (SEM)?
Recognizing the fact that a closed-loop planning, measurement, and analysis environment is critical to the finance function, SEM will continue to be positioned and sold as a complete business performance management suite. SEM will deliver financial specific planning applications built on base of SAP BW integrated planning. Planning and budgeting will continue to be a key component of SEM along with the existing financial consolidation, performance measurement, and strategy management functions.

What are our customers and prospects deployment options?
SAP BW integrated planning will be available with SAP Netweaver BI 7.0 (Ramp-Up mid 2005). Current customers evaluating SAP planning solutions should evaluate and purchase BW-BPS (part of SAP BW 3.5) with the full comfort of knowing that their investment in BPS will be protected in the future should they wish to continue on this planning solution. Additionally, should they wish to migrate to SAP BW integrated planning, a migration strategy will be provided as well.

What are the recommendations for current SEM/BPS customers?
For current SEM-BPS customers and BW-BPS customers, their investment will continue to be supported by SAP. In this way users can expect to continue to realize the benefits of the planning capabilities with BPS and also realize the platform upgrades as future releases of SAP BW continue to evolve.
Please have a look at the presentation Decision Support for recommendations of implementing planning functionality for existing SAP SEM customers and customers planning the implementation in 2004 or 2005.

How will SAP BW integrated planning be integrated with the SEM components (Balanced Scorecard, Consolidations)?
Regarding the integration to Balanced Scorecard and Consolidation current capabilities will remain and be enhanced. The integration will still done via SAP BW InfoCubes. As a result, it will be possible to consolidate plan data in BCS. It will be possible to display plan data within the Balanced Scorecard and to drag or change it in Performance Measurement. The integration of master data will also be guaranteed using the common SAP BW data basis.

What will be delivered with SAP Netweaver BI 7.0 in regards to planning capabilities?
Step 1: SAP Netweaver BI 7.0 with BI Content Add-on 7.0.1 (mid 2005 - Ramp Up)
Features:
§ Integrated planning
§ SAP BW-BPS (former SEM-BPS)*
Existing SEM-BPS customers can use either planning capabilities. New customers can only use Integrated Planning.
Step 2: SAP Netweaver BI 7.0 with BI Content Add-on 7.0.2 (end 2005)
Features:
§ Integrated planning*
§ Planning applications**
§ Application specific planning services
§ Application specific planning services
§ Application specific planning content (pre-customized planning scenarios)
* SAP BW-BPS - former SEM-BPS will be continued to be supported in the future
** Planning Applications may be also delivered as Add-On.

If a customer has installed the SEM Add-on in the past, and wants to upgrade to SAP Netweaver BI 7.0 and subsequent SAP BW releases that contain planning functionality, will he still need to upgrade the SEM Add-on?
Yes. There are current technical limitations in the Add-on registration process that flag a system as being "Add-on" relevant, and will ask for the add-on upgrade when upgrading the core system.

Does this mean that customers have to wait for a period of time after the core SAP BW release, when the SEM Add-on and new BI Content Add-on will be available?
Yes. In order to develop the SEM and BI Add-ons based on the new SAP BW technology platform, there is typically a delay of a few months from the release date of the core SAP BW technology release, for the Add-on releases to be made available.

How are the BI Content Add-ons and the SEM Add-ons correlated?
SEM and SAP BI Content Add-Ons are built upon a core technology release of SAP BW. As such, after delivery of the BI content Add-On the corresponding SEM is available.

What exactly will be supported as a part of the migration from SEM-BPS to SAP Netweaver BI 7.0 /Content Add-on 7.0.1 integrated planning?
Customers will have the following choices:
§ Migrate to SAP BW Integrated Planning
§ No migration, just upgrade SAP BW/SEM and keep running SAP BW-BPS (former SEM-BPS) *
* Note: This selection is a "maintenance only" option, meaning that no new features will be delivered in subsequent releases for this selection. Only in the area of integrated planning are future enhancements planned.
The following objects will be migrated (manual and automatic):
§ Planning Areas*
§ Planning levels + planning packages*
§ Planning Layouts*
§ Planning Functions*
§ Variables*
§ Planning Folders*
§ User Exits*
* New technology is used to render these objects in SAP BW Integrated Planning, but the concept is the same as in SEM -BPS.
The following objects will need no migration:
§ Master Data
§ Transactional Data

FAQ - ALPHA Conversion

Frequently Asked Questions - ALPHA Conversion

What is the "ALPHA conversion" about?
A characteristic in BW can use a conversion routine like the conversion routine called ALPHA. A conversion routine converts data that a user enters (in so called external format) to an internal format before it is stored on the data base.
The most important conversion routine - due to its common use - is the ALPHA routine that converts purely numeric user input like '4711' into '004711' (assuming that the characteristic value is 6 characters long). If a value is not purely numeric like '4711A' it is left unchanged.
We have found out that in customers systems there are quite often characteristics using a conversion routine like ALPHA that have values on the data base which are not in internal format, e.g. one might find '4711' instead of '004711' on the data base.
It could even happen that there is also a value '04711', or ' 4711' (leading space).
This possibly results in data inconsistencies, also for query selection; i.e. if you select '4711', this is converted into '004711', so '04711' won't be selected.

Why is the "ALPHA conversion" necessary?
In such a case, a number of problems can arise in reporting like wrong values of key figures, no data found for certain filter values...
The "conversion of internal characteristic values", in short term: "ALPHA conversion", is a transaction (transaction code RSMDCNVEXIT) that checks the format of all values of characteristics that use one of the conversion routines ALPHA, GJAHR and NUMCV.
If values are found that do not have the correct internal format it can replace them by correct value and update all dependant BW objects (like InfoCubes, Hierarchies, master data of other characteristics...).
This transaction potentially has to touch a very significant part of all the data in BW. While running the check or conversion phase of RSMDCNVEXIT no data loads of any kind are possible; the conversion part of it cannot be interrupted. Therefore you should never start the conversion part without having thoroughly read the documentation.
We recommend to run the conversion as soon as possible.

Where do I find detailed information?
The "ALPHA conversion" transaction RSMDCNVEXIT has online documentation which you reach via its "Help" button.
OSS note 447341 is about the ALPHA conversion in general and has attached to it a number of other OSS notes describing solutions to known problems.

What are the prerequisites for the "ALPHA conversion"?
Before running ALPHA conversion, apply SP 26 (2.0B) resp. SP 18 (2.1C) resp. SP 11 (BW 3.0A).
If you have large ODS Objects (> 50 mio records in all) we recommend to apply Support Package 27 (2.0B) resp. 19 (2.1C) or the coding correction of OSS note 548122.
If you are unsure if the conversion has already been executed in your system (in a BW 3.0A system it probably has already been done during the upgrade to BW 3.0A) start transaction RSMDCNVEXIT and look at the system status: if it says "All characteristic only have correct internal values" you do not need to run it.
We recommend a database backup before you run the transaction.
If you have strong reasons not to apply the named support packages, please note that you can run the ALPHA conversion starting from SP 22 (BW2.0B) resp. SP 14(BW2.1C). If your support package level is strictly smaller than 25 (BW 2.0B) resp. 17 (BW 2.1C) you have to apply the coding correction of OSS note 528381. If you have SID tables with more than several millions of records you have to be on SP 25 (BW 2.0B) resp. 17 (BW 2.1C) and also apply a correction described in OSS note 543482.

What effects does the "ALPHA conversion" have on my BW system?
No data loads are possible while the transaction is checking or converting.
Once the conversion part has been started the conversion has to be completed. The system is in an inconsistent state in the mean time!

How long does the conversion take?
Usually, the alpha conversion requires between 3 and 20 hours for production systems. For very big systems (>1TB) , it could also take up several days.
From our experience, the most decisive factor for the duration is the size of the ODS objects. As a rough rule of thumb, approximately 2.5 mio. Records per hour can be converted within ODS objects (status BW 2.0B SP 27 resp. BW 2.1C SP 19). To improve the conversion for ODS objects, keep the change log small (i.e. delete old entries) because all change log records will be converted, too. Furthermore, the size of the master data tables (which include characters with one of the ALPHA, NUMCV or GJAHR conversions) has impact on the runtime of the upgrade.
As of BW 2.0B SP 29 resp. BW 2.1C SP 21, ODS objects can be converted in parallel. Please see note 559524 for details how to set up this parallelism.
As of BW 2.0B SP 29 resp. BW 2.1C SP 21, transaction RSMDCNVEXIT is enhanced by a workload estimate. This preliminary check lists all characteristics, database tables and the size of the tables that will be converted during the alpha conversion. Furthermore, possible meta data inconsistencies are found and the possibility of aborts during the conversion is reduced.
During the conversion process, you can check the state of the conversion in the log.
This estimate can be executed without locking the system. We recommend to run it before starting the conversion.
Please see the enhanced online help in transaction RSMDCNVEXIT for more details.

What is the interrelation between a BW upgrade and the "ALPHA conversion"?
During the prepare phase of an upgrade to BW 3.0B it is checked that the "conversion of internal characteristic values", also called "ALPHA conversion", has been successfully completed. This "ALPHA conversion" is time-consuming. Therefore we strongly recommend to separate this conversion from the actual upgrade process.

FAQ around SAP BW DeltaQueue (RSA7)

Frequently Asked Questions around SAP BW DeltaQueue (RSA7)

What does the number in the 'Total' column in Transaction RSA7 mean?
The 'Total' column displays the number of LUWs that were written in the delta queue and that have not yet been confirmed. The number includes the LUWs of the last delta request (for repetition of a delta request) and the LUWs for the next delta request. 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.

What is a LUW in the delta queue?
A LUW from the point of view of the delta queue can be an individual document, a group of documents from a collective run or a whole data packet of an application extractor.

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?
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. The detail screen displays the records contained in the LUWs. Both, 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. Thus, only the records that are ready for the next delta request are displayed on the detail screen. In the detail screen of Transaction RSA7, a possibly existing customer exit is not taken into account.

Why does Transaction RSA7 still display LUWs on the overview screen after successful delta loading?
Only when a new delta has been requested does the source system learn that the previous delta was successfully loaded to the BW System. Then, the LUWs of the previous delta may be confirmed (and also deleted). In the meantime, the LUWs must be kept for a possible delta request repetition. In particular, the number on the overview screen does not change when the first delta was loaded to the BW System.

Why are selections not taken into account when the delta queue is filled?
Filtering according to selections takes place when the system reads from the delta queue. This is necessary for reasons of performance.

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). Such a DataSource should not be displayed in RSA7. This error is corrected with BW 20B Support Package 11.

Do the entries in table ROIDOCPRMS have an impact on the performance of the loading procedure from the delta queue?
The impact is limited. If performance problems are related to the loading process from the delta queue, then refer to the application-specific notes (for example in the CO-PA area, in the logistics cockpit area and so on).
Caution: As of PlugIn 2000.2 patch 3 the entries in table ROIDOCPRMS are as effective for the delta queue as for a full update. Please note, however, that LUWs are not split during data loading for consistency reasons. This means that when very large LUWs are written to the DeltaQueue, the actual package size may differ considerably from the MAXSIZE and MAXLINES parameters.

Why does it take so long to display the data in the delta queue (for example approximately 2 hours)?
With PlugIn 2001.1 the display was changed: the user has the option of defining the amount of data to be displayed, to restrict it, to selectively choose the number of a data record, to make a distinction between the 'actual' delta data and the data intended for repetition and so on.

What is the purpose of function 'Delete data and meta data in a queue' in RSA7? What exactly is deleted?
You should act with extreme caution when you use the deletion function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. 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. Then you can only request new deltas after another delta initialization.
When you delete the data, the LUWs kept in the qRFC queue for the corresponding target system are confirmed. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs.
The deletion function is for example intended for a case where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.

Why does it take so long to delete from the delta queue (for example half a day)?
Import PlugIn 2000.2 patch 3. With this patch the performance during deletion is considerably improved.

Why is the delta queue not updated when you start the V3 update in the logistics cockpit area?
It is most likely that a delta initialization had not yet run or that the the delta initialization was not successful. 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.

What is the relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?
The qRFC monitor basically displays the same data as RSA7. The internal queue name must be used for selection on the initial screen of the qRFC monitor. This is made up of the prefix 'BW, the client and the short name of the DataSource. For DataSources whose name is 19 characters long or shorter, the short name corresponds to the name of the DataSource. For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001.1) the short name is assigned in table ROOSSHORTN.
In the qRFC monitor you cannot distinguish between repeatable and new LUWs. Moreover, the data of a LUW is displayed in an unstructured manner there.

Why are the data in the delta queue although the V3 update was not started?
Data was posted in background. Then, the records are updated directly in the delta queue (RSA7). This happens in particular during automatic goods receipt posting (MRRS). There is no duplicate transfer of records to the BW system. See Note 417189.

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, i.e. 'pure' delta records?
Was programmed in a way that the request in repeat mode fetches both actually repeatable (old) data and new data from the source system.

I loaded several delta inits with various selections. For which one is the delta loaded?
For delta, all selections made via delta inits are summed up. This means, a delta for the 'total' of all delta initializations is loaded.

How many selections for delta inits are possible in the system?
With simple selections (intervals without complicated join conditions or single values), you can make up to about 100 delta inits. It should not be more.
With complicated selection conditions, it should be only up to 10-20 delta inits.
Reason: With many selection conditions that are joined in a complicated way, too many 'where' lines are generated in the generated ABAP source code which may exceed the memory limit.

I intend to copy the source system, i.e. make a client copy. What will happen with may delta? Should I initialize again after that?
Before you copy a source client or source system, make sure that your deltas have been fetched from the DeltaQueue into BW and that no delta is pending. After the client copy, an inconsistency might occur between BW delta tables and the OLTP delta tables as described in Note 405943. After the client copy, Table ROOSPRMSC will probably be empty in the OLTP since this table is client-independent. After the system copy, the table will contain the entries with the old logical system name which are no longer useful for further delta loading from the new logical system. The delta must be initialized in any case since delta depends on both the BW system and the source system. Even if no dump 'MESSAGE_TYPE_X' occurs in BW when editing or creating an InfoPackage, you should expect that the delta has to be initialized after the copy.

Is it allowed in Transaction SMQ1 to use the functions for manual control of processes?
Use SMQ1 as an instrument for diagnosis and control only. 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 'BW-WHM-SAPI'.

Despite of the delta request being started after completion of the collective run (V3 update), it does not contain all documents. Only another delta request loads the missing documents into BW. What is the cause for this "splitting"?
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. For this reason, 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. An alternative solution where this problem does not occur is described in Note 505700.

Despite my deleting the delta init, LUWs are still written into the DeltaQueue?!
In general, delta initializations and deletions of delta inits should always be carried out at a time when no posting takes place. Otherwise, buffer problems may occur: If a user started the internal mode at a time when the delta initialization was still active, he/she posts data into the queue even though the initialization had been deleted in the meantime. This is the case in your system.

In SMQ1 (qRFC Monitor) I have status 'NOSEND'. In the table TRFCQOUT, some entries have the status 'READY', others 'RECORDED'. ARFCSSTATE is 'READ'. 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?
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. However, this does not mean that the record has successfully reached the BW yet. 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 any case only the statuses READ, READY and RECORDED in both tables are considered to be valid. The status EXECUTED in TRFCQOUT can occur temporarily. It is set before starting a DeltaExtraction for all records with status READ present at that time. 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. If you see such records, 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, or, if the records remain in the table for a longer period of time with status EXECUTED, it is likely that there are problems with deleting the records which have already been successfully been loaded into the BW. In this state, no more deltas are loaded into the BW. Every other status is an indicator for an error or an inconsistency. NOSEND in SMQ1 means nothing (see note 378903).
The value 'U' in field 'NOSEND' of table TRFCQOUT is discomforting.

The extract structure was changed when the DeltaQueue was empty. Afterwards new delta records were written to the DeltaQueue. When loading the delta into the PSA, it shows that some fields were moved. The same result occurs when the contents of the DeltaQueue are listed via the detail display. 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. We recommend to reset the buffers using Transaction $SYNC. If the extract structure change is not communicated synchronously to the server where delta records are being created, the records are written with the old structure until the new structure has been generated. This may have disastrous consequences for the delta.
When the problem occurs, the delta needs to be re-initialized.

How and where can I control whether a repeat delta is requested?
Via the status of the last delta in the BW Request Monitor. If the request is RED, the next load will be of type 'Repeat'. If you need to repeat the last load for certain reasons, set the request in the monitor to red manually. For the contents of the repeat see Question 14. Delta requests set to red despite of data being already updated lead to duplicate records in a subsequent repeat, if they have not been deleted from the data targets concerned before.

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?
There is no strict limit (except for the restricted number range of the 24-digit QCOUNT counter in the LUW management table - which is of no practical importance, however - or the restrictions regarding the volume and number of records in a database table).
When estimating "smooth" limits, both the number of LUWs is important and the average data volume per LUW. 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 set in the applications, e.g. in the Logistics Cockpit). 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 volumen of about 1GByte per work process, 100 MByte per LUW should not be exceeded). That limit is of rather small practical importance as well since a comparable limit already applies when writing to the DeltaQueue. If the limit is observed, correct reading is guaranteed in most cases.
If the number of LUWs cannot be reduced by bundling application transactions, you should at least make sure that the data are fetched from all connected BWs as quickly as possible. But for other, BW-specific, reasons, the frequency should not be higher than one DeltaRequest per hour.
To avoid memory problems, a program-internal limit ensures that never more than 1 million LUWs are read and fetched from the database per DeltaRequest. If this limit is reached within a request, the DeltaQueue must be emptied by several successive DeltaRequests. We recommend, however, 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.

Thursday, October 25, 2007

How-to Guides for SAP NetWeaver 2004 Business Intelligence

This is a collection of How-to Guides that provide expert advice and tips and tricks on a broad range of topics and challenges. These guides are based on SAP NetWeaver 2004 Business Intelligence.

How to Data Recovery in SAP BW Systems

How to Create and Maintain UI Patterns of BI Content

How to Dynamically Call DataSource Specific Programs in Source System User-Exits

How to Web Printing QuickStart in SAP NetWeaver '04

How to Create Support Messages from BPS Web Interfaces

How to Archive in BW

How to BPS Variables of Type Exit

How to Calculate Balance Sheet Key Figures Using BEx Query Designer

How to Call a BPS Web Interface with Predefined Selections

How to Change the Maximum Dialog Runtime of a Process

How to Configure UD Connect on the J2EE Server to External Data Bases

How to Create Efficient Multi Provider Queries

How to Create Generic Data Sources Which Use the Delta Queue

How to Create Monitor Entries from an Update Routine

How to Disaggregate on Upload

How to Download a Hierarchy to a Flat File

How to Enable SAP BW Web Functionality After a New BW Installation

How to Execute a Planning Sequence in Batch from Business Planning and Simulation - BPS

How to Extract Archived R3 Data via the Archiving Information System

How to Handle Inventory Management Scenarios

How to Hierarchies in Several Characteristics

How to Implement a Virtual InfoCube with Service

How to Implement Business Scenarios for Customer Loyalty Management

How to Implement Custom Process Types

How to Integrate an ABAP Program in a Process Chain

How to Integrate BEx Web Applications into BPS Web Interfaces

How to Integrate BEx Web Applications into SAP Solution Manager

How to Load Balancing For Data Load Processing and Warehouse

How to Loop over Reference Data in Fox Formulas

How to Line Items in BW-BPS

How to Minimize Downtime For Delta Initialization

How to Reconcile Data Between SAP Source Systems and SAP NetWeaver BI

How to Run Planning Sequences on Save and Other Events

How to SAP BW 3.5 Upgrade Prep and Post- Upgrade Checklist

How to SAP BW Unicode with an MDMP Source System

How to Select Multiple Values in a Dropdown Box

How to System Copy in SAP BI System Landscapes

How to Trigger an ALERT from a Process Chain

How to Use Reporting Variables in BW-BPS

How to Use SAP GUI Planning Folders with the ST System

How to Validate InfoCube Data by Comparing it with PSA Data

How to Validate Key Figure Values in Manual Planning

How to Work With Hierarchy Authorizations

How to Save Data into a Flat File in BW-BPS Using SAPGUI

How to Load a Flat File into BW-BPS Using SAPGUI

How to Load a Flat File into BW-BPS Using a Web Browser

How to Upload User-Specific Variable Selections in BW-BPS

Integration Scenarios /Cross Component

How to Push Data from BI to XI

How to Push Data into BW from XI

How to Integrate the BW Reporting Agent With the Alert Framework

How to Expose a BW Query As Web Service in a UDDI Registry