A Scripts for Administration Tasks

Oracle Analytics Cloud provides scripts to perform some common administration tasks. Always use the scripts provided. Don’t perform any administration tasks manually.

To run the scripts, see Running Administration Scripts.

Understanding Customization and Administration

My Services is your primary tool for administering Oracle Analytics Cloud deployments. In addition, there are some scripts to perform some important administration tasks. There are two types of customization for Oracle Analytics Cloud deployments:
  • Supported customizations: Any configuration or functionality change that you make exclusively using Oracle Analytics Cloud scripts available from:

    /bi/app/public/bin

    The changes you make with these scripts are tested and supported.

  • Unsupported customizations: Any configuration or functionality change that you make using any other script or API, using WebLogic Console or Enterprise Manager, or by directly editing files. Such customizations are equivalent to on-premises customizations.
    • Custom changes aren’t covered by Oracle Support. The service owner must design, implement, and support them.

    • Unsupported customizations can prevent patching. Custom changes must be completely removed before you apply a patch and you must re-apply them after patching.

    • Customizations that require a change to read-only binary files aren’t allowed. Never make changes to any file system mounted on /bi/app/.

Administration Scripts for Data Visualization and Business Intelligence Services (BI Services)

Administrative Task Script Name More Information

Change the WebLogic administrator password for my BI service

update_wls_admin_password

Changing the WebLogic Administrator Password (BI Service Script)

Import a batch of users or roles from a CSV file

import_users_groups_csv

Importing Users and Roles from a CSV File (BI Service Script)

Edit or delete a batch of users or roles from a CSV file

update_users_groups

Updating or Deleting Users and Roles from Embedded LDAP (BI Service Script)

Add an OPSS application role to another OPSS application role

grantOpssAppRole

Adding an OPSS Application Role to Another Application Role (BI Service Script)

Configure a public storage container for sharing content

configurePublicStorage

Creating a Public Container for Sharing Content (BI Service Script)

Update the password your BI service uses to access its database schemas.

reset_schema_password

Updating Database Credentials (BI Service Script)

Export and import data sets

migrate_datafiles

Exporting and Importing Data Sets (BI Service Script)

Gather diagnostic logs related to my BI service into a ZIP file before contacting Oracle Support

collect_diagnostic_logs

Gathering Diagnostic Logs into a ZIP File (BI Service Script)

Find out the current status of my BI service

status

Getting Status Information (BI Service Script)

Stop BI component processes running on my service

stop_analytics_suite

Stopping and Starting Component Processes (BI Service Script)

Start up BI component processes on my service

start_analytics_suite

Stopping and Starting Component Processes (BI Service Script)

Register a SSL private key with my HTTP proxy

proxy_register_ssl_private_key

Registering SSL Private Keys with the HTTP Proxy for a Nonmetered Service (BI Service Script)

Redirect all HTTP calls to HTTPS

proxy_redirect_http_to_https

Redirecting HTTP Calls to HTTPS (BI Service Script)

Configure single sign-on for a nonmetered service

configure_saml_non_idcs

Configuring Single Sign-On for a Nonmetered Service (BI Service Script)

Enable a nonmetered service to store user group membership information in a database

configure_bi_sql_group_provider

Enabling Database Storage for User Group Memberships for a Nonmetered Service (BI Service Script)

Administration Scripts for Essbase Services

Administrative Task Script Name More Information

Export Essbase applications and users from v17.3.x to latest update.

export.sh filename

Migrating Essbase Applications and Users

Import Essbase applications and users from v17.3.x to latest update.

import.sh filename

Migrating Essbase Applications and Users

Gather diagnostic logs related to my Essbase service into a ZIP file before contacting Oracle Support

python collect_diagnostic_logs.py

Gathering Diagnostic Logs into a ZIP File (Essbase Service Script)

Update the password your Essbase service uses to access its database schemas

changeRCUPassword.py

Updating Database Credentials (Essbase Service Script)

Running Administration Scripts

