Pre-Source Configuration Validations

Source configuration refers to the process of preparing both the source database and the target database to extract data from the source and transform and load the target database. This section helps you verify that Oracle Utilities Analytics Warehouse is prepared to receive data from the source database.

Before you begin, be sure that source-specific BI extract parameters are configured properly. This section covers all pre-source configuration scenarios and all input parameters required for the installer to configure source. Validate each of the scenarios in this section before running the source configuration.

Source System

# Validation Script or Steps to Validate
C01 Validate that only certified version of source application should be configured. Make sure that the application version you have chosen to configure with Oracle Utilities Analytics Warehouse product is in the product support matrix → Certified source list.
C02

For OUAW version prior to 2.8.0.1.2:

Validate that source DB time zone and timestamp is the same as target.

Run the following query in the source database application schema and in the target database MDADM schema. Validate that time zone is the same in both source and target.

select current_timestamp from dual;
C03

For OUAW versions 2.8.0.1.2 and later, and NMS versions 2.6 and later:

  • Validate that the Source Database time zone is equal to ‘UTC’.

  • Validate that the Source application server timezone and timestamp are the same as target Database or server.

For OUAW versions 2.8.0.1.2 and later, and all other Source products (including NMS versions prior to 2.6):

  • Validate that the source Database timezone and timestamp are the same as target.

  • To validate that the Source database time zone is equal to 'UTC', run the query SELECT DBTIMEZONE FROM DUAL; in the source database. The output of the should be ‘+00:00’.

  • To validate the Source application server time zone, log in to NMS webworkspace > About and check the timezone.

  • To validate the timezone in Target Database, run the query SELECT DBTIMEZONE FROM DUAL; in the target database.

  • To validate the timezone in Target server, run the date command on the target server.
C04 Validate that source DB character set is the same as target.

Run the following query in the source database application schema and in the target database MDADM schema. Validate that character set is the same in both source and target.

select * from nls_database_parameters where parameter in ('NLS_NCHAR_CHARACTERSET','NLS_CHARACTERSET');
C05 Validate that the source database is in archive log mode.

Run the following query in the source database application schema and validate that one row is displayed:

select * from v$database where log_mode = 'ARCHIVELOG';
C06 Validate that the supplemental logging is enabled on primary key columns.

Run the following query in the source database application schema and validate that one row is displayed:

Select * From v$database Where supplemental_Log_Data_Pk = 'YES';
C07 Validate that the system parameter enable_goldengate_replication is set to true for data replication using GoldenGate.

Run the following query in the source database application schema and validate that one row is displayed:

select * from v$parameter where name = 'enable_goldengate_replication' and value = 'TRUE';
C08 Validate that a database user exists in the source database for the GoldenGate owner.

Run the following query in the source database application schema and validate that one row is displayed:

select * from dba_users where username = 'CCB01SRC'
C09 Validate that GG owner user has required privileges.

Run the following query in the source database application schema and validate the following:

select grantee,granted_role,admin_option from dba_role_privs where grantee = 'CCB01SRC' union select grantee,privilege,grantable from dba_tab_privs where grantee = 'CCB01SRC' union select grantee,privilege,admin_option from dba_sys_privs where grantee = 'CCB01SRC' and privilege='UNLIMITED TABLESPACE' and admin_option='YES';

Validate that GG owner schema has CONNECT, RESOURCE, SELECT, EXECUTE, INSERT, UPDATE, UNLIMITED TABLESPACE, EXPORT/IMPORT FULL DATABASE privileges
C10 Validate that database directory B1_DATA_DUMP_DIR exists in source.

Run the following query in the source database application schema and validate the following:

select * from dba_directories where directory_name = 'B1_DATA_DUMP_DIR';
  1. It should return one row.
  2. Ensure that the path mentioned in DIRECTORY_PATH column is a valid path.
  3. Oracle user should be able to read and write on this directory.
C11 Validate Oracle GoldenGate version installed in source. Open the GoldenGate command line interface (adminclient) and validate that the version displayed in the command line interface should be as per the product support matrix.
C12 Validate that a Trail file folder exists with same name as the context code in /<GoldenGate Microservices Deployment Home Directory>/var/lib/data location.
To validate this:
  1. Navigate to GoldenGate Microservices Deployment directory in source.
  2. Validate that a folder with same name as the context code should be present under <Deployment Home Directory>/var/lib/data directory.
C13 Validate that a 128-bit encryption key, along with its logical name, exists in the ENCKEYS file in <GoldenGate Microservices Deployment Home Directory>/etc/conf/ogg location.
To validate the 128-bit encryption key:
  1. Navigate to <GoldenGate Microservices Deployment Home Directory>/etc/conf/ogg path in source.
  2. Open the ENCKEYS file.
  3. Validate that this file has a logical key name and key using which trail data will be encrypted.
C14 Validate that all the GoldenGate services of Source are in running state.

Log in to the Source Administration Server URL of GoldenGate Microservices and verify the status of Extracts on Home screen.
C15 Validate the security certificates in the Source GoldenGate Microservices server.

To validate the security certificates:

  1. Go to GoldenGate Microservices server in Source.
  2. Navigate to the location where certificates are located.
  3. Verify the presence of Root CA Certificates, Server Certificates, and Client Certificates.
C16 Validate that the Trusted certificate between the Source Distribution server and Target Receiver server is added to the wallet.

