- 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.
Showing posts with label Business Warehouse. Show all posts
Showing posts with label Business Warehouse. Show all posts
Saturday, August 9, 2008
The benefits of SAP BW
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
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:
- Source Systems: The source systems, as the bottom layer, serve as the data sources for raw business data. SAP BW supports various data sources:
• 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).
• 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
- Web reporting is faster then Excel, there is less overhead in executing Web reporting as opposed to Excel. (Whitepaper on SAP about this.)
- There is not anymore work in formatting or creation of templates then in comparison to workbooks.
- Query creation is the same as in BEX, so there is no new knowledge there.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Query functionality is EXACTLY THE SAME with BEX and Web reporting, they both use query analyzer. The only difference is in presentation and output.
- With Web reporting, you have (I think) greater control over presentation (combination of reports, charts, etc...) then w/ BEX.
- 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.
- 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.
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
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.
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 machineFind / 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,
Subscribe to:
Posts (Atom)
