Customer Connect Announcements

Get Involved. Join the Conversation.

Announcement

    Lisa Ozkan
    Environment Refresh - Service Entitlement Definition
    Announcement posted October 20, 2015 by Lisa OzkanSilver Medal: 2,000+ Points, tagged Engagement Cloud, Financials, Global HR, GRC, HCM, Marketing, PPM, Procurement, SCM 
    1589 Views, 4 Comments
    Title:
    Environment Refresh - Service Entitlement Definition
    Announcement:

    A new service entitlement definition document has been released on Oct 9th, 2015, that describes the process for Environment Refresh (aka P2T/T2T) service requests.
    Where can I find out more?
    Please check Doc ID 2015788.1 for further details.

    Types of Environment Refresh:
    Environment Refresh is the service entitlement that you should request to migrate data from a source environment to a target environment. Currently there are two different types of environment refresh services available for our customers:

    1. Production-To-Test (P2T): From a production environment to a non-production environment
    2. Test-To-Test (T2T): From a non-production environment to another non-production environment, for those customers with multiple non-production environments.

    Environment Refresh Scheduling – Key Points To Consider:

    • 3-weeks advanced notice: Submit your Environment Refresh Service Request (SR) at least 3 weeks before the requested date.
    • Update levels: Source and target environments must be on the same update level for environment refresh to be performed (including language packs and TDE)
    • P2T blackout period: Stay away from blackout period for P2T requests! 2-week P2T blackout period exists every month between Stage (1st weekend) and Production (3rd weekend) monthly updates. See below calendar for September 2015 as an example.
    • Environment refresh and upgrades: P2T needs to be completed at least 72 hours prior to a scheduled release upgrade start date and time. Since P2T could take up to 48 hrs downtime, this means, the P2T should start 5 days (6 days if data masking is needed) prior to the start of your scheduled non-production environment upgrade. Furthermore avoiding the P2T blackout period is still needed.
    • Exception updates: When a customer requests and gets approved for an exception update due to business critical issue without a workaround, their previously scheduled P2T request may be cancelled. Because exception updates put the source and target environments at different update levels; and P2T cannot be executed till both environments are at same update level again. Please be aware of potential impact to your P2T requests before you request an exception update.
    • Concurrent updates: This option is available for implementing customers that are not live, and allows customers to have their non-production and production environments to be updated on the same schedule during their implementation. Since non-production and production environments are updated at the same time when customer requests Concurrent Update option, P2T blackout period is not applicable. In other words, these customers can request their P2T to be scheduled anytime during the month.

    Test-To-Production (T2P) Manual Data Migration:

    • Environment refreshes don’t support migrating data from a nonproduction environment to a production environment (Test-To-Production).
    • T2P is not a tool or cloud service that can be requested to happen automatically with an Environment Refresh SR.  Rather, it is a series of steps to manually migrate selected content from your test environment to another environment, such as production. Customer or SI will need to perform these steps as part of the implementation.
    • In order to manually migrate setup and other configurations from Test to Production, you can use tools such as Functional Setup Manager, File Based Loader.
    • See Note 1308404.1 for more information on FSM Configuration Package Migration and Note 1510288.1 - Guidance for Managing Customizations in Oracle Cloud Application Services: Flexfield Migration
    • For report migration see Note 1510577.1 - Guidance for Managing Customizations in Oracle Cloud Application Services: Business Intelligence Migration and Note 1611612.1 - How To Migrate Financial Reporting Studio Reports From One Instance To Another

     

    Comment

     

    • Gopinath Kartheesan

      Hi, Is there any document that talks about Post Refresh setups we have to do after every P2T refresh?  For eg: We have to rebuild Essbase cubes after every P2T refresh otherwise the reports using Essbase cube won't work.  Like that are there any other Post Refresh setups we have to do ?

      thanks for your help

      Regards

      Gopi

    • Lisa Ozkan

      Yes, the Doc ID 2015788.1 mentioned in this Post addresses this question. Please check it out on My Oracle Support.

      Lisa

    • Gopinath Kartheesan

      Thanks Lisa.  I saw the details in Appendix A that covers some of the activities based on what gets copied and what doesn't get copied.

       

      Regards

      Gopi

    • Rahul Pidaparti

      Thanks for all the information..

      I have a question.. What is the reason because of which the Essbase Cubes are not getting copied?

      Thanks in advance.