PERI5 Conversion Routine BI InfoObject

Use

The PERI5 conversion serves to convert a five-figure calendar quarter in an external format (Q.YYYY, for example) into the internal format (YYYYQ). Y stands for year (here four digits) and Q for quarter (single digit: 1,2,3, or 4). The separator (‘.’ or ‘/’) has to correspond to the date format in the user settings.

Features

Permitted entries for the date format DD.MM.YYYY are QYY (two digits for year without separator), Q.YY (two digits for year with separator), QYYYY (four digits for year without separator), and Q.YYYY (four digits for year with separator). Permitted entries for the date format YYYY/MM/DD would be YYQ, YY/Q, YYYYQ, YYYY/Q.

Example

Examples where the date format in the user settings is DD.MM.YYYY. A conversion from the external to the internal format takes place:

...

1. '2.02' ® '20022'

2. '31999' ® '19993'

3. '4.2001' ® '20014'

PERI6 Conversion Routine

Use

Conversion routine PERI6 is used with six-digit entries for (fiscal year) periods.

Features

The internal format for six-digit periods is YYYYPP (200206, for example, for period 06 of fiscal year 2002). When the external format is converted to the internal format, this checks whether the entries in the INPUT parameter with external date format (separators, order) comply with user settings. The separator (‘.’ or ‘/’) has to correspond to the date format in the user settings.

Different abbreviated entries are possible and these are converted correctly into the internal format.

Example

For the external date format DD.MM.YYYY in the user settings, the following conversion takes place from external to internal formats:

...

1. '12.1999' ®'199912'

2. '1.1999' ®'199901'

3. '12.99' ®'199912'

4. '1.99' ®'199901'

PERI7 Conversion Routine BI InfoObject

Use

Conversion routine PERI7 is used with seven-digit entries for (fiscal year) periods.
Features

The internal format for seven-digit periods is YYYYPPP (2002006, for example, for period 006 of fiscal year 2002). When the external format is converted to the internal format, this checks whether the entries in the INPUT parameter with external date format (separators, order) comply with user settings. The separator (‘.’ or ‘/’) has to correspond to the date format in the user settings.

Different abbreviated entries are possible and these are converted correctly into the internal format.
Example

For the external date format DD.MM.YYYY in the user settings, the following conversion takes place from external to internal formats:

...

1. '012.1999' ®'1999012'

2. '12.1999' ®'1999012'

3. '1.1999' ®'1999001'

4. '012.99' ®'1999012'

5. '12.99' ®'1999012'

6. '1.99' ®'1999001'

POSID Conversion Routine BI InfoObject

Use

The POSID conversion routine converts the external presentation of the program position (0PROG_PO_EX) into the internal presentation (0PROG_POS), using the active master data table entries for the program position InfoObject (0PROG_POS).

Example

Conversion from the external into the internal format:

P-2411 ® P24110000

PROJ Conversion Routine BI InfoObject

Use

There are extensive possibilities in the ERP system project system for editing the external presentation of the project and PSP elements (project coding, editing mask). These features are included in the ERP conversion routine. This comprehensive logic cannot be mapped in the BI system. For this reason, the characteristic 0PROJECT_EX exists in the attributes of InfoObject 0PROJECT and the external description is stored there. As the external description is entered on the screen, conversion routine 'CONVERSION_EXIT_PROJ_INPUT' reads the corresponding internal description 0PROJECT and uses this for internal processing.

If no master data has been loaded into the BI system (master data generated by uploading transaction data), then the internal description has to be input in order to execute a query.

Example

Internal format: 0PROJECT: ‘A0001’

External format: 0PROJECT_EX: 'A / 0001'

REQID Conversion Routine BI InfoObject

Use

The REQID conversion routine converts the external presentation of the appropriation request (0APPR_REQU) into the internal presentation (0APPR_RE_ED), using the active entries in the master data table for the appropriation request InfoObject (0APPR_RE_ED).

Example

Conversion from the external into the internal format:

P-2411-2 ® P24110002

REQID Conversion Routine BI InfoObject

Use

The REQID conversion routine converts the external presentation of the appropriation request (0APPR_REQU) into the internal presentation (0APPR_RE_ED), using the active entries in the master data table for the appropriation request InfoObject (0APPR_RE_ED).

Example

Conversion from the external into the internal format:

P-2411-2 ® P24110002

IDATE Conversion Routine BI InfoObject

Use

This conversion routine assigns the appropriate internal date presentation (YYYYMMDD) to an external date (01JAN1994, for example).

Call up the test report RSSCA1T0 to be able to better visualize the functionality of this routine. This test report contains the complete date conversion with external as well as internal presentations.

Example

Conversion from the external into the internal format:

'02JAN1994' ® '19940102'

Conversion Routine RSDAT BI InfoObject

Use

Converts a date in an external format into the internal format.

Features

First, the system tries to convert the date in accordance with the user settings (System ® User Profile ® Own Data ® Fixed Values ® Date Format). If the system cannot perform the conversion in this way, it automatically tries to identify the format.

Valid formats:

DD.MM:YYYY

MM/DD/YYYY

MM-DD-YYYY

YYYY.MM.DD

YYYY/MM/DD

YYYY-MM-DD

For automatic recognition, the year has to be in four-digit format. If the date is specified as 14.4.72, this is not unique and can cause errors.

Note: If the system can sensibly specify a date from the format in the user settings, this conversion is performed.

In this example, if the format in the user settings is DD.MM.YYYY, the date is converted to 19720414, since the system conversion recognizes the date.

Example

Conversion from an external format into an internal format:

4/14/1972 ® 19710414

SAP R/3 Source Table.field - How To Find?

What is the quickest way to find the R/3 source table and field name for a field appearing on the BW
InfoSource?

-----Reply Message-----
Subject: RE: R/3 Source Table.field - How To Find?

Hi,

With some ABAP-knowledge you can find some info:

1, Start ST05 (SQL-trace) in R/3
2, Start RSA3 in R/3 just for some records
3, After RSA3 finishes, stop SQL-trace in ST05
4, Analyze SQL-statements in ST05

You can find the tables - but this process doesn't help e.g for the LO-cockpit datasources.

Hope this helps,

-----End of Message-----

What is meant by Primary Index and Secondary Index

Explain the what is primary and secondary index.

When you activate an object say ODS / DSO, the system automatically generate an index based on the key fields and this is primary index.

In addition if you wish to create more indexes , then they are called secondary indexes.

The primary index is distinguished from the secondary indexes of a table. The primary index contains the key fields of the table and a pointer to the non-key fields of the table. The primary index is created automatically when the table is created in the database.

You can also create further indexes on a table. These are called secondary indexes. This is necessary if the table is frequently accessed in a way that does not take advantage of the sorting of the primary index for the access. Different indexes on the same table are distinguished with a three-place index identifier.

Lets say you have an ODS and the Primary Key is defined as Document Nbr, Cal_day. These two fields insure that the records are unqiue, but lets lay you frequently want to run queries where you selct data based on the Bus Area and Document Type. In this case, we could create a secondary index on Bus Area, Doc Type. Then when the query runs, instead of having to read every record, it can use the index to select records that contain just the Bus Area and Doc type values you are looking for.

Just because you have a secondary index however, does not mean it will be used or should be used. This gets into the cardinality of the fields you are thinking about indexing. For most DBs, an index must be fairly selective to be of any value. That is, given the values you provide in a query for Bus Area and Doc Type, if it will retrieve a very small percentage of the rows form the table, the DB probably should use the index, but if the it would result in retrieving say 40% of the rows, it si almost always better to just read the entire table.

Having current DB statististics and possibly histograms can be very important as well. The DB statistics hold information on how many distinct values a field has, e.g. how many distinct values of Business Area are there, how many doc types.

Secondary indexes are usally added to ODS (which you can add using Admin Wkbench) based on your most frequently used queries. Secondary indexes might also be added to selected Dimension and Master data tables as well, but that usually requires a DBA, or someone with similar privileges to create in BW.

Types of Update Methods

What are these update methods and which one has to use at what purpose.

R/3 update methods
-----------------------------------------------
1. Serialized V3 Update
2. Direct Delta
3. Queed Delta
4. Un Serialized Delta Update

By: Anoo

a) Serialized V3 Update

This is the conventional update method in which the document data is collected in the sequence of attachment and transferred to BW by batch job.The sequence of the transfer does not always match the sequence in which the data was created.

b) Queued Delta