To validate the Trusted Certificates between Source Distribution server and Target Receiver server:

  1. In Source, go to GoldenGate Microservices servers in Source server.
  2. Navigate to $deployment_home/etc/ssl/.
  3. Run the following command:

    orapki wallet display <Source_GGMS_deployment_home/etc/ssl/$Source_Distribution_Server_wallet_name> -pwd <Source Wallet Password>
C17 Validate that source application URL is not accessible for user transactions.
To validate that the source application URL is not accessible:
  1. Application URL should be down, and users should not be able create/modify any transactions at the time of source configuration.
  2. Application database should be up and running.
C18 Validate that mandatory patches for Oracle GoldenGate (if any) have been applied.
To validate that mandatory patches for Oracle GoldenGate have been applied:
  1. Find the list of patches for Oracle GoldenGate from the product support matrix.
  2. Navigate to the OPatch directory of each installed software.
  3. Run the 'opatch lsinventory ' command
  4. Validate that all required patches have been applied.

Target System

# Validation Script or Steps to Validate
C19 Validate that a database directory with the name B1_DATA_DUMP_DIR exists in the target database.

Run the following query in target database MDADM schema and validate the following:

select * from dba_directories where directory_name = 'B1_DATA_DUMP_DIR';
  1. It should return one row.
  2. Ensure that the path mentioned in DIRECTORY_PATH column is a valid path.
  3. Oracle user should have read and write privileges on this directory.
C20 Validate that Repository Creation Utility (RCU) for Oracle Data Integrator is executed and the required schemas are created in the target data warehouse.

Run the following query in target database MDADM schema and validate the following:

SELECT comp_name,owner FROM schema_version_registry where mrc_name='<schema prefix>';

<schema prefix>: Prefix you have provided at the time of running the RCU.

Query should retrieve one row for each of these components:
  1. Audit Service
  2. Audit Service Append
  3. Audit Service Viewer
  4. Oracle Platform Security Services
  5. Service Table
  6. WebLogic Services
C21 Validate that WebLogic domain exists for Oracle Data Integrator Agent configuration.
To validate that WebLogic domain exists for Oracle Data Integrator Agent configuration:
  1. Navigate to /<Oracle Data Integrator home> /user projects/domains/
  2. Within this domain directory, there should be one directory with the same name as when the domain was created.
C22 Validate that WebLogic Administration server for Oracle Data Integrator is in running state. Log in to the WebLogic Administration Console for Oracle Data Integrator and validate that the user can login successfully.
C23 Validate that WebLogic Managed server for Oracle Data Integrator is in running state.
To validate that WebLogic Managed server for Oracle Data Integrator is in running state:
  1. Log in to the WebLogic Administration Console for ODI.
  2. In the left pane, expand Environment and select Servers.
  3. In the Servers table, the server's state is indicated in the State column. Validate that it is in a running state.
C24 Validate that Oracle Data Integrator WebLogic Agent test connection is successful.
To validate that Oracle Data Integrator WebLogic Agent test connection is successful:
  1. Log in to Oracle Utilities Analytics work repository using Oracle Data Integrator Studio client.
  2. Navigate to Topology → Agents → OracleDIAgent.
  3. Validate that the host name and port number should be managed server port.
  4. Right-click OracleDIAgent and click Test.
  5. Validate that the connection is successful.
C25 Validate that a Trail file folder exists with same name as the context code in /< GoldenGate Microservices Deployment Home Directory>/var/lib/data location.
To validate that a Trail file folder exists with same name as the context code:
  1. Navigate to GoldenGate Microservices Deployment directory in source.
  2. Validate that a folder with the same name as the context code is present under <Deployment Home Directory>/var/lib/data directory.
C26 Validate that a 128-bit encryption key, along with its logical name, exists in the ENCKEYS file in <GoldenGate Microservices Deployment Home Directory>/etc/conf/ogg.
To validate that a 128-bit encryption key, along with its logical name, exist:
  1. Navigate to <GoldenGate Microservices Deployment Home Directory>/etc/conf/ogg path in source.
  2. Open the ENCKEYS file.
  3. Validate that this file has a logical key name and key using which trail data will be encrypted.
C27 Validate that all the GoldenGate services of Target are in running state.
To validate that all the GoldenGate services of Target are in running state:
  1. Log in to the Target Service Manager URL of GoldenGate Microservices.
  2. On the Home screen, verify that the status of all services are "Running".
C28 Validate Access Control List on Target Database Server.

To validate the Access Control List on Target Database Server:

  1. Connect to the target database as a sys user using Sqlplus sys/<sys password>@<database service name> as sysdba.
  2. Run the query SELECT * FROM DBA_NETWORK_ACLS;.
C29 Validate the Security certificates in Target GoldenGate Microservices servers.

To validate the security certificates:

  1. Go to GoldenGate Microservices server in Target.
  2. Navigate to the location where certificates are located.
  3. Verify the presence of Root CA Certificates, Server Certificates, and Client Certificates.
C30 Validate that the Source Root CA Certificate is added to the Target Client Wallet.

To validate that the Source Root CA Certificate is added to the Target Client Wallet:

  1. Go to Target GoldenGate Microservices server.
  2. Navigate to $deployment_home/etc/ssl/.
  3. Run the following command:

    orapki wallet display <Target GoldenGate Microservices Deployment Home>/etc/ssl/<Target_Client_wallet> -pwd <Target client wallet password>
