How To Write A Report On An Html With A Microsoft Powerbook (Aq) On A Microcube (Apl) On An Ipa (Aipa) On Your Computer Or Your Computer (Apt

Transcription

1 Best Practices for Web Intelligence Report Developers Terry Smith Technical Director, ATT.com

2 Background - Presenter Terry Smith At att.com since years working with Business Objects Former certified BO trainer Many user conferences Steering committee Seattle Area BO User Group 2

3 Synopsis Business Objects works like a giant playground. When everyone follows the same guidelines, everyone can get along and have a great time. This presentation reviews the overall guidelines and best practices for report creators, developed and used at ATT.com with BO XI 3.1. Useful for both new and advanced users, we ll share the tips we ve developed for webi developers to be able to easily create and test reports that run efficiently. Tips range from start small and use a template to understanding the differences between query filters and report filters. 3

4 Learning Points Before you start, make sure you understand the audience, and how the report will be distributed and used. When building a report, make sure you understand the data first. Review the data in a table, before including in a complex crosstab or chart. Start with a template for something similar if possible, and develop your report with a small timeframe for quick query time, and faster development. Instead of having multiple queries, each with a different filter, combine into one query, and use different filters in your report. The report will run much faster if it only has to run one query. 4

5 Report Development Typical Plan.. Develop Deploy in Production 5

6 Report Life Cycle The critical missing step. Design Develop/ Test/ Review/ Iterate Deploy in Production 6

7 Report Life Cycle The complete cycle Design Develop/ Test/ Review/ Iterate Deploy in Production Revise Retire 7

8 Best Practices for Web Intelligence Report Developers REPORT DESIGN 8

9 Report Design Overall Look and Feel Where to start Know your audience. Who? Report Purpose? What are they looking for? What further work will be done with the data? Presentation preference? Frequency? 9

10 Report Design - Distribution Plan report access and distribution. Understand Data Privacy and Security Requirements Report Distribution Infoview Sharepoint Dashboard Mobile platform Output Format PDF Webi Excel 10

11 Report Design - Standards Plan (or obtain) report design standards Report Naming Conventions TPS0245 Weekly Inventory Surplus Report Format Standards Goal: Same look and feel Appropriate to output format and distribution technique Standard elements Header/Footer From/To Date Date Run Report Title, Tab Title Page Number x of x 11

12 Report Design Plan the Testing Before you re done.. How to KNOW it s right? Know your key metrics Report review checklist Column names Totals, calculations Averages double check in total lines! No partial results Format, etc. follows standards (template) Do peer review or supervisor review of final results 12

13 Ready to Start Development.. Template Design Start with a template. Don t start from scratch! Real Templates are NOT supported yet in XI 3.1, must copy a template report, as basis for new report. Some companies have turned off the create new report function, forcing users to start with an existing report. Why a template? Ensures a correct starting point for the data being queried. Gives your reports a consistent look and feel. Report Info tab gives user information about the report and the queries. Make a copy of the template and save it to your own folder before modifying it. Also copy report tabs to get standard formatting. 13

14 Ready to Start Development.. Template Design Start with a template. Report Tab: Report Title Tab Name Date Refreshed Data From/To Dates Page Number x of x Confidentiality Statement Standard Colors, Fonts 14

15 Ready to Start Development.. Template Design Start with a template. Report Info Tab: Report Title Universe Name Date Refreshed Report Data Source Confidentiality Statement Data Provider Names & Number of rows Query Time Report Description Report Change Log Modified SQL Report Comments for Maintenance 15

16 Ready to Start Development..Template Design 16

17 Best Practices for Web Intelligence Report Developers QUERY DESIGN 17

18 Designing the Query Overall Architecture Aggregation (sum, count, etc.) Universe Data warehouse Report Aggregation s Request Data View, Format, Slice & Dice Data Your data (microcube) Data base Aggregation 18

19 Designing the Query General Rules Use only what you need Extra dimensions can create a MUCH larger set of data! Always include a measure Database aggregation is your friend! 19

20 Designing the Query Do it again and again so start small.and fast! If you have long query times.(or are impatient) Develop reports faster and with less frustration when you have a quick refresh turn-around time. Limit your result set during development Use a date range or date filter to query a short date range. Use a limited number of values. 20

21 Designing the Query KISS Keep It Simple, Silly! Start Small! Get to know the data If your report requires a large number of objects, start with the highest-level objects and add only a few at a time. Ensure that they are producing results as expected. If so, then keep adding more objects down to the level of detail you need. If all your objects are added at once and the query produces unexpected results, it will be harder to determine which object caused the issue than if you just added a few at a time. Keep an eye on the grand totals as you keep adding more objects. If that number changes as you add more objects, there may be an issue with the universe joins. 21

22 Designing the Query Crazy for queries?? Don t always be! Use multiple queries only when necessary. Using multiple queries adds processing overhead to both your report and the database. It is a common mistake to create multiple queries for subsets/ aggregations of the same basic data. Instead, use Report-Level filters & aggregation when possible. 22

23 Designing the Query Query Filters vs. Report-Level Filters Request Data Universe Data warehouse Query Filters Report Filters View, Format, Slice & Dice Data Your data (microcube) 23

24 Designing the Query Query Filters vs. Report-Level Filters Query Filters limit the result set returned from the database by your query. Report-Level Filters are applied to the result set to limit what is shown on the report, but the full result set still exists behind the scenes of the report. 24

25 Designing the Query Use webi Aggregation and Filtering Different views of the same data or different sections of data Examples Summary and detail tabs Different Regions Different Product Lines 25

26 Designing the Query Smart Query Filters - Recap Don t use multiple queries if you can use Report-Level filters to show data in the different ways you need. Don t use multiple queries if you can apply different aggregations to show the data in the different ways you need. Make your query more complex with Query Filters and/or additional objects to get the data you need, then apply Report- Level filters. 26

27 Design the Query Save frequently while creating the report. Save before running a new query by switching to View Report view, then saving, then switching back to Query view to refresh the query.

28 Design the Query Common Query Filters If you manually create the same filter across multiple reports, talk with your universe designer about creating it as a condition object. Examples: Date Range Prompt for Order Number Order Type 28

29 Designing the Query Review the data Keep a simple table view of data Verify looks right Verify totals 29

30 Partial Results Some common reasons Forgot to include key filters (date, product) Asking for data at very specific level (account level) Using objects that don t belong together (but available in universe) Universe error 30

31 Best Practices for Web Intelligence Report Developers REPORT FORMATTING AND VARIABLES 31

32 Working with the Results KISS Keep It Simple, Silly Don t get into the fancy formatting (charts, cross-tabs, breaks, sections, styles, etc) until you are sure that the query itself is returning what you need. When you re ready to get fancy, keep one tab with the original results in the plain table format. This provides easy way to check overall results. Like what you see? Save your work often! 32

33 Working with the Results Turn on the Formula Toolbar Check for the partial results icon. If your report contains the Report Info tab, the number of rows returned are also shown there. If you keep getting partial results, but you feel that your query is valid, talk with your universe designer to determine if the universe row limitation should be raised. 33

34 Working with the Results If your report requires a chart, make a copy of the result table. Turn the copy into the chart. This will allow your users to view the data behind the chart. 34

35 Format the Report Follow formatting standards Column header alignment Standard colors, font, etc. Rename Columns Only When Necessary Standard, Consistent Names = fewer questions Use the template 35

36 Develop Report Variables Why Use Variables? Perform Calculations Group Similar Data Decode Data Ask: Should this logic be in the report or in the universe? (or in the data?) Give each variable a meaningful name Can be used in other variables Can be used in multiple report tabs (within this report) Build simple variables that build on top of each other rather than one huge complex formula 36

37 Develop Report Variables Averages and other division-based calculations Average is defined in report Cannot sum an average Instead, calculate average of sums =sum(order dollar amount]) / sum([order quantity]) Not =sum(average order amount) 37

