Some useful T-Code for BI performance tuning

T-Code	Description
SM66	Global Work Process Overview
ST02	Tune Summary
ST06	System monitor
STAD	SAP workload
ST05	SQL Trace
SE30	ABAP Trace
ST12	Single transaction analysis(including ST05/ST30)
RSMO	BW Load monitor
DB02	DB Load overview
ST04	DB Performance snapshot
RSBATCH	BI Background management
RSODSO_SETTINGS	Maintenance of runtime parameter of DSO
RSRV	Analysis and repair BI Objects
ST03	Workload in system
RSRT	Query Monitor
RSRTRACE	Configure Trace Tool

Disadvantages of AGGREGATES, COMPRESSION, IC PARTIONING, INDEXES, LINE ITEM DIMENSIONS

Disadvantages of 

(1) AGGREGATES

Even though Aggregates are used for performance, but it will decrease the same when you create more aggregates. 

Until Rollup takes place the query won't hit the aggregate Cube

Aggregates - its main disadvantage is that it stores data physically as a redundant, more aggregates will cause waste of memory.

(2) COMPRESSION

Once Cube is compressed, then all the request number will be removed and hence deletion by request id is no more possible.

Compression- compressed request cannot be got back to normal, deletion is difficult

(3) Partition

Partition Handling for several thousand partitions is usually impacting DB performance.

IC partition  - partition cannot be done after data loaded (3.X) but repartition is possible in BI 7.0

(4) INDEXES

If you don't drop the index before loading then the data load will be slow

If you don't create the index before the reporting then the reporting will be slow

Index- for large volume of data create and delete index consume lot of time

(5) LINE ITEM DIMENSIONS

This can be set when you have one only characteristic in the Dim table.

Line item - more number of line item cannot be used as number char used will be reduced.

What is reconciliation?

Reconciliation is nothing but the comparison of the values between BW target data with the Source system data like R/3.

In general this process is taken at 3 places one is comparing the info provider data with R/3 data, Compare the Query display data with R/3 or DSO data and Checking the data available in info provider kefigure with PSA key figure values.

Archiving the data in SAP BI

Archiving is used to store your data at a remote location to improve the performance in BI.

Archiving is a process of moving the data from the sap database to storage system which is not required online and archived data can be read offline when ever user required. 

Archiving helps to increase more database size, improvement of the system performance will take care to a greater extant and cost effectiveness for the client with respect to hardware. 

We use archiving process in various SAP application areas. We can archive Master data and Transactional datas. 

Master data such as Customer master data, Vendor master data, Material master data, Batch master data and so on... 

Transaction data such as Sales order, Delivery document, shipment document, Billing document, Purchase requisition, Purchase order, Production Order, Transfer order, Account receivables, Account payables, and so on

Steps should be followed for Archiving in 7.0:

1. Go to transaction -: RSDAP

2. Give info provider name & type- create.

3: Go to General Settings - Give archiving object name.

4. Selection Profile tab- schedule time.

5. ADH (tab)- Specify logical file name.

6. Activate - make sure you copy your archiving object name.

7. go to t-code : SARA give your object name.& click "write request"

8. now create a variable & click on variable & click on MAINTAIN.

9. select a field Then- CONTINUE

10. go to "FURTHER RESTRICTION(tab)"give a value

11. go to to processing options: click on production mode.

12. save 

13. Attribute (tab): give a name & save

14. give start date & print parameters. 

15. Execute.

Usage of compound attribute in reporting

Compounding attribute lets you derive a unique data records in the reporting. 

Suppose you have a cost center and cost accounts like this and you want to maintain proper relation:

Cost centers: 1000, 1001, 1002

Cost accounts: 9001,9001,9003

The cost accounts are not unique across cost centers and the master data will be over written.

So the cost accounts across cost centers cannot be differentiated. 

When you add the cost centers ac compounding attribute a unique record will be present. After compounding the records will look unique like below in reporting:

9001/1000

9002/1000

9003/1000

9001/1001

9002/1001

9003/1001

9001/1002

9002/1002

9003/1002

Thus differentiating each cost account across cost centers uniquely.

Importance of semantic groups in DTP

Semantic Groups to specify how you want to build the data packages that are read from the source (DataSource or InfoProvider). To do this, define key fields. Data records that have the same key are combined in a single data package. 

This setting is only relevant for Data Store objects with data fields that are overwritten. This setting also defines the key fields for the error stack. By defining the key for the error stack, you ensure that the data can be updated in the target in the correct order once the incorrect data records have been corrected.

A very simple example:

Lets say there are two records in the input stream of data for a DTP.

Product   Material 

P1           M1 XYZ 

P1           M1 PQR 

If the data gets divided into multiple packets while getting processed, the above two records might go into separate data packets. In case you have defined semantic group in DTP with product and material, system will always put these two records together. This is sometimes required when it is needed to process all such records together, for eg., in start routine.

Semantic Groups are to specify how you want to build the data packages that are read from the source. To do this, you determine key fields. Data records that have the same key are combined in one data package. Currently, only data that has been read from the PSA can be processed further in semantic groups.

This setting also determines the key fields for the error stack. 

In bw3.x infopackage directly transfers the data to targets but in BI 7 infopackage will only bring data to PSA, Data Transformation Processing will transfer the data from PSA tothe target. PSA is only staging area this will not be a target (we can’t do anything here)

Rule types in transformations

1.Constant 

2.Direct Assignment 

3.Formula 

