Table TRFCQOUT and ARFCSSTATE: Status READ means that the record was read once either in a delta request or in a repetition of the delta request. However, this does not mean that the record has successfully reached the BW yet. The status READY in the TRFCQOUT and RECORDED in the ARFCSSTATE means that the record has been written into the DeltaQueue and will be loaded into the BW with the next delta request or a repetition of a delta. In any case only the statuses READ, READY and RECORDED in both tables are considered to be valid. The status EXECUTED in TRFCQOUT can occur temporarily. It is set before starting a DeltaExtraction for all records with status READ present at that time. The records with status EXECUTED are usually deleted from the queue in packages within a delta request directly after setting the status before extracting a new delta. If you see such records, it means that either a process which is confirming and deleting records which have been loaded into the BW is successfully running at the moment, or, if the records remain in the table for a longer period of time with status EXECUTED, it is likely that there are problems with deleting the records which have already been successfully been loaded into the BW. In this state, no more deltas are loaded into the BW. Every other status is an indicator for an error or an inconsistency. NOSEND in SMQ1 means nothing (see note 378903).

The value ‘U’ in field ‘NOSEND’ of table TRFCQOUT is discomforting.

 Mail this post

Relationship between RSA7 and the qRFC monitor (Transaction SMQ1)?

The qRFC monitor basically displays the same data as RSA7. The internal queue name must be used for selection on the initial screen of the qRFC monitor. This is made up of the prefix ‘BW, the client and the short name of the DataSource. For DataSources whose name is 19 characters long or shorter, the short name corresponds to the name of the DataSource. For DataSources whose name is longer than 19 characters (for delta-capable DataSources only possible as of PlugIn 2001.1) the short name is assigned in table ROOSSHORTN.

In the qRFC monitor you cannot distinguish between repeatable and new LUWs. Moreover, the data of a LUW is displayed in an unstructured manner there.

 Mail this post

What is the purpose of function ‘Delete data and meta data in a queue’ in RSA7?

You should act with extreme caution when you use the deletion function in the delta queue. It is comparable to deleting an InitDelta in the BW System and should preferably be executed there. You do not only delete all data of this DataSource for the affected BW System, but also lose the entire information concerning the delta initialization. Then you can only request new deltas after another delta initialization.

When you delete the data, the LUWs kept in the qRFC queue for the corresponding target system are confirmed. Physical deletion only takes place in the qRFC outbound queue if there are no more references to the LUWs.

The deletion function is for example intended for a case where the BW System, from which the delta initialization was originally executed, no longer exists or can no longer be accessed.

 Mail this post

Transport Strategy

 

Transport strategy is developed to answer the questions as below:

 

·         What is my system landscape?

·         How many different projects are working on that system?

·         How complex are my scenarios?

·         Who is responsible for transports / development classes (central,

·         decentral)?

·         Which kind of system (development, consolidation, production)?

·         How can the transport of BEx objects be organized?

In a standard three system landscape one development class may be sufficient, transport using object collector. In a complex landscape different objects might have to be transported to different system (different development classes, transport layers). There are typically some common objects that need to be transported to all systems and some specific ones.

 

Number of Projects in a system

 

Basically the system landscape considerations also apply for projects. You have to distinguish between common objects and project specific ones. You may want to be prepared to split up into different systems later on (e.g.for performance reasons).

 

Complexity of Scenarios

 

In very complex scenarios dependencies of objects can also be complex. Activating automatic transport connection ensures that no objects are forgotten but the order of the imports is then very important. The object collector helps you find the dependent objects but transport requests may contain many objects. In case of problems split up transports (into parts of the data flow).

 

Responsibility

 

If you have complex scenarios / system landscape / several projects organizing transport may be a crucial issue. Central management may be necessary to decide. Which object is assigned to which development class, which objects are collected in one transport request, in which order and when do the transports take place.

 

Type of Systems

 

The above considerations are focussed mainly on development systems, you may want to create some objects in the consolidation system in exceptional cases. Activation of automatic transport connection for keeping track of all such objects / changes may be a good approach

In the productive system you typically don‘t create objects to be transported but e.g. queries (ad hoc reporting). Using default BW setting (no automatic transport connection) is usually the best option (independent of settings in development or consolidation systems).

 

Transport of BEx Objects

 

Since BEx Objects (once they are assigned to a transportable development

class) are transported in a special way there are special considerations:

 

• All changes of BEx objects (in one development class) in a certain period are transported together (unless standard transport system is activated)
• Granularity of development classes for BEx objects is important for flexibility in transports, e.g.
  • On project level
  • On data target level
  • Several ones for each data target
  • One for each query
• Transport management of BEx requests
  • Agreement on when transport request is released
  • Creation of a new one immediately after (or before) releasing the old one

 

The only way of grouping BEx objects in a transport (after first transport) is by development class. So you have to determine the granularity you need for transporting BEx objects and set up development classes accordingly.

 

• No changes to BEx objects are possible if:
  • No BEx request exists
  • The old BEx request is released and no new one is created
  • A new BEx request is already assigned but the old one has not been released.

 

 Mail this post

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

BI 7 – New features

 

 

 