In this mode, extraction data is collected from document postings in an extraction queue from which the data is transferred into the BW delta queue using a periodic collective run. The transfer sequence is the same as the sequence in which the data was created

c) Direct delta.

When a Document is posted it first saved to the application table and also directly saved to the RSA7 (delta queue) from here it is being moved to BW.

So you can understand that for Delta flow in R/3 Delta queue is the exit point.

d) Queued Delta

When a document is posted it is saved to application table, and also saved to the Extraction Queue ( here is the different to direct delta) and you have to schedule a V3 job to move the data to the delta queue periodically and from their it is moved to BW.

e) Unserialized V3 Update

This method is largely identical to the serialized V3 update. The difference lies in the fact that the sequence of document data in the BW delta queue does not have to agree with the posting sequence. It is recommended only when the sequence that data is transferred into BW does not matter (due to the design of the data targets in BW).

You can use it for Inventory Management, because once a Material Document is created, it is not edited. The sequence of records matters when a document can be edited multiple times. But again, if you are using an ODS in your inventory design, you should switch to the serialized V3 update.

SAP BW versus R/3 Reporting

Dear All,

Would it be sufficient just to Web-enable R/3 Reports ? Why does one need
to implement BW ? What are the major benefits of reporting with BW over
R/3 ?

Thanking you,

-----Reply Message-----
Subject: RE: BW versus R/3 Reporting

There are quite a few companies that share your thought but R/3 was designed
as a OLTP system and not an analytical and reporting system. In fact
depending on you needs you can even get away with a reporting instance
(quite easy with Sun or EMC storage) Yes you can run as many reports as you
need from R/3 and web enable them but consider these factors.

1: Performance -- heavy reporting along with regular OLTP transactions can
produce a lot of load both on the R/3 and the database (cpu, memory, disks,
etc). Just take a look at the load put on your system during a month end,
quarter end, or year end -- now imagine that occurring even more frequently.

2: Data analysis -- BW uses a Data Ware house and OLAP concepts for storing
and analyzing data. Where R/3 was designed for transaction processing. With
a lot of work you can get the same analysis out of R/3 but most likely would
be easier from a BW.

Regards,

-----Reply Message-----
Subject: RE: BW versus R/3 Reporting

Major benefits of BW include:
1) By offloading ad-hoc and long running queries from production R/3 system
to BW system, overall system performance should improve on R/3.

2) Another key performance benefit with BW is the database design. It is
designed specifically for query processing, not data updating and OLTP.
Within BW, the data structures are designed differently and are much better
suited for reporting than R/3 data structures. For example, BW utilizes star
schema design which includes fact and dimension tables with bit-mapped
indexes. Other important factors include the built-in support for
aggregates, database partitioning, more efficient ABAP code by utilizing
TRFC processing versus IDOC.

3) Better front-end reporting within BW. Although the BW excel front-end has
it's problems, it provides more flexibility and analysis capability than the
R/3 reporting screens.

4) BW has ability to pull data from other SAP or non-SAP sources into a
consolidated cube.

In summary, BW provides much better performance and stronger data analysis
capabilities than R/3.

-----End of Message-----

Removing '#' in Analyzer (Report)

In ODS, there are records having a value BLANK/EMPTY for some of the fields. EX: Field: `Creation Date' and there is no value for some of the records.

For the same, when I execute the query in Analyzer, the value `#' is displaying in place of `BLANK' value for DATE and other Characteristic fields. Here, I want to show it as `BLANK/SPACE' instead of `#'. How to do this?

I had a similar problem and our client didn't want to see # signs in the report. And this is what I did. I created a marco in Workbook as SAPBEXonRefresh and run my code in Visual Basic editor. You can run same code in query also as when you will refresh query this # sign will be taken care. You can see similar code in SAP market place.

I will still suggest not to take out # sign as this represent no value in DataMart. And this is SAP standard. I did convince my client for this and later they were OK with it.

The codes are below:

Sub SAPBEXonRefresh(queryID As String, resultArea As Range)

If queryID = "SAPBEXq0001" Then
resultArea.Select

'Remove '#'
Selection.Cells.Replace What:="#", Replacement:="", LookAt:=xlWhole, _ SearchOrder:=xlByRows, MatchCase:=False, MatchByte:=True

'Remove 'Not assigned'
Selection.Cells.Replace What:="Not assigned", Replacement:="", LookAt:=xlWhole, _ SearchOrder:=xlByRows, MatchCase:=False, MatchByte:=True

End If

' Set focus back to top of results
resultArea(1, 1).Select

End Sub

How To Convert Base Units Into Target Units In BW Reports

My client has a requirement to convert the base units of measurements into target units of measurements in BW reports. How to write the conversion routine and otherwise pls refer conversion routine used so that the characteristic value(key) of an infoobject can be displayed or used in a different format to how they are stored in the database.

Have a look at the how to document "HOWTO_ALTERNATE_UOM2"

or

You can use the function module 'UNIT_CONVERSION_SIMPLE'

CALL FUNCTION 'UNIT_CONVERSION_SIMPLE'
EXPORTING
input = ACTUAL QUANTITY
* NO_TYPE_CHECK = 'X'
* ROUND_SIGN = ' '
unit_in = ACTUAL UOM
unit_out = 'KG' ( UOM YOU WANT TO CONVERY )
IMPORTING
* ADD_CONST =
* DECIMALS =
* DENOMINATOR =
* NUMERATOR =
output = w_output-h_qtyin_kg
* EXCEPTIONS
* CONVERSION_NOT_FOUND = 1
* DIVISION_BY_ZERO = 2
* INPUT_INVALID = 3
* OUTPUT_INVALID = 4
* OVERFLOW = 5
* TYPE_INVALID = 6
* UNITS_MISSING = 7
* UNIT_IN_NOT_FOUND = 8
* UNIT_OUT_NOT_FOUND = 9
* OTHERS = 10
.
IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

Deltas Not Working for Installation Master Data BW Errors

I am having trouble with the deltas for master data object "installation". The changes are clearly recorded in the time dependent and time independent tables, EANL/EANLH. The delta update mode is using ALE pointers, does anyone know of a table where I can go check where these deltas/changes are temporarily stored, or what's the process behind this type of delta?

The following steps must be executed:

1. Check, whether the ALE changepointer are active in your source system (Transaction BD61) and whether the number range is maintained (Transaction BDCP).
2. In addition, check in the ALE Customizing, whether all message types you need are active (Transaction SALE -> Model and implement business processes -> Configure the distribution of master data -> Set the replication of changed data -> Activate the change pointer for each message type ).
3. Check, whether the number range for the message type BI_MSTYPE is maintained (Transaction SNUM -> Entry 'BI_MSTYPE' -> Number range -> Intervals). The entry for 'No.' must be exactly '01'. In addition, the interval must start with 0000000001, and the upper limit must be set to 0000009999.
4. Go to your BW system and restart the Admin. workbench.
All of the following activities occur in the InfoSource tree of the Admin. Workbench.
5. Carry out the function "Replicate DataSource" on the affected attached source system for the InfoObject carrying the master data and texts.
4. Activate the X'fer structure
All changes, all initial data creations and deletions of records from now on are recorded in the source system.
5. Create an InfoPackage for the source system. In the tabstrip 'update parameter', there are three alternative extraction modes:
Full update
Delta update
Initialization of delta procedure
First, initialize the delta procedure and then carry out the delta update.

An update on this issue:

In the EMIGALL process, SAP decided to bypass all the standard proces to update the delta queues on IS-U, because it would cause too much overhead during the migration. It is still possible to modify the standard programs, but it is not recommended, except if you want to crash you system.

The other options are as follows :
- Extract MD with full extractions using intervalls..
- modify the standard to put data in a custom table on which you are going to create a generic delta;
- modify the standard to put the ALE pointers in a custom table and then use a copy of the standard functions to extract these data....
- Extract the data you want in a flat file and load it in BW...

By the way, if you want to extract the data from IS-U, forget to do it during migration, find another solution to extract after.

PS: Well if you have generic extractor and huge volume data then you can do it with multiple INITS with RANGES as selection criteria and then a single DELTA(which is summation of all INITS) in order to improve performance with GENERIC DELTA.

Error in bw data transport

After creating a query in BEX, you try and save the query, it gives you the following popup message:

"The query could not be saved due to a problem in transport".

Steps to correct the problem:

1. Within Adminstrator Workbench click on the Transport Connection tab in the Navigation Window on the left
hand side.

2. Select the Request BEx button on the toolbar.

3. Create a transport.

4. Try to change the query again.

