• What Are Analytics?
• What Is the Difference Between Analytics, Reports, and Dashboards?
• Where are Analytics in Oracle Fusion Applications?
• What Analytics Technologies Are Available?
• Which Analytics Technologies Apply Where?
• How Users Can Edit Analytics?
• How to Choose Which Technology to Use?
• What Are Embedded Analytics?
• What Are Not Embedded Analytics?
• When Should Embedded Analytics Go in the Contextual Area?
• How Should Embedded Analytics Be Displayed?
• When Should Embedded Analytics Be Refreshed?
• What if There Is No Data to Be Displayed?
• Can I See Some Examples of Embedded Analytics?

Although some documents use the terms analytics and reporting interchangeably, in user interfaces, object type analysis refers to Oracle Business Intelligence Enterprise Edition (OBIEE) analytics, and reports refers to those produced using Oracle BI Publisher ones. For more information, see the following What Analytics Technologies Are Available? section.

The term dashboards in Oracle Fusion Applications refer to a collection of information summaries that enable users to monitor different objects and data within a subdomain or functional area of interest. In the application's navigational model, dashboards usually provide centralized, role-based launching pads to more granular tasks and information. However, in user interfaces that depend on OBIEE, such as the Reports and Analytics pane and the BI catalog, any analytic containing several regions is represented as a dashboard.

Figure 1. Analytics in the Reports and Analytics pane

The term Business Intelligence dashboard (BI dashboard) usually refers to an analytic content developed with Oracle Business Intelligence Applications (OBIA) technology.

Where Are Analytics in Oracle Fusion Applications?

Analytics can be:

• Placed in the Home dashboard
• Placed in transactional dashboards, work areas, or transactional pages (either in the local or contextual areas)
• Auxiliary to a business process and launched from the Reporting pane and displayed in a secondary window or local area

Figure 2. Home dashboard

Figure 3. Transactional pages

Figure 4. Reporting pane

A number of analytics technologies that can be used with Oracle Fusion Applications:

• Application Development Framework (ADF) data visualization technology (DVT) is a native Oracle Fusion Applications data visualization toolset for rich user experience and deep integration of transacting and analysis.
• OBIEE is an analysis tool used for ad hoc analysis that requires warehouse data, complex queries, and analytic operations. Specifically:
  • Oracle Transactional Business Intelligence (OTBI; formerly Project Ford), refers to real-time ad hoc analysis against the transactional data that is supported by a semantic layer of view objects.
  • OBIA refers to trend and historical analysis of a long range of data stored in the data warehouse, which is a database solely dedicated to analysis.
• Oracle BI Publisher can be used for high-volume operational reporting, such as payroll reports, as well as statutory reports and other highly formatted, pixel-perfect reports such as a 1099.
• Hyperion is used for financial reporting such as a balance sheet or cash flow statement.

• In dashboards, you can create the entire home dashboard in OBIEE with the user interface (UI) shell. Alternatively, you can create the home dashboard by using individual ADF DVT or OBIEE regions from the WebCenter catalog.
• On transactional pages, you can create transactional dashboards, work areas, or transactional pages with regions from either OBIEE or ADF DVT.
• In reporting, you can use the Reporting pane as a launching point for both printable Oracle BI Publisher reports, interactive OBIEE reports, and Hyperion reports.

Figure 9. Analytic technologies used in dashboards

Figure 10. Analytic technologies used in work areas and transactional pages

Figure 11. Analytic technologies used in reporting (Hyperion is not shown)

How Can Users Edit Analytics?

These environments enable users to edit or create new analytics:

• Page Composer and the Resource catalog: You can move, add, or remove analytic regions on the dashboard in Page Composer mode with the Resource catalog (provided by the Webcenter framework).
• Answers: In the OIBEE environment, you can launch Answers (either in full or as a wizard) to enable editing content of analytic regions that are built in OBIEE and to create new OBIEE content.
• Oracle BI Publisher: You can launch the Oracle BI Publisher environment to enable editing or creating new Oracle BI Publisher reports.