C31 Validate that the Trusted certificate between the Source Distribution server and Target Receiver server is added to the wallet.

To validate that the Trusted certificate is added to the wallet:

  1. Go to Target GoldenGate Microservices server.
  2. Navigate to $deployment_home/etc/ssl/.
  3. Run the following command:

    orapki wallet display <Target_GGMS_deployment_home/etc/ssl/$Target_Receiver_Server_wallet_name> -pwd <Target Wallet Password>

Source Application Parameters

This section covers the configurations that need to be done on the Oracle Utilities Analytics Framework based source applications. These configurations are not applicable to the Oracle Utilities Network Management System source. For Network Management System, parameters and buckets need to be configured in the Oracle Utilities Administration Tool post-source configuration.

Customer Care and Billing Parameters and Buckets

Ensure that the following extract parameter and bucket configurations are done properly for Customer Care and Billing and Customer to Meter source configuration. Any modification to these parameters or bucket configurations will require reset and reload of target dimensions and facts. Also, all replication views need to be regenerated.

# Validation Script or Steps to Validate
D01

To Do Characteristic Types

This extract parameter is used for configuring the Account, Service Agreement, Person, and Premise characteristic types that are used to determine the corresponding entities related to a To Do. This is used for the To Do facts (i.e. CF_TD_ENTRY, and CF_RECENT_TD_ENTRY).

Run the following query in source database application schema and validate the following:

select value(x).getrootelement() src_parm_type, extractvalue(value(y),'//parameterType') src_param_type_cd, extractvalue(value(y),'//parameterValue') parm_value from f1_mst_config , table(xmlsequence(extract(xmltype('<xml>' ||mst_config_data ||'</xml>'),'//parameterType/../..'))) p , table(xmlsequence(extract(value(p),'/'))) x, table(xmlsequence(extract(value(x),'//parameterType/..'))) y where trim(bus_obj_cd) = 'C1-BIExtractParametersConfig';

Validate that four records are present with not null parameter value for parameter type toDoCharacteristicTypes.

Note:

Use this query to validate scenarios from D01 - D14.
D02

Recent To Do Miscellaneous

This extract parameter is used for configuring a numeric value that denotes the 'Completed in Days' parameter. Recent To Do entry fact loads all active To Do entries and To Do entries which are completed within this configured number of days.

 Using the query listed in scenario D01, validate that one record is present with not null parameter value for parameter type recentToDoMiscellaneous.
D03

Financial Transaction Characteristic Values

This extract parameter holds the Revenue and Tax characteristic values that are used to determine the Revenue and Tax amount, respectively, of the FT. These values are used by the Financial Transaction, Financial Transaction General Ledger, and SA Billing facts (CF_FT, CF_FT_GL, and CF_SA_BILLING).

 Using the query listed in scenario D01, validate that two records are present with not null parameter value for parameter type ftCharacteristicValues.
D04

Financial Transaction Characteristic Types

This extract parameter contains the GL Account characteristic types that are used to determine the GL Accounts that are extracted for the Financial Transactions, Financial Transaction General Ledger, and SA Billing facts (CF_FT, CF_FT_GL, and CF_SA_BILLING).

 Using the query listed in scenario D01, validate that one record is present with not null parameter value for parameter type ftCharacteristicTypes.
D05

Exclude Archive Adjustment Types

This extract parameter contains all the archive adjustment types that should be excluded by the FT and FT GL facts (CF_FT, and CF_FT_GL).

This is not a mandatory parameter. If Exclude Archive Adjustment Types is configured then at least one record should be present with not null parameter value for parameter type excludeArchiveAdjustmentTypes.

Use the query listed in scenario D01 to validate.
D06

Broken PA Characteristic Types

This extract parameter contains the Broken characteristic type that is used to identify if a payment arrangement is broken. This is used by the Payment Arrangement facts (CF_PA, and CF_PA_SNAP).

 Using the query listed in scenario D01, validate that one record is present with not null parameter value for parameter type brokenPACharacteristicType.
D07

Broken PA Characteristic Values

This extract parameter contains the Broken characteristic value that is used to identify if a payment arrangement is broken. This is used by the Payment Arrangement facts (CF_PA, and CF_PA_SNAP).

 Using the query listed in scenario D01, validate that one record is present with not null parameter value for parameter type brokenPACharacteristicValue.
D08

Broken PA Adjustment Cancel Reasons

This extract parameter contains the adjustment cancel reason that is used to identify if a payment arrangement is broken. This is used by the Payment Arrangement facts (CF_PA, and CF_PA_SNAP).

This is not a mandatory parameter. If Broken PA Adjustment Cancel Reasons is configured then at least one record should be present with not null parameter value for parameter type brokenPAAdjustmentCancelReasons.

Use the query listed in scenario D01 to validate.
D09

Overdue Bill Characteristic Types

This extract parameter contains the overdue bill characteristic type that is used to identify the bill that is associated with the Overdue Process. This is used by the Overdue Process and Event extracts (CF_COLL_PROC, and CF_COLL_EVT).

 Using the query listed in scenario D01, validate that one record is present with not null parameter value for parameter type overdueProcessCharacteristicTypes.
D10

High Bill Complaint Characteristic Types

This extract parameter contains the characteristic type that is used to identify the bill associated with the High Bill Complaint case. This is used by the SA Billing fact (CF_SA_BILLING).

 Using the query listed in scenario D01, validate that one record is present with not null parameter value for parameter type highBillCharacteristicTypes.