SAP BW ERROR : replicate data from source system

BW 2.1C

OS WINT4

The RFC is working fine and you are trying to replicate data from source system (4.0B), while doing this you got an
error an ABAP dump, in this dump the Exception Condition are "CNTL_ERROR" raised

Take a look at OSS notes 158985 and 316243.

Depending on what patch level, GUI, or Kernel you are on.

Transport Process Chains to Test System

What is the best way to transport process chains to test system?
I got many other additional and unwanted objects got collected when I tried for collection of process chains from transport connection.

To transport a process chain the best is to transport only objects created for the process chain. On my system I created specific obejcts for PC : Infopackages, jobs, variant. those objects are only use for PC. By this way I avoid errors when users restart load or job manually.

So when I want to transport a process chain I go in the monitor and select the PC make a grouping on only necessary objects, and I go through the tree generated to select only what I need. Then I go in SE10 to check if the transport contains not other objects which can impact my target system.

You can avoid some uncessary objects by clicking in Grouping > Data flow before & Data Flow After . For example you already have infopackages in your target system but not process chains & you only want to transport only process chain without any other objects like transfer structure or infopackages . You can choose before or after option .

You can also choose hierachries or display option from the Display tab too if you have objects in bulk but make sure all object are selected ( in case when different-2 process chain having different kind of object then better use Hierarchy, not list )

While Creating these TR some objects may be in use or locked in other TR so first release them by Tcode Se03 ,using unclock object ( Expert Tool ).

These options can reduce your effort while collecting your objects , even after so much effort you get some warning or Error like :- objects are already in system then ask basis to use overwrite mode.

Transport a specific infoobject

How to transport a specific info object? I tried to change it and then save but the transport request won't appear. How to manually transport that object?

1. Administrator Workbench (RSA1), then Transport Connection
2. Object Types, then from the list of objects put the requested one on the right side of the screen (drag & drop)
3. Click "Transport Objects", put the development class name and specify the transport (or create the new one)
4. Transaction SE01, check transport and release it
5. Move the transport up to the another system.

If you change and reactivate the infoobject, but get no transport request, this means that your infoobject is still in $tmp class.
go in to the maintenance of the infoobject, menu extras, object directory entry and change the development class. at this point you should have a pop-up requesting a transport request

If you're not getting a transport request when you change and activate, it could also be that the InfoObject is already on an open transport.

When you collect the object in the transport connection as described above, you will see in the right hand pane an entry called Transport Request. If there is an entry here, the object is already on a transport and this gives you the transport number.

You can then use SE01 or SE10 to delete the object from the existing transport if that is what you want to do then, when you change and activate the object again, you should be prompted for a transport request. Alternatively, you can use the existing transport depending on what else is on it.

How To Do Transports in BW?

Step by step procedure for transporting in BW:

1. In RSA1 go to Transport Connection
2. Select Object Types Your Object that you want to transfer.
3. Choose grouping method (in data flow before and after)
4. Drag and drop your object.
5. Click the Truck button to transfer
6. In Source System (e.g Dev SE09).
a. Expand to choose your child request
b. Click on the release button (truck)
c. Choose the parent request and click the Truck button release.
7. In Target System (e.g QA) go to STMS
a. Click on Truck button (Import Overview)
b. Dbl click on your QA system queue
c. Clck on Refresh
d. Clk on adjust import queue
e. Select ur request and click on F11.

The benefits of SAP BW

• SAP Business Warehouse is ships with "Business Content". It comes with ready-made extraction routines, meta-data, InfoCubes, information models, reports and channels that guarantee analysis and reporting capabilities out of the box.


• It closes the loop as it provide a seamless links to planning and execution applications that allow you to act instantly on the insight you gain to improve the performance of your business processes.


• It openness ensure that SAP BW is ideal for SAP R/3Æ and other SAP solutions but not limited to them. You can combine it easily with practically any internal or external data source, including existing data marts, with third-party reporting and analysis tools, or planning and execution applications.


• The flexibility of SAP BW is that it is a ready-to-go solution but easy to adapt. You can modify or add data sources, meta-data, InfoCubes and reports as and when you need to.

SAP BW Cookbook

Extract from the BW Cookbook Volume 1: "The SAP Business Information Warehouse enables Online Analytical Processing (OLAP) to format the information of large amounts of operative and historical data. OLAP technologyenables multi-dimensional analyses according to various business perspectives. The preconfigured Business Information Warehouse Server for core areas and processes ensures information views within the entire enterprise."

Extract from the BW Cookbook Volume 2:

Settings In SAP (R/3) Source System

STEP 1. Install Plug-In

STEP 2. Defining Source System

TRANSACTION CODE: SPRO -> SAP Ref. Img ->

If R/3 system is 4.0B -> Cross Application components -> Distribution ALE -> Basic Settings -> set up logical system -> Maintain logical systems -> New entries -> maintain the entries as : ->

Responsibilities of BW Data Architect

Responsibilities of an implementation project...
For ex, Lets say If its a fresh implementation of BI or for that matter you are implementing SAP...

First and foremost will be your requirements gathering from the client. Depending upon the requirements you will creat a business blueprint of the project which is the entire process from the start to the end of an implementation...

After the blue print phase sign off we start off with the realization phase where the actual development happens... In our example after installing the necessary softwares, patches for BI we need to discuss with the end users who are going to use the system for inputs like how they want a report to look like and what are the Key Performance Indicators(KPI) for the reports etc., basically its a question and answer session with the business users... After collecting those informations the development happens in the development servers...

After the development comes to an end the same objects are tested in quality servers for any bugs, errors etc., When all the tests are done we move all the objects to the production environment and test it again whether everything works fine...

The Go-Live of the project happens where the actually postings happen from the users and reports are generated based on those inputs which will be available as an analytical report for the management to take decisions...

The responsibilites vary depending on the requirement... Initially the business analyst will interact with the end users/managers etc., then on the requirements the software consultants do the development, testers do the testing and finally the go-live happens...

BW Data Architect Description :
The BW Data Architect is responsible for the overall data design of the BW project. This includes the design of the
- BW InfoCubes (Basic Cubes, Multi-cubes, Remote cubes, and Aggregates)
- BW ODS Objects
- BW Datamarts
- Logical Models
- BW Process Models
- BW Enterprise Models

The BW Data Architect plays a critical role in the BW project and is the link between the end user's business requirements and the data architecture solution that will satisfy these requirements. All other activities in the BW project are contingent upon the data design being sound and flexible enough to satisfy evolving business requirements.

Time Commitment – the time which must be committed to this Role to ensure the project requirements are met. Project Complexity Time Commitment:

Low - If the BW project utilizes standard BW content and InfoCubes, this role can be satisfied by the BW Application Consultant. Medium If the BW project requires enhancements to the standard BW content and InfoCubes and/or requires the integration of non-SAP data, this role may require a committed resource.

High - If the BW project requires significant modification and enhancement to standard BW content and InfoCubes, it is highly recommended that an experienced resource be committed full-time to the project.

Key Attributes The BW Data Architect must have:
- An understanding of the BW data architecture
- An understanding of multidimensional modeling
- An understanding of the differences between operational systems data modeling and data warehouse data modeling
- An understanding of the end user's data
- An understanding of the integration points of the data (e.g., customer number, invoice number)
- Excellent troubleshooting and analytical skills
- Excellent communication skills
- Technical competency in data modeling
- Multi-language skills, if an international implementation
- Working knowledge of the BW and R/3 application(s)
- Experience with Data Modeling application software (i.e., ERWIN, Oracle Designer, S-Designer, etc.)

Key Tasks - The BW Data Architect is responsible for capturing the business requirements for the BW project. This effort includes:
- Planning the business requirements gathering sessions and process
- Coordinating all business requirements gathering efforts with the BW Project Manager
- Facilitating the business requirements gathering sessions
- Capturing the information and producing the deliverables from the business requirements gathering sessions
- Understanding and documenting business definitions of data
- Developing the data model
- Ensuring integration of data from both SAP and non-SAP sources
- Fielding questions concerning the data content, definition and structure

This role should also address other critical data sign issues such as:
- Granularity of data and the potential for multiple levels of granularity
- Use of degenerate dimensions
- InfoCube partitioning
- Need for aggregation at multiple levels
- Need for storing derived BW data
- Ensuring overall integrity of all BW Models
- Providing Data Administration development standards for business requirements analysis and BW enterprise modeling
- Provide strategic planning for data management
- Impact analysis of data change requirements

