Creating CO-PA DataSource

Creating CO-PA DataSource for Transaction Data

This step has to be carried out in the R/3 system:

SAP IMG Menu	Integration with Other mySAP.com Components à Data Transfer to the SAP Business Information Warehouse à Settings for Application-Specific DataSources (PI) à Profitability Analysis à Create Transaction Data DataSource
Transaction Code	KEB0

Then carry out the following steps:

1. On the CO-PA/SAP BW: DataSource for Transaction Data screen:

a. Make the following entries:

Field	Entry
DataSource	1_CO_PA%CL%ERK is automatically generated. Do not change anything. You can add additional characters.
Create	X
Operating concern	Your Operating concern, e.g.BP01.
Costing-based	X

b. Choose Execute.

c. Make the following entries:

Field	Entry
Short text	CO-PA Baseline
Medium length text	CO-PA Baseline
Long text	CO-PA Baseline
Field name for partitioning	---

4. Select all Characteristics from the segment level.

e. Select all Characteristics from the segment table.

f. Select all Value Fields.

7. Choose InfoCatalog from the application toolbar.

2. The Create Object Directory Entry dialog box is displayed requesting the user to enter a development class. Enter a development class in the customer namespace and choose Save or choose Local object.

3. On the DataSource: Customer version Edit screen:

a. Select all possible checkboxes in column Selection.

b. Choose Save.

4. In the information dialog box, choose Enter.

Then replicate the datasource in BW

Metadata Modelling

SAP BW Business Warehouse- Metadata Modelling

The administration services in SAP BW can be availed through Administration Workbench (AWB). It is a single point of entry for data warehouse development, administration and maintenance tasks in SAP BW with Metadata modeling component, scheduler and monitor as its main components as described in the figure hereunder:

Metadata modeling: Metadata modeling component is the main entry point for defining the core metadata objects used to support reporting and analysis. This includes everything from defining the extraction process and implementing transformations to defining flat or multidimensional objects for storage of information.

Modeling Features

• Metadata modeling provides a Metadata Repository where all the metadata is stored and a Metadata Manager that handles all the requests for retrieving, adding, changing, or deleting metadata.
• Reporting and scheduling mechanism: Reporting and scheduling are the processes required for the smooth functioning of SAP BW. The various batch processes in the SAP BW need to be planned to provide timely results, avoid resource conflicts by running too many jobs at a time and to take care of logical dependencies between different jobs. These processes are controlled in the scheduler component of AWB. This is achieved by either scheduling single processes independently or defining process chains for complex network of jobs required to update the information available in the SAP BW system. Reporting Agent controls execution of queries in a batch mode to print reports, identify exception conditions and notify users and pre compute results for web templates.
• Administering ETL service layer in multi- tier level: SAP’s ETL service layer provides services for data extraction, data transformation and loading of data. It also serves as the staging area for intermediate data storage for quality assurance purposes. The extraction technology of SAP BW is supported by database management systems of mySAP technology and does not allow extraction from other database systems like IBM, IMS and Sybase. It does not support dBase, MS Access and MS Excel file formats. However, it provides all the functionality required for loading data from non- SAP systems as the ETL services layer provide open interfaces for loading non-SAP data.

Tickets and Authorization in SAP Business Warehouse

What is tickets? and example?

Tickets are the tracking tool by which the user will track the work which we do. It can be a change requests or data loads or what ever. They will of types critical or moderate. Critical can be (Need to solve in 1 day or half a day) depends on the client. After solving the ticket will be closed by informing the client that the issue is solved. Tickets are raised at the time of support project these may be any issues, problems.....etc. If the support person faces any issues then he will ask/request to operator to raise a ticket. Operator will raise a ticket and assign it to the respective person. Critical means it is most complicated issues ....depends how you measure this...hope it helps. The concept of Ticket varies from contract to contract in between companies. Generally Ticket raised by the client can be considered based on the priority. Like High Priority, Low priority and so on. If a ticket is of high priority it has to be resolved ASAP. If the ticket is of low priority it must be considered only after attending to high priority tickets.

The typical tickets in a production Support work could be:
1. Loading any of the missing master data attributes/texts.
2. Create ADHOC hierarchies.
3. Validating the data in Cubes/ODS.
4. If any of the loads runs into errors then resolve it.
5. Add/remove fields in any of the master data/ODS/Cube.
6. Data source Enhancement.
7. Create ADHOC reports.

1. Loading any of the missing master data attributes/texts - This would be done by scheduling the infopackages for the attributes/texts mentioned by the client.
2. Create ADHOC hierarchies. - Create hierarchies in RSA1 for the info-object.
3. Validating the data in Cubes/ODS. - By using the Validation reports or by comparing BW data with R/3.
4. If any of the loads runs into errors then resolve it. - Analyze the error and take suitable action.
5. Add/remove fields in any of the master data/ODS/Cube. - Depends upon the requirement
6. Data source Enhancement.
7. Create ADHOC reports. - Create some new reports based on the requirement of client.