You must be an Oracle Analytics Cloud administrator to run the administration scripts. To access a compute node associated with Oracle Analytics Cloud, you use Secure Shell (SSH) client software to establish a secure connection and log in as the user oracle. Several SSH clients are freely available. This topic describes how to run scripts using the ssh utility, included with UNIX and UNIX-like platforms.

Before you start, you’ll need some connection information:

  • The IP address of the compute node

    The IP address of a compute node associated with your Oracle Analytics Cloud service is displayed in My Services (Overview page for the service). See Viewing and Managing Services.

  • The SSH private key file that matches the public key associated with the service.

To connect to a compute node using the ssh utility:
  1. Run the utility.
    $ ssh -i private-key-file-location opc@node-ip-address
    Where:
    • private-key-file-location is the path to the SSH private key file that you registered when you created the service.

    • opc is the operating system user you must connect as. An opc user can perform operations that require root access to the compute node, such as running administration scripts, This user can use the sudo command to gain root access to the compute node.

    • node-ip-address is the IP address of the compute node in x.x.x.x format.

  2. Change to the oracle user.
    sudo su - oracle
  3. Run the Analytics Cloud script.

Changing the WebLogic Administrator Password (BI Service Script)

You set the administrator password for the WebLogic server when you set up your service. If you want to change the password you must always use the script update_wls_admin_password.

Script Location

/bi/app/public/bin/update_wls_admin_password

To run the script, see Running Administration Scripts.

Syntax

update_wls_admin_password [-h] [LOGLEVEL] [LOGDIR] 'username' 'old_password' 'new_password'

Where:

username           Existing WebLogic server administrator username.

old_password  Existing WebLogic server administrator password.

new_password  New password for the WebLogic server administrator user.

Optional parameters:
  • -h      Shows help for the script and exits.

  • LOGLEVEL      Sets the logging level for standard errors (stderr). The default is INFO. Options:

    • DEBUG
    • INFO
    • WARNING
    • ERROR
    • CRITICAL

    The logging level for messages in the log file is always DEBUG.

  • LOGDIR      Log directory. The default directory is: /var/log/bi

Example

update_wls_admin_password 'weblogic' 'oldpassword' 'newpassword'

Importing Users and Roles from a CSV File (BI Service Script)

Rather than add users manually one at a time through the Console, you can add a batch of users from a file. To do this, create a CSV (comma-separated values) file that contains the user data in a fixed format. You can create multiple user roles with member assignments from CSV files too. To import users and roles this way, use the script import_users_groups_csv.

It’s important that the CSV file is formatted correctly. Spaces are not allowed.

Import Type Information Required in the CSV Example
Users User ID,Display Name,Password,givenname,lastname,mail
User ID,Display Name,Password,givenname,lastname,mail
AGold,Ali Gold,MyPassword1,Alice,Gold,alice.gold@example.com
BJones,Brian Jones,MyPassword12,Brian,Jones,brian.jones@example.com
JSmith,Johnnie Smith,MyPassword1234,John,Smith,john.smith@example.com
SWasher,Sal Washer,MyPassword12345,Sally,Washer,sally.washer@example.com
Roles Display Name,Description,User Members

One or more User IDs separated by a semicolon.

Display Name,Description,User Members
Reviewers,This role includes a group of users who can review reports,Agold;BJones;JSmith
Editors,This role defines a group of users who can edit reports,BJones;JSmith

Script Location

/bi/app/public/bin/import_users_groups_csv

To run the script, see Running Administration Scripts.

Syntax

import_users_groups_csv [-h] --admin-user ADMIN_USER
                                --type {users,groups}
                               [--loglevel LOGLEVEL] [--logdir LOGDIR]
                               filename

Where:

filename           Name of the CSV file.

Optional parameters:

  • h      Shows Help for the script and exits.

  • ADMIN_USER      Sets the administrator user name.

  • users,groups      Specifies the type of CSV you want to import.

  • LOGLEVEL       Sets the logging level for standard errors (stderr). The default is INFO. Options:

    • DEBUG
    • INFO
    • WARNING
    • ERROR
    • CRITICAL

    The logging level for messages in the log file is always DEBUG.

  • LOGDIR      Log directory. The default directory is: /var/log/bi

Examples

