Application Environments
Each cloud service by default comes with three environments designated as Development, Pre-Production (formally called Test), and Production. Pre-Production and Production are sized as full-sized environments based on the billable metric of the subscription, while Development is a smaller environment.
Customers can request additional non-production environments through the initial sales order or in a subsequent order for an additional subscription. When asking for more environments, the names of the base and additional environment are predefined and cannot be changed.
Available additional non-production environment types include:
Additional Pre-Production Non-Production Environment
Designed for: production volume activities such as pre-production staging, parallel testing and performance testing (including regular performance regression testing)
Size: production size in terms of database storage as well as batch and online capacity
Additional Functional Test Non-Production Environment
Designed for: functional (including regular functional regression), system, integration, and user acceptance testing activities
Size: production sized in terms of database storage, and one-third (1/3rd) of the production batch and online capacity (or a minimum Development environment capacity, whichever is larger)
Additional Training Non-Production Environment
Designed for: end-user training and product familiarization type activities
Size: development sized in terms of database storage and batch capacity, but with additional online capacity to support up to thirty (30) concurrent online users
Additional Development Non-Production Environment
Designed for: development and unit testing activities only
Size: fixed, minimum development size
Environment Names and Codes
Cloud service environments have an environment code and name. The environment code is used to identify the environment and enable migration processes (such as configuration migrations) between the environments. The environment code is also used at installation/provisioning time. The table below lists all the possible environments that can be provisioned for each cloud service.
Environment Code
Name
Type
Default
Additional
DEV
Development
Development
Yes
No
TEST
Test
Pre-Production
Yes
No
PROD
Production
Production
Yes
No
DEV01..DEV20
Development 1 .. 20
Development or Training
No
Yes
TEST01..TEST20
Test 1 .. 20
Pre-Production or Functional Test
No
Yes
Environment Type Use Cases
Cloud service environments have been designed and sized for specific use cases during the implementation and live operation phases. Usage and processing limits are specified in the relevant contract documents (including Service Descriptions), and additional, environment specific, sizing information may additionally be provided via operational notifications.
Production Environment
The Production environment is designed for daily commercial use and production operations of live data during the live operation phase (that is, after go-live). During the implementation phase, the Production environment is intended to be used by customers and implementers for all data conversion and data migration related activities. This allows Pre-Production and Functional Test environments to be reserved for performance and functional testing of your configuration (respectively).
Pre-Production and Functional Test Environments
Both Pre-Production and Functional Test environments are designed for non-production use only, and both allow for a full Production database copy to be loaded.
Pre-Production environments are designed for:
Performance testing, regular performance regression testing and parallel testing of configuration during the initial implementation phase, and of configuration updates released by customers/implementers during live operations
Performance regression testing of cloud services after patching or updates
Pre-production staging activities for large migration data sets added during live operations
Functional Test environments are designed for
Functional, system integration, and user acceptance of configuration during the initial implementation phase, and for configuration updates released by customers/implementers during live operations.
Functional regression testing of cloud services after patching or updates.
Troubleshooting of production issues where production data and production data volumes may be required.
Oracle recommends limiting the number of Pre-Production environments to one due to the higher associated subscription costs. General observation of the existing customer base suggests that the Pre-Production environment included with your base subscription is sufficient for most implementation and live operation scenarios, however additional Pre-Production environments are available for subscription should they be required.
Training and Development Environments
Development environments are small, fixed size environments designed for non-production use only, and are designed for the configuration of cloud service features and unit testing. The Development environment type supports a up to ten (10) concurrent online users.
Training environments are the same size as Development environments, except that they are designed to support up to thirty (30) concurrent online users, which is a common scenario during end-user training or product familiarization sessions.
Additional Environment Resources
Additional data storage and processing resources may be subscribed to separately. These additional resources provide additional processing and/or storage capacity for a specific environment over and above that which is provided as part of the base cloud service. The additional resources that are available for subscription are as follows:
Additional Batch Threads
Additional Concurrent Online Users
Additional Data Storage
Additional Integration Requests per Minute
Each cloud service is benchmarked to confirm scalability, and is sized according to a reasonable set of assumptions based on customer base observations, however some implementations may require additional processing resources (additional batch threads, concurrent online users or integration requests per minute) and/or additional storage. Common reasons for requiring additional resources include (but are not limited to):
High volume, high frequency interval read data (specifically, less than 15 minute interval data such as 5 minute interval data)
Example: 5 minute interval data involves 3x the data volumes of 15 minute interval data, which means a significant increase to batch processing and storage capacity requirements.
Effective critical batch window durations of less than 6 hours
Highly complex configuration, custom integration and/or batch logic
Inefficient batch process scheduling
Inefficient configuration, customer integration and/or batch logic which has not been sufficiently performance tested, optimized, and tuned during the implementation phase prior to go-live
Not properly implementing the recommended Information Lifecycle Management (ILM) business rules
Failure to ensure that ILM processing occurs regularly and that unnecessary database partitions are regularly dropped
Storing high volumes of custom information/data (for example via the Java Migration Cloud Service)
Transitioning to live operations with large numbers of uncorrected data migration validation errors, and/or data that has not been properly sanitized
Not implementing Information Lifecycle Management protocol
Application / Environment Access and URL Tokens
When environment provisioning is complete, customers / implementers will receive a list of links to the various product environments included with their subscription. There are cases in which cloud service applications need to access other cloud service or on-premises applications or other environments, such as:
Data/Configuration Migration
Data Conversion
Redirecting a user to another application as part of a business process transaction that is integrated across products
Invoking web services of a different application (another cloud service or SOA for existing SOA-supported cloud integrations)
Invoking a web service of the same application in a different environment. This type of communication is used to help automate inter-environment processes like configuration migrations. See the Code and Configuration Migration section in Chapter 7: Operational Guidelines for more information.
The following URL Tokens are available for direct navigation or web service calls for each cloud service.
Token
Description
EXT_PUB
Prefix token that should be used to reference external addresses in Message Senders.
 