As stated above, the BW Data Architect is responsible for the overall data design of the BW project. This includes the design of the:
- BW InfoCubes (Basic Cubes, Multi-cubes, Remote cubes, and Aggregates)
- BW ODS Objects
- BW Datamarts
- Logical Models
- BW Process Models
- BW Enterprise Models

Free Download Book Decentralized Warehouse Management (LE-IDW)

Decentralized Warehouse Management (LE-IDW)

The Three Layers of SAP BW

SAP BW has three layers:

• Business Explorer: As the top layer in the SAP BW architecture, the Business Explorer (BEx) serves as the reporting environment (presentation and analysis) for end users. It consists of the BEx Analyzer, BEx Browser, BEx Web, and BEx Map for analysis and reporting activities.


• Business Information Warehouse Server: The SAP BW server, as the middle layer, has two primary roles:

• Data warehouse management and administration: These tasks are handled by the production data extractor (a set of programs for the extraction of data from R/3 OLTP applications such as logistics, and controlling), the staging engine, and the Administrator Workbench.
• Data storage and representation: These tasks are handled by the InfoCubes in conjunction with the data manager, Metadata repository, and Operational Data Store (ODS).

• Source Systems: The source systems, as the bottom layer, serve as the data sources for raw business data. SAP BW supports various data sources:

• R/3 Systems as of Release 3.1H (with Business Content) and R/3 Systems prior to Release 3.1H (SAP BW regards them as external systems)
• Non-SAP systems or external systems
• mySAP.com components (such as mySAP SCM, mySAP SEM, mySAP CRM, or R/3 components) or another SAP BW system.

SAP Data Warehouse

We have large amounts of historical sales data stored on our legacy system (i.e. multiple files with 1 million+ records). Today the users use custom written programs and the Focus query tool to generate sales'ish type of reports.

We are wanting that existing legacy system to go away and need to find a home for the data and the functionality to access and report on that data. What options does SAP afford for data warehousing? How does it affect the response of the SAP database server?

We are thinking of moving the data onto a scaleable NT server with large amounts of disk (10gb +) and using PC tools to access the data. In this environment, our production SAP machine would perform weekly data transfers to this historical sales reporting system.

Has anybody implemented a similar solution or have any ideas on a good attack method to solve this issue?

You may want to look at SAP's Business Information Warehouse. This is their answer to data warehousing. I saw a presentation on this last October at the SAP Technical Education Conference and it looked pretty slick.

BIW runs on its own server to relieve the main database from query and report processing. It accepts data from many different types of systems and has a detailed administration piece to determine data source and age. Although the Information System may be around for sometime it sounded like SAP is moving towards the Business Information Warehouse as a reporting solution.

SAP Business Information Warehouse

Ever heard about apples and oranges. SAP/R3 is an OLTP system where as BIW
is an OLAP system. LIS reports can not provide the functionality provided
by BIW.

-----Reply Message-----
Subject: Business Information Warehouse

Hello,

The following information is for you to get more clarity on the subject:
SAP R/3 LIS (Logistic Information System) consist of infostructures (which
are representation of reporting requirements). So whenever any event (goods
reciept, invoice reciept etc. ) takes place in SAP R/3 module, if relevant
to the infostructure, an corresponding entry is made in the infostructures.
Thus infostructures form the database part of the datawarehouse. For
reporting the data (based on OLAP features such drill-down, abc, graphics
etc.), you can use SAP R/3 standard analysis (or flexible analysis) or
Business Warehouse (which is excel based) or Business Objects (which is
third party product but can interface with SAP R/3 infostructures using BAPI
calls).

In short, the infostructures (which are part of SAP R/3 LIS) form the data
basis for reporting with BW.

Regards

-----End of Message-----

Use of manual security profiles with SAP BW

Our company is currently on version 3.1H and will be moving to 4.6B late
summer 2000. Currently all of our R/3 security profiles were created
manually. We are also in the stage of developing and going live with the
add-on system of Business Warehouse (BW). For consistency, we have wish
to use manual profiles within the BW system and later convert all of our
manual security profiles (R/3 and BW) to profile generated ones.

Is there anyone else that can shed any light on this situation? (Success
or problems with using manual security profiles with BW?)

Any feedback would be greatly appreciated.

Thank you,

-----Reply Message-----
Subject: Use of manual security profiles with BW? (Business Information Warehouse)

Hi ,
You are going to have fun doing this upgrade. The 4.6b system is a
completely different beast than the 3.1h system. You will probably find a
lot of areas where you have to extend you manually created profiles to
cover new authorisation objects (but then you can have this at any level).

In 4.6b you really have to use the profile generator, but at least there is
a utility to allow you to pick up your manually created profile and have it
converted to an activity group for you. This will give you a running start
in this area, but you will still have a lot of work to do.

The fact that you did not use PG at 3.1h will not matter as it changed at
4.5 too and the old activity groups need the same type of conversion (we
are going through that bit right now).

What Is SPRO In BW Project?

1) What is spro?
2) How to use in bw project?
3) What is difference between idoc and psa in transfer methods?

1. SPRO is the transaction code for Implementation Guide, where you can do configuration settings.
* Type spro in the transaction box and you will get a screen customizing :
Execute Project.
* Click on the SAP Reference IMG button. you will come to Display IMG Screen.
* The following path will allow you to do the configuration settings :
SAP Cutomizing Implementation Guide -> SAP Netweaver ->SAP Business Warehouse Information.

2. SPRO is used to configure the following settings :
* General Settings like printer settings, fiscal year settings, ODS Object Settings, Authorisation settings, settings for displaying SAP Documents, etc., etc.,
* Links to other systems : like links between flat files and BW Systems, R/3 and BW, and other data sources, link between BW system and Microsoft Analysis services, and crystal enterprise....etc., etc.,
* UD Connect Settings : Like configuring BI Java Connectors, Establishing the RFC Desitination for SAP BW for J2EEE Engine, Installation of Availability monitoring for UD Connect.
* Automated Processes: like settings for batch processes, background processes etc., etc.,
* Transport Settings : like settings for source system name change after transport and create destination for import post-processing.
* Reporting Relevant Settings : Like Bex Settings, General Reporting Settings.
* Settings for Business Content : which is already provided by SAP.

3. PSA : Persistant Staging Area : is a holding area of raw data. It contains detailed requests in the format of the transfer structure. It is defined according to the Datasource and source system, and is source system dependent.

IDOCS : Intermediate DOCuments : Data Structures used as API working storage for applications, which need to move data in or out of SAP Systems.

Main advantages of BW 3.0 over 2.1C

Here's a brief list, without detailed explanations :-

- XML support for reading and writing metadata and data.
- Web application designer: graphically design and publish web reports and web applications.
- Open Hub Service for distributing data to other tables/systems on a schedule.
It supports selection, projection, and aggregation. Integrated into the BW monitor.
- Process Chains and graphical scheduler for automating complex processes.
Supports branching, condition testing, etc. Enables you to schedule all admin functions in a graphical, drag-and-drop
fashion, including extracts, index drops and rebuilds, activating data, compressing, rolling up to aggregates, etc.
- Transactional ODS objects with read/write API.
- Transfer rules for hierarchies.
- Subtree insert and subtree update for hierarchies.
- Active attributes on hierarchies (sign flip, etc.)
- Load, stage, and merge master data to ODS.
- DB Connect Service allows BW to extract data from any DBMS supported by SAP R/3.
- Formula editor in transfer and update rules to avoid ABAP coding.
- Toolbox of standard transformations such as substring, look up data in a table, concatenate, offset and length,
arithmetic operations, etc.
- Parallel loading into a single ODS object.
- Secondary index maintenance for ODS objects built in to BW Admin Workbench.
- Multiprovider: Use ODS objects, master data, and cubes in a multicube (now called multiprovider.)
- New InfoSet Concept: join tabular data together and make it available for reporting. You can join ODS objects,
master data tables, etc.
- Archiving: Built-in tools to archive data on a schedule using selection criteria.
Integrated into BW monitor; archived data deleted from InfoCubes and corresponding aggregates.
Support for re-loading data from archives as necessary.
- BW Monitor includes all activities of process chains, open hub service, and archiving.
- Use multiple hierarchies in a BW query.
- Use a mix of hierarchies and characteristics on rows or columns in a BW query.
- Use restricted key figures in a calculated key figure.
- Generate static, offline web reports.
- BEx Cell Editor: In queries with two structures, you can now reference cells at the intersections of rows and columns.

Pros and Cons of Web against BEX