Checklists for a support project of BPS - To start the checklist:

1) InfoCubes / ODS / datatargets
2) planning areas
3) planning levels
4) planning packages
5) planning functions
6) planning layouts
7) global planning sequences
8) profiles
9) list of reports
10) process chains
11) enhancements in update routines
12) any ABAP programs to be run and their logic
13) major bps dev issues
14) major bps production support issues and resolution

Difference Between BW Technical and Functional

n general Functional means, derive the funtional specification from the business requirement document. This job normally is done either by the business analyst or system analyst who has a very good knowledge of the business. In some large organizations there will be a business analyst as well as system analyst.

In any business requirement or need for new reports or queries originates with the business user. This requirement will be recorded after discussion by the business analyst. A system analyst analyses these requirements and generates functional specification document. In the case of BW it could be also called logical design in DATA MODELING.

After review this logical desing will be translated to physical design . This process defines all the required dimensions, key figures, master data, etc.

Once this process is approved and signed off by the requester(users), then conversion of this into practically usable tasks using the SAP BW software. This is called Technical. The whole process of creating an InfoProvider, InfoObjects, InforSources, Source system, etc falls under the Technical domain.

What is the role of consultant has to play if the title is BW administrator? What is his day to day activity and which will be the main focus area for him in which he should be proficient?

BW Administartor - is the person who provides Authorization access to different Roles, Profiles depending upon the requirement.

For eg. There are two groups of people : Group A and Group B.

Group A - Manager

Group B - Developer

Now the Authorization or Access Rights for both the Groups are different.

So for doing this sort of activity.........we required Administrator.

How to handle inventory in SAP BW

Controlling the inventory in BW
very helpful document
inventory.pdf

Business Warehouse- Architecture -

Being implemented on top of SAP Web Application Services SAP’s BW provides a multi-tier architecture (figure shown below), along with a complete software development environment, system management tools and additional functionalities such as currency conversion or security. Although it is closely related to SAP R/3, SAP BW is a completely separate software package which comes with automated extraction and loading facilities.

Components of BW architecture

SAP BW is based on integrated metadata concept with metadata being managed by metadata services. SAP’s BW has following layers:

• Extraction, Loading and Transformation (ELT) services layer.
• Storage services layer, with services for storing and archiving information.
• Analysis and access services layer, which provides access to the information stored in SAP BW.
• Presentation services layer, which offers different options for presenting information to end users.
• Administration services.
• Metadata services.

Useful Tables for BW Reporting

Tables for BW Reporting:

SAP... its all just tables and programs right? Sounds pretty easy, a couple of 1s here and few 0s over there and then you have a high powered analytical datewarehouse. Works for me.

I have this pessimistic theory that as technology grows we will be so focused on growing new technologies that we will forget the basic principles that lead to these nascent developments. For instance, you dont think about how or why the database software works, it just does. But if something at that fundamental level became corrupt everything above that layer would cease to work.

Much like the engine in your car. Drivers probably give about 5 seconds thought about their car engine in a given year. But features like satellite radio, heated seats, and sun roofs seem to garner all the attention. Most drivers can tell you every detailed function about each of the buttons on the radio, but probably couldnt point out a spark plug if asked.

Long tangent, sorry.

Anyway, we use abstraction layers to simplify some complex technologies. Query designer, Visual Composer etc etc. However, when things don't work it really helps to know 'whats under the hood'. Below is a list of some helpful frontend tables to grab technical IDs (useful when troubleshooting transports) and text descriptions in bulk, amongst other things.

For homework, try using SE54 to create some nice views, then send me the view definitions!

Queries
RSZELTDIR Directory of the reporting component elements
RSZELTTXT Texts of reporting component elements
RSZELTXREF Directory of query element references
RSRREPDIR Directory of all reports (Query GENUNIID)
RSZCOMPDIR Directory of reporting components

Workbooks
RSRWBINDEX List of binary large objects (Excel workbooks)
RSRWBINDEXT Titles of binary objects (Excel workbooks)
RSRWBSTORE Storage for binary large objects (Excel workbooks)
RSRWBTEMPLATE Assignment of Excel workbooks as personal templates
RSRWORKBOOK 'Where-used list' for reports in workbooks

Web templates
RSZWOBJ Storage of the Web Objects
RSZWOBJTXT Texts for Templates/Items/Views
RSZWOBJXREF Structure of the BW Objects in a Template
RSZWTEMPLATE Header Table for BW HTML Templates