For example, to reference paymentcorp.payusa.com endpoint URL you would need to use the following notation: @EXT_PUB@paymentcorp.payusa.com.
 
Note: The target URL must be on the allowlist.
CCS_WS
CCS_ONLINE
Customer Cloud Service address for web service calls.
Customer Cloud Service address for online access.
MSCS_WS
MSCS_ONLINE
Meter Solution Cloud Service address for web service calls.
Meter Solution Cloud Service address for online access.
WACS_WS
WACS_ONLINE
Work and Asset Cloud Service address for web service calls.
Work and Asset Cloud Service address for online access.
AICS_ONLINE
Analytics Insights Cloud Service (aka DataRaker) address for online access.
INT_WS
Invoke SOA web services (for integration via SOA)
BI_PUBLISHER_ADMIN
Analytics Publisher address for web services calls.
BI_PUBLISHER_ADMIN_INT
Used with Reporting Options with Analytics Publisher as "Reporting Server From App Server" for Batch reporting.
BIP_DEF_DIR
Used as soft parameter value ("Output Directory") to Analytics Publisher extract algorithm type.
BIP_DEF_PATH
Used as soft parameter value ("Report Absoluted Path") to Analytics Publisher extract algorithm type.
CI_BILL_URL
Used as a substitution variable to allow access to a bill from an external source based on the request URL.
CI_LETTER_URL
Used as a substitution variable to allow access to a Letter from an external source based on the request URL.
DEV_WS, DEV01_WS-DEV10_WS
TEST_WS, TEST01_WS-TEST10_WS
PROD_WS
Web service addresses for all possible environments.
For example, DEV_WS can point to Customer Cloud Service in the DEV domain while PROD_WS will point to the same application but in the PROD domain.
Usage Examples:
The outbound message sender on the Customer Cloud Service configured for invoking a Meter Solution Cloud Service Inbound Web Service service named "ABC" (in production) will be have the URL definition of @MSCS_WS@abc.
The value of @MSCS_WS@ will be different in each environment so that the same token can be used in all environments, and the runtime value translation will be based on the environment invoking the call.
Internal-facing tokens such as DEV_WS can be used for inter-domain communications, such as the automation of configuration migration between product domains. These tokens are used by the Process Automation Tool within Cloud Service Foundation.
External facing addresses will use the @EXT_PUB@ prefix, for example: @EXT_PUB@paymentcorp.payusa.com/api/int01/addPayment
The port is not required in the URL definition when using EXT_PUB as all outbound calls from cloud services are sent via Https and port 443 is implied.
The CI_BILL_URL and CI_LETTER_URL substitution variables can be used with base online bill and letter display algorithm parameters, but this requires a Service Request from the customer to set these parameters to the external system.