1. Web reporting is faster then Excel, there is less overhead in executing Web reporting as opposed to Excel. (Whitepaper on SAP about this.)
2. There is not anymore work in formatting or creation of templates then in comparison to workbooks.
3. Query creation is the same as in BEX, so there is no new knowledge there.
4. Yes, knowledge of HTML is needed, but if you use the standard CSS templates, you really don't need to know them unless you want to change them. But, if you can write queries or code ABAP, you can definitely learn basic HTML and CSS to customize reporting. Its not that hard.
5. The learning curve for NEW users in Web Reporting vs.. BEX is actually considerably lower. Most people are very familiar with using a web browser, and IMOE I have found they pick up usage of web reporting much quicker then trying to teach them BEX.
6. Note, if you have a large user base which is already power Excel/BEx users, then they might be more reluctant to switch, though they would have no problem learning quickly the web reporting. Their downside would be that the behavior is not like Excel, which is a learned behavior, though the functionality is the same.
7. Publishing of queries and reports is done (or can be) via a role template which can be published on the web to provide common access to reports and queries.
8. Your implementation team (or at least one person on there) could be designated to picking up learning creation of web templates. (Its not hard, really.) Depending on organization size you may not need an additional person.
9. Publishing can be as easy a link on an existing intranet, or if you are using Portals already, integration with Portals is straightforward and you should have the knowledge base for doing so w/ your Portals group.
10. Query functionality is EXACTLY THE SAME with BEX and Web reporting, they both use query analyzer. The only difference is in presentation and output.
11. With Web reporting, you have (I think) greater control over presentation (combination of reports, charts, etc...) then w/ BEX.
12. You can provide the ability for "Printer friendly" versions of web reports, you can also provide the ability to easily pull the results into Excel in standard format or CSV format.
13. Finally, I think you have the ability to open up reporting and information consumption to a wider audience then in sticking w/ just BEx. (It definitely has its place in the organization.)

API Functions Available In BEX

API functions available in BEX 3.x:

1. Function SAPBEXinitConnection(Optional newConnectionObj As Object) As Boolean
Set up a connection to BW Server

2. Function SAPBEXgetConnection(Optional what As Integer) As Variant
Get the existing connection object if already connected to BW server by help of BEX

3. Sub SAPBEXattachGIS(Optional refreshOnly As Boolean) Attach GIS-MAP (same as clicking the BEX-Toolbar button)

4. Sub SAPBEXpauseOn()
In case you like to fire more than one API command (like two individual filter values) without immediate refresh

5. Sub SAPBEXpauseOff()
After this command all of the commands called after SAPBEXpauseOn will be executed

6. Function SAPBEXsetVariables(varValues As Range) As Integer
Set variable Values for User to provide Pop-Up Filter selections (Filter dialogs will be disabled if properly filled)

7. Function SAPBEXrefresh(allQueries As Boolean, Optional atCell As Range) As Integer
Refresh either all Queries in Workbook all Queries=FALSE or selected Queries by identifying the Query range

8. Function SAPBEXsetDrillState(newState As Integer, Optional atCell As Range) As Integer
Set the Drill state via coding to: vertical (newState=1) or horizontal (newState=2) or no drill state (newState=0)

9. Function SAPBEXgetDrillState(currentState As Integer, Optional atCell As Range) As Integer
Find out what DrillState is defined for a specific object

10. Function SAPBEXsetFilterValue(intValue As String, Optional hierValue As String, Optional atCell As Range)
As Integer
Set a filter value for a specific characterictic ( i.E. 0CUSTOMER = 1002) to filter either on simple or hierarchy values.

11. Function SAPBEXgetFilterValue(intValue As String, hierValue As String, Optional atCell As Range) As Integer
Get a filter value for a specific characterictic ( i.E. 0CUSTOMER) to use it later on either on simple or hierarchy node.

12. Function SAPBEXcopyFilterValue(fromCell As Range, Optional atCell As Range) As Integer
Copy a filter value for a specific characteristic see our little example above

13. Function SAPBEXfireCommand(fCode As String, Optional atCell As Range) As Integer
Fire commands like remote control context menu or toolbar (values can be found via Trace file)

14. Function SAPBEXcheckContext(fCode As String, Optional atCell As Range) As Integer
Check if an OLAP command like SAPBEXfireCommand can be used on that particular cell

15. Function SAPBEXshowTextElements(Optional selectGroup As String, Optional atCell As Range) As Integer
Like display of text elements (filters, global values) via Toolbar

16. Function SAPBEXjump(jumpType As String, jumpTarget As String, Optional atCell As Range) As Integer
ReportReport Interface(RRI) ; Jump to a specified Workbook or view

17. Function SAPBEXgetResultRangeByID(ByVal queryID As String, Optional ByVal charName As String) As Range
Find out where data from query is being displayed; for example in case you like to add data to last column

18. Function SAPBEXsaveWorkbook(Optional wbName As String) As Integer
Save your workbook after refresh (no name needed) or save as new file

19. Function SAPBEXreadWorkbook(wbID As String) As String
Open your workbook via Workbook ID (GUID) see text above for later use

20. Function SAPBEXgetWorkbookID(wbName As String) As String
Find out workbook Id by open Workbook by 'human friendly' name. Return value is GUID

21. Function SAPBEXembedQuery(genUID As String, Optional atActiveCell As Boolean) As String
Like Toolbar function; embed a new query (not workbook) to your active workbook.

Huge Performance Problems on SAP BW 3.10.

We have huge performance problems on SAP BW 3.10. (Oracle 9.2, AIX). Our users don't get the results of theirs queries, and they often have to log-off from sap when they use the bex analyzer .
I have read the differents topics regarding this problem , and read the differents SAP notes.

*The database statistics are refreshed every moring , after the data loads.
(statistic for the fact table is always current, transaction db20)
* Oracle Parameters are set according to SAP notes 632556.
* Oracle indices are deleted and recreated every day
* Fact table is partitioned
* I have tried to change the read mode in RSRT but it didn't work

I have checked the BW statistics (st03 and table RSDDSTAT). The database proportion is very high FOR ALL QUERIES (40 to 90%), and for the infocube (64%).
The ratio of selected to transfered record is 397 for the infocube and for the queries : 270.000 to 30.

We do not use aggregates and we do not use Cube compression. At first , I thought it was the reason of our problem but now I'm wondering If we do not have a database problem.

Is there anyone who could give me some advice ?

Further informations :
Data Buffer Quality : 96,3 %

I/O read times :
Read (Avg ms) : 2 to 7
Write (Avg ms) :150 to 459
According to OSS note 443544 , IO timesbelow should be acceptable below 10 ms, but in BW only the read mode (queries performances) is important, right ?

It looks like you are doing a great job tuning the database, an area I tend to neglect (as a non DBA BW consultant). However you say you are not using aggregates. I have to ask why?

The fact you have a selected to transfered ration of 270,000 in some queries suggests having to read many base level records to produce a summary result. By using the BW server to summarise into aggregates at load time, generally a quiet time, you will reduce the amount of work it has to do at query time.

If you decide to use aggregates you can let BW design aggregates for you, in which case you get many aggregates based on navigations in statistics, or design a few levels yourself, which means you control the extra storage. I tend to create a summary level aggregate, and mid level aggregate and sometimes additional customer without material or material without customer aggregates.

As you are using Oracle did you also know you can run an 'explain' on the SQL statement of a poorly performing query - run the query -> trans SM66 to find the Process ID (PID) of a the query -> trans ST04 -> detailed analysis -> oracle session -> select SQL text from DBA_VIEWS where PID -> use DBA tools to run an explain on the SQL statement. From this you may also find some areas for improvement.

Not much to add to the above great answer: looks like you're a textbook example to use aggregates.
In addition also have a look at compression: note 590370 explains the advantages you could get from it.

The above note may mention this , but in order to reap the benefits of fact table partioning you need to compress your infocube.
Database partioning works on the 'E' table within the infocube (not the 'F' fact table that hold the uncompressed data).

How to build an extractor?

Using SAP BW 2.1C and soon 3.0A we have to extract data from R/3 FI.
Standard extractor can´t be used, since data need to be enhanced and go throug various routines before data contains all information needed in BW. Delta upload mechanism is needed.
Where can information on
- building a new extractor (including delta mechanism)
- enhancing a standard extractor be found?

Technically, programming a function module data source would be a modification. There's also a way that allows you to stay close to the standard, especially if you extract data from standard tables:

In OLTP:
1) Find out which change document object points to the table.
2) Use the generic extractor to build a data source for _master data_ over the table.
3) Use the "enhance extract structure" feature in the BW img to add computed fields to the data source
4) Use the user exit for extraction to program your enhancement logic and compute additional fields
5) In data source maintenance, enter the change document object to delta-enable the data source

In BW:
7) Create an infoobject with attributes. (Key figures can be attributes, too.) Use concatenated keys or "Klammerung" to make the key fields identical to the key fields of your source table.
8) Create infopackages for initial load and delta load, and load data.

Now you need to load the data from your infoobject into a data target for transactional data (ODS or InfoCube).

In BW:
9) In infoobject maintenance, look up the view for master data for your new infoobject.
10) Use the generic extractor to create a generic datasource for transactional data out of this view.
11) Load data from this second generic extractor into your Cube/ODS.

As far as I know, BW 3.0 will allow loading data straight from OLTP _master_data datasources into BW ODS/Cubes, so as soon as you've upgraded, steps 7 - 11 will be obsolete.

COPA Extraction Steps

The below are the command steps and explanation. COPA Extraction -steps

R/3 System
1. KEB0
2. Select Datasource 1_CO_PA_CCA
3. Select Field Name for Partitioning (Eg, Ccode)
4. Initialise
5. Select characteristics & Value Fields & Key Figures
6. Select Development Class/Local Object
7. Workbench Request
8. Edit your Data Source to Select/Hide Fields
9. Extract Checker at RSA3 & Extract

BW
1. Replicate Data Source
2. Assign Info Source
3. Transfer all Data Source elements to Info Source
4. Activate Info Source
5. Create Cube on Infoprovider (Copy str from Infosource)
6. Go to Dimensions and create dimensions, Define & Assign
7. Check & Activate
8. Create Update Rules
9. Insert/Modify KF and write routines (const, formula, abap)
10. Activate
11. Create InfoPackage for Initialization
12. Maintain Infopackage
13. Under Update Tab Select Initialize delta on Infopackage
14. Schedule/Monitor
15. Create Another InfoPackage for Delta
16. Check on DELTA OptionPls r
17. Ready for Delta Load

LIS, CO/PA, and FI/SL are Customer Generated Generic Extractors, and LO is BW Content Extractors.

LIS is a cross application component LIS of SAP R/3 , which includes, Sales Information System, Purchasing Information System, Inventory Controlling....

Similarly CO/PA and FI/SL are used for specific Application Component of SAP R/3.

CO/PA collects all the OLTP data for calculating contribution margins (sales, cost of sales, overhead costs). FI/SL collects all the OLTP data for financial accounting, special ledger

1) Add the fields to the operating concern. So that the required field is visible in CE1XXXX table and other concerned tables CE2XXXX, CE3XXXX etc.

2) After you have enhanced the operating concern then you are ready to add it to the CO-PA data source. Since CO-PA is a regenerating application you can't add the field directly to the CO-PA data source. You need to delete the data source and then need to re-create using KEB2 transaction.

3) While re-creating the data source use the same old name so that there won't be any changes in the BW side when you need to assign the data source to info-source. Just replicate the new data source in BW side and map the new field in info-source. If you re-create using a different name then you will be needing extra build efforts to take the data into BW through IS all the way top to IC. I would personally suggest keep the same old data source name as before.

If you are adding the fields from the same "Operating concern" then goto KE24 and edit the dataaource and add your fields. However if you are adding fields outside the "Operating concern" then you need to append the extract structure and populate the fields in user exit using ABAP code. Reference OSS note: 852443

1. Check RSA7 on your R3 to see if there is any delta queue for COPA. (just to see, sometimes there is nothing here for the datasource, sometimes there is)
2. On BW go to SE16 and open the table RSSDLINIT
3. Find the line(s) corresponding to the problem datasource.
4. You can check the load status in RSRQ using the RNR from the table
5. Delete the line(s) in question from RSSDLINIT table
6. Now you will be able to open the infopackage. So now you can ReInit. But before you try to ReInit ....
7. In the infopackage go to the 'Scheduler' menu > 'Initialization options for the source system' and delete the existing INIT (if one is listed)

ODS infosource not showing up

To display export infosources under the Infosource hierarchy you need to do the following :

1. Right click the tree at the highest level (Infosources node) and then choose Insert Lost Nodes.

2. Also make sure that under Settings under the menu options you have selected the option to display generated
objects for ODS . By default the setting is set to hide objects.

And finally refresh your tree. You should be able to the infosources and the infopkgs. They might show up under Unassigned Nodes if you have not transferred the BW app component hierarchy in which case they show up under DM (Data Marts ) node.

The query could not be saved due to a problem in transport

After creating a query in BEX, you try and save the query, it gives you the following popup message:

"The query could not be saved due to a problem in transport".

Steps to correct the problem:

1. Within Adminstrator Workbench click on the Transport Connection tab in the Navigation Window on the left
hand side.

2. Select the Request BEx button on the toolbar.

3. Create a transport.

4. Try to change the query again.

Query View Workbook

You formatted a query view ( By changing Fonts/column width etc ) and saved as workbook in your favorites in the Browser.

When you execute the workbook thru the browser you get the format that has been saved. However, you loose the format when you click the Refresh Button.

How to set permanent settings so that formatting remains same as has been designed in the workbook?

You can do this :-

In Excel using BW, you have what I categorize as 2 different types of cells.

You have "Excel" Cells and "BW" Cells. You can determine which you are in by selecting a cell and right mouse clicking. If you get the BW options (Drilldown, Swap, Insert.....) then you are in a BW Cell. If you get the standard (Cut, Copy, Paste) you are in the Excel Cells.

If you are formatting an Excel Cell, Format using the option from the Excel Menu. If it is a BW Cell, Format using the option from the BW Toolbar (5th button from right).

When you refresh you will retain your settings.

Also, as a hint, you don't have to select all of your BW cells when formatting. Select a characteristic and format using the BW toolbar and all characteristics will format. Same goes for key figures, Free characteristics etc.

BW uses the "BW Style Tool"to format. For more detail and customization follow the below steps:

1. Download OSS Note #300570.

2. On your machine
Find / Execute SAPBEXS.XLA -> Click Enable Macros.

Stop a scheduled infopacket

I have tried using SM50 to stop a process that has been running for
quite sometime. How do I kill a scheduled infopacket.

Thanks,

-----Reply Message-----
Subject: RE: Stop a scheduled infopacket

Hello

select the Process and press F9. Or can kill the same from the OS level
using the UNIX command kill -9 .

Happy going..

-----Reply Message-----
Subject: RE: Stop a scheduled infopacket

Kill the job on the R/3 side by using SM37 for ALEREMOTE.

Hope this helps...

Thanks.

-----End of Message-----

BEX Query Authorizations

We are have authorization issues with Querries. We have created a generic
Role that has some Standard Query's for our Company attached to this Role.
We give access to this role to our user community. The problem we are
having is that the users can Execute the querries and what they are suppose
to do is only Save the Workbook to there favorites. We are running across
a problem because some of the users are saving the workbook as existing
workbook. So when they do this it wipes out the Query in that Role. How
can I stop users from overlaying the MASTER Query. There has to be a way
that you can protect a query so that it cannot be changed. Because we
have generic querries that are being used throughout our company, I need to
be able to protect the query so that it can only be saved to users
Favorites.

-----Reply Message-----
Subject: RE: BEX Query Authorizations

We would appreciate anyones input that could help us with this authorization
issue that we are having. Maybe if we could get input as to how other
Companies are handling there workbooks. There has to be a company that is
having the same problems with Workbooks being overwritten.

Any input would help

-----Reply Message-----
Subject: RE: BEX Query Authorizations

Hi,

Unfortunately I haven't managed to restrict access
to workbook depending on its menu location.

Hey gurus, it would be great to know any more ideas...

Best Regards,

-----Reply Message-----
Subject: RE: BEX Query Authorizations

Hi,

We tried changing the role and are unable to overly the generic role. But
we're unable to save a workbook to our favorites. Any ideas??

-----Reply Message-----
Subject: RE: BEX Query Authorizations

Hello,

Go to role maintenance (PFCG) -> Authorization ->
Chanhe Authorization Data.

Open Basis - General Functions -> BC-SRV-KPR-BDS
and restrict the user activities set like
"Display, Print, Retrieve from Archive, Determine, Assign".

User with appropriate role could not be able to overwrite
WORKBOOKS (!!!).

