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):
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: 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). DeleteFor key
figures: Inserting: Constants, Customer exit (for user-specific coding).
Replacing key figures with: Customer exit (for user-specific coding).
DeleteSAP 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.
