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