Figure 12. Work area in Page Composer mode with the Resource Catalog (provided by Webcenter framework)

Figure 13. OBIEE Answers

Figure 14. OBIEE Create/Edit Analysis Wizard

Figure 15. BIP

How to Choose Which Technology to Use?

Sometimes the choice between ADF DVT and OBIEE technologies for data visualization is not obvious. Base your decision about which technology to select on the expected usage of analytics in the life cycle of the application. OBIEE is an end-user tool that nondevelopers can easily use to customize content created with OBIEE. However, OBIEE limits how much you can customize the look. ADF DVT is part of JDeveloper environment and is more flexible at implementing a complex look and feel. However, using ADF DVT requires more development effort to customize the content. Ideally, you should see no effect on the look and feel with either approach because OBIEE reports are based on DVT components.

The sourcing of analytics has a significant impact on performance, which metrics are available, and on the development process required for implementation.

Analytics use cases can be divided into several types:

• Operational analytics: Those that require real-time information and are sourced directly from online transaction processing (OLTP) (either by using view objects or directly from the database schema). These analytics have no dependency on BI content. You can display transactional analytics in various forms, such as charts, tables, fields, labels, icons, inserted rows or columns, and so on, in any part of a transaction page. Teams manage all aspects of these embedded analytics on their own using JDeveloper and ADF. Examples include:
  • Data taken directly from the OLTP system (for example, "What is the current customer's name, contact, and phone number?")
    
  • Operational analytics that closely represent real-time operational reality sourced directly from OLTP (for example, "How many unprocessed invoices are there for this department and AP manager?" or "Do I have enough inventory to fill this order?").

• Operational reporting: Statutory reports and reports sent to an external organization (supplier, customer, and so on) that need to be highly formatted. Examples include payroll reports, 1099s, and trail balance reports.

• Ad hoc analytics: These analytics require real-time information and are sourced from the OTBI layer. They can appear only in an ADF frame created to host an OBIEE-delivered content area. The typical mode for this information is an ad hoc query on operational data that does not require cross-object analysis, data transformation, aggregations, advanced calculations, and so on. A detailed coordination process between the OTBI team and the Oracle Fusion Applications teams determines which metrics or dimensions and content areas are to be included in the scope. Examples include operational analytics that closely represent real-time operational reality sourced through OBIEE (for example, “What invoices over $1 million are currently open in the Asia Pacific region?” or "How many unprocessed invoices are there for this department and AP manager?" or "Do I have enough inventory to fill this order?").

• Warehouse analytics: Those that are sourced from the OBIA data warehouse. Warehouse analytics usually appear in an ADF frame created to host an OBIEE-delivered content area. A detailed coordination process between the OBIA team and the Applications teams determines which metrics or dimensions and content areas included in the scope. Examples include:
  • Analytics that represent historical perspective (for example, "What are the fulfillment performance trends?")
  • Analytics that require nontrivial calculations (for example, "What is the average cost to repair, mean time to repair, and mean time between failure for this asset?")
  • Analytics that require nontrivial aggregations (for example, "What is the year-to-date revenue for North America?" or "What does the Q3 pipeline look like across EMEA for product X?")
  • Analytics that represent cycle time analysis (for example, "What is the cycle time from order to shipment?")
  • Analytics that require cross-object joins (for example, "What is the revenue per full-time equivalent?") 

  In some cases, you can visualize warehouse date with ADF UI controls. This enables developers to combine BI data and Apps data in a single UI control.

You provide embedded analytics in the context of a business transaction.

Embedded analytics have the following characteristics:

• The information presented enables a user to effectively and expediently complete an OLTP transaction such as processing a purchase order or approving a salary adjustment.
• The user is able to see the information from inside an OLTP application in the same window, without having to drill down or invoke any command.
• The information conveyed is concise enough to convey a clear message. For example, you could consider a five-row table to be an embedded analytic, but a 1,000-row table would be considered a report.
• The information is always in the current context and directly applicable to the transaction at hand.

Good Example

The advantages of this example are that it:

• Presents data in the context of the application
• Enables users to address the example without drilling down or conducting further analysis
• Enables users to intelligently complete the transaction by either approving or rejecting it or by sending for more information

The following examples illustrate things that are not considered embedded analytics:

• Analytics used to orchestrate a business process or design a flow (for example, if a requisition is for more than 100,000 USD, send it to a VP for approval; otherwise send it to the supervisor)
• Analytics used to facilitate navigation (for example, if a sale is outstanding more than 30 days, it is send to accounts receivable)
• Dashboards
• Metrics or key performance indicators on dashboards
• Highly interactive what-if analysis tools
• Any information that is nice to have but that does not directly support the action required to complete the transaction

Bad Example

The disadvantages of this example are that it:

• Does not apply to the completion of a transaction but to the assessment of performance of an organizational entity.
• Is not in the context of transaction. Rather, it is a general and vague question about the performance of some unspecified group, and it doesn't explain what percentage of invoices is overdue. Is the overage for a division, group, or for a supplier?
• It is not appropriate for the user role. This is the kind of question that an accounts payable manager would ask using a role-based dashboard.
• It does not enable users to effectively complete the transaction.

When determining where to embed analytics on an Oracle Fusion page, the first decision point is often whether to place it in the local area or in the contextual area. Factors that help you determine this decision include:

• Form: You can place charts and tables in either the local area or in the contextual area. If the most effective presentation of an embedded analytic is more granular, such as an additional table column or a modification to information already present in the transaction UI (for example, showing preferred customers rows in bold), then place the analytic in the local area.
• Content: Users sometimes need to see the bigger picture and sometimes need to see details when they are entering data and making decisions. If the information conveyed by an embedded analytic is integral to the details of a routine task, place it in the local area where users focus their attention. Place information that presents more general information in the contextual area.
• Scope: If the local area is divided into multiple tabs or sections, and if different analytics apply to different sections, you can embed them either directly in each section of the local area or place them in the contextual area and switch or update them as users moves from tab to tab. However, if the analytic applies across all sections or tabs, you should probably placed it in the contextual area.
• Risk of being overlooked: users always have the option of collapsing the contextual area. Even when the contextual area is visible, users often tend to focus their attention on the local area. If users often collapse the contextual area the embedded analytic is vital to making correct decisions, then place it in the local area where users are most likely to see it.
• Likelihood of suppression: If all other factors are equal, and if the analytic is applicable in only certain situations and otherwise needs to be suppressed, place it in the contextual area where users can collapse or expand it without leaving blank space in the layout.

In general, performance should not be a factor in this decision. All DVT components have a content delivery property that can delay the actual rendering of the component until the data set is ready. This enables developers to show the rest of the page and then display a graph or another component later if the associated query is going to take some time to materialize. You should not expect performance advantages when placing embedded analytics into the contextual area versus the local area.

You can shape embedded analytics to fit any region or component. The decisive factor is how much information needs to be included into the analytical feature. Placing the analytics inside of the transactional interface should also be relevant to the part of the transaction that the analytics qualifies. Consider if the information is related to the entire transaction, its section, or to a single number.

Figure 16. Shows possible presentation regions and components.

Possible presentations include:

• Label and data fields
• Icon or conditional formatting (analytics used to highlight existing information)
• Table row, column, or cell
• Portlet in the contextual region
• Page section or region in the work area

The factors involved in deciding when to update each embedded analytic depend on the content and layout of the work area. You should strive to satisfy the following three criteria:

1. Is the information in synch? If an embedded analytic is tied to a specific value that appears in the work area, then you must change it whenever that value changes. Otherwise, the analytic could be misleading and cause users to make faulty decisions.
   
   
2. Is the information relevant? If an embedded analytic in the contextual area refers to information in the work area that is currently not shown (for example, because users have collapsed a section or switched to a different tab), you may need to hide or replace the embedded analytic until the information reappears, especially if users could misconstrue the embedded analytic to refer to some other currently visible information.
   
   
3. Is the information up to date? If the information is changing significantly on a minute-by-minute basis, you may need to either automatically refresh the data or provide users with some obvious means of doing so. Whenever feasible, automatically refreshing the date is preferred because users often forget to click the buttons or fail to notice them.