4.Read Master data 

5.No Transformation 

6.Routine

behavior of transfer routine at characteristic level in transformations

When you create a transfer routine, it is valid globally for the characteristic and is included in all the transformation rules that contain the InfoObject. However, the transfer routine is only run in one transformation with a DataSource as a source. The transfer routine is used to correct data before it is updated in the characteristic. 

During data transfer, the logic stored in the individual transformation rule is executed first. Then the transfer routine for the value of the corresponding field is executed for each InfoObject that has a transfer routine. 

In this way, the transfer routine can store InfoObject-dependent coding that only needs to be maintained once, but that is valid for all transformation rules.

What is the impact on existing routines if we create expert routine?

Automatically existing routines will be deleted or deactive. 

We have following types of routines in BI 7. 

Start Routine:

The start routine is run for each data package at the start of the transformation. The start routine has a table in the format of the source structure as input and output parameters. It is used to perform preliminary calculations and store these in a global data structure or in a table. This structure or table can be accessed from other routines. You can modify or delete data in the data package.

Routine for Key Figures or Characteristics:

This routine is available as a rule type; you can define the routine as a transformation rule for a key figure or a characteristic. The input and output values depend on the selected field in the transformation rule. 

End Routine:

An end routine is a routine with a table in the target structure format as input and output parameters. You can use an end routine to post process data after transformation on a package-by-package basis. For example, you can delete records that are not to be updated, or perform data checks.

Expert Routine:

This type of routine is only intended for use in special cases. You can use the expert routine if there are not sufficient functions to perform a transformation. The expert routine should be used as an interim solution until the necessary functions are available in the standard routine. 

Difference among start routines, end routines and expert routines

Start Routine: Start routine runs before the transformation rules. It manipulates the source data package. The source data package is in the structure of data source. The start routine has a table in the format of the source structure as input and output parameters. It is used to perform preliminary calculations and store these in a global data structure or in a table. This structure or table can be accessed from other routines. You can modify or delete data in the data package. Generally used for Filtering records.

End Routine: End routine runs after the transformation rules. It manipulates the target data package. The result package is in the structure of the target object. It is a routine with a table in the target structure format as input and output parameters. You can use an end routine to post process data after transformation on a package-by-package basis. For example, you can delete records that are not to be updated, or perform data checks. 

Expert Routine: This will trigger without any transformation Rule. Whenever we try to write a expert routine, all existing rules are deleted. This is used generally for customizing rules. It is helpful if complex or better performing transformations are needed. 

When we use write optimized DSO?

Write optimized DSO used to pull large volume of data 

a. Used where fast loads are essential. Example: multiple loads per day (or) short source system access times (world wide system landscapes). 

i) If the Data Source is not delta enabled. In this case, you would want to     have a Write-Optimized DataStore to be the first stage in BI and then pull the Delta request to a cube. 

ii) Write-optimized DataStore object is used as a temporary storage area for large sets of data when executing complex transformations for this data before it is written to the DataStore object. Subsequently, the data can be updated to further InfoProviders. You only have to create the complex transformations once for all incoming data. 

b. Write-optimized DataStore objects can be the staging layer for saving data. Business rules are only applied when the data is updated to additional InfoProviders. 

c. If you want to retain history at request level. In this case you may not need to have PSA archive; instead you can use Write-Optimized DataStore. 

d. If a multi dimensional analysis is not required and you want to have operational reports, you might want to use Write Optimized DataStore first, and then feed data into Standard Datastore. 

e. Probably you can use it for preliminary landing space for your incoming data from diffrent sources. 

f. If you want to report daily refresh data with out activation.In this case it can be used in reporting layer with InfoSet (or) MultiProvider. 

Functionality of Write-Optimized DataStore 

Only active data table (DSO key: request ID, Packet No, and Record No): 

o No change log table and no activation queue. 

o Size of the DataStore is maintainable. 

o Technical key is unique. 

o Every record has a new technical key, only inserts. 

o Data is stored at request level like PSA table. 

No SID generation: 

o Reporting is possible(but you need make sure performance is optimized ) 

o BEx Reporting is switched off. 

o Can be included in InfoSet or Multiprovider. 

o Performence improvement during dataload. 

Fully integrated in data flow: 

o Used as data source and data target 

o Export into info providers via request delta 

Uniqueness of Data: 

o Checkbox “Do not check Uniqueness of data”. 

o If this indicator is set, the active table of the DataStore object could contain 

several records with the same key. 

Allows parallel load. 

Can be included in Process chain with out activation step. 

Supports Archiving.

Difference between SAP BI 3.x, 7.0, 7.3

Major Differences between Sap Bw 3.5 & Sap BI 7.0 version:

1. In Infosets now you can include Infocubes as well.

2. The Remodeling transaction helps you add new key figure and characteristics and handles historical data as well without much hassle. This is only for info cube.

3. The BI accelerator (for now only for infocubes) helps in reducing query run time by almost a factor of 10 - 100. This BI accelerator is a separate box and would cost more. Vendors for these would be HP or IBM.

4. The monitoring has been improved with a new portal based cockpit. Which means you would need to have an EP guy in your project for implementing the portal !

5. Search functionality has improved!! You can search any object. Not like 3.5

6. Transformations are in and routines are passe! Yes, you can always revert to the old transactions too.

7. The Data Warehousing Workbench replaces the Administrator Workbench.8. Functional enhancements have been made for the DataStore object: New type of DataStore object Enhanced settings for performance optimization of DataStore objects.