import_users_groups_csv weblogic_admin users allmyusers.csv
import_users_groups_csv weblogic_admin groups allmygroups.csv

Updating or Deleting Users and Roles from Embedded LDAP (BI Service Script)

(Only valid for services using WebLogic embedded LDAP server). Rather than updating or deleting users manually one at a time through the Console, you can update or delete a batch of users from a file. To do this, create a CSV (comma-separated values) file that contains the user data in a fixed format. You can update or delete multiple user roles from CSV files too. To modify users and roles this way, use the script update_users_groups.

It’s important that the CSV file is formatted correctly. Spaces aren’t allowed.

Type Information Required in the CSV Example
Users User ID,Display Name,Password,givenname,lastname,mail
AGold,Ali Gold,MyPassword1,Alice,Gold,alice.gold@example.com
BJones,Brian Jones,MyPassword12,Brian,Jones,brian.jones@example.com
JSmith,Johnnie Smith,MyPassword1234,John,Smith,john.smith@example.com
SWasher,Sal Washer,MyPassword12345,Sally,Washer,sally.washer@example.com
Roles Display Name,Description,User Members

One or more User IDs separated by a semicolon.

Reviewers,This role includes a group of users who can review reports,Agold;BJones;JSmith
Editors,This role defines a group of users who can edit reports,BJones;JSmith

Script Location

/bi/app/public/bin/update_users_groups

To run the script, see Running Administration Scripts.

Syntax

update_users_groups [-h] --admin-user ADMIN_USER
                                --action {update,delete}
                                --type {users,groups}                              [--loglevel LOGLEVEL] [--logdir LOGDIR]
                               filename

Where:

filename           Name of the CSV file.

Optional parameters:

  • h      Shows Help for the script and exits.

  • ADMIN_USER      Sets the administrator user name.

  • update,delete      Specifies whether you want to modify or delete users (or groups) in the CSV file.

  • users,groups      Specifies whether the CSV file contains users or groups.

  • LOGLEVEL       Sets the logging level for standard errors (stderr). The default is INFO. Options:

    • DEBUG
    • INFO
    • WARNING
    • ERROR
    • CRITICAL

    The logging level for messages in the log file is always DEBUG.

  • LOGDIR      Log directory. The default directory is: /var/log/bi

Example

update_users_groups delete removeoldusers.csv

Adding an OPSS Application Role to Another Application Role (BI Service Script)

Oracle Platform Security Services (OPSS) application roles can include other OPSS application roles. Use the script grantOpssAppRole. to grant an OPSS application role to another application role.

Note:

Only use this script to grant OPSS application roles. You can’t use it to grant any other type of role, user, or group.

Script Location

/bi/app/public/bin/grantOpssAppRole

To run the script, see Running Administration Scripts.

Syntax

grantOpssAppRole [-h] ADMIN_USER MEMBERROLENAME APPROLENAME [LOGLEVEL] [LOGDIR]

Where:

ADMIN_USER      Username for the WebLogic server administrator.

MEMBERROLENAME  OPSS application role that you want to grant to APPROLENAME.

APPROLENAME      OPSS application role in which you want to add MEMBERROLENAME.

Optional parameters:
  • -h      Shows help for the script and exits.

  • LOGLEVEL      Sets the logging level for standard errors (stderr). The default is INFO. Options:

    • DEBUG
    • INFO
    • WARNING
    • ERROR
    • CRITICAL

    The logging level for messages in the log file is always DEBUG.

  • LOGDIR      Log directory. The default directory is: /var/log/bi

Example

grantOpssAppRole admin NewSalesTeamAppRole SalesManagerAppRole

Creating a Public Container for Sharing Content (BI Service Script)

You can define a public storage container so that other users can share their content. Use the script configurePublicStorage to specify the storage container you want to use.

If you configured a public container when you set up your service, you override the container that you specified when you run this script.

Script Location

/bi/app/public/bin/configurePublicStorage

To run the script, see Running Administration Scripts.

Syntax

configurePublicStorage user pwd baseurl container [force]

Where:

user - Name of a user with permission to create containers.

pwd - Password for the storage user.