D11

Exclude High Bill Complaint Case Statuses

This extract parameter contains the case statuses for which High Bill Complaint cases should not be considered. This is used by the SA Billing fact (CF_SA_BILLING) to identify if a bill is associated to a high bill complaint. If this parameter is configured, then all these statuses will not be excluded at the time of populating high bill indicator.

This is not a mandatory parameter. If Exclude High Bill Complaint Case Statuses is configured then at least one record should be present with not null parameter value for parameter type excludeHighBillCaseStatusTypes.

Use the query listed in scenario D01 to validate.
D12

High Bill Complaint Case Types

This extract parameter contains the case types for high bill complaint cases. This is used by the SA Billing fact (CF_SA_BILLING).

 Using the query listed in scenario D01, validate that one record is present with not null parameter value for parameter type highBillCaseTypes.
D13

SA Snapshot Miscellaneous

This extract parameter contains a numeric value to denote the Exclude SAs Closed in Days parameter. Exclude SAs Closed in Days, if specified, is used to retrieve SAs closed within the last 'x' days, for inclusion on the SA Snapshot and Payment Arrangement Snapshot facts (CF_SA, and CF_PA_SNAP)

 Using the query listed in scenario D01, validate that one record is present with not null parameter value for parameter type saArrearsMiscellaneousTypes.
D14

IncludeBillCalculationLines

This extract parameter contains a value for bill segment lines to be included. It is used to calculate CALC_AMT column in Billed Usage Fact (CF_BILLED_USAGE)

 Using the query listed in scenario D01, validate that one record is present with not null parameter value for parameter type includeBillCalculationLines.
D15

Billing Day In Window Buckets

Billing Day In Window bucket configuration defines the bucket ranges that identify the day in the billing window when the bill segment was frozen. It also indicates whether the range is within the window or outside the window.

Two sets of ranges can be defined for this bucket configuration: one set for day ranges that fall inside the billing window (bill window status of In Window), and another set for day ranges that fall outside the billing window (bill window status of Outside Window).

This bucket configuration data is extracted into the Billing Day In Window Dimension (CD_BILL_DAY_IN_WIN). Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd= 'C1-BillingDayInWindow';
Two sets of bucket ranges should be present. One set is for inside day in window and another for outside day in window. In each set:
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
D16

Days Before Bill Window Closes Buckets

Days Before Bill Window Closes bucket configuration defines the bucket ranges that identify the number of days left before the bill window closes.

Two sets of ranges should be configured for this bucket configuration: one set for day ranges when the bill window is still open (window closure status is Open), and another set for days when the bill window is closed (window closure status is Closed).

This bucket configuration data is extracted into the Days Before Bill Window Closes Dimension (CD_DAYS_TO_WIN_CLS).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd= 'C1-DaysBeforeBillWindowCloses';
Two sets of bucket ranges should be present. One set for day ranges when the bill window is still open, and another set for days when the bill window is closed. In each set:
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
D17

Days of Unbilled Usage Buckets

Days of Unbilled Usage bucket configuration defines the bucket ranges used to identify how many days the service agreement has usage but has not been billed for.

This bucket configuration data is extracted into the Days of Unbilled Usage Dimension (CD_DAYS_UNBILLED_USG).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd= 'C1-DaysOfUnbilledUsage';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
D18

Days Since Last Frozen Bill Segment Buckets

Days Since Last Frozen Bill Segment bucket configuration defines the bucket ranges used to identify the number of days since the service agreement has a frozen bill segment.

This bucket configuration data is extracted into the Days Since Last Frozen Bill Segment Dimension (CD_DAYS_LAST_FRZ_BS).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd= 'C1-DaysSinceLastFrozenBSeg';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
D19

PA Future Payment Age Buckets

PA Future Payment Age defines the configurable day ranges indicating the age of future scheduled payments for payment arrangements. The future payments for a payment arrangement are approximated using the number of installments left and the frequency that the payment arrangement SA is billed (via the bill cycle schedule of the account).

This bucket configuration data is used in PA Accumulation/Snapshot facts (CF_PA, and CF_PA_SNAP).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd= 'C1-PAFuturePaymentAge';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
D20

PA Number of Installments Buckets

PA Number of Installments bucket defines the bucket ranges used to group payment arrangements based on the number of installments.

This bucket configuration data is extracted into the Number of Installments Dimension (CD_INSTALLMENT_CNT).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd= 'C1-PANumberOfInstallments';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
D21

PA Recurring Charge Amount Buckets PA Recurring Charge Amount Buckets

A Recurring Charge Amount bucket defines the bucket ranges used to group payment arrangements based on their recurring charge amounts.

This bucket configuration data is extracted into the PA Recurring Charge Amount Dimension (CD_REC_CHARGE_AMOUNT).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd= 'C1-RecurringChargeAmounts';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
D22

PP Future Payment Age Buckets

Pay Plan Future Payment Age bucket defines the age buckets for which future payments for pay plans are scheduled to be paid.

This bucket configuration data is used in Pay Plan Accumulation/Snapshot facts (CF_PAY_PLAN, and CF_PAY_PLAN_SNAP).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='C1-PPFuturePaymentAge';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
D23

SA Arrears Buckets

SA Arrears bucket defines the bucket ranges for the service agreement's arrears age.

