Application Environments
Each cloud service by default comes with three environments designated as Development, Test, and Production. Test 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.
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 migration related activities. This allows Test environments to be reserved for functional and performance testing of configuration.
Test Environments
Test environments are designed for non-production use only, and are designed for:
• Functional, system integration, user acceptance and performance testing of configuration during the initial implementation phase, and for configuration updates released by customers/implementers during live operations.
• Functional and performance regression testing of cloud services after patching or updates.
• Training environments where larger numbers of users (i.e. more than 10 users) are expected to be undergoing end-user training concurrently.
• Troubleshooting of production issues where production data and production data volumes may be required.
Full sized Test environments (including default and additional environments) are designed for functional, system integration, user acceptance and performance testing, whereas smaller sized Test environments (where available) are designed for functional or system integration testing only.
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.
Environment Sizing Process
The sizing process is designed to estimate the resources required to ensure reasonable performance for a given workload. Essentially, this sizing process attempts to understand what the final workload will look like, and to estimate the quantity and type of hardware that should be deployed to support it.
The sizing process can be broken down into three phases:
1. Initial Sizing, which aims to appropriately size the deployment for the initial implementation project. This phase assesses the following:
• The cloud services to be implemented
• High-level estimates of go-live subscription quantities (service dependant)
• Expected critical batch processing window
• Historical data conversion requirements
• Planned cut-over window
• Database storage estimates
2. Implementation Sizing, which aims to improve sizing accuracy as implementation specifics are understood (such as when the configuration is near final, and subscription quantities and expected go-live data volumes are known). Typically this is done as part of the preparation for the performance testing phase of the project, and assesses the following additional information:
• Specific batch processing schedules
• Number of users expected to log in concurrently
• External interface workload
• Data extract processes
• End to end processing windows
3. Go-Live Sizing, which aims to determine the final sizing and deployment requirements in preparation for go-live. In order for this final sizing phase to be as accurate as possible, it is expected that:
• Usage processing and billing complexity is fully understood
• Performance testing, tuning and optimization is complete
• Specific configuration details are available
• Final data volumes clearly understood
Each phase involves the compilation of an Oracle Utilities Cloud Services Sizing Workbook, which is used to:
• Capture customer/implementer answers to specific sizing-related questions and to document any assumptions that have been made regarding environment sizing. These constitute the inputs to the sizing process.
• Summarize the estimated performance metrics that can reasonably be expected for each environment based on the sizing inputs provided, including:
• Subscription metric counts
• Critical batch window duration
• Available batch threads
• The maximum number of users that can be concurrently logged into the application at any point in time
• The maximum supported number of integration (REST/SOAP) requests per minute (peak load)
• Database storage limits
Resizing
Re-assessment of sizing (and potential deployment resizing) may be required when the cloud service subscriptions themselves are changed (for example, subscription expansions), or when any of the sizing inputs change (for example, more users are accessing the system concurrently that was originally planned, or where configuration changes result in increased computational complexity).
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 (as accurately as possible) according to the environment sizing process defined above, and so it is typically not necessary to purchase additional resources unless performance is deemed to be insufficient. Common reasons for requiring additional resources include (but are not limited to):
• High volume, high frequency interval read data
• Effective critical batch window durations of less than 6 hours
• Highly complex or inefficient configuration, custom integration and/or batch logic
• Inefficient batch process scheduling
• Lack of performance testing and tuning during the implementation phase prior to go-live
• Storing high volumes of custom information/data, and/or storing data for longer-than-recommended time periods
• 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.