New features in BI 7

 

- Flexibility

-Transformation Concept

- DataStore object

- Data Transfer Process

- Real-Time Data Acquisition

- Administration Cockpit

- High Performance Analytics

- Near-line Storage

- Enterprise Reporting, Query, and Analysis

Query, Reporting & Analysis – Designing a Query

Query, Reporting & Analysis – Designing a Report

Query, Reporting & Analysis – Designing a Web Application

- BEx Web Printing

- Information Broadcasting – Enhancements

- Business Planning and Analytical Services

- Further Enhancements

- The Administrator Workbench is now called Data Warehousing Workbench.

- The ODS object is now called DataStore object.

- The transaction ODS object is now called as direct update DataStore

- The transactional InfoCube is now called real-time InfoCube.

- The RemoteCube, SAP RemoteCube and virtual InfoCube with services are now referred

to as VirtualProviders.

- The monitor is now called the extraction monitor, to distinguish it from the other monitors.

 

New terminology in BI 7

 

BI 7 provides additional flexibility for implementing new data models and changing

existing ones :

Remodeling Toolbox

Changing InfoCubes without rebuilding them from scratch – improved flexibility. As of

now applicable only for infocube. To access re-modeling option select InfoCube->right

click Additional function->Remodelling

Note: During (dictionary-based) conversion process it is not possible to get data in

queries, aggregates will be automatically deactivated and need to be rebuilt.

Transporting remodeling is not possible

Enhanced DataStore objects

 

 

(formerly: ODS objects)

Improved performance and flexibility. New DataStore type: Write-optimised (without

change-log, no activation queue)

Enhanced Info Sets

Improved flexibility

Integrate InfoCubes into join condition, can have join between infocube and master data

(outer join between master data and InfoCube).

 

Modeling the EDW – Flexibility

Remodelling

 

InfoSet with master data and InfoCube

 

BI 7 significantly improves transformation capabilities.

Improved performance, flexibility and usability

Graphical UI

Unification of transfer and update rules

Grouping (Ex. Sales agent and his manager)

New rule type: end routine – Data after transformation

New rule type: expert routine (pure coding of transformation)

Transformation directly links from source Infoprovider

(Datasource) to target Infoprovider (Infosource usually not

required)

 

 

 

Data transfer process

BI 7 improves and streamlines the data flow definition and process chain set-up. In addition,

it provides new real-time data acquisition capabilities that facilitate operational reporting:

Data transfer process (DTP)

Data distribution within SAP BI (from PSA or Info Providers to Info Providers)

Improved transparency of staging processes across data warehouse layers

(PSA, DWH layer, ODS layer, Architected Data Marts)

Improved performance

Separation of delta mechanism for different data targets (Ex: Daily/Weekly load)

Enhanced filtering in dataflow

 

 

 

Data Transfer process (Filter option)

 

 

 

Enhanced real-time data acquisition capabilities

XML Web service

Direct push into PSA (instead of Service API/Delta Queue)

Near-real-time InfoPackage & DTP

Daemon-based update from delta queue (BW Service API)

Daemon-based update of DataStore objects

(ODS layer) – including lean staging (with minimized logging)

 

Real time data acquisition

 

- Enhanced real-time data acquisition capabilities

 

 

 

High performance Analytics

 

BI 7 provides various tools to increase the data load and query performance

Significantly – among them the innovative high performance analytics approach.

Thus, the implementation of large enterprise data warehouses is facilitated.

High performance analytics (HPA) / BI Accelerator (BIA)

A new paradigm for high performance data access.

- Query performance is improved by factor 10 – 100

- HPA is used in connection with KM search engine TREX

- TREX indexes – Vertical indexes in which stored data in column wise not row wise

- No need of change run in aggregates

Near-line storage

Administrator cockpit

 

Enterprise Reporting, Query and Analysis

 

Query , Reporting and Analysis.

Query design takes place in the Business Explorer (BEx) Query Designer,

a Visual Basic .NET-based Unicode-compliant tool.

 

 

State-of-the-art UI concept, providing for example:

 

 

 

Available tasks for a selected object presented via a

task pane

 

 

 

Message panel shows warnings and error messages in context 

helps to avoid or

correct errors

 

 

 

Enhanced application menus, toolbars and context menus

 

 

 

Extended visualization of status and user actions

 

 

Support of multi-selected objects – drag&drop, properties

 

 

Options for BI-integrated Planning

26

Report designer

Designing a Report

Report design takes place in the Business Explorer (BEx) Report Designer – a new,

VB .Net-based tool that allows to create formatted, print-optimized reports.

 

 

Standard formatting: Font styles (e.g. bold, italic) and colors, etc.

 

 

Group level changes with individual formattings

 

 

Layout options, for example

 

 

 

Height of rows, width of columns

 

 

 

Multiline column headers

 

 

 

Flexible positioning of fields

 

 

 

Merger of cells

 

 

Support of hierarchies

 

 

Integration of texts, pictures, and charts

 

 

Header and footer for reports and pages

 

Web application designer

 

Model-driven BI application building

 

 

 

Wizards for charts, maps, command editing

 

 

 