This bucket configuration data is used in the SA Arrears Snapshot fact (CF_ARREARS).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd= 'C1-SAArrearsBuckets' ;
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. Gaps in bucket ranges are not allowed.
  4. Overlaps are allowed within the bucket ranges.

Meter Data Management Parameters and Buckets

Ensure that the following extract parameter and bucket configurations are done properly for Meter Data Management source configuration. Any modification to these parameters or bucket configurations will require reset and reload of target dimensions and facts. Also, all replication views need to be regenerated.

# Validation Script or Steps to Validate
E01

Market Relationship Types

A service point may have several service providers (for example: distributor, retailer, etc.) where each is defined with a specific market relationship type on either the service point directly or on the service point's market indirectly.

All fact tables for meter data management populates SPR1_KEY and SPR2_KEY column based on two market relationship types configured.

Run the following query in the source database application schema and validate the following.

select value(x).getrootelement() src_parm_type, extractvalue(value(y),'//parameterType') src_param_type_cd, extractvalue(value(y),'//parameterValue') parm_value from f1_mst_config , table(xmlsequence(extract(xmltype('<xml>' ||mst_config_data ||'</xml>'),'//parameterType/../..'))) p , table(xmlsequence(extract(value(p),'/'))) x, table(xmlsequence(extract(value(x),'//parameterType/..'))) y where trim(bus_obj_cd) = 'D1-ODIBasedBIMasterConfig';

Validate that two records are present with marketRelationshipTypes.

Note:

Use this query to validate scenarios from E01 - E04.
E02

Subscription Types

A service point may have several usage subscriptions. All fact tables for meter data management populates US1_KEY and US2_KEY column based on two usage subscriptions are determined via the Subscription Type.

 Using the query listed in scenario E01, validate that two records are present with subscriptionTypes.
E03

Activity Category Types

Activity accumulation fact (CF_DEVICE_ACTIVITY) extract only activities, whose Activity Type Category is specified on this master configuration BO.

If this parameter is not configured, then this fact will not load any data.

 Using the query listed in scenario E01, validate that at least one record is present with activityCategoryTypes.
E04

Device Event BOs to Exclude

Device Event accumulation fact (CF_DEVICE_EVT) can be filtered to exclude certain device events. The device events, whose Device Event BO is specified on this master configuration BO, are excluded in the extract.

 It is not mandatory that above query should return one or more rows with deviceEventBOs. If this BO is configured and rows returned with deviceEventBOs, then ETL will exclude related device events, else it will load all device events.
E05

Measurement Condition

This extendable lookup is used to define a measurement, such as the source/type of the measurement (for example: a system estimate vs. a normal read vs. a human override). This configured values are extracted into Measurement Condition Code Dimension(CD_MSRMT_COND).

Run the following query in the source database application schema and validate that at least one record is displayed:

select * from f1_ext_lookup_val where bus_obj_cd='D1-MeasurementConditionLookup';
E06

Days Since Last Normal Measurement

This extendable lookup is used to define the age ranges for days since the last normal measurement was received. The configured values are extracted into Days Since Last Normal Measurement Dimension (CD_DAYS_LAST_MSRMT).

Run the following query in the source database application schema and validate that at least one record is displayed:

select * from f1_ext_lookup_val where bus_obj_cd='D1-DaysSinceLastNormalMsrmtLkp';
E07

Usage Snapshot Type

This extendable lookup is used to define the granularity of the aggregated consumptions of a service point. It defines the TOU map that is applied to the service point's consumptions, where every resultant TOU and condition results in a row on the SP Usage Snapshot fact.

Run the following query in the source database application schema and validate that at least one record is displayed:

select * from f1_ext_lookup_val where bus_obj_cd ='D2-ConsumptionSnapshotTypeLkup';
E08

Days Since Last Usage Transaction

This extendable lookup is used to define the bucket definitions for the number of days since the last usage transaction was created for the service point. These age bucket definitions are used while extracting data for the Unreported Usage Snapshot Fact.

Run the following query in the source database application schema and validate that at least one record is displayed:

select * from f1_ext_lookup_val where bus_obj_cd ='D2-DaysSinceLastUTLookup';
E09

Unreported Usage Analysis Snapshot Type

This extendable lookup is used to define the different aging snapshots that can be taken for a service point for different types of usage subscriptions. Multiple snapshots of a single service point are allowed as implementations could have multiple systems it is sending consumption to and it may need a snapshot for each.

Run the following query in the source database application schema and validate that at least one record is displayed:

select * from f1_ext_lookup_val where bus_obj_cd ='D2-SPUTAgingSnapshotTypeLookup';
E10

External System Mapping

This extendable lookup provides a mapping between an external system and its data source indicator.

This parameter is for integration between different OUAF-based source products for cross product integration for OUAW.

To validate External System Mapping lookup value for MDM of C2M product:
  1. Log in to the C2M source application.
  2. Navigate to Meter Data Analytics Configuration > Analytics – Oriented Extendable Lookup List.
  3. Click External System Mapping under the Description column.
  4. Validate if the DSI value of CCB is added under the extendable lookup section.
E11

External System Entity Name

This extendable lookup defines the entity names of entity information that can be received from external systems.

This parameter is for integration between different OUAF-based source products for cross product integration for OUAW.