9. The transformation replaces the transfer and update rules.

10. New authorization objects have been added

11. Remodeling of InfoProviders supports you in Information Lifecycle Management.

12 The Data Source:

There is a new object concept for the Data Source.

Options for direct access to data have been enhanced.From BI, remote activation of Data Sources is possible in SAP source systems.

13.There are functional changes to the Persistent Staging Area (PSA).14.BI supports real-time data acquisition.

15 SAP BW is now known formally as BI (part of NetWeaver 2004s). It implements the Enterprise Data Warehousing (EDW). The new features/ Major differences include :

a) Renamed ODS as DataStore.

b) Inclusion of Write-optmized DataStore which does not have any change log and the requests do need any activation

c) Unification of Transfer and Update rules

d) Introduction of "end routine" and "Expert Routine"

e) Push of XML data into BI system (into PSA) without Service API or Delta Queue

f) Intoduction of BI accelerator that significantly improves the performance.

16. Load through PSA has become a mandatory. You can't skip this, and also there is no IDoc transfer method in BI 7.0. DTP (Data Transfer Process) replaced the Transfer and Update rules. Also in the Transformation now we can do "Start Routine, Expert Routine and End Routine". during data load.

New features in BI 7 compared to earlier versions:

i. New data flow capabilities such as Data Transfer Process (DTP), Real time data Acquisition (RDA).

ii. Enhanced and Graphical transformation capabilities such as Drag and Relate options.

iii. One level of Transformation. This replaces the Transfer Rules and Update Rulesiv. Performance optimization includes new BI Accelerator feature.

v. User management (includes new concept for analysis authorizations) for more flexible BI end user authorizations.

ASAP Methodologies

ASAP stands for Accelerated SAP. Its purpose is to help design SAP implementation in the most efficient manner possible. Its goal is to effectively optimize time, people, quality and other resources, using a proven methodology to implementation. ASAP focuses on tools and training, wrapped up in a five-phase process oriented road map for guiding implementation.The road map is composed of five well-known consecutive phases:

• Phase 1 Project Preparation
• Phase 2 Business Blueprint
• Phase 3 Realization
• Phase 4 Final Preparation
• Phase 5 Go-Live and supportIn today's post we will discuss the first phase.

Phase 1 : Project PreparationPhase

One initiates with a retrieval of information and resources. It is an important time to assemble the necessary components for the implementation. Some important milestones that need to be accomplished for phase 1 include

• Obtaining senior-level management/stakeholder support
• identifying clear project objectives
• architect an efficient decision-making process
• creating an environment suitable for change and re-engineering
• building a qualified and capable project team.

Senior level management support:

One of the most important milestones with phase 1 of ASAP is the full agreement and cooperation of the important company decision-makers - key stake holders and others. Their backing and support is crucial for a successful implementation.

Clear project objectives:

be concise in defining what your objectives and expectations are for this venture. Vague or unclear notions of what you hope to obtain with SAP will handicap the implementation process. Also make sure that your expectations are reasonable considering your company's resources. It is essential to have clearly defined ideas, goals and project plans devised before moving forward.

An efficient decision making process:

One obstacle that often stalls implementation is a poorly constructed decision-making process. Before embarking on this venture, individuals need to be clearly identified. Decide now who is responsible for different decisions along the way. From day one, the implementation decision makers and project leaders from each area must be aware of the onus placed on them to return good decisions quickly.

Environment suitable for change and re engineering: Your team must be willing to accept that, along with new SAP software, things are going to change, the business will change, and information technology enabling the business will change as well. By implementing SAP, you will essentially redesign your current practices to model more efficient or predefined best business practices as espoused by SAP. Resistance to this change will impede the progress of your implementation.

ASAP- Second Phase- Business Blueprint

SAP has defined a business blueprint phase to help extract pertinent information about your company that is necessary for implementation. These blueprints are in the form of questionnaires that are designed to probe for information that uncovers how your company does business. As such, they also serve to document the implementation. Each business blueprint document essentially outlines your future business processes and business requirements. The kinds of questions asked are germane to the particular business function, as seen in the following sample questions:

1) What information do you capture on a purchase order?

2) What information is required to complete a purchase order?

Accelerated SAP question and answer database: The question and answer database (QADB) is a simple although aging tool designed to facilitate the creation and maintenance of your business blueprint. This database stores the questions and the answers and serves as the heart of your blue print. Customers are provided with a customer input template for each application that collects the data. The question and answer format is standard across applications to facilitate easier use by the project team.

Issues database:

Another tool used in the blueprinting phase is the issues database. This database stores any open concerns and pending issues that relate to the implementation. Centrally storing this information assists in gathering and then managing issues to resolution, so that important matters do not fall through the cracks. You can then track the issues in database, assign them to team members, and update the database accordingly.

ASAP Phase- 3 - Realization:

With the completion of the business in phase 2, "functional" experts are now ready to begin configuring SAP. The Realization phase is broken in to two parts.

1) Your SAP consulting team helps you configure your baseline system, called the baseline configuration.

2) Your implementation project team fine-tunes that system to meet all your business and process requirements as part of the fine tuning configuration.

The initial configuration completed during the base line configuration is based on the information that you provided in your blueprint document. The remaining approximately 20% of your configuration that was not tackled during the baseline configuration is completed during the fine tuning configuration. Fine tuning usually deals with the exceptions that are not covered in baseline configuration. This final bit of tweaking represents the work necessary to fit your special needs.