baseurl - Base URL for the storage service. For example: https://storage.oraclecorp.com/v1

    • https://domain.storage.oraclecloud.com/v1

      For example: https://example.storage.oraclecloud.com/v1

    • https://Storage-GUID.storage.oraclecloud.com/v1

      For example: https://Storage-ab1c23de4456f78g9123456hi7k8j89.storage.oraclecloud.com/v1

container - Name of the storage container you want to create, in the format: storage-identityDomainID/containtername

Optional parameters:

force - Override the current public container, if one is designated.

Example

configurePublicStorage --user mystorageuser.Storageadmin --pwd secretpassword --baseURL https://storage.oraclecorp.com/v1 --container Storage-mystorageuser/My_Public_Container force

Exporting and Importing Data Sets (BI Service Script)

You can export and import data sets that users have uploaded to Oracle Analytics Cloud. Use the script migrate_datafiles to export all the data sets in cloud storage to an archive (.zip file) and import them on another service.

Script Location

/bi/app/public/bin/migrate_datafiles

To run the script, see Running Administration Scripts.

Syntax

migrate_datafiles sikey archive action

Where:

sikey - Service key. Always bootstrap.

archive - Full path to the archive you want to create or import. For example /tmp/mydatasets.zip.

action - Either export or import.

Example — Export

$ migrate_datafiles bootstrap /tmp/mydatasets.zip export

  Enter encryption password for archive: ENTER_PASSWORD
  Confirm encryption password for archive: ENTER_PASSWORD
$ chmod ugo+rw /tmp/dss.zip

Example — Import

If you haven’t done so already, copy the data set archive you want to import the target service, for example mydatasets.zip.

$ migrate_datafiles bootstrap /tmp/mydatasets.zip import
  Enter encryption password for archive: ENTER_PASSWORD
  Confirm encryption password for archive: ENTER_PASSWORD

Updating Database Credentials (BI Service Script)

When you create an Oracle Analytics Cloud service, various schemas are created and loaded into an associated Oracle Database Cloud Service that you select. If the database administrator password for this Oracle Database Cloud Service changes or expires, you can use the reset_schema_password script to update the password that your BI service uses to access its schemas.

Before you run the command, you must stop BI processes, and then restart them after resetting the password.
  1. Connect to the compute node for your service

  2. Change to the script folder: /bi/app/public/bin

  3. Stop BI processes using the script stop_analytics_suite

  4. Update the schema password using the script reset_schema_password

  5. Restart BI processes, using the script start_analytics_suite

Script Location

/bi/app/public/bin

To run the script, see Running Administration Scripts.

Syntax

reset_schema_password [-h] [LOGLEVEL] [LOGDIR]

Where:

  • -h      Shows help for the script and exits.

  • LOGLEVEL      Sets the logging level for standard errors (stderr). The default is INFO. Options:

    • DEBUG
    • INFO
    • WARNING
    • ERROR
    • CRITICAL

    The logging level for messages in the log file is always DEBUG.

  • LOGDIR      Log directory. The default directory is: /var/log/bi

Example

To update the schema password, run all three scripts from /bi/app/public/bin in this order:

> stop_analytics_suite
> reset_schema_password
> start_analytics_suite

Gathering Diagnostic Logs into a ZIP File (BI Service Script)

If you're troubleshooting an issue with your service or you need to contact Oracle Support, you can easily collect all available log files into one place. Use the script collect_diagnostic_logs to collect diagnostic data into a ZIP file.

Script Location

/bi/app/public/bin/collect_diagnostic_logs

To run the script, see Running Administration Scripts.

Syntax

collect_diagnostic_logs [-h] [--loglevel LOGLEVEL] [--logdir LOGDIR] filename

Where:

filename           Name of the ZIP file you want to generate.

Optional parameters:

  • h      Shows help for the script and exits.

  • LOGLEVEL       Sets the logging level for standard errors (stderr). The default is INFO. Options:

    • DEBUG
    • INFO
    • WARNING
    • ERROR
    • CRITICAL

    The logging level for messages in the log file is always DEBUG.

  • LOGDIR      Log directory. The default directory is: /var/log/bi