38 Best Practices for Web Intelligence Report Developers TESTING THE REPORT 38

39 Testing the Report Remove temporary filters and run report Verify no Partial Results Verify totals and averages are correct Save with desired output format (pdf, Excel, etc.) and tweak (in webi) as necessary for correct viewing Follow plan made during report design to ensure correct results

40 Prep for Production Once you ve completed your development and formatting of the final report Remove any unnecessary objects. Change the query filter(s) to what you ll use for production. Perform a final test and final formatting review with the complete data set. Determine if the nature of your reporting/overhead requires the report to be saved with data. If not, purge the queries before saving the report. This will save space on your server. 40

41 Ready for Production Congratulations! You have created a report without having gone through the fuss and frustration you may have encountered if you didn t follow these Best Practices. Now go forth and report! 41

42 Best Practices for Web Intelligence Report Developers PRODUCTION AND MAINTENANCE 42

43 Production and Maintenance Ad hoc requests. Don t proliferate Don t make many copies of the same report with only minor changes in each. Keep ONE version of each report. If you need to run an ad-hoc with an extra field or two, great, but don t keep it as another version of the report.

44 Organizing Folders and Reports in InfoView Have a folder dedicated to report templates so they are easy to find. If you have users across different business areas, create a folder for each business area under Public Folders. Create user sandboxes under each business area so that personal reports and under-construction reports are separate from the main folder. Remember that reports stored in the My Favorites folder cannot be seen by other people (including administrators). If it needs to be used/supported by others, be sure to store it under Public Folders. 44

