What is BI Content?
Why use it and what is the purpose?
To summarize, it’s to expedite BW development and provide industry standard templates that you may use in your system. Think of BI content like walking into a giant market of SAP delivered objects (objects in ‘D’ status which means delivered, instead of ‘A’ or active status which you can actually use). Using BI Content, you can easily browse and activate various types of SAP “0” objects for use in your BW environment instead of making your own custom “Z” objects. SAP has even provides entire end to end data flow structures from source to cube. You just choose a Cube to activate and all the objects required for that cube to function will also be activated for use in your environment.
InfoPackage, DTP, and Process Chain Transport Best Practices
We have a InfoPackage, DTP, and Process Chain we need moved from our Dev environment up to Test and Prod. Should we transport these objects into the target system or manually re-create in each target environment?
InfoPackages, DTPs, and chains can be transported, however it’s not recommended due to the logical system being hardcoded into the source object. Plus they are super easy to create in the target environment. In my opinion, although chains are able to be transported, i’d recommend creating them manually in the target environment. It’s a best practice to document each of the steps/objects from the source environment process chain and re-create manually in the target system. Chains, just like info packages and DTPs, can be created even in a locked down environment (like test and Prod). They can just as easily be deleted, so do document each to better prep for disaster recovery situations.
Delta vs Full Loads
What’s the difference?
Delta loads are great. They are absolutely essential when dealing with large info provider loads. Here’s a quick example: Let’s say it’s January 1st 2015 and we have two brand new InfoCubes. One using DTP configured for delta loading and the other full loading. ZFIN2015A (Using Delta DTP)
1/1/15 – 100000 records loaded
1/2/15 – 15000 records loaded
1/3/15 – 25000 records loaded
Total record count = 140,000 after three delta loads
ZFIN2015B (Using Full DTP)
1/1/15 – 100000 records loaded
1/2/15 – 100000 records removed
1/2/15 – 115000 records loaded
1/3/15 – 115000 records removed
1/3/15 – 140000 records loaded
Total record count = 140,000 after two data drops and three full loads
Obviously this example is using a low volume of data but the real benefit of using delta over full comes into play when your DSO/Cube has let’s say 500,000,000 records. If we add 50000 records using a delta load, it won’t take more than a minute. Imagine using a full load on 500,050,000 records. It would take hours!.
Data Structures and Transporting
If we change the structure of data objects, infocubes, and transformation routines then this is done in DEV and logged into TRANSPORTS REQUESTS to be carried into TEST QA and PROD, is this correct?
Correct. All new development and modification to existing objects MUST take place in Dev and be transported upward through TEST and Prod.
Avoiding a Single Point of Failure
We have an employee that had set up reports with BEx broadcaster and has since left the company. How do we configure BEx broadcaster reports so that if a user leaves the company we are not impacting business operations?
You will need a system user created that will be the primary ID for all business critical tasks. The SAP admins (Basis Admins) or SAP Security team could help you out with getting that new account configured.
Optimizing Production the Safe Way
If we are tuning the infocubes/infoproviders (performance tuning, collapsing or compressing) then this is done in either system but will not be tracked by a TRANSPORT REQUEST. So we can do those tasks in DEV or TEST QA to practice and then do them in PROD to resolve existing slow response time?
Yes. It’s important to keep all of your BW environments in check and optimized, not just Production. What better way than to practice what you plan to optimize in lower environments prior to executing in Production. This also enables you to capture/estimate task run times and document each step along the way for easy knowledge transfer across your team.
BEx Broadcaster with Static URLs
We recently updated some of our sharepoint URLs and ever since then our BEx reports are no longer being broadcasted to our sharepoint site. How do we configure BEx broadcaster reports so that if a user leaves the company we are not impacting business operations?
You should be able to modify the existing target destination, but if you are unable to, a copy of the report with new broadcaster settings will suffice.
SAP ABAP Experience and BI/BW!
I’m an experienced SAP ABAP Developer. I’m looking to make a change and want to get into BW/BI?
BI/BW/BO is more object based where development and modeling is done through a GUI rather than coding ABAP programs. The great part about knowing ABAP is you can add tremendous value in transforming data and adding ABAP code to introduce functionality that is not pre-delivered in the transformation process of BW. We point out in the videos certain areas where ABAP may be inserted to add in additional functionality. ABAP is not a core part of this training, but knowing it can’t hurt. Google: “SAP BW start routine ABAP” to learn more about how you can use your ABAP skills in the transforming of data process.
SAP BASIS Experience IS transferrable to BI/BW!
I’m an experienced SAP BASIS Admin. I’m looking to make a change and want to get into BW/BI?
Definitely a good idea. A lot of my BI team members were BASIS admins at one time. Highly transferrable skills as you are loading data from multiple systems. You’re better able to trouble shoot RFC connection issues, slowdowns, load failures, etc…
SAP BI/BW Job Market!
How is the BI/BW job market? Are my chances good of joining a BI team or finding BI project work after completing this training?
The market is still incredibly hot. There is such a shortage for BW/BI resources. So many companies train with us to skill up other SAP (BASIS, ABAPers) and non-SAP team members in their organization to teach them BW/BI skills.
We have some BEx queries which are linked to the BW production server. Is there a way we can point them to the Development server? Is there a way to change the source system? The idea behind it is to point to the testing/dev environment as there is much less data and also we will not be disturbing the users in production and we will not be bringing down the production system.
Definitely a good idea to offload that to a sandbox/dev environment. Most companies will regularly take a snapshot of their PROD environment and copy that into a Sandbox. in addition to system refreshes, the BASIS team (SAP system admins) can assist you with capturing and migrating BW objects across the various environments within your SAP landscape. Once the object is migrated, they simply update the logical system connection/RFC connection to point to the new source database (DEV instead of PROD)
BEx Query Migration
Is the logical procedure to first create the queries in DEV and then transport it to PROD? Does this happen in BEX Query Designer? Is there a transport system in BEx Query Designer? We can see the queries in BW via transactions: RSCRM_BAPI and RSRT, but are they only created in BEX QUERY DESIGNER? and how are they transported between the systems?.
The queries are physical files that reside on the SAP Application Server and can be collected and migrated to another environment within your SAP landscape. It’s a best practice to move queries from DEV up PROD to ensure the environments stay in synch. Here’s a tutorial that walks you through the process