Example

collect_diagnostic_logs DiagnosticsForMyService.zip

Getting Status Information (BI Service Script)

You can find out the status of your service at any time. Use the script status to report whether WebLogic Server and various other BI processes are up and running.

If this script can't respond for some reason, restart the service and try again. See Stopping and Starting Component Processes (BI Service Script).

Script Location

/bi/app/public/bin/status

To run the script, see Running Administration Scripts.

Syntax

status [-v]

Where:

v           Indicates verbose.

Example

>status

/Servers/AdminServer/ListenPort=7001
Accessing admin server using URL t3://xxx:7001

Status of Domain: /bi/domain/fmw/user_projects/domains/bi
NodeManager xxx:9556): RUNNING  

Name Type Machine Restart Int Max Restart Status
---- ---- ------- ----------- ----------- ------ 
AdminServer Server xxx unknown unknown RUNNING 
bi_server1 Server m1 unknown unknown RUNNING 
obiccs1 OBICCS m1 3600 2 RUNNING 
obisch1 OBISCH m1 3600 2 RUNNING 
obips1 OBIPS m1 3600 2 RUNNING 
obijh1 OBIJH m1 3600 2 RUNNING 
obis1 OBIS m1 3600 2 RUNNING

Stopping and Starting Component Processes (BI Service Script)

If you’re having issues, you can restart the BI components running on your service rather than the entire service. Restarting BI components is often quicker than restarting the service. When you stop BI processes, anyone who is signed in, is signed out. When you restart, users are prompted to sign in again. Use scripts stop_analytics_suite and start_analytics_suite to stop and start BI components.

Script Location

/bi/app/public/bin/stop_analytics_suite

/bi/app/public/bin/start_analytics_suite

To run the scripts, see Running Administration Scripts.

Syntax — stopPod.py

stop_analytics_suite [-h] [--loglevel LOGLEVEL] [--logdir LOGDIR]
start_analytics_suite [-h] [--loglevel LOGLEVEL] [--logdir LOGDIR]

Optional parameters:

  • h      Shows help for the script and exits.

  • LOGLEVEL      Sets the logging level for standard errors (stderr). The default is INFO. Options:

    • DEBUG
    • INFO
    • WARNING
    • ERROR
    • CRITICAL

    The logging level for messages in the log file is always DEBUG.

  • LOGDIR      Log directory. The default directory is: /var/log/bi

Examples

stop_analytics_suite
start_analytics_suite

Registering SSL Private Keys with the HTTP Proxy for a Nonmetered Service (BI Service Script)

If you have a nonmetered subscription for Oracle Analytics Cloud, you can register your custom SSL certificates to secure HTTPS access to your service. Use the script proxy_register_ssl_private_key. to register your private key and your Certificate Authority (CA) signed certificate.

When the service is created, a self-signed certificate is generated. The self-signed certificate is intended to be temporary and you must replace it with a new private key and a certificate signed by a CA which your browsers are configured to trust (that is, a commercial CA built into the browser by the browser vendor).  The temporary certificate expires after one year.

Before You Run the Script

  1. Verify that your private key and SSL certificate files contain the required information.
    • Private key and CA signed certificate must use the DNS registered name as the common name (CN).

      • CA signed certificate must also include the CN as the first Subject Alternative Name

    • Private key and CA signed certificate files must be in PEM format.

    • Private key must not be protected with passphrase.

    • Private key permissions must be set to read-only and owned by the oracle user.

    Note:

    To test any changes you make to certificates and certificate chains on Windows, you might need to clear your SSL state. From the Control Panel menu, select Internet Options, then Content, then Clear SSL State.
  2. If your service uses a DNS registered host name, specify the host name that you want to secure with SSL in servername.conf:

    Note:

    Each service has a public IP address available on the internet. You can register your own FQDN (Fully Qualified Domain Name) against this public IP address so your service appears in your organization's internet domain. The FQDN must match the CN in the certificate. The FQDN must also be present as Subject Alternative Name in the certificate.
    1. Create a file named servername.conf at this location:

      /bi/data/httpd/conf.d/servername.conf

    2. Set permissions on the file as, owned by the oracle user and readable by everyone.

    3. In servername.conf, add a single line:

      ServerName <DNS name that matches your SSL certificate>

      For example: ServerName analytics.myexample.com