Configuration Testing:

With the help of your SAP consulting team, you segregate your business processes into cycles of related business flows. The cycles serve as independent units that enable you to test specific parts of the business process. You can also work through configuring the SAP implementation guide (IMG). A tool used to assist you in configuring your SAP system in a step by step manner.

Knowledge Transfer:

As the configuration phase comes to a close, it becomes necessary for the Project team to be self-sufficient in their knowledge of the configuration of your SAP system. Knowledge transfer to the configuration team tasked with system maintenance (that is, maintenance of the business processes after Go-live) needs to be completed at this time.In addition, the end users tasked with actually using the system for day-to-day business purposes must be trained.

ASAP Methodology - Phase 4 - Final Preparation:

As phase 3 merges into phase 4, you should find yourselves not only in the midst of SAP training, but also in the midst of rigorous functional and stress testing. Phase 4 also concentrates on the fine tuning of your configuration before Go-live and more importantly, the migration of data from your old system or systems to SAP.

Workload testing (including peak volume, daily load, and other forms of stress testing), and integration or functional testing are conducted to ensure the accuracy of your data and the stability of your SAP system. Because you should have begun testing back in phase 2, you do not have too far to go until Go-live. Now is an important time to perform preventative maintenance checks to ensure optimal performance at your SAP system.At the conclusion of phase 4, take time to plan and document a Go-live strategy. Preparation for Go-live means preparing for your end-users questions as they start actively working on the new SAP system.

ASAP - Phase 5 - Go-live and Support:

The Go-live milestone is itself is easy to achieve; a smooth and uneventful Go-live is another matter altogether. Preparation is the key, including attention to what-if scenarios related not only to the individual business processes deployed but also to the functioning of technology underpinning these business processes and preparation for ongoing support, including maintenance contracts and documented processes and procedures are essential. 

SAP BW Monitoring Tool

SAP BW Monitoring Tool

Language Translation of BI objects

Language Translation of BI objects

How to Extract Sales Order data from SAP R/3 to BI using generic DataSources

How to Extract Sales Order data from SAP R/3 to BI using generic DataSources

Remodeling of Info Providers

Remodeling of Info Providers

Step-by-Step tutorial to upload Master Data from Flat File (SourceSystem) to InfoObjects (Master data table)

Step-by-Step Procedure to upload Master Data from Flat File

Creating Process Chains for DSO

A process chain is a sequence of processes that are scheduled to wait in the background for an event. Some of these processes trigger a separate event that can, in turn, start other processes. It looks similar to a flow chart. You define the list of Infopackages / DTPs that is needed to load the data, say delta or Full load. Then you schedule the Process chain as hourly, daily, monthly, etc, depending on the requirement 

Use: If you want to automatically load and schedule a hierarchy, you can include this as an application process in the procedure for a Process Chain 

Note: Before you define process chains, you need to have the Objects ready i.e DSO, Cubes etc 

Steps to Create Process Chains 

Step 1: Go to RSPC transaction. Click on Create. Give Process chain name and Description. 

Step 2: Give the Start process name and description and click on Enter 

Note: Each process chain should start with a Start Process 

Step 3: The next screen will show the Scheduling options. 

There are two options:

Direct Scheduling:

Start Using Meta Chain or API 

In my example I have chosen Direct Scheduling as I am processing only one chain i.e DSO. Click on “Change Selections” 

In the below screen shot, you can give the scheduling details i.e the Immediate, Date& time etc. and click on SAVE 

The Screen shot below indicates that we have started the process. 

Step 4:

Click on the icon process types as shown in the below figure. You will get a list of options.

In my example I am scheduling for DSO. To process we need to have InfoPackage, DTP’s for the corresponding DSO

Open the tree Load Process and Post Processing, We need to drag and drop “Execute InfoPackage” 

Step 5: Once you drag and drop the “Execute infopackage” we get the below Popup. We need to keyin the Infopackage name. To do this click on F4 and chose your Infopackage and click onENTER

Step 6: Once you drag & drop the InfoPackage, the corresponding DTP’s and the corresponding Active Data table are automatically called. 

Step 7: Save + Activate and Execute the Process.

Step 8: Once the process is completed, we can see the whole chain converted to Green, Which indicates the process is successfully completed 

Note: In case of errors in any step, the particular chain will be displayed in red 

Step 9: We can see if the data is successfully updated by Right-click on the Data store Data

Step 10: On selecting Administer Data Target, will lead you to InfoProvider Administration. 

Step 11: Click on “Active Data” tab to see the data successfully uploaded. 

Note:

Similarly the process can be done for Cubes, Master data and Transactional data

When you create Process chains, by default they are stored in “Not Assigned”. If you want to create your own folders, 

a) Click on the icon “Display Components” on your toolbar => choose F4 => Create

b) Give appropriate name for the folder => Enter

c) SAVE + ACTIVATE

Changes in BI 7.0 and BW 3.5

Below are the major changes in BI 7.0 or 2004S version when compared with earlier versions.