As for QUERIES, address to
Business Information Warehouse -> BEx - Components
and restrict Activities retaled to Queries -
then users with appropriate role could not be able to
overwrite GLOBAL DEFINITION of QUERY (!!!).

So, you can see, you need to restrict access to queries and
workbooks separately.

Best Regards,

SAP Console

Subject: SAPConsole

Good Morning to all

Can I use the standard SAPConsole for Inventory Management related
transactions also. Examble: Movement 103 /105 etc.

With Best Regards

-----Reply Message-----
Subject: RE: SAPConsole

Can you please explain me, What is a SAP Consule?

-----Reply Message-----
Subject: RE: SAPConsole

Dear:

SapConsole is a standard SAP tool which was offered as of 46B (but is
backwards compatible to earlier releases) which translates GUI screens into
the Character based screens that are used with most handheld Radio Frequency
devices used in Warehouses.

Beginning in 46B, SAP provided standard transactions which could be used in
Warehouse Management, specifically designed to be used with Radio Frequency
devices. As far as I know the only one that touches IM, allows a Goods
Reciept based on an Inbound Delivery number. To my knowledge, the Inbound
Delivery process is not being used very widely.

It is possible to design own transactions or to hire a systems integrator
that has already designed them, which will allow wireless processing of IM
Movements. This would be outside of the current SAP standard.

Best Regards,

Delete unwanted Objects in QA system

I have deleted unwanted Update rules and InfoSources (that have already been transported to QA system) in my DEV system. How do I get them out of my QA system? I cannot find the deletions in any transports that I have created. Although they could be buried somewhere. Any help would be appreciated.

I had the same problem with you. And I have been told there is a way to delete the unwanted objects. You may request the Basis team to open up test box temporarily to remove the obsolete Update rules and InfoSources. Remember to delete the request created in test after you have removed the Update rules and InfoSources.

When I tried to delete the master data, get the following message"Lock NOT set for: Deleting master data attributes". What I need to do in order to allow me can delete the master data.

Since, technically, the master data tables are not locked via SAP locks but via a BW-specific locking mechanism, it may occur in certain situations, that a lock is retained after the termination of one of the above transactions. This always happens if the monitor no longer has control, for example in the case of a short dump. If the monitor gets the control back after an update termination (regular case), it analyzes whether all update processes (data packets) for a request have been updated or whether they have terminated. If this is the case, the lock is removed.

Since the master data table lock is no SAP lock, this can neither be displayed nor deleted via Transaction SM12. There is an overview transaction in the BW System, which can display and delete all currently existing master data table locks. Via the button in the monitor with the lock icon or via Transaction code RS12 you can branch to this overview.

A maximum of two locks is possible for each basis characteristic:

Lock of the master data attribute tables
Lock of the text table

Changed by, Request number, Date and Time is displayed for every lock. Furthermore, a flag in the overview shows whether locks have been created via master data maintenance or master data deletion.

During a loading process the first update process starting to update data into the BW System (several processes update may update in parallel for each data request), sets the lock entry. All other processes only check whether they belong to the same data request. The last process, which has either been updated or has terminated, causes the monitor to trigger the deletion of the lock.

LO Cockpit Step By Step

Here is LO Cockpit Step By Step

LO EXTRACTION

- Go to Transaction LBWE (LO Customizing Cockpit)

1). Select Logistics Application
SD Sales BW
Extract Structures

2). Select the desired Extract Structure and deactivate it first.

3). Give the Transport Request number and continue

