• Limited Database Object Type Support: At the present time only the following object types are supported:

• Tables

• Columns

• Constraints

• Indexes

• Limited Data Type Support: The Oracle Utilities Application Framework uses a subset of the database types available for columns and therefore only this subset is supported. This includes the following data types:

• CHAR

• CLOB

• DATE (includes Data and time)

• NUMBER

• VARCHAR2

• XMLTYPE (Selected releases only)

• Naming Conventions are Strictly Enforced: The Oracle Utilities Application Framework uses a set of database naming conventions for tables and columns that are enforced. Refer to the Oracle Utilities SDK for details. This is enforced to minimize impacts of patches and upgrades on Oracle Utilities cloud services.

• Limited Scope for Change: In line with Oracle policy, the relative amount of change on the custom content is limited and is checked as part of compliance. It is expected that further extensions will be implemented using cloud facilities to retain the cost benefits of the service.

• No Partitioning Support: The custom tables cannot be partitioned as of 23A release.

• No ILM Support: Custom tables cannot implement Information Lifecycle Management (ILM) in the current release. This is in line with current on-premises directions. Managing of the lifecycle of the data in these custom tables is not a responsibility of the service.

• Custom CMA Content Required: Content Migration Assistant is used to migrate data on the cloud. Implementations must create custom Migration Plans and Migration Requests to include any custom tables in migrations or test data management.

• Table Definition Required: Each table must be defined as a table object within the Oracle Utilities Application Framework to ensure the cloud service is aware of the presence of the table. This definition must include all columns, constraints, and indexes to ensure compliance. Any conflicts with base tables must result in changes to custom tables.

• No Definition Autoload: In the present release, there is no autoload capability to transfer the format of the custom tables to the table definition. They must be entered manually using the provided Table maintenance capability.

• Data Loading Support: After definition the data can be loaded using the cloud standard data loader process. Refer to the XXXXX for more information.

• Minimal Configuration: For a custom table to be accepted by the system it must satisfy the following for definitions:

• The System Table flag must not be set. This is reserved for tables supplied by Oracle only.

• A primary key for the table must be defined.

• The primary key index must be defined to the table.

• The VERSION field must exist in the table.

• Tablespace Automatically Allocated: The tablespace and storage allocations are created automatically as part of the deployment. There is no configuration necessary.

• Automatically Connected: The table is available automatically to the product, SQL Developer/Oracle Database Actions and Analytics Publisher as part of the deployment. This includes providing automatic Oracle REST Data Service integration.

• Isolation from Product: The table is installed in its own isolated schema to prevent schema leakage into the main service schema.

• Data Loading: The data is loaded using the Cloud endorsed method used for other tables. Refer to the Cloud implementation guides for additional information.

• Table Maintenance: The tables and related objects are defined to the service via the Table Maintenance function. Each table to be implemented will be defined to the Oracle Utilities Application Framework to ensure correct definition and management by the service. Any maintenance of the definition is performed using this capability. It is recommended that only a subset of approved users perform this action to provide sufficient control. By default, the definition should be set to Pending state when being created. Once the definition is complete, each table entry should be manually transitioned in Ready To Generate status, to progress to the next step.

• Generation: The table definition can be generated and deployed using the K1-GENTB batch process, which will implement any table definition in Ready to Generate status. Once deployed to the database the batch process automatically enables access to the service components. Once this is performed the table definition is transitioned to Generated state. Any maintenance changes should be performed after manual transitioning the table object back to the Pending state to repeat the process for changes.

• Follow Naming Conventions: Follow the table naming conventions for tables, columns, constraints, and indexes as outlined in the Oracle Utilities SDK. These are assessed to ensure no conflicts with base objects.

• Column Naming: As per the Oracle Utilities SDK, the column names should conform with standards and any shared columns names with base should adhere to standards. Avoid creating new field definitions if there are field definitions that can be reused to minimize impacts of change.

• Remove Storage and Technical Details: The table maintenance will automatically allocate storage and other attributes of the table outside the definition.

• Enter Table Definition Appropriate for Custom Tables. Define the table object using the following guidelines:

• Define Columns: Define the columns in the table. Ensure each column is defined as a Field with appropriate formats etc. to add to the table definition. Reuse base field definitions as appropriately. If fields conflict with base fields, then you must alter your custom table to mitigate conflict.

• Define Constraints: Define all the key constraints including primary key and foreign keys. Conditional foreign keys are only checked if values are present. Once this is specified and saved, the Relationship tab will be populated.

• Define Indexes: Define all required indexes for the table including any primary key indexes.