• In Infosets now you can include Infocubes as well. 
• The Remodeling transaction helps you add new key figure and characteristics and handles historical data as well without much hassle. This is only for info cube. 
• The BI accelerator (for now only for infocubes) helps in reducing query run time by almost a factor of 10 - 100. This BI accl is a separate box and would cost more. Vendors for these would be HP or IBM. 
• The monitoring has been improved with a new portal based cockpit. Which means you would need to have an EP guy in ur project for implementing the portal ! 
• Search functionality has improved!! You can search any object. Not like 3. 
• Transformations are in and routines are passe! Yes, you can always revert to the old transactions too 
• Renamed ODS as DataStore. 
• Inclusion of Write-optimized DataStore which does not have any change log and the requests do need any activation 
• Unification of Transfer and Update rules 
• Introduction of "end routine" and "Expert Routine" 
• Push of XML data into BI system (into PSA) without Service API or Delta Queue 
• Introduction of BI accelerator that significantly improves the performance. 
• Load through PSA has become a must. It looks like we would not have the option to bypass the PSA during data load.

 Metadata Search (Developer Functionality) :

• It is possible to search BI metadata (such as InfoCubes, InfoObjects, queries, Web templates) using the TREX search engine. This search is integrated into the Metadata Repository, the Data Warehousing Workbench and to some degree into the object editors. With the simple search, a search for one or all object types is performed in technical names and in text.
• During the text search, lower and uppercase are ignored and the object will also be found when the case in the text is different from that in the search term. With the advanced search, you can also search in attributes. These attributes are specific to every object type. Beyond that, it can be restricted for all object types according to the person who last changed it and according to the time of the change.
• For example, you can search in all queries that were changed in the last month and that include both the term "overview" in the text and the characteristic customer in the definition. Further functions include searching in the delivered (A) version, fuzzy search and the option of linking search terms with "AND" and "OR".
• "Because the advanced search described above offers more extensive options for search in metadata, the function ""Generation of Documents for Metadata"" in the administration of document management (transaction RSODADMIN) was deleted. You have to schedule (delta) indexing of metadata as a regular job (transaction RSODADMIN). 

Effects on Customizing

Installation of TREX search engine

Creation of an RFC destination for the TREX search engine

Entering the RFC destination into table RSODADMIN_INT

Determining relevant object types

Initial indexing of metadata

Remote Activation of DataSources (Developer Functionality) : 

1. When activating Business Content in BI, you can activate DataSources remotely from the BI system. This activation is subject to an authorization check. You need role SAP_RO_BCTRA. Authorization object S_RO_BCTRA is checked. The authorization is valid for all DataSources of a source system. When the objects are collected, the system checks the authorizations remotely, and issues a warning if you lack authorization to activate the DataSources.

2. In BI, if you trigger the transfer of the Business Content in the active version, the results of the authorization check are based on the cache. If you lack the necessary authorization for activation, the system issues a warning for the DataSources. BW issues an error for the corresponding source-system-dependent objects (transformations, transfer rules, transfer structure, InfoPackage, process chain, process variant). In this case, you can use Customizing for the extractors to manually transfer the required DataSources in the source system from the Business Content, replicate them in the BI system, and then transfer the corresponding source-system-dependent objects from the Business Content. If you have the necessary authorizations for activation, the DataSources in the source system are transferred to the active version and replicated in the BI system. The source-system-dependent objects are activated in the BI system. 

3. Source systems and/or BI systems have to have BI Service API SAP NetWeaver 2004s at least; otherwise remote activation is not supported. In this case, you have to activate the DataSources in the source system manually and then replicate them to the BI system.

Copy Process Chains (Developer Functionality): 

You find this function in the Process Chain menu and use it to copy the process chain you have selected, along with its references to process variants, and save it under a new name and description.

InfoObjects in Hierarchies (Data Modeling):

1. Up to Release SAP NetWeaver 2004s, it was not possible to use InfoObjects with a length longer than 32 characters in hierarchies. These types of InfoObjects could not be used as a hierarchy basic characteristic and it was not possible to copy characteristic values for such InfoObjects as foreign characteristic nodes into existing hierarchies. From SAP NetWeaver 2004s, characteristics of any length can be used for hierarchies.

2. To load hierarchies, the PSA transfer method has to be selected (which is always recommended for loading data anyway). With the IDOC transfer method, it continues to be the case that only hierarchies can be loaded that contain characteristic values with a length of less than or equal to 32 characters.

Parallelized Deletion of Requests in DataStore Objects (Data Management) :

Now you can delete active requests in a DataStore object in parallel. Up to now, the requests were deleted serially within an LUW. This can now be processed by package and in parallel.

Object-Specific Setting of the Runtime Parameters of DataStore Objects (Data Management):

Now you can set the runtime parameters of DataStore objects by object and then transport them into connected systems. The following parameters can be maintained:

- Package size for activation

- Package size for SID determination

- Maximum wait time before a process is designated lost

- Type of processing: Serial, Parallel(batch), Parallel (dialog)

- Number of processes to be used

- Server/server group to be used

Enhanced Monitor for Request Processing in DataStore Objects (Data Management):

1. for the request operations executed on DataStore objects (activation, rollback and so on), there is now a separate, detailed monitor. In previous releases, request-changing operations are displayed in the extraction monitor. When the same operations are executed multiple times, it will be very difficult to assign the messages to the respective operations.

2. In order to guarantee a more simple error analysis and optimization potential during configuration of runtime parameters, as of release SAP NetWeaver 2004s, all messages relevant for DataStore objects are displayed in their own monitor.

Write-Optimized DataStore Object (Data Management):

1. Up to now it was necessary to activate the data loaded into a DataStore object to make it visible to reporting or to be able to update it to further InfoProviders. As of SAP NetWeaver 2004s, a new type of DataStore object is introduced: the write-optimized DataStore object. 