To validate External System Entity Name lookup value for MDM of C2M product:
  1. Log in to the C2M source application.
  2. Navigate to Meter Data Analytics Configuration > Analytics – Oriented Extendable Lookup List.
  3. Click SOM - External System Entity Name under the Description column.
  4. Validate if the External Entity Name value of CCB is added under the extendable lookup section.
E12

External System ID Mapping

This extendable lookup provides a mapping between the external identifiers captured in Oracle Utilities Meter Data Management and the external system where that identifier is from.

This parameter is for integration between different OUAF-based source products for cross product integration for OUAW.

To validate External System ID Mapping lookup value for MDM of C2M product:
  1. Log in to the C2M source application.
  2. Navigate to Meter Data Analytics Configuration > Analytics – Oriented Extendable Lookup List.
  3. Click SOM - External System ID Mapping under the Description column.
  4. Validate if the External Entity ID value of CCB is added under the External System Identifier Mapping section.

Mobile Workforce Management Parameters and Buckets

Ensure that the following extract parameter and bucket configurations are done properly for Mobile Workforce Management source configuration. Any modification to these parameters or bucket configurations will require reset and reload of target dimensions and facts. Also, all replication views need to be regenerated.

# Validation Script or Steps to Validate
F01

Crew Time Usage

Crew Time Usage is an extendable lookup defining crew time usage types (Work, Travel, POU, Break, Depot, Idle, Logon, Logoff, Out of Service, Wait), where each crew time usage type is further classified as either productive or not.

The configured values are extracted into Crew Time Usage Dimension (CD_CREW_TM_USG).

Run the following query in the source database application schema and validate the following:

Select f1_ext_lookup_value,bo_data_area from f1_ext_lookup_val where bus_obj_cd='M1-CrewTimeUsageLookup';
  1. Query should return one or more rows (i.e. crew time usage codes).
  2. For each row in bo_data_area column a code should be present inside the tag <productivityIndicator>. For example: <productivityIndicator>M1NP</productivityIndicator>. Here, productivity code is M1NP.
F02

Crew Hierarchy

Crew hierarchies organize crews into logical structures of up to three levels that represent their position relative to other crews. The configured values are extracted into Crew Dimension (CD_CREW).

Run the following query in the source database application schema and validate the following:

Select h.m1_hierarchy_cd,u.m1_hier_lev_flg from m1_hierarchy h , m1_hier_upstream u , m1_resrc_char c Where h.m1_hierarchy_cd=u.m1_hierarchy_cd and u.M1_Hier_Lev_Flg in ('M101','M102','M103') and c.char_val_fk1=h.m1_hierarchy_cd and c.char_type_cd='M1CRHIER';
  1. Query should display rows with crew hierarchy code and hierarchy level if set already.
  2. Validate that hierarchy level flag contains M101 or M102 or M103.
F03

Service Area Hierarchy

Service Area hierarchies organize service areas into logical structures of up to three levels that represent their position relative to other service areas. The configured values are extracted into Service Area Dimension (CD_SERVICE_AREA).

Run the following query in the source database application schema and validate the following:

Select h.m1_hierarchy_cd,u.m1_hier_lev_flg from m1_hierarchy h , m1_hier_upstream u , m1_svc_area_char c Where h.m1_hierarchy_cd=u.m1_hierarchy_cd and u.M1_Hier_Lev_Flg in ('M101','M102','M103') and c.char_val_fk1=h.m1_hierarchy_cd and c.char_type_cd='M1SAHIER';
  1. Query should display rows with service area hierarchy code and hierarchy level if set already.
  2. Validate that hierarchy level flag should contain M101 or M102 or M103.
F04

Appointment Time Buckets

Appointment time bucket configuration defines the time ranges (in minutes) indicating whether the crew missed an appointment and if so, by how much time.

This bucket configuration data is extracted into the Appointment Time dimension (CD_APPT_TM).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='M1-AppointmentTimeBucketConfig';
  1. One negative bucket should be present for early appointment. For example, start range is -99999 and end range is 0.
  2. No gaps or overlaps are allowed within the bucket ranges.
  3. Bucket ranges should be configured as per the business need and it should cover all possible values. For example: -99999 to 0 (on time), 0-5(on time), 5-15 (15min Late), 15-30 (30min Late), 30-60(1 hour Late), 60-99999 (Too Late).
F05

Appointment Time of Day Buckets

Appointment time of day bucket configuration defines the time ranges (in minutes) classifying an appointment time of day. This bucket configuration data is extracted into the Appointment Time of Day dimension (CD_APPT_TM_OF_DAY). Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='M1-AppointmentTimeOfDayBktConf';
  1. Bucket start and end range should be configured based on the crews business hours. For example, Crews will be available from 8am-8pm then start range is 480min end 1200min. This big bucket can be break into smaller multiple buckets like (8am-10am, 10am-12pm, 2pm-5pm, and 5pm-8pm).
  2. Gaps and overlap ranges are allowed.
  3. At least one bucket should be present to cover each time of the day.
F06

Late Logon Buckets

Late logon bucket configuration defines the time ranges (in minutes) indicating by how much time the crew is late to logon for a shift.

This bucket configuration data is extracted into the Late Logon dimension (CD_LATE_LOGON_TM).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='M1-LateLogonBucketConf';
  1. One negative bucket range -99999 to 0 should be configured to represent on time logon.
  2. No gaps or overlaps are allowed within the bucket ranges.
  3. Bucket ranges should be configured as per the business need and it should cover all possible values. For example: -99999 to 0 (on time), 0-5(on time), 5-15 (15min Late), 15-30 (30min Late), 30-60(1 hour Late), 60-99999 (Too Late).