Script Location

/bi/app/public/bin/proxy_register_ssl_private_key

To run the script, see Running Administration Scripts.

Syntax

proxy_register_ssl_private_key [-h] [LOGLEVEL] [LOGDIR] privatekeypath sslcertificatepath

Where:

privatekeypath Name and location of the file containing your private key. For example: /temp/myprivate.key

sslcertificatepath Name and location of the SSL certificate. For example: /temp/mycertfile.crt

Optional parameters:

  • h      Shows help for the script and exits.

  • LOGLEVEL      Sets the logging level for standard errors (stderr). The default is INFO. Options:

    • DEBUG
    • INFO
    • WARNING
    • ERROR
    • CRITICAL

    The logging level for messages in the log file is always DEBUG.

  • LOGDIR      Log directory. The default directory is: /var/log/bi

Redirecting HTTP Calls to HTTPS (BI Service Script)

By default, both HTTP and HTTPS access to the Oracle Analytics Cloud URL is enabled. If you want to redirect all incoming HTTP traffic to HTTPS, you can use the script proxy_redirect_http_to_https.

For example, if you currently access the service using http://analytics.mycorp.com/analytics, you are redirected to this URL after running the script: https://analytics.mycorp.com/analytics.  The browser should confirm the valid certificate.

Script Location

/bi/app/public/bin/proxy_redirect_http_to_https

Syntax

proxy_redirect_http_to_https [-h] [LOGLEVEL] [LOGDIR]

Optional parameters:

  • h      Shows help for the script and exits.

  • LOGLEVEL      Sets the logging level for standard errors (stderr). The default is INFO. Options:

    • DEBUG
    • INFO
    • WARNING
    • ERROR
    • CRITICAL

    The logging level for messages in the log file is always DEBUG.

  • LOGDIR      Log directory. The default directory is: /var/log/bi

Example

proxy_redirect_http_to_https

Configuring Single Sign-On for a Nonmetered Service (BI Service Script)

If you have a nonmetered subscription for Oracle Analytics Cloud you can configure your service as a SAML 2.0 service provider to federate single sign-on (SSO) against an external SAML 2.0 identity provider. A complete documented solution is available through My Oracle Support (Doc ID 2340646.1). You must log a service request if you want access to this support note. This SSO approach is under controlled availability because the primary mechanism for SSO is based on Oracle Identity Cloud Service, which isn’t available with nonmetered subscriptions.

One of the steps in the support note instructs you to run the script configure_saml_non_idcs to configure your service to accept the SSO user ID from the SAML service provider.

Note:

Don’t run this script if you subscribe to Oracle Analytics Cloud through Oracle Universal Credits. If you do so, your service might not work properly.

Script Location

/bi/app/public/bin/configure_saml_non_idcs

To run the script, see Running Administration Scripts.

Syntax

configure_saml_non_idcs [-h] [LOGLEVEL] [LOGDIR]
Optional parameters:
  • -h      Shows help for the script and exits.

  • LOGLEVEL      Sets the logging level for standard errors (stderr). The default is INFO. Options:

    • DEBUG
    • INFO
    • WARNING
    • ERROR
    • CRITICAL

    The logging level for messages in the log file is always DEBUG.

  • LOGDIR      Log directory. The default directory is: /var/log/bi

Example

configure_saml_non_idcs

Enabling Database Storage for User Group Memberships for a Nonmetered Service (BI Service Script)

If you have a nonmetered subscription for Oracle Analytics Cloud, you might want to store user group memberships in a database and for your service’s authentication provider to access this information when authenticating a user's identity. You can use the script configure_bi_sql_group_provider to set up the provider and create the tables that you need (GROUPS and GROUPMEMBERS). After you run the script, you must populate the tables with your group and group member (user) information.

Note:

Group memberships that you derive from the SQL provider don't show up in the Users and Roles page in Oracle Analytics Cloud Console as you might expect but the member assignments work correctly.

