Agile Product Lifecycle Management Agile Configuration Propagation Guide Release 9.3.3 E39285-02 |
|
![]() Previous |
![]() Next |
This chapter describes terms that are used by ACP.
Your company will likely have several instances of Agile PLM, which were set up for specific purposes. (These purposes are detailed in the next chapter, "Use Case."
First there are two "instance" terms that simply name "From" and "To" installations when you use ACP:
Source instance - the installation of Agile PLM from which you are propagating Administrator data with ACP
Target instance - the installation of Agile PLM to which you are propagating Administrator data with ACP
Beyond Source and Target, the instance names below are only suggestions.They are not required in order to use ACP; however, these names are used in this manual as defined below, notably in "Use Case."
Agile instance - an autonomous system of Agile PLM that maintains data in a single database
Golden Configuration instance - a controlled environment to make configuration changes in.
The "Golden Config" Agile PLM instance is for maintaining a clean, controlled configuration environment. Normally, it would exist with only configuration data and no business data. The critical aspect to this instance is the amount of control on it. If your installation has a practice of making configuration changes in your Production instance, you will need to update your Golden Config instance periodically with configuration information from your Production instance.
Development instance - for developing and testing new features in PLM, and other improvements
The "Dev" Agile PLM instance is where any configuration changes should be tested before taking them to your Production instance. By its nature, the Development instance is not a controlled instance and its configuration may therefore not be "clean". It is prudent to update the Dev configuration from Production before starting a new project. This will help avoid lost configurations.
Stage or Test instance - for testing in a Production-like environment the changes made in the Development instance before they are applied to the Production instance
The Stage Agile PLM instance is a Production-like instance that can serve two purposes: (1) perform dry runs of ACP prior to going live; and (2) an instance for training your user community on the feature changes provided by the latest configuration changes.
Production instance - contains your company's live data and business objects
The Production Agile PLM instance is the ultimate master instance. This is where business is conducted. It must stay pure and always be in a consistent state.
propagate - when an Agile instance is changed, no matter if it is a single change to a single object's attributes or sweeping changes across the system, "propagate" is the broad idea of effecting the same change to another Agile instance.
ACP propagates in two steps, Export and Import:
export - ACP gathers data from the Source instance of Agile. The result of the Export function in ACP is an XML file, or archive, of the Source.
import - ACP replaces data from XML (the Source archive) into the Target instance of Agile.
Note: ACP's export and import functions should not be confused with either the PLM utilities Agile Export and Import, nor Administrator Export and Import in Java Client. |
compare - ACP compares between Source-instance and Target-instance data so it can report object-specific differences between the two Agile instances.
There are two kinds of Compare in ACP:
Name Compare - the name-based comparison identifies new objects, deleted objects, and objects whose name changed. (This is the same compare function supported by ACP 9.2.x.)
Deep Compare - ACP can examine Administration objects at a deeper level, the level of object attributes. With Deep Compare, Admin objects in the Source instance are compared to those in the Target instance to capture changes in the names and properties of object Attributes.
API Name - a required field for many Administrator objects and PLM business objects; as it tends not to change (whereas the Name attribute is much more likely to change), it is a unique systemwide identifier or key for Admin/PLM objects.
object key - a business object's key is the API Name if the Administrator node supports it, or the object's Name if the node does not support API Name; in the case of Users, the object key is User ID. This term is important when ACP is performing the operations listed in "Process Terms".
configuration data, Administrator data - the content of all the settings in PLM Administrator represent the configuration data for an instance of Agile PLM. These two terms are interchangeable.
configuration type, Administrator node - the content of the settings of one node in the Administrator UI "tree."
These terms are also interchangeable, although there is not one-to-one correspondence. Some Admin nodes are never propagated by ACP, and some config types are not nodes in Administrator.
When you propagate the data settings held in the Roles node in Administrator, you are propagating the Roles configuration type in ACP.
configuration object, Administrator object - the content of the settings for a single item in an Admin node.
Therefore, when you propagate the data settings held in the Change Analyst role in Administrator (User Settings > Roles node > Change Analyst role), you are propagating the Change Analyst configuration object in ACP.
Agile Server - the machine where Agile PLM is installed
ACP Client - the machine where ACP runs
Agile Install Directory - this is the directory you choose to install the ACP utility. "<version>" indicates where you would fill in the version of Agile PLM that you are working in, for example, "931".
Example in Windows: D:\Agile\ACP
<version>
Example in Unix: /opt/agile/acp
<version>
ACP Utility - the collective set of files installed in the <ACP Install Directory>
Project Directory - this directory contains ACP control files, which are named - or in named folders - in such a way that you know what the control file is targeted to do. "<version>" indicates where you would fill in the version of Agile PLM that you are working in, for example, "931".
Example in Windows: D:\Agile\ACPwork
<version>
Example in Unix: <user.home>/Agile/ACPWork
<version>
ACP scripts - since ACP is a command-line-driven utility, in effect the scripts are the "User Interface" for interacting with the ACP programs.
ACP Control File - the Control File (default name: config.xml) directs ACP which configuration types to process. (It is possible to keep config.xml as an "example control file" and create working control files with meaningful names. This idea is detailed in "Running ACP.")
Agile XMLarchive - a ZIP file with an extension (.agl) that contains XML files exported by ACP
Delete - a propagate action; the Delete section of the Control File instructs ACP about delete operations it should perform;
Rename - a propagate action; the Rename section of the control file instructs ACP about rename operations it should perform;
Copy - a propagate action; the Copy section of the control file instructs ACP about create, update, and replace operations it should perform.
Agile user - a person at your company who is created in the Agile PLM system and assigned an Agile role that permits use of the PLM system; also called "end-user" (or simply "user," although this could be confused with the other users listed below)
Administrator user - an Agile user who is assigned the Administrator role (or, more specifically, the Administrator privilege mask), which enables access to the Administrator modules in Java Client and Web Client; usually referred to as "administrator" (lower-case "a"), "Agile administrator," or even the "Admin user"
User Administrator - a specialized Agile administrator (an Agile user who is assigned the "Admin Access for User Admin" privilege mask) whose role is limited to management of users and user groups
ACP user - a person at your company who uses the ACP utility could be called an "ACP user," but formally it means "an Agile user who is given role/privilege access to use ACP."