Documente Academic
Documente Profesional
Documente Cultură
January 2017
Contents
Contents
Overview ...................................................................................................................... 3
3
About the Environment Refresh Service
Request an environment refresh using either the online self-service scheduling feature or the Service
Request (SR) user interface in My Oracle Support (MOS). If you need to request a coordinated Fusion-
Taleo refresh, or require data masking as part of your refresh request, log a Service Request (SR)
because the self-service scheduling feature does not currently support these types of requests.
Submit your SR 3-12 weeks before the date you need changes applied.
When to Submit SR Submitting an SR before or after this submittal window will result in your
environment refresh request being canceled and rescheduled.
Be sure you understand limitations with using masked data before you request the data masking
service. Do not request the data masking service if:
You have not paid for a data masking subscription via an order managed by your Oracle
Account Team.
You want to replicate the same results as when using real, unmasked data.
Your test purpose is to verify interfaces to downstream systems that require real data that is not
modified.
4
Cloud Service Type ERP, HCM, and OSC
Fulfillment Method Scenario 1: You want the environment refresh and data masking
service to occur as a combined activity. In this scenario, complete a
single SR for both. Data migrated to a test environment using an
environment refresh is masked as part of the environment refresh
fulfillment process.
Scenario 2: You need to add or change data after it is migrated using
an environment refresh, but before data masking is applied. With this
scenario, you must submit two SRs: one to request the environment
refresh service and one to request the data masking standalone
service. If you need only data masking without an environment refresh,
refer to Oracle Applications Cloud - Data Masking Standalone Service
Entitlement on My Oracle Support (Doc ID 2092389.1).
Submit your SR 3-12 weeks before the date you need your environment
When to Submit SR refresh. Submitting an SR before or after this submittal window will result in
your environment refresh request being canceled and rescheduled.
For more information about data masking, refer to Oracle Applications Cloud - Data Masking
Standalone Service Entitlement on My Oracle Support (Doc ID 2092389.1).
Fulfillment Considerations
Plan Ahead
You must submit your request at least three weeks before you want the refresh to occur. The
Refresh request must occur outside of blackout periods. Blackout periods are the time during
which Oracle cannot provide the environment refresh. See the following calendar examples for
more information about blackout periods.
If you request a refresh with less than three weeks’ advance notice or during a blackout period, it
will be rejected. We recommend allowing a minimum of six week’s notice for an upgrade-related
refresh to accommodate for blackout periods and provide adequate time between the refresh
and the upgrade.
Your request will take 3-4 business days for review, initial approval, and scheduling.
Environment refresh scheduling is done on a first-come, first-served basis.
If you use the delivered integration between Oracle Fusion HCM and Taleo Recruiting Cloud
services, there is a minimum six-week advance notice for requesting a coordinated Taleo-Fusion
refresh service.
Review the Schedule Maintenance calendar in My Services
The Schedule Maintenance calendar shows the dates an environment refresh can occur.
Choose an available date for your environment refresh
5
An environment refresh cannot be scheduled on the weekends when updates occur.
You cannot schedule a refresh on any date when the source and target environments are at
different update levels. This can occur as a result of our policy to update nonproduction and
production environments two weeks apart from each other.
If the source and target environments for your refresh are on different update cadences (for
example if one is updated on the production cadence and the other on the nonproduction
cadence), blackout periods will periodically limit when your refresh can be fulfilled as described
below:
For P2T refreshes, a quarterly blackout period exists between the Thursday before the 1st
Friday of February, May, August, and November (and any month that you opt-in for a
Monthly Update) through the Sunday 18 days later. (For the Middle East, the blackout
period begins on the Wednesday before the 1st Friday of the update month.)
For T2T, the blackout period starts on the Thursday before the 1st Friday of February,
May, August, and November (and any month that you opt-in for a Monthly Update) and
ends on the Sunday after the 1st Friday of the update month. (For the Middle East, the
blackout period begins on the Wednesday before the 1st Friday of the update month.)
If the source and target environments for your refresh are on the same update cadence (for
example, both are updated on the nonproduction cadence), blackout periods are limited to only
the Thursday (or Wednesday if in the Middle East) through Sunday during which either
production or nonproduction environments are being updated.
If we no longer provide quarterly updates for a release that is near its end, there is no blackout
period. You will receive a notification when quarterly updates are no longer provided.
Additional Considerations
Concurrent Maintenance
P2T when production is on nonproduction update cadence, there is no blackout
period, since both environments are updated at the same time.
P2T when nonproduction is on production update cadence, there is no blackout
period, since both environments are updated at the same time.
T2T when nonproduction environments are on different update cadences. For
example, nonproduction 1 is on nonproduction cadence, and nonproduction 2 is on
production cadence.
The normal blackout period is between the Thursday before the first Friday
of the month and the Sunday after the third Friday of the month does apply.
In the Middle East, the T2T blackout period starts on the Wednesday before
the first Friday of the month and ends on the Sunday after the first Friday of
the month.
For more information about concurrent maintenance, refer to Oracle Fusion Applications
Cloud Concurrent Maintenance Option on My Oracle Support (Doc ID 1646394.1).
No Updates on Current Release: If we are no longer providing updates for your release,
there is no blackout period.
Release Upgrade: Environment refresh is not available between different release
versions.
Examples: The following examples show regular environment refresh blackout periods in two
6
consecutive months. This calendar does not apply to any of the additional considerations
previously mentioned:
February
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5
Blackout Blackout Blackout Blackout
Period Period Period Period
13 14 15 16 17 18 19
Blackout Blackout Blackout Blackout Blackout Blackout Blackout
Period Period Period Period Period Period Period
20 21 22 23 24 25 26
Blackout
Period
27 28 29 30
March
Sun Mon Tue Wed Thu Fri Sat
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
The sample February calendar shows the blackout period for a Quarterly Update. The
sample calendar for March reflects no blackout period for a customer receiving only
Quarterly Updates, but no optional Monthly Updates.
For more information, review the following My Oracle Support articles: Oracle Applications
Cloud – Fusion Applications Update Policy (Doc ID 1966109.1) and Oracle Applications
Cloud - Concurrent Maintenance (Doc ID 1646394.1).
7
Match Update Levels Between Source and Target Environments: The environment refresh
service entitlement requires that the source and target environments:
o are at the same release level
o have the same updates applied
o contain the same Language Packs
If you subscribed to the Database Vault and Transparent Data Encryption (TDE) services, they
must be present and at the same update level in both environments; if not, the environment
refresh will be canceled. The same applies if you subscribe to the Oracle Database Vault and
Break Glass for Fusion Cloud Service.
Even if your request is initially accepted, if the environments are not at the same update level
before the scheduled environment refresh, your request will be canceled.
If your environments are not at the same level, you must reschedule the refresh for when your
environments are at the same update level. This will cause the standard three-week lead time to
restart, and you must log a new SR.
Understand Additional Updates May Impact the Timing of Your Environment Refresh:
Environment refresh is not available if you requested an additional update on any one of your
environments. Oracle Support will explain the type of update you’ll receive and the timing for
applying it. If you are approved to receive additional updates, applying them will put your
environments out of sync and result in cancellation of the previously scheduled environment
refresh. This means your environment refresh request cannot be fulfilled until both environments
are again at the same update level after the blackout period.
Obtain Required Preapproval: Submitting an environment refresh SR does not guarantee that
the request can be fulfilled on the date requested. Comparison of update levels for source and
target environments, as well as advance notice requirements, play a significant role in
determining whether the request can be fulfilled. Your request will be evaluated considering
these factors and you’ll see the acceptance or rejection of your request within your SR.
8
Are you on a release that is no longer updated and near the end of an upgrade
window? If the answer is yes, normal environment refresh blackout periods do not apply.
Since previous release environments will not be updated during this time frame, they will
remain in sync and can be refreshed outside of the blackout period. However, any additional
updates approved and applied will still put your environment refresh requests at risk.
Do you use data integrations, such as HCM Cloud Service data loading tool, to move
data between your Oracle Applications Cloud environment and your system of
record? If so, carefully coordinate the Oracle Applications Cloud environment refresh with
the other system’s content migration capability, such as for cloning or other refresh. If you do
not synch these processes, data integrity issues may surface in the target environment. To
avoid this:
o Pair your integrated production environments together and your integrated
nonproduction environments together. Establish this pairing early in your
implementation and do not change it, if possible.
o Do NOT run any integration processes between the two systems, once the first
content migration process has started, until the other system’s similar process has
completed.
o Schedule your refresh to coincide with the other system’s content migration solution.
The closer in time they complete, the sooner you can process integrations between
the paired environments.
o Review and change any setup or configuration in the target nonproduction
environment that points to a production environment. Instead, point to the other
paired nonproduction environment.
o After both processes have completed, resume your integration processes.
The online self service scheduling feature is available for the environment refresh process. Follow these
steps:
1. Sign in to My Services for the environment from which data will be refreshed. This is referred to as
the source environment.
2. Select Schedule Maintenance.
3. Follow the online instructions.
4. If you need further assistance, click Help about this page.
Once your request is submitted, a SR is created with Support. Work with Support using the SR as a
reference. You can track the status of the environment refresh approval through My Services.
Note: The self-service environment refresh feature in My Services simplifies the scheduling effort by
presenting you with a calendar that displays capacity for dates on which you can schedule both P2Ts
and T2Ts. If any of the considerations listed below prevent you from scheduling your environment
refresh via this self-service feature, you can always request it using the SR process
9
The Service Administrator who submits the environment refresh request must have a MOS
account for the Customer Support Identifier (CSI) assigned to the customer. If they do not,
another Service Administrator should enter the request.
The self-service feature does not currently support the data masking option or the version of
an environment refresh which coordinates with Taleo Recruiting.
After submitting a self-service environment refresh request, you cannot change or delete it via
MyServices. Instead, you must update the SR previously generated in MOS.
The link displayed in MyServices for the environment refresh SR created by this process will
direct you to the standard MOS SR viewer. From the SR page you can click Switch to Cloud
Support in the upper right hand corner, if you prefer that view. Note that this is a temporary
restriction.
SRs generated by the self-service environment refresh process will appear in My Company's
Service Requests instead of My Service Requests. To view your environment refresh SR,
search for it under My Company's Service Requests. Note that this is a temporary restriction.
When filing your request, you will be prompted to answer the following questions that are specific
to this Cloud service:
Section Enter
Desired Refresh Start Date The date you’d like to have content refreshed to the
target/nonproduction environment. The target
environment will be down for up to 48 hours (without data
masking) or up to 72 hours (with data masking).
10
Section Enter
Additional Information Any additional information that will help clarify the timing
and special considerations for this request.
Is this Refresh Release Upgrade related? If so, provide the environment names and Oracle-
proposed upgrade dates for your nonproduction and
production environments. Your response to this question
is for additional information only. The upgrade scheduling
process is handled separately and must be handled by
filing separate SRs. You should carefully plan and
schedule these activities.
Note: If you have not heard from Oracle on the upgrade
dates, then do not file this as a Release Upgrade-related
refresh.
Note: You must submit a new SR if you make any change to the source, target, or environment
refresh desired date, as the request fulfillment process is based exclusively on these
parameters. This will cause the 3 week lead time to restart.
11
Frequently Asked Questions
How much time is needed to cancel the environment refresh?
At least 7 days’ advance notice is required to cancel an environment refresh.
How much advance notice do I need to give Oracle to schedule the environment refresh?
A minimum of 21 days advance notice is required. You can schedule the environment refresh up
to 12 weeks in advance.
How long does an environment refresh take?
The target environment will be down for up to 48 hours (without data masking) or up to 72 hours
(with data masking).
When is the blackout period?
For Quarterly Updates, the blackout period starts on the 1st Thursday of the February, May,
August, and November, and ends on the Sunday following the 3rd Friday of the month.
However, if the 1st of the month falls on a Friday, the environment refresh can’t be scheduled on
the Thursday before the 1st Friday of the month.
Can an environment refresh be completed during a blackout period?
No, unless you are on concurrent maintenance or requesting a T2T. If this is the case, it can be
scheduled any time except on the weekends when updates occur.
How do I schedule an environment refresh?
You can request environment refreshes using the online self-service scheduling feature. If you
need to request a coordinated Fusion-Taleo refresh, or require data masking as part of your
refresh request, log an SR.
Will e-mail notifications be disabled in the target environment?
For P2T environment refresh, the e-mail notifications will be disabled on the target environment.
The source environment e-mail notifications will remain unchanged. If you need the target
environment's e-mail notifications to be turned on, please create a new SR requesting this.
What happens to the user security setup during environment refresh?
Environment refresh migrates your user security setup from the source environment to the target
environment. If you’ve enabled Single Sign-on on the source environment but not on the target
environment, your users won’t be able to logon to the target because passwords won’t be
available. You need to open a service request (SR) to reset the password for the administrator,
who can then reset the password for all other users after the environment refresh completes.
12
Oracle Applications Cloud - Data Masking Standalone Service Entitlement, Doc ID 2092389.1
Oracle Applications Cloud – Additional Test Environment with Refresh, Doc ID 2173513.1
13
Appendix A: What Is Copied During Environment Refresh
The most important thing to understand is that almost all data is refreshed, but compiled binary objects
are not. There are some exceptions to this general rule and some possible implications for you.
What is copied?
All data in the Fusion schema, such as all transactional data and functional setup.
Webcenter content, such as file attachments and inbound and outbound integration files.
Key artifacts managed through Fusion Middleware Metadata Services (MDS), such as user
interface extensions managed as Application Development Framework (ADF) sandboxes, such
as flexfields and workflow/approval extensions managed by the Service-Oriented Architecture
(SOA) Suite.
Business Intelligence Web Catalog and Repository Definitions (RPDs).
Pre-compiled Fast Formula used by the HCM Cloud Service.
Special cases
You may need to take steps before or after an environment refresh as a result of what is and what is not
copied.
User interface extensions Copied To retain in-process UI extensions, export them from the
maintained in ADF sandboxes target environment before environment refresh and
import them back after. See Oracle Applications Cloud
Extensibility Guide for Functional Administrators.
Functional setup, including Copied To retain some functional setup in the target, export it
HCM Fast Formula from the target environment before the environment
refresh and import it back after, using FSM’s
Configuration Package capability. See Oracle
Applications Cloud Using Functional Setup Manager
Business Intelligence Copied To retain custom BI objects, export them from the target
definitions environment before the environment refresh and import
them back after, using the BI archive/unarchive facility.
14
Application Object Copied or Not? Possible Action
HCM Extract definitions Copied To retain custom HCM Extract definitions, export them
from the target environment before the environment
refresh and import them back after, using the
export/import function on the Manage HCM Extracts
Definition user interface.
ESS process parameters Not Copied After the environment refresh, review the process
parameters in the target for your key ESS processes.
Reestablish scheduling and reset those default
parameters (for example, the number of threads) you
want to change.
EssBase cubes Not Copied Create EssBase cubes in the target environment after
the environment refresh, by submitting standard jobs
through the Scheduler page.
For example, to create a Ledger EssBase cube:
15
Follow us at:
Copyright © 2016, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes
only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free,
nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied
warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability
with respect to this document, and no contractual obligations are formed either directly or indirectly by this document.
This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their
respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under
license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the
AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of
The Open Group. 0115