Oracle Database Cloud Service - Schema (a.k.a Database Schema Service) is an Oracle Platform Cloud Service offering that provides a single Oracle Database schema which is fully managed by Oracle. It also includes Oracle Application Express (APEX), which is a rapid browser-based database application development system.
In addition to allowing you to rapidly build database-based applications, the other purpose of Oracle Database Cloud Service -Schema (referred henceforth simply as DbCS) is its ability to work in conjunction with Oracle Java Cloud Service (SaaS Extension offering) as the primary database.
If you have a JCS-SX instance you will be automatically provided with an instance of DbCS instance. When building applications using JCS-SX, new data created will be hosted in the associated DbCS instance.
APEX is the primary mechanism to interact with data and data models within DbCS. The APEX console provides comprehensive access to the database schema, including SQL worksheets, the ability to work with PL-SQL objects, and the ability to perform data modeling. Due to the security model of this cloud offering, DbCS does not provide a JDBC interface for external applications and tools (such as SQL developer) to work directly with data in DbCS. However, there are multiple options available bringing data into and outside of DbCS. This blog discusses these options in the context of loading data and also compares different options.
Note: If you require a full-fledged Oracle Database with multiple schemas and JDBC access, explore other Oracle Database Cloud offerings at https://cloud.oracle.com.
DbCS provides at least 4 different ways to load data.
Each option has its own advantages and may be better suited for a certain usage scenario compared to another. The options are described below along with recommended usage scenarios.
APEX Console provides a simple browser-based interface to import data. You can access the import utility by navigating to SQL Workshop > Utilities within APEX Console. The file to be imported can be in text (any delimiter), CSV or XML format. You will be able to browse, select the file and upload it. Alternatively, you can simply copy-paste data. During upload, you will be taken through a wizard, which allows you to specify the tables, delimiters, column mapping, and other metadata such as currency symbols, number group separators and decimal separators. Refer Oracle documentation for more details on this option.
When to use this option?
This option is well suited for scenarios where data is imported in a less-frequent fashion and where it is reasonable to expect that a user will perform this activity manually. For example loading weekly or monthly sales summary data to display in dashboard built on JCS-SX. Since data is imported directly using a browser, a non-DBA user can also perform this activity. However, since the browser is involved during the import, it is also suggested that this option be used for loading lower volumes of data for better performance and better usability. It is important to note that when using this option, data from a file is imported directly into database objects without validation. Similarly, there is no ability to load data from one file into multiple database objects. This makes this option suited for scenarios where data it can be assumed that the data to be imported is prepared and validated prior to making it available as a file.
Database Cart is a feature within Oracle SQL Developer (and Oracle JDeveloper) that allow you to move data from any database into DbCS. Using the cart, you have the ability to specify one or more database objects that you want to move from a database to DbCS. You have fine-grained control over the data that you select to move. Once data is selected, it is compressed and sent to DbCS directly using SFTP. All actions are performed from within SQL Developer. The exact data Steps to use database cart are available here within Oracle documentation.
When to use this option?
Similar to the APEX console option, this option can also be termed manual, since a DBA or Developer is expected to perform this activity manually. Hence this option is also suited where data loading frequency is lesser. Since SQL Developer is required, this option is targeted more towards a DBA or Developer. Using Data cart provides better control over the data being imported. For example, a subset of rows can be selected and data pertaining to multiple tables can be moved in one go. This option is best suited for loading large amounts of data. Since data to be moved is compressed and sent to DbCS via SFTP, best performance achieved compared to other options. Similar to using APEX console, Database Cart option does not provide the ability to validate data as it gets imported into DbCS (beyond database level validations such as primary key and referential integrity). Hence it is to be assumed that the data is validated and enriched in SQL Developer prior to loading to DbCS
DbCS allows external applications to interact with database objects using inbound REST Services. REST services are not automatically created for all database objects. Instead, you can rapidly define these services using the APEX console. External applications can use REST services to perform GET, POST, PUT, or DELETE operations on database objects, which in turn translate to the execution of SQL commands or anonymous PL/SQL blocks. REST services are made available as https://<dbcs_instance_URL>/apex/<service_module_URI_prefix>/<resource_URI_template>
REST services definition screens can be accessed using the APEX console, by navigating to SQL Workshop > RESTful Services. You will also find a sample called oracle.example.hr. A REST service can be created for a database object or the service can provide a more granular interface that encompasses multiple database objects. Data can be made available in XML or REST format. REST services can also expose PL/SQL functions and can expose parameters that easily get translated as bind variables. Additionally, you can secure these REST services using OAuth. Refer to Oracle documentation for more information on this option.
When to use this option?
Since data is exposed as REST services, this option is well suited for two types of scenarios – Integration and Mobile.
REST services exposed by DbCS can be invoked by an integration infrastructure for posting data into DbCS. Since REST APIs can handle only one record at a time it is not suited for large volumes. However, since manual intervention is not required, low to medium volume data can be imported over a period of time.
Mobile applications can also consume OAuth-protected REST services to post data into DbCS. Although more suited for Mobile applications, REST services can be used by any other application in your enterprise to insert data into DbCS.
Since REST services can be based on PL/SQL packages, data can be validated during insert and data can also be inserted into multiple tables if desired. This makes it suitable for scenarios where data is not guaranteed to be validated. Additionally, since a coarse-grained REST service can operate on multiple database objects, the need to load data into multiple tables can be largely simplified. For example, a customer’s basic information along with his/her address can be imported using the same REST API although they may be eventually inserted into multiple database tables.
You can configure DbCS to invoke SOAP and REST services in an outbound fashion, which can be used to bring in data. For example, you can invoke a SOAP service, obtain the response and insert into one or more tables. Unlike REST services, there is no console-based mechanism to configure these outbound invocations. Instead, DbCS provides APIs that you can use along with PL/SQL to programmatically invoke SOAP and REST services. These APIs are available as a PL/SQL package called APEX_WEB_SERVICE. For example, you can use the MAKE_REQUEST API to invoke a SOAP service. The SOAP input payload will be provided as CLOB and the response can be obtained as an APEX Collection (a specialized APEX type) or XMLTYPE. Similarly, REST services can be accessed through the MAKE_REST_REQUEST API.
Since you have access to PL/SQL APIs, you can use the power of PL/SQL to enhance the data import functionality such as including data validations during import and using PL/SQL scheduler feature. Combined with PL/SQL scheduler you can poll for data using SOAP and REST services in pre-determined intervals. The scheduler is available through the DBMS_SCHEDULER package and is well documented in Oracle documentation.
When to use this option?
This option is well suited for scenarios where an application running on your JCS-SX (associated with your DbCS instance) requires to poll external data frequently. Similar to the console option and data cart option, the DbCS instance administrator has control over when data can be imported. Since these APIs are used within the context of PL/SQL, similar to the REST option, you have advanced control over the import process.
Since there is XML marshalling and unmarshalling involved, performance can become a concern when dealing with large volumes. In such scenarios, consider using webservices that return a collection of data rather than invoking MAKE_REQUEST individually for each record. If web services return data as a collection, you can use the power of PL/SQL to process the collection response data. For large data sets, consider processing the returned data in chunks.
The table below provides a quick comparison of the usage scenarios described earlier for data import option
|Using DbCS Console||Using Database Cart||Using Inbound REST services||Using outbound SOAP and REST invocation APIs|
|Load Volume||Low||High||Low to Medium||Medium (chunking recommended)|
|Skill required to implement||Basic Database knowledge||Developer or DBA skills||REST and PL/SQL||PL/SQL|
|Validation during loading||Database level integrity||Database level integrity||PL/SQL level and Database level||PL/SQL level and Database level|
|Importing multiple objects in a single run||No||Yes||Yes||Yes|