2. The objective of the new object type is to save data as efficiently as possible in order to be able to further process it as quickly as possible without addition effort for generating SIDs, aggregation and data-record based delta. Data that is loaded into write-optimized DataStore objects is available immediately for further processing. The activation step that has been necessary up to now is no longer required.

3. The loaded data is not aggregated. If two data records with the same logical key are extracted from the source, both records are saved in the DataStore object. During loading, for reasons of efficiency, no SID values can be determined for the loaded characteristics. The data is still available for reporting. However, in comparison to standard DataStore objects, you can expect to lose performance because the necessary SID values have to be determined during query runtime.

Deleting from the Change Log (Data Management):

The Deletion of Requests from the Change Log process type supports the deletion of change log files. You select DataStore objects to determine the selection of requests. The system supports multiple selections. You select objects in a dialog box for this purpose. The process type supports the deletion of requests from any number of change logs.

Using InfoCubes in InfoSets (Data Modeling):

1. You can now include InfoCubes in an InfoSet and use them in a join. InfoCubes are handled logically in InfoSets like DataStore objects. This is also true for time dependencies. In an InfoCube, data that is valid for different dates can be read.

2. For performance reasons you cannot define an InfoCube as the right operand of a left outer join. SAP does not generally support more than two InfoCubes in an InfoSet.

Pseudo Time Dependency of DataStore Objects and InfoCubes in InfoSets (Data Modeling) :

In BI only master data can be defined as a time-dependent data source. Two additional fields/attributes are added to the characteristic. DataStore objects and InfoCubes that are being used as InfoProviders in the InfoSet cannot be defined as time dependent. As of SAP NetWeaver 2004s, you can specify a date or use a time characteristic with DataStore objects and InfoCubes to describe the validity of a record. These InfoProviders are then interpreted as time-dependent data sources.

Left Outer: Include Filter Value in On-Condition (Data Modeling) : 

The global properties in InfoSet maintenance have been enhanced by one setting Left Outer: Include Filter Value in On-Condition. This indicator is used to control how a condition on a field of a left-outer table is converted in the SQL statement. This affects the query results:

• If the indicator is set, the condition/restriction is included in the on-condition in the SQL statement. In this case the condition is evaluated before the join.
• If the indicator is not set, the condition/restriction is included in the where-condition. In this case the condition is only evaluated after the join.
• The indicator is not set by default. 

Key Date Derivation from Time Characteristics (Data Modeling) : 

Key dates can be derived from the time characteristics 0CALWEEK, 0CALMONTH, 0CALQUARTER, 0CALYEAR, 0FISCPER, 0FISCYEAR: It was previously possible to specify the first, last or a fixed offset for key date derivation. As of SAP NetWeaver 2004s, you can also use a key date derivation type to define the key date.

Repartitioning of InfoCubes and DataStore Objects (Data Management):

With SAP NetWeaver 2004s, the repartitioning of InfoCubes and DataStore objects on the database that are already filled is supported. With partitioning, the runtime for reading and modifying access to InfoCubes and DataStore objects can be decreased. Using repartitioning, non-partitioned InfoCubes and DataStore objects can be partitioned or the partitioning schema for already partitioned InfoCubes and DataStore objects can be adapted.

Remodeling InfoProviders (Data Modeling):

1. As of SAP NetWeaver 2004s, you can change the structure of InfoCubes into which you have already loaded data, without losing the data. You have the following remodeling options:

2. For characteristics:

• Inserting, or replacing characteristics with: Constants, Attribute of an InfoObject within the same dimension, Value of another InfoObject within the same dimension, Customer exit (for user-specific coding).
• Delete

3. For key figures:

• Inserting: Constants, Customer exit (for user-specific coding).
• Replacing key figures with: Customer exit (for user-specific coding).
• Delete

4. SAP NetWeaver 2004s does not support the remodeling of InfoObjects or DataStore objects. This is planned for future releases. Before you start remodeling, make sure:

(A) You have stopped any process chains that run periodically and affect the corresponding InfoProvider. Do not restart these process chains until remodeling is finished.

(B) There is enough available tablespace on the database.

After remodeling, check which BI objects that are connected to the InfoProvider (transformation rules, MultiProviders, queries and so on) have been deactivated. You have to reactivate these objects manually 

Parallel Processing for Aggregates (Performance):

1. The change run, rollup, condensing and checking up multiple aggregates can be executed in parallel. Parallelization takes place using the aggregates. The parallel processes are continually executed in the background, even when the main process is executed in the dialog. 

2. This can considerably decrease execution time for these processes. You can determine the degree of parallelization and determine the server on which the processes are to run and with which priority.

3. If no setting is made, a maximum of three processes are executed in parallel. This setting can be adjusted for a single process (change run, rollup, condensing of aggregates and checks). Together with process chains, the affected setting can be overridden for every one of the processes listed above. Parallelization of the change run according to SAP Note 534630 is obsolete and is no longer being supported.

Multiple Change Runs (Performance):

1. You can start multiple change runs simultaneously. The prerequisite for this is that the lists of the master data and hierarchies to be activated are different and that the changes affect different InfoCubes. After a change run, all affected aggregates are condensed automatically.

2. If a change run terminates, the same change run must be started again. You have to start the change run with the same parameterization (same list of characteristics and hierarchies). SAP Note 583202 is obsolete.

Partitioning Optional for Aggregates (Performance):