4). Click on `Maintenance' to maintain such Extract Structure
Select the fields of your choice and continue
Maintain DataSource if needed

5). Activate the extract structure

6). Give the Transport Request number and continue

- Next step is to Delete the setup tables

7). Go to T-Code SBIW

8). Select Business Information Warehouse
i. Setting for Application-Specific Datasources
ii. Logistics
iii. Managing Extract Structures
iv. Initialization
v. Delete the content of Setup tables (T-Code LBWG)
vi. Select the application (01 – Sales & Distribution) and Execute

- Now, Fill the Setup tables

9). Select Business Information Warehouse
i. Setting for Application-Specific Datasources
ii. Logistics
iii. Managing Extract Structures
iv. Initialization
v. Filling the Setup tables
vi. Application-Specific Setup of statistical data
vii. SD Sales Orders – Perform Setup (T-Code OLI7BW)
Specify a Run Name and time and Date (put future date)
Execute

- Check the data in Setup tables at RSA3

- Replicate the DataSource

Use of setup tables:
You should fill the setup table in the R/3 system and extract the data to BW - the setup tables is in SBIW - after that you can do delta extractions by initialize the extractor.
Full loads are always taken from the setup tables

Differences Among Query, Workbook and View

Many people are confused by the differences among: Query, Workbook, and View.

Here are my thoughts on the subject:

A query definition is saved on the server. Never anywhere else.

Although people say a workbook contains a query (or several queries); it does not. It contains a reference to a query. The workbook can be saved on the server; or anywhere else that you might save an Excel workbook.

What happens if someone changes the query definition on the server?

Answer: the next time you refresh the query in the Excel workbook, the new query definition replaces the old query definition in the workbook. Maybe. It depends on what change was made.

For example, if someone added a Condition to the query definition, the workbook will be virtually invisible to this. The Condition is available; but, is not implemented in the workbook. (Until the user of the workbook manually adds the view of the Condition and then activates it.)

For example, if someone changed the definition of a KF in the query definition, the revised KF will show up in place of the old KF in the workbook.

But ... if, for example, someone deleted the old KF and added a new KF, we get a different story. Now the old KF no longer appears (it does not exist); but, the new KF does not appear (it was not marked to be visible in the workbook).

About workbooks as views ... OK, a workbook may very well have a certain "view" of the query (drilldown, filters, et cetera). And, if the workbook is saved to the server in a Role where everyone can access it, this is good. But, if the workbook is saved to one's favorites, then this "view" is only accessible to that individual. Which may be good. Or may not.

A "saved view", on the other hand is stored on the server. So, it is available to all.

If you navigate in a workbook you can back up. You can back up, though, only as far as you navigated in the current session. You cannot back up to where you were in the middle of last week's session. Unless you saved that navigation state as a "saved view". Then, you can jump to that view at any time.

The downside of saved views is that they are easy for anyone to set up and difficult for most to delete.

Customer Exit Variable In Bex

The customer exit works at:

1. Extraction side

After enhancing datasource in RSA6 we need to populate those enhanced fields in that case we have to create a project in cmod transaction and select the Enhancement assignment RSAP0001 and select the appropriate FM and need to write the select statement in the appropriate include. EXIT_SAPLRSAP_001 - Transaction data EXIT_SAPLRSAP_002 - Master data EXIT_SAPLRSAP_003 - Text EXIT_SAPLRSAP_004 - Hierarchy The above things we need to do in Source System side Ex: R/3

2. Reporting side

We need to write the user-exit to populate Reporting related variables in the Enhancement assignment RSR00001 and select the FM EXIT_SAPLRRS0_001 and then in the include ZXRSRU01 we need to write the code. These are helpful especially we need to derive any varible.

Along with that:

BEx User Exit allows the creation and population of variables and calculations for key figures and variables on a runtime basis.

R/3 User Exit is found in R/3 under CMOD and contains additional programming that is needed to fill field additions to extract structures.

What Are Routines and Transfer

What are routines? are Transfer/Update rules and routines one and the same?

Routines are like conditions or business rules that could be applied to filter the data while entering the BW system or could be used to apply certain conditions on the info objects itself.

There are 4 types of routines

1. Start routine- Could be used at two levels (transfer rule level and the Update rule level)

This Start routine written at the transfer rule level helps filter the necessary data coming from the source system.
For Example: If you decide to extract data that contain only quantity greater than 500 , then you could specify the Start rouitne to achieve this.

The Start routine at the Update rule level provides similar functionality but at this point it helps direct specific data to
different data targets. For Example: If there 3 data targets being fed from the Infosource, you may want to apply some condition to each data target, like send year 2000 data ti Data target1, 2001 to data target 2 and so on. This can be achieved by using Start routine at the Update rule level

2. Transfer Routine: This feature is available at the transfer rule levels

While performing the transfer rules operation, there are 4 features available to the developers to create business rules on top pf the Infoobjects.

1. You could do a one to one mappping of the Infoobject
2. Provide a constant value
3. Include a formula
4. Write an ABAp routine.

These 4 options refers to the transfer routine

3. Update Routine:
The limitations of just having 4 options in the transfer routine is overcome at the update rule level. There are various other
sophisticated features avaialable apart from the 4 options mentioned above. These business rules could be specified pertaining to each data target.

4. Conversion Routine: It provides functionality to do Currency and unit conversion.

What Is SEM and BPS

What is sem & bps? Where and why we use those in relation to sap-bw?

Business Planning (BW-BPS) enables you to produce planning applications. You can either develop your own planning application or use the Business Content delivered by SAP. The area of application stretches from simple data input through to complex scenarios with data extraction, automatic planning preparation, manual data input, controlling the planning process, and retracting plan data. The architecture of BW-BPS is structured so that you are able to implement simple scenarios without great effort but are equally able to build sophisticated business-wide planning processes.

Strategic Enterprise Management - Business Planning and Simulation (SEM-BPS) is SAP's new dimension product focusing on Financial Planning. It is intended to replace all financial planning functionality that exists within R/3. SEM-BPS is a BW (Business Warehouse) based application which allows for multi-dimensional planning, complex calculation programming, etc. It allows for multiple types of front-ends. Two of the biggest are the MS Excel front-end and Web enabled planning folders and layouts.

SEM-BPS is a planning system, in which you can record and evaluate aggregated plan data. It is suitable for the collection and maintenance of data from the various functional plan sections in one uniform view.

Business Planning (SEM-BPS) enables you to produce a group-wide strategic business plan. The business plan adds an overall plan to the detailed plans that have been put together using the transaction systems' components. The aim of strategic business planning is to produce a consistent and realistic plan from various perspectives. The plan should improve the efficiency of the enterprise and the management process. Here, the issue is – in contrast to the operational subplans – less the level of detail, but rather planning the enterprise's development over the longer term.

SEM-BPS supports Web-based planning with the help of planning applications and a Status and Tracking System. With these means you can also form planning scenarios in companies with many different branches in different locations, though the technical administrative effort is limited to the availability of an internet connection.

You carry out manual planning using planning layouts. You can configure these planning layouts as you wish. Here, you can use the characteristics and key figures from the data basis, and you can also define formulas for locally-calculated key figures. The planned data is saved bottom-up, which means that data from a lower level is aggregated to the next highest level.

The SEM-BPS planning applications are used to solve standard tasks of business planning, for example balance sheet or profit planning, with as little configuration work possible.

The Data Warehouse Concept in SAP BW

The following documentation describes the data warehouse concept. As well as general information about the architecture and uses of a data warehouse, it shows the concrete implementation of the concept within SAP NetWeaver BI.

BW BI Transformation

Use

The transformation process allows you to consolidate, cleanse, and integrate data. You can semantically synchronize data from heterogeneous sources.

When you load data from one BI object into a further BI object, the data is passed through a transformation. A transformation converts the fields of the source into the format of the target.

Features

You create a transformation between a source and a target. The BI objects DataSource, InfoSource, DataStore object, InfoCube, InfoObject and InfoSet serve as source objects. The BI objects InfoSource, InfoObject, DataStore object and InfoCube serve as target objects.

The following figure illustrates how the transformation is integrated in the dataflow:

A transformation consists of at least one transformation rule. Various rule types, transformation types, and routine types are available. These allow you to create very simple to highly complex transformations:

● Transformation rules: Transformation rules map any number of source fields to at least one target field. You can use different rules types for this.

● Rule type: A rule type is a specific operation that is applied to the relevant fields using a transformation rule.

For more information, see Rule Type.

● Transformation type: The transformation type determines how data is written into the fields of the target.

For more information, see Aggregation Type.

● Rule group: A rule group is a group of transformation rules. Rule groups allow you to combine various rules.

For more information, see Rule Group.

● Routine: You use routines to implement complex transformation rules yourself. Routines are available as a rule type. There are also routine types that you can use to implement additional transformations.

For more information, see Routines in the Transformation.

BW BI Transformation Rule Type

Use

The rule type determines whether and how a characteristic or key figure, or a data field or key field is updated into the target.

Features

The following options are available:

Direct Assignment:

The field is filled directly from the selected source InfoObject. If the system does not propose a source InfoObject, you can assign a source InfoObject of the same type (amount, number, integer, quantity, float, time) or you can create a routine.

If you assign a source InfoObject to a target InfoObject that has the same type but a different currency, you have to translate the source

The Transformation Library and Formula Builder BW BI Transformation Rule Type

Use

A transformation library is available in the maintenance for transformation rules (and in the update rules). You can use this in connection with the formula builder.

Do not use formulas for VirtualProviders because inversion is not allowed for them. Use routines in this case.

Features

The transformation library, in collaboration with the formula builder, enables you to easily create formulas, without using ABAP coding.

The transformation library has over 70 pre-defined functions, in the following categories:

· Functions for character strings

· Date functions

· Basic functions

· Mathematical functions

· Suitable functions

· Miscellaneous functions

In the dialog box to select an update method, you can use the information pushbutton to get a list of the available functions with a description of their syntax.

You also have the option to implement self-defined functions in the transformation library of the formula builder. You can integrate existing function modules in these self-defined functions. In doing so, you can also make available special functions to be used frequently that are not contained in the transformation library. Refer to BAdI: Customer-defined Functions in the Formula Builder.

The formula builder has two modes: Standard and expert mode. In the standard mode, you can only enter the formulas using the pushbuttons and by double clicking on functions and fields. In the expert mode, however, you can enter formulas directly. You can also toggle between the tow modes when entering a formula.

You can find more detailed operating instructions for the formula builder by means of the information button .

You can find a step-by-step guide using an example under Example for Using the Formula Builder.

Example for Using the Formula Editor BW BI Transformation Rule Type

The company code field (0COMP_CODE) is not included in your data target or InfoSource. However you can determine the company code from the first four character spaces of the cost center (0COSTCENTER).

You create the following formula for this purpose:

SUBSTRING( cost center, '0' , '4')

Syntax:

SUBSTRING( String, Offset , Länge )

Step-by-Step Procedure in Standard mode:

1. In the transformation library, on the right hand side under Show Me, choose the category Strings. From the list, select the Substring function by double-clicking on it. The syntax of the formula is displayed in the formula window:
SUBSTRING( , , )

The cursor automatically appears over the first parameter that needs to be specified.

2. From the list on the left-hand side of the screen, choose the Cost Center field by double-clicking on it.
3. Place the cursor where you want to enter the next parameter.
4. Enter the number 0 using the Constant button (for the Offset parameter). The commas are added automatically.
5. Place the cursor where you want to enter the next parameter.
6. Enter the number 4 using the Constant button (for the Length parameter).
7. Choose Back. The formula is now checked and saved if it is correct. You receive a message if errors occurred during the check, and the system highlights the erroneous element in color.

BAdI: Customer-Defined Functions in the Formula Builder BW BI Transformation Rule Type

Use

You can integrate self-defined functions in the transformation library of the formula builder. In doing so, you can also make special functions available for frequent use that are not contained in the transformation library. The Business Add-In RSAR_CONNECTOR is available for this. For more information about using Business Add-Ins (BAdIs), see Classic BAdls.

Procedure

Implementing the BAdI

...

To implement a BAdI, see Implementing a Classic BAdl. The specific special features for the implementation of the BAdI RSAR_CONNECTOR are described below.

1. Call transaction SE19. Enter RSAR_CONNECTOR as the name for the Add-In, for which you want to create the implementation.

By double-clicking the method (GET), the class builder appears. You can enter your coding for implementing the enhancement. For more information, see Structure of Implementation of a Functionand Implementation of a Category.

A function does not have a type. Therefore, the TYPE field of structure SFBEOPRND cannot be filled.

2. Save and activate your implementation.

Naming Conventions

The technical name of a self-defined function:

● cannot be empty

● must be consistent

● must begin with ‘C_’

● can only contain alphanumeric characters, that is, 'ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_' (small letters, blank spaces and special characters are not allowed)

● can have a maximum of 61 characters

Implementing the Methods

The ABAP methods specified in the function description under class and method are called later in maintenance and formula evaluation. Therefore, the customer-defined functions must additionally be implemented as methods for BAdI implementation in an additional class. These methods must have the following properties:

● They are declared static and public.

● They can only have importing, exporting, and returning parameters. Changing parameters are not permitted.

● They can only have one exporting or returning parameter.

● Exporting parameters cannot have a generic type.

In the methods, you can use ABAP code to implement the function.

The system does not check whether the class or method specified in BAdI implementation actually exists. If a class or method does not exist, a runtime error occurs when the function is used in the formula builder.

Result

The functions you have defined are available in the transformation library in the Customer-Defined Functions selection.