11g Release 7 (11.1.7)
Part Number E20388-06
Home
Contents
Book
List
Contact
Us
|
Oracle® Fusion Applications CRM Extensibility Guide 11g Release 7 (11.1.7) Part Number E20388-06 |
Home |
Contents |
Book List |
Contact Us |
 Previous |
 Next |
This chapter contains the following:
Sandboxes : How They Work with Some Customizations and Features
Sandbox Development Lifecycle Components : Explained
Using the Sandbox Manager: Explained
Supported Sandbox Manager Operations : Explained
Multiple Sandbox User Conflicts : Explained
How to create and activate sandboxes
How to best work in a sandbox when others on your team may also be testing customizations in their own sandboxes
Which types of customizations you cannot do inside a sandbox
Maintain sandboxes using the Sandbox Manager, which you can access by selecting Manage Sandboxes... from the Administration menu.
Sandboxes in Oracle Fusion Applications provide robust out-of-the-box functionality to help isolate and control customization efforts without impacting other users' configuration environments, and/or the production environment. You can read all about sandboxes in the Oracle Fusion Applications Extensibility Guide for Business Analysts. Or, review this document to learn how to customize Oracle Fusion CRM Applications, specifically, using sandboxes.
Sandboxes let users make changes isolated from the mainline application, as well as from other sandboxes. The mainline is the source of data and definitions used at the time of creating a new sandbox. Business analysts can implement and test application customizations in a sandbox and, once satisfied, publish them back to the mainline. When making changes in a sandbox, your customizations will not be available to any other sandbox or to the mainline application until you have published your sandbox. When publishing a sandbox, the included application customizations overwrite the mainline application's existing configuration.
Within this section, the term customizing means to change an existing artifact, for example, adding a new field to an existing business object. Customizing also refers to changing what is displayed on a page, as well as creating a completely new artifact, such as a business object or page.
Note
Never make your customizations directly in the mainline. Instead, always use sandboxes whenever possible.
To customize applications within Oracle Fusion CRM, you can use these composers:
Oracle Fusion CRM Application Composer: Customize pages, business objects, and all the artifacts that support them (such as fields, pages, buttons and links, security, server scripts, and saved searches). Extend Oracle Fusion CRM applications by creating completely new business objects and artifacts.
Page Composer: Customize pages.
For more information on customizing pages using Page Composer, see "Editing a Page in Page Composer" in Oracle Fusion Applications Extensibility Guide for Business Analysts on Oracle Technology Network at http://www.oracle.com/technetwork/indexes/documentation
First, all changes result in the creation or updating of many files within the MDS repository. Your customizations are stored as XML files in the repository, segregated by sandbox.
Additionally, as custom objects and fields are created, their definitions are allocated to generic placeholders that already exist as tables or columns in the database.
Sandboxes handle metadata customizations made to the data stored in the Metadata Services (MDS) repository.
Test-Only: Users perform all customizations using the test-only sandbox. Changes made here should never be published to the mainline.
Publish: Once satisfied with the customizations made in the test-only sandbox, users replicate their changes in this sandbox, and then publish them to the mainline. This sandbox type is also known as the integration sandbox, because teams working in parallel use this sandbox as the final staging point before publication to the mainline.
Create a sandbox
Activate a sandbox
Delete a sandbox
Publish a sandbox
View available or published sandboxes
Lookup types and lookup values are considered seed data, and are not stored inside the MDS. Accordingly, any lookup types or lookup values that you create as part of a customization are retained in the database, even after a sandbox is deleted.
You can use the Oracle Business Intelligence (BI) Composer to build custom reports. During report creation, you select a report subject area as the basis for your new report. A report subject area contains a set of objects and fields that represent information about the areas of an organization's business. Many report subject areas are already available to you as part of Oracle Fusion Applications.
Note that you can also create custom subject areas, which are report subject areas that you build using the Application Composer. To create a custom subject area, however, you must be in the mainline application; you cannot be in a sandbox. Therefore, if you want your report to include custom fields or objects (always created inside a sandbox), you must first publish your sandbox. Only after publication can you create a custom subject area that includes the custom fields or objects that you want to later report on.
Web services do not reflect sandbox changes such as custom fields or objects until the sandbox is published. Consequently, features that depend on Web services to work will not gain access to the custom fields or objects until the sandbox is published.
For example, when working with object workflows, you can create a custom field and define a workflow condition using that field. While working in a sandbox, however, you cannot reference the custom field in the workflow actions because workflow actions rely on Web services to get field values. Therefore, you must first publish the sandbox in which you created your custom field. Only after publishing the sandbox can you then update the object workflow's condition using your custom field.
Note
Since e-mail templates are part of the object workflow feature, you must create these templates outside a sandbox as well, in the mainline application.
To support the importing and exporting of the custom objects that you created with the Application Composer, you must first generate the object artifacts required for both file-based import and bulk export. Note that this task is not supported from within a sandbox, and can only be completed in the mainline application.
Use the Sandbox Manager to:
Create sandboxes
Activate sandboxes
Review a list of available or published sandboxes
Publish sandboxes
Delete sandboxes
Using the Sandbox Manager, create a new sandbox by using the Actions menu option, or by clicking the New button.
Tip
To customize data security policies outside Oracle Fusion CRM without affecting the mainline, create a separate data security sandbox by selecting the Create data security sandbox check box when creating a new sandbox. When working within Oracle Fusion CRM, however, do not create data security sandboxes.
When creating multiple sandboxes, create one for testing only which you will never publish. Also, create a single integration sandbox that you do intend to eventually publish.
Private sandbox - Testing and prototyping only. Never publish. Delete when finished, or after its related integration sandbox has been published.
Integration sandbox - Testing and validations with the intent to publish. Ensure only one administrator user works in this sandbox at a time.
Coordinate with other administrator users to manually migrate (re-key) approved configurations from a private sandbox into the integration sandbox. To avoid confusion, establish naming conventions such as rjones4_19nopub, mhoope4_19nopub, and integrationsandbox4_19topub. The date indicates when a sandbox was derived from the mainline application. You can also check the sandbox creation date and time using the Sandbox Manager.
After creating a new sandbox, you must next activate it to be able to use it. To activate a sandbox, select the sandbox and then click the Set as Active button. Only one sandbox can be active at a time.
Once a sandbox is active for your session, the sandbox name is displayed in the global area.
After activating a sandbox, you should always log out from Oracle Fusion Applications and log back in. This helps you to avoid conflicts by ensuring that the cache is cleared.
Note that if you log out and log back in, your sandbox remains active. A sandbox remains active until you exit the sandbox, publish the sandbox, delete the sandbox, or set another sandbox as active.
To exit from the current sandbox session, hover over the sandbox name in the global area and then click Exit Sandbox.
The sandbox session is closed and you are returned to the mainline application. After exiting a sandbox session, you should always log out from Oracle Fusion Applications and log back in. This helps you to avoid conflicts by ensuring that the cache is cleared.
Important
Once back in the mainline application, avoid making customizations using the Oracle Fusion CRM Application Composer. To start making customizations again, use the Sandbox Manager to set a new sandbox as active.
Completed customizations created within a test-only sandbox and then replicated to an integration sandbox must be published to be available to other users in the mainline application. Always publish customizations from the integration sandbox only.
Note that there is no standard mechanism to roll back changes that have already been published to the mainline.
To publish a sandbox, select the sandbox and then click the Publish button.
After you publish a sandbox, the sandbox session is closed and the sandbox is no longer active. Be sure to delete your test-only sandboxes, and then create new sandboxes (including a new integration sandbox) for your application customization work.
Deleting sandboxes cleans up the Metadata Services (MDS) repository and database layers.
Once you have tested your customizations, you then move those customizations to the integration sandbox. After you publish your integration sandbox, you must delete all test-only sandboxes, and then create and work in entirely brand new sandboxes, including a new integration sandbox. You can delete only nonpublished sandboxes that are not active.
Warning
Although you might delete a sandbox, transactional data for custom objects is retained because transactional data is stored outside of the MDS. Suppose a custom object named D1 is created in a sandbox, three rows of transactional data were entered through its work area at run time, and then the sandbox is deleted. The three rows of transactional data are retained, although not visible to users unless a new custom object is created with the exact same name (D1) with the same fields in the same order. In this case, the data might be exposed once again.
The only supported sandbox operations are:
Create
Activate - only one sandbox can be active at a time.
Delete - delete a sandbox only when the sandbox is no longer needed, the sandbox is outdated, or its related integration sandbox has been published to the mainline.
Publish - publish a sandbox using extreme caution. Once a sandbox has been published, all existing sandboxes derived from the same mainline are now invalid. There is no rollback operation for published sandboxes.
Download All - coordinate this operation with the main administrator user, before publishing a sandbox, as a way of performing a backup of current sandbox customizations. This backup can be shared with Oracle Support Services, should you encounter a scenario that you cannot resolve.
Exit - exit the sandbox.
Do not import sandboxes. This operation is reserved for Oracle internal development only.
Sign out and sign back in when:
Activating a sandbox for the first time
Exiting a sandbox
Switching between sandboxes
A user might overwrite changes performed by other users using the same sandbox:
Directly - by changing the same artifact object
Indirectly - by updating metadata files shared between different artifacts
When more than one user is working in the same sandbox, and the same object within the sandbox is saved at the same time, only one user's customization is saved. The other user's customization (customization B) may not be lost, but will overwrite customization A if the other user again tries to save customization B.
If customizations on the same object are saved at different times, then the last saved customization will overwrite the other user's changes.
When multiple sandboxes exist for publication, one user might overwrite changes made by another user during sandbox publication into the mainline application. The resulting mainline configuration is always from the last published sandbox.
To avoid such conflicts, comply with these guidelines:
Use a distinct user name for each administrative user.
Within the Customer Relationship Management Application Administrator duty, ensure that every administrative user has a distinct username. Do not share users per administrator to perform customizations.
Create a single integration sandbox at a time.
Never create more than one integration sandbox at a time. Only create another integration sandbox once the previous sandbox is published.
Enforce a single user per sandbox rule.
Users should never be in the same sandbox at the same time. Ensure that only a single user is in a sandbox at a time. (You must manually enforce this rule.)
You need to test the following configurations, which must be tested outside a sandbox:
Import/Export
Web services
Custom subject area creation
Object workflow
E-mail templates.
Note
Once you publish an integration sandbox, all private sandboxes are invalid because the label in the mainline application has changed. If you made changes to private sandboxes that you want to retain, document those changes and then delete all private sandboxes.
ProfileMO.xml Error: If you encounter a message showing a conflict on /oracle/apps/fnd/applcore/profiles/profileService/mds/ProfileMO.xml when you publish your sandbox, you can ignore this message and continue to publish the sandbox
Log an Oracle Technical Support Request with the Incident Number found on the error message and the name of the sandbox
Create a new sandbox, activate it, and resume your work.
Note
When you delete a sandbox, you should first confirm that the sandbox is not active. Only non-published sandboxes can be deleted.
Once you have tested your customizations, you must move those customizations to the integration sandbox. Publish your integration sandbox and then delete all the test-only sandboxes. You can then create and work in entirely brand new sandboxes, including a new integration sandbox.
Exit the sandbox
Create a new sandbox, activate it, and resume your work
Apply or create your security changes in the new sandbox
Delete the original sandbox where you encountered the error.