1. Up to now, the aggregate fact tables were partitioned if the associated InfoCube was partitioned and the partitioning characteristic was in the aggregate. Now it is possible to suppress partitioning for individual aggregates. If aggregates do not contain much data, very small partitions can result. This affects read performance. Aggregates with very little data should not be partitioned.

2. Aggregates that are not to be partitioned have to be activated and filled again after the associated property has been set.

MOLAP Store (Deleted) (Performance):

Previously you were able to create aggregates either on the basis of a ROLAP store or on the basis of a MOLAP store. The MOLAP store was a platform-specific means of optimizing query performance. It used Microsoft Analysis Services and, for this reason, it was only available for a Microsoft SQL server database platform. Because HPA indexes, available with SAP NetWeaver 2004s, are a platform-independent alternative to ROLAP aggregates with high performance and low administrative costs, the MOLAP store is no longer being supported.

Data Transformation (Data Management):

1. A transformation has a graphic user interfaces and replaces the transfer rules and update rules with the functionality of the data transfer process (DTP). Transformations are generally used to transform an input format into an output format. A transformation consists of rules. A rule defines how the data content of a target field is determined. Various types of rule are available to the user such as direct transfer, currency translation, unit of measure conversion, routine, read from master data. 

2. Block transformations can be realized using different data package-based rule types such as start routine, for example. If the output format has key fields, the defined aggregation behavior is taken into account when the transformation is performed in the output format. Using a transformation, every (data) source can be converted into the format of the target by using an individual transformation (one-step procedure). An InfoSource is only required for complex transformations (multistep procedures) that cannot be performed in a one-step procedure.

3. The following functional limitations currently apply:

• You cannot- use hierarchies as the source or target of a transformation.
• You can- not use master data as the source of a transformation.
• You cannot- use a template to create a transformation.
• No- documentation has been created in the metadata repository yet for transformations.
• In the- transformation there is no check for referential integrity, the InfoObject transfer routines are not considered and routines cannot be created using the return table. 

Quantity Conversion : 

As of SAP NetWeaver 2004s you can create quantity conversion types using transaction RSUOM. The business transaction rules of the conversion are established in the quantity conversion type. The conversion type is a combination of different parameters (conversion factors, source and target units of measure) that determine how the conversion is performed. In terms of functionality, quantity conversion is structured similarly to currency translation. Quantity conversion allows you to convert key figures with units that have different units of measure in the source system into a uniform unit of measure in the BI system when you update them into InfoCubes.

Data Transfer Process :

You use the data transfer process (DTP) to transfer data within BI from a persistent object to another object in accordance with certain transformations and filters. In this respect, it replaces the InfoPackage, which only loads data to the entry layer of BI (PSA), and the data mart interface. The data transfer process makes the transfer processes in the data warehousing layer more transparent. Optimized parallel processing improves the performance of the transfer process (the data transfer process determines the processing mode). You can use the data transfer process to separate delta processes for different targets and you can use filter options between the persistent objects on various levels. For example, you can use filters between a DataStore object and an InfoCube. Data transfer processes are used for standard data transfer, for real-time data acquisition, and for accessing data directly. The data transfer process is available as a process type in process chain maintenance and is to be used in process chains. 

ETL Error Handling :

The data transfer process supports you in handling data records with errors. The data transfer process also supports error handling for DataStore objects. As was previously the case with InfoPackages, you can determine how the system responds if errors occur. At runtime, the incorrect data records are sorted and can be written to an error stack (request-based database table). After the error has been resolved, you can further update data to the target from the error stack. It is easier to restart failed load processes if the data is written to a temporary store after each processing step. This allows you to determine the processing step in which the error occurred. You can display the data records in the error stack from the monitor for the data transfer process request or in the temporary storage for the processing step (if filled). In data transfer process maintenance, you determine the processing steps that you want to store temporarily.

InfoPackages :

InfoPackages only load the data into the input layer of BI, the Persistent Staging Area (PSA). Further distribution of the data within BI is done by the data transfer processes. The following changes have occurred due to this:

- New tab page: Extraction -- The Extraction tab page includes the settings for adaptor and data format that were made for the DataSource. If data transfer from files occurred, the External Data tab page is obsolete; the settings are made in DataSource maintenance.

- Tab page: Processing -- Information on how the data is updated is obsolete because further processing of the data is always controlled by data transfer processes.

- Tab page: Updating -- On the Updating tab page, you can set the update mode to the PSA depending on the settings in the DataSource. In the data transfer process, you now determine how the update from the PSA to other targets is performed. Here you have the option to separate delta transfer for various targets. 

For real-time acquisition with the Service API, you create special InfoPackages in which you determine how the requests are handled by the daemon (for example, after which time interval a request for real-time data acquisition should be closed and a new one opened). For real-time data acquisition with Web services (push), you also create special InfoPackages to set certain parameters for real-time data acquisition such as sizes and time limits for requests.

PSA :

The persistent staging area (PSA), the entry layer for data in BI, has been changed in SAP NetWeaver 2004s. Previously, the PSA table was part of the transfer structure. You managed the PSA table in the Administrator Workbench in its own object tree. Now you manage the PSA table for the entry layer from the DataSource. The PSA table for the entry layer is generated when you activate the DataSource. In an object tree in the Data Warehousing Workbench, you choose the context menu option Manage to display a DataSource in PSA table management. You can display or delete data here. Alternatively, you can access PSA maintenance from the load process monitor. Therefore, the PSA tree is obsolete. 

Real-Time Data Acquisition :