F07

Early Logoff Buckets

Early logoff bucket configuration defines the time ranges (in minutes) indicating by how much time the crew is logging off earlier than planned for a shift. This bucket configuration data is extracted into the Early Logoff dimension (CD_EARLY_LOGOFF_TM). Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='M1-EarlyLogoffBucketConf';
  1. One negative bucket range -99999 to 0 should be configured to represent on time/Late logoff.
  2. No gaps or overlaps are allowed within the bucket ranges.
  3. Bucket ranges should be configured as per the business need and it should cover all possible values. For example: -99999 to 0 (on time/Late logoff), 0-5(on time), 5-15 (15min early), 15-30 (30min early), 30-60(1 hour early), 60-99999 (Too early).
F08

Work Duration Deviation Buckets

Work duration deviation bucket configuration defines the percentage ranges to indicate the deviation of actual work duration relative to estimated work duration.

This bucket configuration data is extracted into the Work Duration Deviation dimension (CD_WORK_DUR_DEV).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='M1-WorkDurationDeviationBktCon';
  1. Negative bucket ranges should be present for underestimated or as expected (i.e. actual duration is more than the expected duration).
  2. Positive bucket ranges should be present for overestimated or as expected (i.e. actual duration is less than the expected duration).
  3. No gaps or overlaps are allowed within the bucket ranges.
  4. Bucket ranges should be configured as per the business need and it should cover all possible values. For example: -99999 to -25 (>25% Under), -25- to -10 (10–25% Under), -10 to -1 (1–10% Under), -1 to 0 (As Expected), 0 to 10(<10% Over), 10 to 25 (10–25% Over), and 25 to 99999(>25% Over).
F09

Travel Duration Deviation Buckets

Travel duration deviation bucket configuration defines the percentage ranges to indicate the deviation of actual travel duration relative to estimated travel duration.

This bucket configuration data is extracted into the Travel Duration Deviation dimension (CD_TRAVEL_DUR_DEV).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='M1-TravleDurationDeviBktCon';
  1. Negative bucket ranges for underestimated or as expected (i.e. actual duration is more than the expected duration).
  2. Positive bucket ranges for overestimated (i.e. actual duration is less than the expected duration).
  3. No gaps or overlaps are allowed within the bucket ranges.
  4. Bucket ranges should be configured as per the business need and it should cover all possible values. For example: -99999 to -25 (>25% Under), -25- to -10 (10–25% Under), -10 to -1 (1–10% Under), -1 to 0 (As Expected), 0 to 10(<10% Over), 10 to 25 (10–25% Over), and 25 to 99999(>25% Over).
F10

Travel Distance Deviation Buckets

Travel distance deviation bucket configuration defines the percentage ranges to indicate the deviation of actual travel distance relative to estimated travel distance.

This bucket configuration data is extracted into the Travel Distance Deviation dimension (CD_TRAVEL_DIST_DEV).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='M1-TravleDistanceDeviBktCon';
  1. Negative bucket ranges for underestimated or as expected (i.e. actual distance is more than the expected distance).
  2. Positive bucket ranges for overestimated (i.e. actual distance is less than the expected distance).
  3. No gaps or overlaps are allowed within the bucket ranges.
  4. Bucket ranges should be configured as per the business need and it should cover all possible values. For example: -99999 to -25 (>25% Under), -25- to -10 (10–25% Under), -10 to -1 (1–10% Under), -1 to 0 (As Expected), 0 to 10(<10% Over), 10 to 25 (10–25% Over), and 25 to 99999(>25% Over).
F11

Response Time Deviation Buckets

Response time deviation bucket configuration defines ranges (in minutes) to indicate the deviation of actual response time relative to response time SLA.

This bucket configuration data is extracted into the Response Time Deviation dimension (CD_RESP_TM_DEV).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='M1-ResponseTimeDeviBktCon';
  1. Negative bucket ranges for underestimated or as expected (i.e. actual response time is more than the expected).
  2. Positive bucket ranges for overestimated (i.e. actual response time is less than the expected)
  3. No gaps or overlaps are allowed within the bucket ranges.
  4. Bucket ranges should be configured as per the business need and it should cover all possible values. For example: -99999 to -25 (>25% Under), -25- to -10 (10–25% Under), -10 to -1 (1–10% Under), -1 to 0 (As Expected), 0 to 10(<10% Over), 10 to 25 (10–25% Over), and 25 to 99999(>25% Over).

Work and Asset Management Parameters and Buckets

Ensure that the following extract parameter and bucket configurations are done properly for Work and Asset Management source configuration. Any modification to these parameters or bucket configurations will require reset and reload of target dimensions and facts. Also, all replication views need to be regenerated.

# Validation Script or Steps to Validate
G01

Location BO Parameters

Location snapshot fact (CF_LOCATION_SNAP) will be loaded based on Business Object codes configured for Location BO Parameter.

Run the following query in the source database application schema and validate the following:

select value(x).getrootelement() "Extract Parameter Type", extractvalue(value(y),'//parameterType') "Parameter Code", extractvalue(value(y),'//parameterValue') "Parameter Value" from f1_mst_config , table(xmlsequence(extract(xmltype('<xml>'||mst_config_data||'</xml>') ,'//parameterType/../..'))) p , table(xmlsequence(extract(value(p),'/'))) x , table(xmlsequence(extract(value(x),'//parameterType/..'))) y where trim(bus_obj_cd) in ('W1-WAMBIExtractParameters','W1-BIExtractParameters');