45 Best Practices for Web Intelligence Report Developers MULTIPLE DATA PROVIDERS 45

46 Working With Multiple Data Providers Why use multiple data providers (queries)? Easy comparisons of different slices of same data.i.e. Current vs. Historical values Current month vs. last month Totals by day vs same day Avg for past 2 months Budget vs actuals Different data needed in same report 46

47 Working With Multiple Data Providers Working with multiple data providers Are you sure you need them? Analyze what is being requested to see if a single data provider can be used instead. Rename your queries with meaningful names. Don t keep them as Query 1, Query 2, etc. Don t refresh them all every time. Only refresh the one you are working on. 47

48 Working with Multiple Data Providers Depending on your queries, it may be easier to work with them when the Data tab is arranged by Query instead of Alphabetic. 48

49 Working with Multiple Data Providers Do you need to merge data from multiple data providers? Examine the data for each data provider alone. Determine totals for each. Specify the dimensions to be merged. Merge rules: Only dimensions can be merged. Merged Dimensions do not have to be from the same universe or have the same name. Merged Dimensions must have the same format and exactly matching values. 49

50 Best Practices Working with Multiple Data Providers Do you need to merge data from multiple data providers? (con t) Combine the data from the two (or more) data providers in one block. Make sure measures are correct, with correct totals, with no duplicating values. Repeating values indicates that the Business Objects cannot determine how to combine the data. Have the merged dimensions been specified? After you have validated the merged data, create variables as appropriate. Variables can reference measures from both data providers. 50

51 Working With Multiple Data Providers Working with multiple data providers Turn off Automatic Merging in Report Properties Merge dimensions as needed Create variables using measures across Data Providers For example, Current Period Data Provider Previous Period Data Provider Create Variables to show difference as between Current and Previous for dollar amount and percent change 51

52 Best Practices for Web Intelligence Report Developers SUBQUERIES 52

53 Best Practices Creating Sub-Queries Avoid subqueries if possible. Poorly defined subqueries can severely impact performance of not only your report, but also other reports running at the same time. If you must use a subquery, keep the following tips in mind: Don t try it unless you know what you re doing or get coaching. Use complete filters, including date filters, for both the primary query AND the subquery. Set the Do Not Retrieve Duplicate Rows parameter on the query. 53

54 Best Practices for Web Intelligence Report Developers OTHER BEST PRACTICES 54

55 Partnership.. Report Developer and Universe Designer Great Universe requires feedback! Query filters Decoding values Frequent calculations Default format of numbers Object descriptions Folder organization Dimensions for grouping or buckets Complex variables used in multiple reports Difficulties getting right data 55

56 Clean Up Retire reports no longer needed. Keep reports well organized 56

57 Web Intelligence Operations Webi is very picky about Java version Turn off Java updates Set extra Java memory &highlight=java+memory Sometimes, if have trouble with IE, try Firefox Always logout of Infoview. If a session is not logged out of properly, it can persist in the server. 57

58 Key Learnings Spend time on report design to understand requirements Use template to speed development and improve conformity Iterate Consider the entire life cycle 58

59 Other Sessions by att.com Group Maximizing Query Performance in a High-Volume Environment Session Code: 9002 Day and Time: Monday 10:45 AM - 11:45 AM Best Practices for Web Intelligence Report Developers Session Code: 2003 Day and Time: Monday 1:30 PM - 2:30 PM Cross Channel Analytics Session Code: 0113 Day and Time: Wednesday 10:30 AM - 11:30 AM 59

60 ] Thank you for participating. Please remember to complete and return your evaluation form following this session. For ongoing education on this area of focus, visit the Year- Round Community page at [ SESSION CODE: