3 Use Case

This chapter is an overview of the administration configuration management process of Agile PLM as a whole. You may choose to do some tasks below or add tasks that are not mentioned here.

3.1 Configuration Management

The primary use case for ACP is configuration management across two or more Agile PLM instances. Individual installations may vary in how instances are used and what configuration procedures are followed.

Note: Configuring the Agile PLM solutions requires full understanding of your company's business goals and procedures. Successful configuration of PLM - initial or upgrade - often requires a representative from Oracle Consulting - Agile Practice

Agile Configuration Propagation supports regular and frequent cycles of developing, testing, and deploying Administrator configuration of the PLM solutions. ACP allows you to propagate the entire configuration or only a subset of the configuration.

Regardless of the amount of configuration data being propagated, the following tasks offer recommended best practices, at least until you become familiar with ACP and its limitations.

These tasks are in a suggested order to be executed, however, the order should be changed to facilitate your process.

For the discussion below, please refer to "Instance Terms" for the definitions of various kinds of Agile instances, such as Golden Config, Dev, Stage, and Production.

3.2 Configuration Tasks

The configuration tasks that are discussed in this section are also schematically depicted in the graphic below.

3.2.1 Schematic of PLM Configuration

Figure 3-1 Schematic of PLM Configuration

3.2.2 Validate Agile PLM Data

Use aVerify to validate the data in an Agile PLM instance. A good practice whether or not you are using ACP is to periodically validate PLM data.

Keeping your data valid ensures smooth operation of your Agile PLM instance. All Agile PLM instances should be validated before accessing it with ACP.

Since ACP only propagates Administrator data, you can limit your concern about data issues to Administrator data.

For information pertaining to aVerify, please consult aVerify Release Notes (on OTN, Preface) or contact Oracle Support Services.

3.2.3 Create a Project

Use ACP Control Files to denote a set of related configuration changes.

Although you can propagate all configuration data in a single run with ACP, it is better to group related configuration changes. These groups can be called projects. Each project can have its own lifecycle.

In the Control File, you can explicitly state which objects belong to the project. Projects can also be reused.

3.2.4 Configure Agile PLM

Use Java Client to modify Admin data in the source instance (Golden Config or Dev). Avoid making Admin data changes in your Production instance as those changes can get lost during subsequent ACP imports.

• Keep track of Admin objects changed in your project control file. This will ease the burden of trying to figure out which Admin objects need to be propagated later.

• Use a spreadsheet to keep track of actual changes made. This will aid in validating the propagation results.

3.2.5 Export Admin Data

Use ACP to export the Admin data related to a project from the source instance (Golden Config or Dev). Refer to "Running ACP" for more information.

3.2.6 Import Admin Data for Testing

Use ACP to import the Admin data that is related to a project.

This task is oriented toward moving Admin data from the Golden Config instance to the Stage instance. New features are developed and tested on the Dev instance, but they should be tested again on the Stage instance before exposing the Production instance to these changes.

The Dev instance is also an appropriate place to develop process extensions. The process extensions can also be tested with the modified Admin data.

• Use ACP to import the Admin data related to the project to the target instance.

• Review ACP logs for errors.

• Verify that the propagation worked as expected. Use the spreadsheet used to track changes for the project to verify that the Admin data changes are present in the target instance.

3.2.7 Test Admin Data Changes

Use the Agile PLM application to test the Admin data changes in the Test instance.

1. Develop a formal test plan to test the changes.

2. Develop a Go Live! "sanity test plan".

3. Execute the formal test plan.

4. Validate the test plan results.

5. Adjust the Admin data in the source instance (Golden Config or Dev) as necessary.

3.2.8 Prepare for Dry Run

Use ACP to prepare for a Dry Run. You want to make sure that ACP will propagate all Administrator data changes associated with a project. The way to do this is by comparing the configuration data in the source instance (Golden Config or Dev) and the target instance (Stage). This task comprises several steps:

• Create a backup of the Production instance.

• Refresh the Stage instance from the Production instance.

• Sanitize the Stage instance.

  • Turn off notifications.

  • Change Production-only Admin data to have suitable values for Stage.

• Compare the Admin Data between the source instance and the target instance.

  • Use ACP to export the Admin Data from the target instance (Stage). This can be the entire Admin data or just limited to the Admin data related to the project.

  • Use ACP to export the Admin Data from the source instance (Golden Config or Dev). This only needs to be done if you wish to compare the entire Admin data with the target instance.

  • Compare the XML files generated by ACP.

• Update the configuration data in the source instance as necessary.

• Update the project ACP control file as necessary.

3.2.9 Execute Dry Run

Use ACP to execute the Dry Run.

Note: Multiple Dry Runs may be warranted. Dry Runs typically use the Stage instance as the target instance. At this point, your project ACP control file should be configured to propagate all Admin data related to the project.

• Lock out users from logging into the target instance. This ensures your backup is valid.

• Back up target instance. It is best to back up your target instance for recovery purposes.

• Develop a Propagation Script. This script will document the exact steps used to propagate the data to the Production instance. It is used to document the order in which steps are performed as well as any manual steps required.

• Use ACP to export the Admin data related to the project from the source instance (if not already done).

• Use ACP to import the Admin data related to the project to the target instance.

• Review ACP logs for errors.

• Verify that the propagation worked as expected. Use the spreadsheet used to track changes for the project to verify that the Admin data changes are present in the target instance.

• Execute the formal test plan.

• Adjust the Admin data in the source instance (Golden Config or Dev) as necessary.

• Re-run the Dry Run as many times as necessary to get a clean run of ACP.

3.2.10 Execute Go Live

Use ACP to execute the "Go Live" task. The Go Live task copies the Admin data changes from the source instance (Golden Config or Dev) to the Production instance.

• Lock out users from logging in to the Production instance. This ensures your backup is valid.

• Back up Production instance. It is best to back up your Production instance for recovery purposes.

• Follow the Propagation script created during the Dry Run.

• Use ACP to import the Admin data related to the project to the Production instance.

• Review ACP logs for errors.

• Verify that the propagation worked as expected. Use the spreadsheet used to track changes for the project to verify that the Admin data changes are present in the target instance.

• Execute the Go Live sanity test plan.

• Allow users to log in to the Production instance.

3.2.11 Audit Configuration Changes

Use ACP and a source control system to keep track of the changes made.

• Export entire Admin data from the Production instance.

• Place the AGL file created into any source control system.