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 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.
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.