This post describes generic standards and guidelines that apply to the use of standard BI objects delivered by SAP as part of the BI business content. Again, these may change as per your client’s BW system standards.
Activating Business Content
Anyone with access to the sandbox may activate business content there. If you activate content in sandbox, make sure that you do not activate the content in the background (batch mode.) Instead, activate the content in the foreground and always keep any existing customization for the objects you activate.
No one except the people allowed may activate business content in SAP BW development system.
If you need business content activated, contact one of those people and explain what you need activated. Continue reading “SAP BI Business Content”
Write Optimized DataStore Objects
Consider the following important facts in mind before you choose to use a Write Optimized DataStore Object:
- The primary unique key to a WODS Object consists of Request ID, Data Packet ID, and Record Number. The system does not use the semantic key as the primary, unique key to the data. This means that each time you load a particular semantic key into a WODS Object, you get a new, unique record.
- Write Optimized DataStore Objects do not aggregate data. If you extract and load two records with the same logical key (or extract and load the same record twice,) both records appear in the WODS Object.
- No delta detection or extraction function exists for WODS Objects. When forwarding data to subsequent data targets, the system will forward the requests (loads) that have not yet moved to those targets. Note, however, that this can result in duplicate rows going to the subsequent target.
Continue reading “SAP BW Back-End Usage Standards and Guidelines”
This post provides guidelines for managing space in the SAP BW Production environment in general. It describes these guidelines in the context of generic business intelligence goals, principles, and architecture.
Principles of Data Warehousing Data Retention:
Data warehouses exist to serve as the “information memory” of an enterprise. Data warehouses record all the critical business transactions conducted by an enterprise, so decision makers and business strategists can leverage the information to meet their goals and objectives.
The Value of Historical Information:
The business intelligence team must ensure that information captured in the data warehouse supports both the current, known requirements for analyses, but also supports the future, unknown requirements.
Low level, historical transaction data captures information about past behavior of the enterprise that no other source of information provides. When we delete this data, we eliminate forever the ability of the enterprise to leverage the knowledge contained in the raw data. If we summarize data and delete the original details, we eliminate forever the ability to produce alternate summaries of that data. Continue reading “BW Data Retention / Archival and Space Management Guidelines”
This post describes best practices for building appropriate secondary indexes on DataStore Objects.
General guidelines for placing secondary indexes on DataStore Objects:
- The presence of secondary indexes on an DataStore Object can greatly improve query performance, but it may slow down load performance.
- If your application does not have routine, frequent reads or reports on a DataStore Object, do not build secondary indexes on it.
Designing Secondary Indexes:
Apply these general guidelines when determining the number and structure of secondary indexes on DataStore Objects: Continue reading “Designing and Building Secondary Indexes on DataStore Objects”
The standards and guidelines in this post apply to situations where you must move flat files into the BW environment and load them through the BW flat file interface. You may only load from flat files when you absolutely cannot use the BW Service API, the DB Connect interface, or the Universal Data Connect interface to extract data into BW.
File Locations on the BW System:
As part of your solution implementation, you need to ask the Basis team to create at least one file system directory for your application’s flat files. You should request a folder under the following path;
NOTE: Refer your client’s SAP BW Naming Convention document for the details to follow naming convention.
Managing Flat Files in BW Process Chains
The BI Technology group has developed four custom process types to help you manage flat files in BW. You can find these process types under “General Services” in the Process Chain Maintenance tool. Their icons and descriptions appear below:
Each of these process types can perform its process on either the local BW system or on a remote system accessible from the BW server via ftp. In addition, each process type allows branching to one of two subsequent processes based on success or failure.
Standards Continue reading “BW Development Standards Part 10: Flat File Management Guidelines”
This post describes standards for building process chains in SAP BW at any generic development project.
Process Chain Names & Attributes Standards:
Process chain technical names should begin with Z or as per your client naming conventions.
Descriptions for meta chains (parent process chains that execute sub-chains) should include “Meta” or “Parent.”
- Never leave a process chain under the default, “Not Assigned,” Display Grouping. Use the Display Components toolbar button ( ) to assign new process chains to the appropriate display grouping.
- Refer your client’s SAP BW Naming Convention document for Display Grouping technical names
- If you have a large application composed of multiple logical subsystems, you may create multiple display groupings for your application. Doing so can help you organize your process chains by subsystem. Just make sure the name and description conform to the client standards.
- To ensure that you do not leave process chains abandoned under the “Not Assigned” display grouping, consider getting into the habit of assigning the display grouping immediately after you create the Start process for new process chains.
Process Chain Scheduling: Continue reading “BW Development Standards Part 9: Process chain Standards and Guidelines”
This post describes the standard methods and architecture for extracting data from source systems and into the first level Data Targets.
The preferred extraction method varies depending on the source system technology. The standard extraction methods appear in descending order from most to least desired. Developers must attempt to use the methods at the top of these lists before proceeding down to the less preferred methods.
Continue reading “BW Development Standards Part 8: Data Extraction Technology”
1. All queries should be built on multi-providers – even if it is to be built on a single InfoProvider.
Multi-providers provide flexibility for the reporting layer. Additional InfoCubes/DSO’s can be added in the future without much impact to the existing reports built. In cases where data needs to be combined using “joins,” InfoSets can be created. However, multiproviders should still be built on top of InfoSets for reporting. No end user reports should be built directly on InfoCubes, DSO’s or InfoSets.
Any reports built directly on InfoCubes/DSO’s should be utilized from an IT perspective for data quality or support inquiries.
2. For reporting, standards will be set as it relates to the information stored within each data warehousing layer. InfoCubes should be used to access summarized information and, DSO’s or additional detailed InfoCubes should be used to access detailed information.
Since the data warehousing architecture should include a DSO layer, this detail information should be the basis for providing Continue reading “BW Development Standards Part 7: Reporting Guidelines”
1. Managing Change Control and Transports
This blog post addresses standards and guidelines related to changing and transporting objects within the SAP BI landscape.
1.1. General Standards and Guidelines
Do not create BW objects and leave them in the $TMP package. If you need to prototype or experiment, you should do so in the Sandbox or Temporary TR created for that purpose. If you cannot use the sandbox, contact your development manager and the BI Platform Health team to discuss options.
As you create objects, assign them the proper package (development class) and put them into the correct transport request, based on the standards described below.
1.1.1. Object Grouping and Sequencing
Group objects logically, and release transports in the following order to minimize errors: Continue reading “BW Development Standards Part 5: Transports”