Wizard for layout elements (e.g. buttons)

 

 

 

Intellisense“ support for Web API developers

 

 

 

Easy integration of native HTML commands

 

 

New layout elements (Tab strips etc.)

 

 

New Web items

 

 

New chart types, e.g. GANTT chart, MTA (Milestone trend analysis) chart

 

 

Design of planning aware business applications

Web printing

Comfortable PDF based BEx Web printing

 

 

Any type of BEx Web query, Report or Web Application can be converted to PDF and printed

 

 

Leveraging the SAP NetWeaver AS integration with Adobe Document Service

 

 

Adobe Acrobat Reader required, no plug-ins necessary

 

 

Printing options can be maintained globally or individually by an end-user

 

Business planning and analytics services (BI integrated planning)

 

 

Open and flexible planning framework for all SAP applications

 

 

Fully integrated with BI and analytics services

 

 

One user interface, one design environment, one engine

 

 

Shared services and persistency and integrated meta data

 

Further enhancement

 

Modeling the EDW

Data Warehousing Workbench

New infocube maintanence UI like ODS

Contains process chain maintanence,monitor, delta queue etc.

Display complete dataflow from source to target

PSA mandatory

Running the EDW

Process Chains

Display-only mode, copying of process chain

Additional functionality(interupt process,workflow, and process types (condition),

choosing background user for execution process

New Analysis Authorization concept

Higher flexibility and simplified modeling

32

Process chain enhancement

33

Data warehouse workbench

34

InfoCube maintenance

35

Distinction between 3.X and BI 7 objects

36

BI 7 vs. 3.x DataSource

37

Migration

38

DataSource Migration

 Mail this post

Why Load Balancing  for BW

Load balancing provides the capability to distribute processing across several servers in order to optimally utilize the server resources that are available. An effective load balancing strategy can help you to avoid inefficient situations where one server is overloaded (and thus performance suffers on that server), while other servers go underutilized. The following processes can be balanced:

• Logon load balancing (via group login): This allows you to distribute the workload of multiple query/administration users across several application servers.

• Distribution of web users across application servers can be configured in the BEx service in SICF.

• ODS Object Data Activation is definable for specific server groups (BW 3.x).

• Process Chains can be processed on specified server groups (BW 3.x).

• Extraction in the mySAP source system can be processed on specified server groups: RFC destination in BW to source system must be defined accordingly (transaction SM59).

• Data load in BW can be processed on specified server groups: RFC destination in source system to BW must be defined accordingly (transaction SM59).

• Data staging via XML over HTTP/SOAP can be processed on specified server groups (BW 3.x).

You can define logon server groups in transaction SMLG and RZ12 and assign these groups to the mentioned processes; the data packages are sent to the servers included in the server group.

 Mail this post

IT Landscape and Configuration

A BW environment can contain a DB server and several application servers. These servers can be configured individually (e.g. number of dialog and batch processes), so that the execution of the different job types (such as queries, loading, DB processes) can be optimized. The general guideline here is to avoid hot spots and bottlenecks.

Be sure that enough processes (of a certain type) are configured.

A BW application server does not need a UP2 process and at most would use 2 UPD processes.

Operation modes can be switched to affect the allocations for dialog and batch processing for different application servers.

For optimizing the hardware resources, it is recommended to define at least two operation modes: one for batch processing (if there is a dedicated batch window) with several batch processes and one for the query processing with several dialog processes.

Note that the data load in BW for extraction from R/3 runs in dialog processes.

An important point here is that sufficient resources should be available in order to distribute the workload across several application servers. Monitor the activity on different app servers to determine a strategy for optimizing the workload distribution (using load balancing). Also, if the database server is “tight” on resources, consider moving the central instance away from the database server, in order to allocate maximum resources to database processes. Note that database processes may utilize a significant number of CPUs, and thus you should carefully monitor CPU utilization in the DB server.

Different application servers have separate buffers and caches. E.g. the OLAP cache (BW 3.x) on one application server does not use the OLAP cache on other servers

 Mail this post

Hardware Impact

The capacity of the hardware resources represents highly significant aspect of the overall performance of the BW system in general. Insufficient resources in any one area can constraint performance capabilities

These include:

• number of CPUs

• speed of CPUs

• memory

• I/O-Controller

• Disk architecture (e.g. RAID)

The hardware sizing should be done according to the recommendations of SAP’s hardware partner. The number of CPUs is dependent on the required number of parallel processes (e.g. upload processes, queries). In the end, better hardware will certainly improve your system performance and should be considered, if all other optimizing activities were not satisfactory.

A reasonable sizing is the prerequisite for satisfactory performance. If your BW system is likely to grow, be sure that the hardware is scalable. We recommend to have a five year growth projection that takes into account a long term near line storage and archiving plan, as well as granularity size goals – for example maintaining two years of detail level data, and five years summary data. You also need to account for your PSA size – Do you delete an old load after the next successful load? Or do you manage PSA at all?

See QuickSizer in SAP Service Marketplace for more details.

The client hardware has also significant impact on the query response time. You can improve rendering time of web applications or BEx Analyzer queries significantly by supplying a better frontend client hardware

 Mail this post