Validate that at least one record is present with locationBOParameter.

Note:

Use this query to validate scenarios from G01 - G05.
G02

Asset BO Parameters

Asset snapshot fact (CF_ASSET_SNAP) will be loaded based on Business Object codes configured for Asset BO Parameter.

 Using the query listed in scenario G01, validate that at least one record is present with assetBOParameter.
G03

Firmware Parameters

In Operational Device Dimension (CD_OPR_DEVICE) there are ten slots for firmware's to capture the appropriate firmware versions of the asset.

 Using the query listed in scenario G01, validate that at least one record is present with firmwareParameter.
G04

Operation Device BO Parameters

Operational Device Dimension (CD_OPR_DEVICE), Operational Device Snapshot (CF_OPR_DEVICE_SNAP), and Operation Device Accumulation (CF_OPR_DEVICE) facts will be loaded based on Business Object codes configured for the Operation Device BO Parameter.

 Using the query listed in scenario G01, validate that at least one record is present with operationalDeviceBOParameter.
G05

Asset Failure Parameters

Failed Indicator in Operational Device Snapshot and Asset Location facts are populated based on the failure condition codes configured for the Asset Failure Parameters.

 Using the query listed in scenario G01, validate that at least one record is present with assetFailureParameter.
G06

Asset Age Buckets Asset

Age bucket configuration defines various bucket ranges that are used to classify how long an asset has been in the system. This bucket configuration data is extracted into the Asset Age Bucket Dimension (CD_W_ASSET_AGE).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='W1-WAssetAgeBuckets';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
G07

Asset Installation Age Buckets

Asset Installation Age bucket configuration defines various bucket ranges that are used to classify how long an asset has been installed on the field.

This bucket configuration data is extracted into the Asset Installation Age Bucket Dimension (CD_W_ASSET_INSTALL_AGE).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='W1-WAssetInstallAgeBuckets';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
G08

Asset Criticality Buckets

Asset Criticality bucket configuration defines various bucket ranges that are used to classify the criticality defined at a given location.

This data is extracted into the Location dimension (CD_LOCATION).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='W1-AssetCriticalityBuckets';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
G09

Asset Condition Score Buckets

Asset Condition Score bucket configuration defines various bucket ranges that are used to classify the condition score of a given asset.

This data is extracted into the Asset dimension (CD_UTIL_ASSET).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='W1-AssetConditionScoreBuckets';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
G10

Work Priority Buckets

Work Priority bucket configuration defines various bucket ranges that are used to classify the priority set for a work order.

This data is extracted into the Work Order dimension (CD_WO).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='W1-WorkPriorityBuckets';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
G11

Number of Cycles Overdue Buckets

Number of Cycles Overdue bucket configuration defines various bucket ranges that are used to classify how long a work order activity has been overdue in the system.

This bucket configuration data is extracted into the Number of Cycles Overdue Dimension (CD_NUM_CYC_OD).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='W1-NumberOfCyclesOverdueBucket';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
G12

MTBF/MTTR Buckets

MTBF/MTTR bucket configuration defines various bucket ranges that are used to determine the Mean Time Between Failure (MTBF) or Mean Time To Repair (MTTR) ratings of a given asset.

This data is replicated into the data warehouse and is referenced in the Asset and Location Snapshot facts (CF_ASSET_SNAP & CF_LOCATION_SNAP) to determine the MTBF rating, MTTR rating, and the count of failures for each of these buckets. If these buckets are not configured properly then these two facts will be impacted.

Make sure that these buckets is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='W1-MTBFMTTRBuckets';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
G13

Asset Age Buckets (Operational Device)

Asset Age bucket configuration defines various bucket ranges that are used to classify how long an operational asset has been in the system.

This bucket configuration data is extracted into the Asset Age Bucket Dimension (CD_ASSET_AGE).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='W1-AssetAgeBktConfig';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
G14

Asset Installation Age Buckets (Operational Device)

Asset Installation Age bucket configuration defines various bucket ranges that are used to classify how long an operational asset has been installed on the field.

This bucket configuration data is extracted into the Asset Installation Age Bucket Dimension (CD_ASSET_INSTALL_AGE).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='W1-AssetInstallAgeBktConfig';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.
G15

Asset In Storage Age Buckets (Operational Device)

Asset Installation Age bucket configuration defines various bucket ranges that are used to classify how long an operational asset has been in store.

This bucket configuration data is extracted into the Asset Instore Age Bucket Dimension (CD_ASSET_INSTORE_AGE).

Make sure that this bucket is configured properly as mentioned in validation steps.

Run the following query in the source database application schema and validate the following:

Select c.bkt_config_cd,val.bkt_start_range,val.bkt_end_range from f1_bkt_config c, f1_bkt_config_val val Where c.bkt_config_cd=val.bkt_config_cd and c.bus_obj_cd='W1-AssetInstoreAgeBktConfig';
  1. One bucket should have the start range as 0.
  2. One bucket should have the end range as 99999.
  3. No gaps or overlaps are allowed within the bucket ranges.

This concludes the validation of pre-source configuration checks. The next step is to configure the source with the Oracle Utilities Analytics Warehouse.