Monthly Archives: November 2014

Oracle BI Cloud Service (BICS) versus On Premise Oracle BI (OBIEE)

November 26, 2014

Oracle recently unveiled its Software-as-a-Service (SaaS) business intelligence offering called Business Intelligence Cloud Service, or BICS. The Performance Architects team is very excited about the introduction of this solution, as we believe BICS takes a big first step towards bridging the gap between departmental BI solutions that don’t scale well and those behemoth, legacy enterprise-wide BI solutions that offer reporting and some analytics, but don’t offer functionality needed to work with new data storage and data visualization technologies.

This is more than just an evolution of the on premise Oracle Business Intelligence Enterprise Edition (OBIEE) solution; it is a new platform altogether. The offering is appealing to both existing OBIEE on premise customers as well as new customers, but it is important to know the differences between the two offerings.

BICS is comprised of two main components: the BI server service and a single schema Oracle database. BICS applications can only query from data stored in this single schema Oracle database. There is no support for connecting directly to an on premise database such as a data warehouse or online transaction processing (OLTP) system. For static data sources, BICS provides an upload utility to move data into the cloud database. This is acceptable for departmental solutions, but for enterprise-wide applications with large data sources, what are the options for loading?

For large data loads, and automation thereof, BICS turns to application programming interfaces (APIs) and tools like SQL Developer. The latest versions of SQL Developer allow for a “Cloud Connection” option:

MB1

Using secure file transfer protocol (FTP) credentials provided as part of BICS, database developers can create a connection to their cloud Oracle database. Then, they can create “Carts” in SQL Developer which contain table definitions and data required for their BICS applications. These Carts are then deployed to the BICS cloud database using the cloud connector. SQL Developer also allows for command line scripting.

MB2

For existing OBIEE customers, here’s a synopsis of the differences between on premise and BICS:

MB3

In addition to these differences, I wanted to point out a few other items for those familiar with on premise OBIEE. BICS does not have a feature like Agents as of now for scheduling. As far as the BICS version of the RPD, features like physical source aliasing are not supported, while multiple key joins and variables are supported. Oracle Essbase is not supported as a data source; Oracle BI Publisher is not an option for report development; and the Oracle BI Mobile App Designer is not supported either, although content is viewable through Oracle BI Mobile HD (although we’ve heard rumors through the grapevine that all of these will be addressed shortly in coming versions!). In terms of code migration, BICS offers a snapshot capability which bundles the model, report content, and security together; a big improvement over on premise.

For more information on BICS, register for Performance Architects’ upcoming webinar entitled, “Oracle’s Business Intelligence Cloud Service (BICS) Overview and Demonstration” on December 10, 2014 at 3:30 PM EST and visit https://cloud.oracle.com/business_intelligence.

Author: Michael Bender, Performance Architects


© Performance Architects, Inc. and Performance Architects Blog, 2006 - present. Unauthorized use and/or duplication of this material without express and written permission from this blog's author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Performance Architects, Inc. and Performance Architects Blog with appropriate and specific direction to the original content.

Status and Type as Attribute Dimension Names in Oracle Hyperion Planning

November 6, 2014

The Performance Architects team recently upgraded Oracle Hyperion Planning from 11.1.2.2 to 11.1.2.3.500 at several clients. One of these upgrades was supposed to be a simple and quick engagement…and it almost was…until we discovered an issue with Attribute dimension names that slowed us down!   The purpose of this blog post is to highlight what we learned so that you don’t make the same mistake during your upgrade.

The model we upgraded was based on “classic” Hyperion Planning.  The refresh of the hierarchies was performed via the “Outline Load” utility (OLU), and data was loaded via MaxL scripts.

Post-upgrade, one of the tasks was to sync back the pre-production environment with the hierarchies and data from the production environment. Hierarchies were regularly updated in production, as this was needed to keep the model functional. However, there was never a pressing need to synchronize the pre-production environment with those updates because the artifacts didn’t change much. In this case, the task was performed in an attempt to establish a baseline post-upgrade, and because “the experts were in the house”.

The tool of choice was Oracle Life Cycle Management (LCM). Since Hyperion EPM 11.1.2.1, LCM has matured into the tool that it was always meant to be, and is not just usable – it is also makes life easier! For that reason, it is usually the Performance Architects’ team’s first choice for migrations.

That’s when we noticed something was not right. One of the custom dimensions in the “Staff” model (Position) would not export. The error message simply indicated a “sqlMember” exception. We then tried exporting the dimensions via the OLU, and found that it failed with a similar exception only on the Position dimension. In addition, importing records via OLU did not run into any problems, for any dimension. On further analysis, we found the problem to be an attribute dimension named “Type.”

It may not be a well-known fact (it was certainly not known to the consultants who built the model) that “Status” and “Type” are two words that are not supposed to be used as Attribute dimension names in Planning. The software does not stop you from naming an attribute dimension with them, but the software breaks as a result, because the code makes the assumption that these are reserved words and can be used internally. This was not a problem in 11.1.2.2, and seems to have been introduced in 11.1.2.3.500. Besides these words, using standard dimension names like “Account” or “Entity” as Attribute dimension names is discouraged.

It is difficult to comment on the reasoning behind using “Status” and/or “Type” as names for Attribute dimensions, or the reasoning behind assuming that they will not be used. It could be argued both ways, quite successfully in fact. “Based on this experience, we at Performance Architects now recommend utilizing more descriptive naming conventions (like “employee_type” and “position_status”), with the intent of reducing the risk of unknown, and conflicting system based, key words.”

Author: Andrew Tauro, Performance Architects

 


© Performance Architects, Inc. and Performance Architects Blog, 2006 - present. Unauthorized use and/or duplication of this material without express and written permission from this blog's author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Performance Architects, Inc. and Performance Architects Blog with appropriate and specific direction to the original content.