Always consider performance when you use embedded analytics, especially in time-critical settings such as data entry pages or customer call centers. If you cannot refresh the embedded analytic in a timely manner, reevaluate what information you actually needs to display or how the data is stored and aggregated.

When you have a large number of variables inherent in transactional taskflows, you may have a case where an insufficient amount of data or no data at all is available for a given embedded analytic. For example, a graph of employee past performance may have no data for an employee who was just hired.

You can use a number of possible strategies if a graph has no data. Make sure that users always understand that lack of data isn't an error, but rather is because of the nature of the metric and when it was measured.

Avoid creating pie charts with only one slice or bar charts with only one bar. If you frequently use empty or trivial graphs, consider using a different graph type, such as a gauge, to convey information in a way that does not produce an empty analytic.

Designers and developers should anticipate and test for conditions that result in empty graphs or missing fields. When such a situation arises, you can:

• Replace the graph or field: The same conditions that defeat one type of embedded analytic can provide an opportunity to substitute a different analytic that can provide insight into why the situation has occurred or provide additional information.
• Explain the absence of the graph or field: Fill the space usually occupied by a graph or field with a concise explanation that explains why the expected graph or field is not there.
• Hide the graph or field: Although this strategy is not recommended, sometimes the lack of an embedded analytic disrupts the page (for example, portlets in the contextual area). However, suppressing a field or graph can cause usability problems, especially if users' previous experience with the taskflow creates an expectation, if other elements on the page refer to or assume the presence of the graph, or if a sudden blank spot on the page disrupts other elements. Avoid situations in which users must search for a graph without understanding why it is absent.

During design time, you cannot predict every situation that could occur at a customer site or invest limited resources to fix every possible exception. In such cases, an empty graph may appear with axes, a frame, or a title but with no visual elements. Avoid this situation whenever possible.

Here are some screen shots taken from Oracle Fusion prototypes that illustrate ways you can embed analytics into your taskflows:

Figure 17. Label and Data fields in contextual portlets

Here the taskflow is product configuration. The local area enables users to help a customer select options to configure a product. You embed upsells and cross-sells as portlets in the contextual area, and they update automatically when users select products in the local area.

Upsells and cross-sells are not ordinarily considered to be analytics, but they meet the definition: additional data leveraged to provide actionable insight in the context of a business transaction. Place this data in the contextual area because the content is general information, not detailed information. 

Although the display options in these portlets are not interactive, they do include buttons that enable users to act directly on the provided insights. Row selection in the local area triggers updates to the contextual area, and button clicks in the contextual area trigger updates to the local area, replacing the currently selected row or adding a new row.

Figure 18. Table Column in Local Area

The product table in the local area of this task flow displays definition data about each product (description, price, and so on). The availability of each product is additional information (from a different part of the OLTP system) that helps users to complete the task at hand (selecting configuration options). In previous systems, users had to click a separate button in order to determine availability. This new design embeds the availability metric directly into the local work area as an additional column in the existing table. The integration is seamless and becomes just another property of the product to consider.

Figure 19. Graphs in the local area

In this self-service flow, users review and possibly change benefit allocations. Using two embedded graphs makes it easy for users to understand current allocations. Because this information pertains directly to the task at hand, embed it in the local area. An earlier version of this design forced users to move to a secondary page and select one graph at a time. By consolidating several simpler graphs into a single stacked bar chart and placing it beside a pie chart, users can gain the insights that they need at one glance.

Figure 20. Icon and conditional formatting

In this taskflow, analytics trigger the highlight of a number in a table cell in the local area. The item in the fourth row exceeds corporate standards, causing an exception alert to appear. Although you can display an exception analysis in some kind of separate display, it is more effective to simply highlight the item by displaying an icon button and changing both the style and color of the number itself. You embed the analytic not by adding an additional element, but by altering existing elements.