Real-time data acquisition supports tactical decision making. You use real-time data acquisition if you want to transfer data to BI at frequent intervals (every hour or minute) and access this data in reporting frequently or regularly (several times a day, at least). In terms of data acquisition, it supports operational reporting by allowing you to send data to the delta queue or PSA table in real time. You use a daemon to transfer DataStore objects that have been released for reporting to the ODS layer at frequent regular intervals. The data is stored persistently in BI. You can use real-time data acquisition for DataSources in SAP source systems that have been released for real time, and for data that is transferred into BI using the Web service (push). A daemon controls the transfer of data into the PSA table and its further posting into the DataStore object. In BI, InfoPackages are created for real-time data acquisition. These are scheduled using an assigned daemon and are executed at regular intervals. With certain data transfer processes for real-time data acquisition, the daemon takes on the further posting of data to DataStore objects from the PSA. As soon as data is successfully posted to the DataStore object, it is available for reporting. Refresh the query display in order to display the up-to-date data. In the query, a time stamp shows the age of the data. The monitor for real-time data acquisition displays the available daemons and their status. Under the relevant DataSource, the system displays the InfoPackages and data transfer processes with requests that are assigned to each daemon. You can use the monitor to execute various functions for the daemon, DataSource, InfoPackage, data transfer process, and requests. 

Archiving Request Administration Data :

You can now archive log and administration data requests. This allows you to improve the performance of the load monitor and the monitor for load processes. It also allows you to free up tablespace on the database. The archiving concept for request administration data is based on the SAP NetWeaver data archiving concept. The archiving object BWREQARCH contains information about which database tables are used for archiving, and which programs you can run (write program, delete program, reload program). You execute these programs in transaction SARA (archive administration for an archiving object). In addition, in the Administration functional area of the Data Warehousing Workbench, in the archive management for requests, you can manage archive runs for requests. You can execute various functions for the archive runs here.

After an upgrade, use BI background management or transaction SE38 to execute report RSSTATMAN_CHECK_CONVERT_DTA and report RSSTATMAN_CHECK_CONVERT_PSA for all objects (InfoProviders and PSA tables). Execute these reports at least once so that the available request information for the existing objects is written to the new table for quick access, and is prepared for archiving. Check that the reports have successfully converted your BI objects. Only perform archiving runs for request administration data after you have executed the reports. 

Flexible process path based on multi-value decisions :

The workflow and decision process types support the event Process ends with complex status. When you use this process type, you can control the process chain process on the basis of multi-value decisions. The process does not have to end simply successfully or with errors; for example, the week day can be used to decide that the process was successful and determine how the process chain is processed further. With the workflow option, the user can make this decision. With the decision process type, the final status of the process, and therefore the decision, is determined on the basis of conditions. These conditions are stored as formulas.

Evaluating the output of system commands : 

You use this function to decide whether the system command process is successful or has errors. You can do this if the output of the command includes a character string that you defined. This allows you to check, for example, whether a particular file exists in a directory before you load data to it. If the file is not in the directory, the load process can be repeated at pre-determined intervals.

Repairing and repeating process chains :

You use this function to repair processes that were terminated. You execute the same instance again, or repeat it (execute a new instance of the process), if this is supported by the process type. You call this function in log view in the context menu of the process that has errors. You can restart a terminated process in the log view of process chain maintenance when this is possible for the process type.

If the process cannot be repaired or repeated after termination, the corresponding entry is missing from the context menu in the log view of process chain maintenance. In this case, you are able to start the subsequent processes. A corresponding entry can be found in the context menu for these subsequent processes.

Executing process chains synchronously :

You use this function to schedule and execute the process in the dialog, instead of in the background. The processes in the chain are processed serially using a dialog process. With synchronous execution, you can debug process chains or simulate a process chain run.

Error handling in process chains:

You use this function in the attribute maintenance of a process chain to classify all the incorrect processes of the chain as successful, with regard to the overall status of the run, if you have scheduled a successor process Upon Errors or Always. This function is relevant if you are using metachains. It allows you to continue processing metachains despite errors in the subchains, if the successor of the subchain is scheduled Upon Success.

Determining the user that executes the process chain :

You use this function in the attribute maintenance of a process chain to determine which user executes the process chain. In the default setting, this is the BI background user.

Display mode in process chain maintenance :

When you access process chain maintenance, the process chain display appears. The process chain is not locked and does not call the transport connection. In the process chain display, you can schedule without locking the process chain.

Checking the number of background processes available for a process chain :

During the check, the system calculates the number of parallel processes according to the structure of the tree. It compares the result with the number of background processes on the selected server (or the total number of all available servers if no server is specified in the attributes of the process chain). If the number of parallel processes is greater than the number of available background processes, the system highlights every level of the process chain where the number of processes is too high, and produces a warning. 

Open Hub / Data Transfer Process Integration :

As of SAP NetWeaver 2004s SPS 6, the open hub destination has its own maintenance interface and can be connected to the data transfer process as an independent object. As a result, all data transfer process services for the open hub destination can be used. You can now select an open hub destination as a target in a data transfer process. In this way, the data is transformed as with all other BI objects. In addition to the InfoCube, InfoObject and DataStore object, you can also use the DataSource and InfoSource as a template for the field definitions of the open hub destination. The open hub destination now has its own tree in the Data Warehousing Workbench under Modeling. This tree is structured by InfoAreas.

The open hub service with the InfoSpoke that was provided until now can still be used. We recommend, however, that new objects are defined with the new technology.