Features in BI 7.0 or Netweaver 2004s
Below are the features in SAP BI 7.0 version. Some of the features are
new and the others are tweaked from previous versions.
Metadata Search (Developer Functionality):
1. 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.
2. 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.
3. 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”.
4. “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 writeoptimized
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 timedependent
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 userspecific
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:
• You have stopped any process chains that run periodically
and affect the corresponding InfoProvider. Do not restart
these process chains until remodeling is finished.
• There is enough available tablespace on the database.
5. 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 packagebased
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 realtime
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 realtime
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.