These tables are in the Oracle Database Cloud Service you configured for Oracle Analytics Cloud and in the schema created for your service. Unlike the on-premises equivalent functionality, you can’t change the location of these tables or the SQL that retrieves the results. Instead, you must populate these fixed tables using any supported means for loading database tables.

Script Location

/bi/app/public/bin/configure_bi_sql_group_provider

To run the script, see Running Administration Scripts.

Syntax

configure_bi_sql_group_provider [-h] [LOGLEVEL] [LOGDIR]
Optional parameters:
  • -h      Shows help for the script and exits.

  • LOGLEVEL      Sets the logging level for standard errors (stderr). The default is INFO. Options:

    • DEBUG
    • INFO
    • WARNING
    • ERROR
    • CRITICAL

    The logging level for messages in the log file is always DEBUG.

  • LOGDIR      Log directory. The default directory is: /var/log/bi

Example

configure_bi_sql_group_provider

Migrating Essbase Applications and Users

You can migrate applications and users from Oracle Analytics Cloud — Essbase services from v17.3.3 (or earlier) to the latest version, using scripts.

Prerequisites

You can use the scripts in this section to import Essbase applications, users and groups when you install a new Essbase service version.

Note:

  • Oracle Identity Cloud Service (IDCS) requires that user fields aren’t empty. If you’re enabling IDCS, then in your existing Essbase services and prior to migrating your data, open the Security tab and ensure that all user data fields (including ID, name. email, and role) contain values and aren’t empty.

  • When you export applications, the target file is overwritten. If you want to save the previous version of an LCM exported application, rename it or run the export script with another file name.

Before you migrate applications and users, copy the following scripts from the older Essbase service version to the latest version, at the same file location. You can check first whether they already exist on the new host

  • /u01/app/oracle/tools/acss/BI/esscs_tools/lcm/esscs_lcm.py

  • /u01/app/oracle/tools/acss/BI /esscs_tools/lcm/idcs_users.py

  • /u01/app/oracle/tools/acss/BI /esscs_tools/lcm/ldap_users.py

  • /u01/app/oracle/tools/acss/BI /esscs_tools/lcm/user_group.py

  • /u01/app/oracle/tools/acss/BI /esscs_tools/public/essbase_export.sh

  • /u01/app/oracle/tools/acss/BI /esscs_tools/public/essbase_import.sh

Export Script Location

/bi/app/public/bin

To run the export script, see Running Administration Scripts.

Export Syntax

essbase_export.sh filename

Where:

filename           Full path to the tar archive file that stores all Essbase applications, CSV files of users and groups, and files of settings.

Import Script Location

/bi/app/public/bin

To run the import script, see Running Administration Scripts.

Import Syntax

essbase_import.sh filename

Where:

filename           Name of the tar created by the export script.

Gathering Diagnostic Logs into a ZIP File (Essbase Service Script)

If you're troubleshooting an issue with your service or you need to contact Oracle Support, you can easily collect all available log files into one place.

Script Location

/bi/app/public/bin

To run the script, see Running Administration Scripts.

Syntax

python collect_diagnostic_logs.py [-h] filename

Where:

filename           Full path of the ZIP file that you want to generate.

Optional parameter:

h      Shows help for the script.

Example

python collect_diagnostic_logs.py /tmp/DiagnosticsForEssbaseService

Updating Database Credentials (Essbase Service Script)

When you create an Essbase service, various schemas are created and loaded into the Oracle Database Cloud Service that you selected. If the password expires for this Oracle Database Cloud Service, you can use the changeRCUPassword script to update the password that your Essbase service uses to access the database.

The changeRCUPassword script changes passwords for:

  • Wallet Store stored credentials

  • Bootstrap credentials

  • WebLogic server data sources

  • Oracle database schemas

Script Location

/bi/app/public/bin

To run the script, see Running Administration Scripts.

Syntax

python changeRCUPassword.py <new_password> <sys db_user> <sys db_password>

Where:

new_password New password for the database.

sys db_user System database user name.

sys db_password System database user password.

Example

python changeRCUPassword.py xxxxxxxx dsmith ds112233