This winter, we upgraded our on-premise OBIEE 11g (11.1.1.9) to Oracle Analytics Cloud (OAC). This posts outlines some of the pain points we faced that others, (who are still using 11g) may run into while upgrading.

We had assistance from Oracle’s Cloud Lift Services (CLS) team, who created the OAC instances within Oracle Cloud Infrastructure (OCI), set up the networking components to connect to our on-premise data sources, created the identity domains and imported the 11g artifacts. They ensured data connections were functioning and sanity tested 5 pages.

Here we faced our first hiccup. While CLS was instrumental in creation of the instances and ensuring data connectivity, the actual testing my team was tasked with – as expected. However, as we found errors and other issues, CLS was not tasked with resolving these and directed us to open service requests, often for minor issues. This was not what we were originally let to believe when given the cloud sales pitch.

Lack of Documentation / Outdated Documentation

You’ll find that a lot of Oracle’s documentation referenced OAC Classic, versus the current “Gen 2” offerings that we were implementing. System administration (including user identity management) is very different between the two, and documentation for Classic (and the relating confusion around version numbers: Oracle Analytics Cloud 105.1.0-217 (also known as OAC 5.1) is Released) is not applicable for Gen 2.

Extremely Confusion / Misleading Information about IAM / IDCS

As we’re using Gen 2 architecture, we are using Oracle’s Identity Domains through their Identity & Access Management (IAM) solution, which is NOT the same as Identity Cloud Service. However, much of Oracle’s documentation conflates the two, as does Oracle Support in the SR process, and CLS used the IDCS acronym when referring to IAM.

We also ran into an issue where we exceeded the limits of the Free domain type (see IAM Identity Domain Types (oracle.com), and were advised to upgrade our domains to Premium, at a cost of 1.6cents per user/month due to confusion. Unfortunately, the actual cost was over $3 per user per month; and we ended up actually not needing to upgrade to Premium at all. We actually needed the “Oracle Apps” domain type which is free and included when OAC was provisioned – even though the UI Downgrading as a user is not possible, even with OCI tenancy admin rights, and took long enough to resolve with Oracle support that we incurred significant unexpected costs.

Email set up (SMTP configuration)

This was not part of cloud lift services engagement, and not clearly listed as out of scope, but also not specifically listed as in scope of the cloud lift services engagement. We were able to eventually work with CLS to help resolve the issue, but it took a significant amount of time and delay on the project.

Set up of usage tracking (“RCU Schema”)

As a SaaS solution, OAC does not have the traditional RCU schemas (BIPLATFORM / MDS) that OBIEE has. However, it still does have ability to write usage tracking to database tables in our warehouse. The set up of this was not part of scope, and we were on our own. Certain things are different between OBIEE and OAC (lack of S_ETL_DAY table for example) and we had to create SR’s to confirm this.

No assistance with setting us up for routine patching properly

As a SaaS solution, OAC is patched automatically by Oracle on a regular basis. We have a DEV-STG-PROD environment. However, Oracle’s CLS did not set us up, or even let us know, that we needed to specifically set the patching scheduled for the instances (DEV/STG first, then PROD), and which we only found after PROD was patched first. There’s a process (How To Submit a Service Request With Support To Request Patching Schedule Change for Oracle Analytics Cloud) to specifically request the patching schedule that we’ve since done.

No more Job Manager Windows Application

OBIEE has a windows job manager application, allowing authorized users to disable/enable and run jobs (agent emails). We have a monitoring team that used this tool to prevent emails from being run if the underlying dataset was not ready, and manually trigger them as needed after any ETL delays were resolved. OAC does not have this application, but allows users to manage emails (Deliveries) through the console user interface. Ignoring that the interface is extremely sluggish and only allows for pausing/resuming schedule, the permissions to access this interface also give users almost all admin control over the OAC instance.

I solved this by building into a Python web based application the ability for our monitoring team to trigger an agent, using the OBIEE web services that are still available for OAC. The web service does not allow for pausing schedules, so we had to solve for that by a combination of business process changes and using conditions on the agents themselves, preventing them from running if a data set wasn’t loaded.

Fine Grain Cache Clearing

We used in OBIEE the nqcmd to call ODBC procedure SAPurgeCacheByTable to purge cache by dataset (an arbitrary set of tables), via scripts saved on our Linux server. These scripts were scheduled using crontab, as well as trigger as part of our ETL processes. However, as OAC does not have nqcmd that we can access, we had to find other solution. I ultimately built this into the same python web app, using OBIEE web services to issue logical SQL, which includes calling SAPurgeCacheByTable. I was able to build in same functionality to allow the ETL process to call these same scripts.