Database Tools
This section describes a variety of database tools that are supplied with the product.
Contents
Defining Environment Reference Options
Defining Maintenance Object Options
Defining Database Process Options
Defining Database Process Instruction Options
The Big Picture Of Audit Trails
An environment reference is used to track a supporting environment's purpose relative to the current environment within the application. An environment is an instance of your product database and runtime programs. Environment references specify roles that describe how the supporting environment is used.
Registration Utility. The registration utility adds environment references for you. Refer to Archiving and Purging and Configuration Lab for more information on the functions of the registration utility and how to execute it.
Select Admin Menu, Environment Reference to view environments and their use within the application.
Description of Page
Some fields on this page are protected as only the registration utility may change them. The following describes fields you may change and fields that may be relevant to Archiving and Configuration Lab:
Environment Reference is the name of the supporting environment reference.
Enter a Description and Long Description for the environment reference.
Use Environment Role to specify how the supporting environment that is represented by the environment reference is to be used. The valid values are:
· Archive. Specify if the environment reference represents a supporting environment used to house archived data moved from the current environment.
· Compare Source. Specify if the environment reference represents a supporting environment used as a source of control data from which the current environment may copy.
· ConfigLab. Specify if the environment reference represents an environment used as a configuration lab.
· Sync Target. Specify if the environment reference represents a supporting environment used as the target for a copy of a subset of data from the current environment.
For more information on specific uses of environment roles, refer to Archiving and Purging and Configuration Lab.
The Environment ID associates the environment reference with its environment's universal identifier within the application. This universal identifier is on the Installation Options of the target environment.
Use Name Prefix to specify how the current environment accesses tables in the supporting environment described by the environment reference. The prefix replaces the C in the table name. For instance, assuming the current environment is production, the production environment accesses the CI_ACCT table in the ConfigLab as ZI_ACCT.
The topics in this section describe the transaction that allows you to define metadata for the application's tables.
Table - Referred by Constraints
Table - Main
Select Admin Menu, Table to view information about a table, define the fields whose changes should be audited, and to override a field’s label on a specific table.
Description of Page
Many fields cannot be changed. You cannot change most attributes on tables that are owned by the base-package (i.e., those whose Owner is not Customer Modification).
Description contains a brief description of the table.
System Table defines if the table holds rows that are owned by the base-package.
Enable Referential Integrity defines if the system performs referential integrity validation when rows in this table are deleted.
Data Group ID is used for internal purposes.
Table Usage defines how the table is used in the application. In the current release, only tables that are part of Oracle Utilities Business Intelligence make use of this field.
Table Type defines if the table is a View or a physical Table.
Date / Time Data Type defines if the system shows times on this table in Local Legal Time or in Standard Time (Local Legal Time is the time as adjusted for daylight savings).
Audit Table is the name of the table on which this table’s audit logs are stored. Refer to The Audit Trail File for more information.
Use Audit Program Type to define if the audit program is written in Java or COBOL.
COBOL Programs. COBOL programs are only supported as part of Oracle Utilities Customer Care and Billing.
Audit Program is the name of the program that is executed to store an audit log. Refer to Turn On Auditing For a Table for more information.
· If the Program Type is COBOL, enter the name of the COBOL program.
· If the Program Type is Java, enter the Java class name.
View the source. If the program is shipped with the base package, you can use the adjacent button to display the source code of this program in the source viewer or Java docs viewer.
Upgrade controls what happens to the rows in this table when the system is upgraded to a new release:
· Keep means that the rows on this table are not touched during an upgrade
· Merge means that the rows on this table are merged with rows owned by the base package
· Refresh means that the rows on this table are deleted and refreshed with rows owned by the base package.
Data Conversion Role controls if / how the table is used by the conversion tool:
· Convert (Retain PK) means that the table's rows are populated from the conversion schema and the prime key in the conversion schema is used when the rows are converted. A new key is not assigned by the system.
· Convert (New PK) means that the table's rows are populated from the conversion schema and the prime key is reassigned by the system during conversion.
· Not Converted means that the table's rows are not managed by the conversion tool.
· View of Production means that the conversion tool uses a view of the table in production when accessing the rows in the table. For example, the customer class table would be set up using this value so that the conversion tool will use the customer classes in production when it needs to access customer class codes.
A Language Table is specified when fields containing descriptions are kept in a child table. The child table keeps a separate record for each language for which a description is translated.
Enable Data Dictionary defines if the table is to be included in the Data Dictionary application viewer.
A Key Table is specified when the prime-key is assigned by the system. This table holds the identity of the prime keys allocated to both live and archived rows.
Type of Key specifies how prime key values are generated when records are added to the table:
· Other means a foreign-system allocates the table's prime-key (e.g., the fact and dimension tables within Oracle Utilities Business Intelligence have their keys assigned by Oracle Warehouse Builder).
· Sequential means a sequence number is incremented whenever a record is added to the table. The next number in the sequence determines the key value.
· System-generated means a program generates a random key for the record when it is added. If the record's table is the child of another table, it may inherit a portion of the random number from its parent's key.
· User-defined means the user specifies the key when a record is added.
Inherited Key Prefix Length defines the number of most significant digits used from a parent record's primary key value to be used as the prefix for a child record's key value. This is only specified when the Type of Key is System-generated and the high-order values of the table's key is inherited from the parent table.
Help URL is the link to the user documentation that describes this table.
Special Notes contains any notes or special information about the table.
The grid contains an entry for every field on the table. Drilling down on the field takes you to the Table Field tab where you may modify certain attributes. The following fields may also be modified from the grid: Description, Override Label, Audit Delete, Audit Insert and Audit Update. Refer to the Table Field tab for descriptions of these fields.
Table - Table Field
Select Admin Menu, Table and navigate to the Table Field tab to define the fields whose changes should be audited and to override a field’s label on a specific table (note, you can also maintain a subset of this information in the grid on the Main tab).
Description of Page
Many fields on this page are protected as only the product development group may change them. The following describes fields you may change for records that are part of the base product. Fields containing information that may be of interest are also described.
Turn on Audit Delete if an audit record should be stored for this field when a row is deleted. Refer to How To Enable Auditing for more information.
Turn on Audit Insert if an audit record should be stored for this field when a row is added. Refer to How To Enable Auditing for more information.
Turn on Audit Update if an audit record should be stored for this field when it is changed. Refer to How To Enable Auditing for more information.
The Label column only contains a value if the base-product indicates a value other than the field's label should be shown on the various pages in the system. The field's label is shown above, adjacent to the field's code.
The Override Label is provided in case you want to override the base-package's label. If specified, it will be displayed throughout the application.
Note. If you want the Override Label to be shown in the data dictionary, you must regenerate the data dictionary.
Special Notes contains any notes or special information about the table.
Field Usage defines how the field is used in the application. In the current release, only tables that are part of Oracle Utilities Business Intelligence make use of this field.
Table - Constraints
Select Admin Menu, Table and navigate to the Constraints tab to view the constraints defined on the table.
Description of Page
The fields on this page are protected as only the product development group may change them.
This page represents a collection of constraints defined for the table. A constraint is a field (or set of fields) that represents the unique identifier of a given record stored in the table or a field (or set of fields) that represents a given record's relationship to another record in the system.
Constraint ID is a unique identifier of the constraint.
Owner indicates if this is owned by the base package or by your implementation (Customer Modification)
Constraint Type Flag defines how the constraint is used in the system:
· Primary Key represents the field or set of fields that represent the unique identifier of a record stored in a table.
· Logical Key represents an alternate unique identifier of a record based on a different set of fields than the Primary key.
· Foreign Key represents a field or set of fields that specifies identifying and non-identifying relationships to other tables in the application. A foreign key constraint references the primary key constraint of another table.
· Conditional Foreign Key represents rare relationships between tables where a single field (or set of fields) may reference multiple primary key constraints of other tables within the application as a foreign key.
When Enable Referential Integrity is checked, the system validates the integrity of the constraint when a row in the table is modified.
Referring Constraint Owner indicates if this is owned by the base package or by your implementation (Customer Modification).
Referring Constraint ID is the Primary Key constraint of another table whose records are referenced by records stored in this table.
Referring Constraint Table displays the table on which the Referring Constraint ID is defined. You can use the adjacent go-to button to open the table.
Additional Conditional SQL Text is only specified when the constraint is a Conditional Foreign Key. The SQL represents the condition under which the foreign key represents a relationship to the referring constraint table.
Additional Conditional SQL Syntax. When specifying additional conditional SQL text, all table names are prefixed with a pound (#) sign.
The Constraint Field grid at the bottom of the page is for maintaining the field or set of fields that make up this constraint.
Field The name of the table's field that is a component of the constraint.
Sequence The rank of the field as a component of the constraint.
The Referring Constraint Field grid at the bottom of the page displays the field or set of fields that make up the Primary key constraint of the referring constraint.
Field The name of the table's field that is a component of the referring constraint.
Sequence The rank of the field as a component of the referring constraint.
Table - Referred by Constraints
Select Admin Menu, Table and navigate to the Referred By Constraints tab to view the constraints defined on other tables that reference the Primary Key constraint of this table.
Description of Page
This page is used to display the collection of constraints defined on other tables that reference the table.
Referred By Constraint Id is the unique identifier of the constraint defined on another table.
Referred By Constraint Owner indicates if this constraint is owned by the base package or by your implementation (Customer Modification).
Prime Key Constraint Id is the Primary Key constraint of the current table.
Prime Key Owner indicates if this prime key is owned by the base package or by your implementation (Customer Modification).
Referred By Constraint Table is the table on which Referred By Constraint Idis defined.
When Enable Referential Integrity is checked, the system validates the integrity of the constraint when a row in the table is modified.
The grid at the bottom of the page displays the Field and Sequence for the fields that make up the constraint defined on the other table.
The topics in this section describe the transaction that can be used to view information about a field and to change the name of a field on the various pages in the system.
Contents
Field - Main
Open this page using Admin Menu, Field.
Important! If you change a field’s label, the new label appears on ALL transactions on which the field exists.
Warning! A field’s label can be overridden for a specific table. If this is the case and you change the field’s name on this transaction, the change will have no effect when the field is displayed for that specific table. If you find this to be true, change the field’s label on the respective table on which it was overridden. You do this using the Table Maintenance transaction.
Description of Page
Many fields on this page are protected as only the product development group may change them. The following describes fields you may change for records that are part of the base product. Fields containing information that may be of interest are also described.
Field Name uniquely identifies this field.
Important! As described in System Data Naming Convention for most system data tables, the base product follows a specific naming convention. However, this is not true for the Field table. If you introduce new fields, you must prefix the field with CM. If you do not do this, there is a possibility that a future release of the application could introduce a new field with the name you allocated.
Owner indicates if this field is owned by the base package or by your implementation (Customer Modification). The system sets the owner to Customer Modification when you add a field.
This information is display-only.
Base Field
Data Type indicates if the field will hold Character, Date, DateTime, Number, Time, or Varchar2 data.
Ext Data Type
Precision defines the length of the field. In the case of variable length fields, it is the maximum length possible.
Scale
Sign
Level 88 Cpybk
Description contains the label of the field. This is the label of the field that appears on the various pages on which the field is displayed. Note, the field's label can be overridden for a specific table (by specifying an Override Label on the table / field information).
Java Field Name
Override Label
Check Work Field if the field does not represent a database table column.
Help Text
Special Notescontains any notes or special information about the field.
Field - Tables Using Field
Select Admin Menu, Field and navigate to the Tables Using Field tab to view the tables that contain a field.
Description of Page
The grid on this page contains the Tables that reference the Field. You can use the adjacent go to button to open the Table Maintenance transaction.
A maintenance object is a group of tables maintained together within the system.
Contents
Maintenance Object - Algorithms
Maintenance Object - Maintenance Object Tree
Maintenance Object - Main
Select Admin Menu, Maintenance Object to view information about a maintenance object.
Description of Page
Most maintenance objects are provided with the base package. An implementation can introduce custom maintenance objects when needed. Most fields may not be changed if owned by the base package.
Enter a unique Maintenance Object name and Description. Ownerindicates if this business object is owned by the base package or by your implementation (Customer Modification).
Important! If you introduce a new maintenance object, carefully consider its naming convention. Refer to System Data Naming Convention for more information.
Program Com ID is the name of the program used to call the maintenance object's page program for validating constraints when objects are archived, purged, or compared. Refer to Archiving and ConfigLab for more information.
Service Name is the name of the internal service associated with the maintenance object.
The grid displays the following for each table defined under the maintenance object:
Table The name of a given table maintained as part of the maintenance object.
Table Role The table's place in the maintenance object hierarchy. Only one Primary table may be specified within a maintenance object, but the maintenance object may contain many Child tables.
Parent Constraint ID Specifies the constraint used to link the table to its parent table within the maintenance object table hierarchy.
Compare Method Either Normal or Large Table; specifies the comparison method used by the compare utility in the ConfigLab.
Owner Indicates if this is owned by the base package or by your implementation (Customer Modification).
Click the View XML hyperlink to view the XML document associated with the maintenance object service in the Service XML Viewer.
Maintenance Object - Options
Use this page to maintain a maintenance object's options. Open this page using Admin Menu, Maintenance Object and then navigate to the Optionstab.
Description of Page
The optionsgrid allows you to configure the maintenance object to support extensible options. Select the Option Type drop-down to define its Value. Detailed Description may display additional information on the option type. Set the Sequence to 1 unless the option can have more than one value. Ownerindicates if this is owned by the base package or by your implementation (Customer Modification).
You can add new option types. Your implementation may want to add additional maintenance option types. For example, your implementation may have plug-in driven logic that would benefit from a new option. To do that, add your new values to the customizable lookup field MAINT_OBJ_OPT_FLG.
Maintenance Object - Algorithms
Use this page to maintain a maintenance object's algorithms. Open this page using Admin Menu, Maintenance Object and then navigate to the Algorithms tab.
Description of Page
The Algorithms grid contains algorithms that control important functions for instances of this maintenance object. You must define the following for each algorithm:
· Specify the System Event with which the algorithm is associated (see the table that follows for a description of all possible events).
· Specify the Sequence Number and Algorithm for each system event. You can set the Sequence Number to 10 unless you have a System Event that has multiple Algorithms. In this case, you need to tell the system the Sequence in which they should execute.
· If the algorithm is implemented as a script, a link to the Script is provided. Refer to Plug-in Scripts for more information.
· Ownerindicates if this is owned by the base package or by your implementation (Customer Modification).
The following table describes each System Event.
|
System Event |
Optional / Required |
Description |
|
Determine BO |
Optional |
Algorithm of this type is used to determine the Business Object associated with an instance of the maintenance object. It is necessary to plug in such an algorithm on a Maintenance Object to enable the business object rules functionality. The system invokes a single algorithm of this type. If more than one algorithm is plugged-in the system invokes the one with the greatest sequence number. Click here to see the algorithm types available for this system event. |
|
Information |
Optional |
We use the term “Maintenance Object Information” to describe the basic information that appears throughout the system to describe an instance of the maintenance object. The data that appears in this information description is constructed using this algorithm. The system invokes a single algorithm of this type. If more than one algorithm is plugged-in the system invokes the one with the greatest sequence number. Click here to see the algorithm types available for this system event. |
|
Transition |
Optional |
The system calls algorithms of this type upon each successful state transition of a business object as well as when it is first created. These are typically used to record the transition on the maintenance object's log. Note that some base maintenance objects are already shipped with an automatic logging of state transitions. In this case you may use these algorithms to override the base logging functionality with your own. Click here to see the algorithm types available for this system event. |
|
Transition Error |
Optional |
The system calls this type of algorithm when a state transition fails and the business object should be saved in its latest successful state. The algorithm is responsible for logging the transition error somewhere, typically on the maintenance object's log. Notice that in this case, the caller does NOT get an error back but rather the call ends successfully and the exception is recorded somewhere, as per the plug-in logic. The system invokes a single algorithm of this type. If more than one algorithm is plugged-in the system invokes the one with the greatest sequence number. Click here to see the algorithm types available for this system event. |
Maintenance Object - Maintenance Object Tree
You can navigate to the Maintenance Object Tree to see an overview of the tables and table relationships associated with the maintenance objects.
Description of Page
This page is dedicated to a tree that shows the maintenance object's tables as well as business objects, if you have defined any. You can use this tree to both view high-level information about these objects and to transfer to the respective page in which an object is maintained.
The topics in this section describe the transaction that can be used to maintain database processes used to perform Archive Engine operations such as archive and purge and ConfigLab operations like compare.
Contents
Database Process - DB Process Tree
Database Process - Main
Select Admin Menu, DB Processto set up database processes used with ConfigLab and Archive Engine.
Important! There are many sample database processes provided in the demonstration database. For information on how to copy a database process from the demonstration database, refer to How To Copy Samples From The Demonstration Database.
Use DB Process to specify the name of the database process.
Description and Long Description contain descriptions of the database process.
Use Status to specify if the database process is Active or Inactive.
Use DB Process Type to specify if the DB process is used for Archive, Compare, or Purge.
Use Batch Control to specify the batch control associated with the DB process.
The grid at the bottom shows all of the DB process instructions for the DB process. Note that each DB process instruction is linked to a maintenance object.
To the left of the Seq column information about the instruction is displayed as hypertext. Clicking on the hypertext brings you to the DB instruction. The following grid describes the text that may appear:
|
Text |
When Text Appears |
|
Rule(s) & Algorithm(s) |
Displays when the instruction has at least one rule and at least one algorithm. |
|
Rule(s) |
Displays when the instruction has at least one rule and no algorithms. |
|
Algorithm(s) |
Displays when the instruction has at least one algorithm and no rules. |
|
Instruction |
Displays when the instruction has no rules or algorithms. |
The following fields display for each instruction.
Seq A unique identifier for the DB process instruction under the DB process.
Description Enter a description of the DB process instruction.
Maintenance Object Specify the maintenance object associated with the DB process instruction.
Role Either Primary or Child. If Child is specified, specify parent process sequence and a linkage constraint referring to a table defined on the parent instruction's maintenance object.
Parent Seq Specify the process sequence of the parent DB process instruction on which the DB process instruction is dependent.
Linkage Constraint ID Specify how maintenance objects of the DB process instruction and its parent are linked. This is a constraint on a table defined under the DB process instruction's maintenance object. This constraint references a table defined under the maintenance object that belongs to the DB process instruction specified by parent process sequence.
Database Process - DB Process Tree
You can navigate to the DB Process Tree to see an overview of the database process, associated maintenance objects, and instruction algorithms.
Description of Page
This page is dedicated to a tree that shows the DB process instructions and instruction algorithms associated with the database process. You can use this tree to both view high-level information about these objects and to transfer to the respective page in which an object is maintained.
Defining Database Process Instruction Options
A DB process instruction represents a single maintenance object as part of a DB process.
Contents
Database Process Instruction - Main
Database Process Instruction - DB Process Instruction Tree
Database Process Instruction - Main
Select Admin Menu, DB Instruction to define DB process instructions for a given DB process.
Description of Page
DB Process Instruction contains a concatenation of basic information about the DB Process instruction. This information only appears after the DB process instruction has been added to the database. The adjacent up and down arrows cause the DB process instruction immediately before or after this DB process instruction to be displayed.
DB Process specifies the name of the database process to which this DB process instruction belongs.
Click View SQL to display the resulting select statement used as the basis for building root objects or archive root objects when the DB process is executed.
Process Sequence is a unique identifier for the DB process instruction under the DB process.
Enter a Description of the DB process instruction.
Skipping an Instruction. If you would like a DB process to skip a DB process instruction during a given batch run, you can temporarily add two forward slashes (“//”) to the description of the DB process instruction. For example, imagine you have defined a Copy Account DB Process that includes instructions to copy credit and collection information. Perhaps you would like to copy a set of accounts, but you do not need the C&C information. Rather than creating another DB process that does not include these instructions, you could add “//” to the instructions you want to skip during this batch run.
Maintenance Object specifies the maintenance object associated with the DB process instruction.
Instruction Role identifies the DB process instruction as Primary or Child. If Child is specified, specify parent process sequence and a linkage constraint referring to a table defined on the parent instruction's maintenance object.
Parent Seq is the process sequence of the parent DB process instruction on which the DB process instruction is dependent.
Linkage Constraint ID specifies how maintenance objects of the DB process instruction and its parent are linked. This is a constraint on a table defined under the DB process instruction's maintenance object. This constraint references a table defined under the maintenance object that belongs to the DB process instruction specified by parent process sequence. The Constraint Owner indicates whether the constraint is Base Product or a Customer Modification.
The Instruction Algorithms grid shows the algorithms associated with the DB process instruction. These algorithms are used as criteria for root object exclusion when a DB process is executed, or they may execute special processing required to maintain normal system operation after the DB process has been executed.
· Specify the order in which DB process instructions algorithms are executed by entering a Sequence number.
· Specify the algorithm's System Event (see the following table for a description of all possible events).
· Specify an Algorithm used to perform operations associated with the DB process instruction.
The following table describes each System Event.
|
System Event |
Description |
|
Apply Changes Processing |
Click here to see the algorithm types available for this system event. |
|
Archive Copy Data |
For information about this system event refer to Archiving Data to Flat Files. Click here to see the algorithm types available for this system event. |
|
Archive Criteria |
For information about this system event refer to Criteria Algorithms Exclude Records. Click here to see the algorithm types available for this system event. |
|
Archive Processing |
For information about this system event refer to Processing Algorithms Perform Extra Processing. Click here to see the algorithm types available for this system event. |
|
Compare Criteria |
For information about this system event refer to Criteria Algorithms Also Define Which Objects To Compare. Click here to see the algorithm types available for this system event. |
|
Purge Criteria |
For information about this system event refer to Criteria Algorithms Exclude Records. Click here to see the algorithm types available for this system event. |
|
Purge Processing |
For information about this system event refer to Processing Algorithms Perform Extra Processing. Click here to see the algorithm types available for this system event. |
|
Sync Criteria |
For information about this system event refer to Criteria Algorithms Also Define Which Objects To Compare. Click here to see the algorithm types available for this system event. |
|
Sync Processing |
Click here to see the algorithm types available for this system event. |
The Table Rules grid shows the table rules associated with the DB process instruction. Similar to criteria algorithms specified above, table rules can exclude a subset of records from being processed when the DB process is executed.
Table Specify the table within the maintenance object hierarchy. Generally, this is the Primary table of the maintenance object associated with a Primary DB process instruction. When selecting records from tables during a DB process, it is assumed that all child records within the hierarchy are selected. Specifying a table rule for a child table is unusual.
Override Condition The condition specified is incorporated into the WHERE clause of the dynamic SQL used to create root objects.
Override Condition Syntax. When specifying an override condition, you must prefix all table names with a pound (#) sign. For example, if a DB process' purpose was to archive bills, and you wanted to exclude the bills for account 3728474536 from being archived, you would specify CI_BILL as the table in the table rule, and the override condition would be #CI_BILL.ACCT_ID <> '3728474536'. Note that you do not include the word "WHERE" in the override condition text. Note also that SQL syntax for Oracle and DB2 may differ, and that DB2 is stricter with regard to data type comparisons than Oracle. You may alias table names in table rules that make use of sub-queries, but avoid prefixing aliases with "CHD" or "PRT" as they may conflict with internal aliases.
Warning! Use table rules sparingly. Since table rules are incorporated into the WHERE clause when selecting records during DB process execution, override conditions that are not based on indexes can cause inefficient data access.
Database Process Instruction - DB Process Instruction Tree
You can navigate to the DB Process Instruction Tree to see an overview of the database process instruction, associated maintenance objects, instruction algorithms for the current DB process instruction and recursive child DB process instructions.
Description of Page
This page is dedicated to a tree that shows the database process instruction, associated maintenance objects, instruction algorithms for the current DB process instruction and recursive child DB process instructions. You can use this tree to both view high-level information about these objects and to transfer to the respective page in which an object is maintained.
Some special fields have values that are defined by the base-package development group. For example:
· The navigation option usage field has potential values of Favorites, Go To and Menu. On the database, these values are represented by the values of FAV, GOTO and MENU, respectively.
· The access mode (used by application security) defines the actions that are available on various application services, for example Add, Change, Delete, Complete and Cancel. On the database, these values are represented by the values of A, C, D, CO, and CA respectively
We call these types of fields “lookup fields” (because we have to “look up” the descriptions on the “look up” table when they are displayed on a transaction).
The two examples described above represent the two different types of lookup fields.
· The first example (navigation option usage) is a lookup field where you cannot add, remove or change the valid values.
· The second example (access mode) is a lookup field where you are allowed to add valid values.
We differentiate between these two types of lookups because the first type of lookup field (e.g., navigation usage option) controls logic in the system and if you change the valid values, the system will not work and if you add valid values, they will not be used by any system logic. For the second type of lookup field (e.g., access mode), your implementation may define additional values to be used by your customer modifications.
Important! If you introduce new lookup values, you must prefix the lookup value code with X or Y. If you do not do this, there is a possibility that a future release of the application could introduce a new lookup value with the name you allocated.
Lookup - Main
Select Admin Menu, Look Up to maintain lookup values.
Description of Page
Field Name is the name of the field whose lookup values are maintained in the grid. If you need to add a new lookup field, you must first add a Field with an extended data type of Flag.
Owner indicates if this lookup field is owned by the base package or by your implementation (Customer Modification). This information is display-only.
Custom switch is used to indicate whether you are allowed to add valid values for a lookup field whose owner is not Customer Modification.
· If this switch is turned on, you may add new values to the grid for system owned lookup fields.
· If this switch is turned off, you may not add, remove or change any of the values for system owned lookup fields, with the exception of the override description.
This field is always protected for system owned lookup fields because you may not change a field from customizable to non-customizable (or vice versa).
Java Field Name indicates the name of the field as it is referenced in Java code.
The grid contains the look up values for a specific field. The following fields may be modified:
Field Value This is the unique identifier of the lookup value. If you add a new value, it must begin with an X or Y (in order to allow future upgrades to differentiate between your implementation-specific values and base-package values).
Description This is the name of the lookup value that appears on the various transactions in the system
Java Value Name This indicates the unique identifier of the lookup value as it is referenced in Java code.
Status This indicates if the value is Active or Inactive. The system does not allow Inactive values to be used (the reason we allow Inactive values is to support historical data that references a value that is no longer valid).
Detailed Description A detailed description for a lookup value is provided in certain cases.
Override Description Enter a value in this field if your implementation wishes to override the description of the value provided by the product.
Note. If you wish the override descriptions of your lookup values to appear in the application viewer, you must regenerate the data dictionary application viewer background process.
Owner Indicates if this lookup value is owned by the base package or by your implementation (Customer Modification). The system sets the owner to Customer Modification when you add lookup values to a field. This information is display-only.
The topics in this section describe auditing, enabling auditing for fields, and auditing queries that you can use to view audit records.
Contents
Captured Information
When auditing is enabled for a field, the following information is recorded when the field is changed, added and/or deleted (depending on the actions that you are auditing for that field):
· User ID
· Date and time
· Table name
· Row’s prime key value
· Field name
· Before image (blank when a row is added)
· After image (blank when a row is deleted)
· Row action (add, change, delete)
How Auditing Works
You enable auditing on a table in the table’s meta-data by specifying the name of the table in which to insert the audit information (the audit table) and the name of the program responsible for inserting the data (the audit trail insert program). Then you define the fields you want to audit by turning on each field's audit switch in the table’s field meta-data. You can audit fields for delete, insert and update actions.
Once auditing is enabled for fields in a table, the respective row maintenance program for the table assembles the list of changed fields and calls the audit trail insert program (CIPZADTA is supplied with the base package). If any of the changed fields are marked for audit, CIPZADTA inserts audit rows into the audit table (CI_AUDIT is the audit table supplied with the base package).
Customizing Audit Information. You may want to maintain audit information other than what is described in Captured Information or you may want to maintain it in a different format. For example, you may want to maintain audit information for an entire row instead of a field. If so, your implementation team can use CIPZADTA and CI_AUDIT as examples when creating your own audit trail insert program and audit table structures.
The Audit Trail File
Audit log records are inserted in the audit tables you define. The base product contains a single such table (called CI_AUDIT). However, the audit insert program (CIPZADTA) is designed to allow you to use multiple audit tables.
If you want to segregate audit information into multiple tables, you must create these tables. Use the following guidelines when creating new audit tables (that use the CIPZADTA audit insert program):
· The new audit tables must look identical to the base table (CI_AUDIT).
· The new tables must be prefixed with CM (e.g., CM_AUDIT_A, CM_AUDIT_B, etc.).
· The name of the new table must be referenced on the various tables whose changes should be logged in the new table.
Interesting fact. It’s important to note if you use your own tables (as opposed to using the base package table called CI_AUDIT), the SQL used to insert and access audit trail records (in CIPZADTA) is dynamic. Otherwise, if the base package’s table is used, the SQL is static.
How To Enable Auditing
Enabling audits is a two-step process:
· First, you must turn on auditing for a table by specifying an audit table and an audit trail insert program.
· Second, you must specify the fields and actions to be audited for the table.
The following topics describe this process.
Contents
Specify The Fields and Actions To Be Audited
Turn On Auditing For a Table
In order to tell the system which fields to audit, you must know the name of the table on which the field is located. You must specify the audit table and the audit trail insert program for a table in the table’s meta-data.
Most of the system’s table names are fairly intuitive. For example, the user table is called SC_USER, the navigation option table is called CI_NAV_OPT, etc. If you cannot find the table using the search facility on the Table Maintenance page, try using the Data Dictionary. If you still cannot find the name of the table, please contact customer support.
To enable auditing for a table:
· Navigate to the Table maintenance page and find the table associated with the field(s) for which you want to capture audit information.
· Specify the name of the Audit Table.
Specifying the Audit Table. You can use the audit table that comes supplied with the base package (CI_AUDIT) to audit multiple tables and fields. All the audit logs are combined in a single table (CI_AUDIT). However, you can also have a separate audit table for each audited table. Refer to The Audit Trail File for more information.
· Specify the name of the Audit Program (CIPZADTA is the default audit program supplied with the base package).
Warning! By default, none of a table’s fields are marked for audit. Even though you have enabled auditing for a table, you must still specify the fields and actions on those fields to be audited (see below).
Specify The Fields and Actions To Be Audited
The system only audits actions (insert, update and delete) made to fields that you want audited.
To specify the fields and actions to be audited:
· Navigate to the Table - Table Field maintenance page for a table on which you have enabled auditing.
· For each field you want to audit, specify the actions you want to audit by turning on the Audit Delete, Audit Insert and Audit Update switches as appropriate.
Note. You can also turn on the audit switches using the Field grid at the bottom of the Table maintenance page.
Audit Program Caching! The audit program from the table meta-data is read into a program cache on the application server whenever the date changes or when the server starts. If you implement new auditing on a table, your audit trail does not become effective until this program cache is reloaded. In other words, new audits on tables where the audit program was not previously specified do not become effective until the next day (or the next restart of the application server). However, if you change the fields to be audited for a table where the audit program is already in the cache, your changes are effective immediately.
Audit Queries
There are two queries that can be used to access the audit information.
Contents
Audit Query by Table / Field / Key
Audit Query by User
This transaction is used to view changes made by a user that are stored on a given Audit Trail File.
Warning! The system only audits changes that you’ve told it to audit. Refer to The Big Picture Of Audit Trails for more information.
Navigate to this page by selecting Admin Menu, Audit Query By User.
Description of Page
To use this transaction:
· Enter the User ID of the user whose changes you wish to view.
· Enter the name of the table on which the audit trail information is stored in Audit Table. Refer to The Audit Trail File for more information about this field.
Default Note. If only one audit table is used to store audit trail information, that table is defaulted.
· Specify a date and time range in Created between to restrict the records that result from the query.
Default Note. The current date is defaulted.
· Click the search button to display all changes recorded on a specific audit table associated with a given user.
Information on this query is initially displayed in reverse chronological order.
The following information is displayed in the grid:
· Row Creation Date is the date and time that the change was made.
· Audited Table Name contains the name of the table whose contents were changed.
· Primary Key is the prime key of the row in the Audited Table whose contents where changed.
· Audited Field Name is the name of the field that was changed.
· Audit Action indicates whether the row action was Add, Change or Delete.
· Field Value Before Update contains the content of the field before the change. This column is blank if information was Added.
· Field Value After Update contains the content of the field after the change. This column is blank if information was Deleted.
Audit Query by Table / Field / Key
This transaction is used to view audited changes made to a given table.
Warning! The system only audits changes that you’ve told it to audit. Refer to The Big Picture Of Audit Trails for more information.
Most of the system’s table names are fairly intuitive. For example, the user table is called SC_USER, the navigation option table is called CI_NAV_OPT, etc. If you cannot find the table using the search facility on the Table Maintenance page, try using the Data Dictionary. If you still cannot find the name of the table, please contact customer support.
This transaction can be used in several different ways:
· You can view all audited changes to a table. To do this, enter the Audited Table Name and leave the other input fields blank.
· You can view all audited changes to a given row in a table (e.g., all changes made to a given user). To do this, enter the Audited Table Name and row’s prime key (the row’s prime key is entered in the field(s) beneath Audited Field Name).
· You can view all audited changes to a given field in a table (e.g., all changes made to all customers’ rates). To do this, enter the Audited Table Name and the Audited Field Name.
· You can view all audited changes to a given field on a specific row. To do this, enter the Audited Table Name, the Audited Field Name, and row’s prime key (the row’s prime key is entered in the field(s) beneath Audited Field Name).
Navigate to this page by selecting Admin Menu, Audit Query By Table/Field/Key.
Description of Page
To use this transaction:
· Enter the name of the table whose changes you wish to view in Audited Table Name.
· If you wish to restrict the audit trail to changes made to a specific field, enter the Audited Field Name.
· If you wish to restrict the audit trail to changes made to a given row, enter the row’s prime key (the row’s prime key is entered in the field(s) beneath Audited Field Name). These fields are dynamic based on the Audited Table Name.
· Specify a date and time range in Created between to restrict the records that result from the query.
Default Note. The current date is defaulted.
· Click the search button to display all changes made to this data.
Information on this query is initially displayed in reverse chronological order by field.
The following information is displayed in the grid:
· Create Date/Time is the date / time that the change was made.
· User Name is the name of the person who changed the information.
· Primary Key is the prime key of the row in the Audited Table whose contents where changed.
· Audited Field Name is the name of the field that was changed.
· Audit Action indicates whether the row action was Add, Change or Delete.
· Value Before Update contains the content of the field before the change. This column is blank if information was Added.
· Value After Update contains the content of the field after the change. This column is blank if information was Deleted.
The topics in this section describe the bundling features in the application.
Contents
About Bundling
Bundling is the process of grouping entities for export or import from one environment to another.
For example, you might export a set of business objects and service scripts from a development environment and import them into a QA environment for testing. The group of entities is referred to as a bundle. You create export bundles in the source environment; you create import bundles in the target environment.
Working with bundles involves the following tasks:
· Configuring entities for bundling if they are not preconfigured
· Creating an export bundle, which contains a list of entities to be exported from the source environment
· Creating an import bundle to import those entities to the target environment
· Applying the import bundle, which adds or updates the bundled entities to the target environment
Contents
Sequencing of Objects in a Bundle
Owner Flags on Bundled Entities
Sequencing of Objects in a Bundle
Bundle entities are added or updated to the target environment in the sequence defined in the bundle
Typically, the sequence of entities does not matter. However, sequence is important in the following situations:
· Entities that are referenced as foreign keys should be at the top of the sequence, before the entities that reference them. Specify zones last, as they typically contain numerous foreign key references.
· When importing a business object, specify the business object first, then its plug-in scripts, then the algorithms that reference the scripts, and then the algorithm types that reference the algorithms.
· When importing a portal and its zones, specify the portal first and then its zones.
· When importing a multi-query zone, specify the referenced zones first and then the multi-query zone.
· Always specify algorithms types before algorithms.
You can specify the sequence when you define the export bundle or when you import the bundle to the target environment.
Recursive Key References
Recursive foreign keys result when one object has a foreign key reference to another object that in turn has a foreign key reference to the first object.
For example, a zone has foreign keys to its portals, which have foreign keys to their zones. If the objects you want to bundle have recursive relationships, you must create a 'bundling add' business object that has only the minimal number of elements needed to add the entity. A bundling add business object for a zone contains only the zone code and description, with no references to its portals. In the same way, a bundling add business object for a portal defines only its code and description.
When you apply the bundle, the system initially adds the maintenance object based on the elements defined in the bundling add business object. Before committing the bundle, the system updates the maintenance object with the complete set of elements based on its physical business object.
Owner Flags on Bundled Entities
The owner flag of the entities in an import bundle must match the owner flag of the target environment.
If you need to import objects that your source environment does not own, you must replace the owner flag in the import bundle with the owner flag of the target environment.
Configuring MOs for Bundling
All base package meta-data objects are pre-configured to support bundling. All other objects must be manually configured.
To configure other objects for bundling, review the configuration tasks below and complete all those that apply:
|
Complete this configuration task... |
for... |
|
Make maintenance objects eligible for bundling |
All objects to be included in the bundle |
|
Add a foreign key reference |
All objects to be included in the bundle |
|
Create a physical business object |
All objects to be included in the bundle |
|
Create a bundling add business object |
Objects with recursive foreign key references |
|
Add the Current Bundle zone |
All objects, if you want the Current Bundle zone to appear on the maintenance object's dashboard. This is not required by the bundling process. |
|
Create a custom Entity Search zone and add it to the Bundle Export portal |
All objects, if you want them to be searchable in the Bundle Export portal. This is not required by the bundling process. |
Contents
Making Maintenance Objects Eligible for Bundling
Adding a Foreign Key Reference
Creating a Physical Business Object
Creating a Bundling Add Business Object
Adding the Current Bundle Zone
Adding a Customized Entity Search Query Zone to the Bundle Export Portal
Making Maintenance Objects Eligible for Bundling
The "Eligible For Bundling" maintenance object option must be set to "Y" for all bundled objects. To make maintenance objects eligible for bundling:
· Select Admin Menu > Maintenance Object and search for the maintenance object.
· On the Options tab, add a new option with the type Eligible For Bundling.
· Set the value to "Y" and click Save.
Adding a Foreign Key Reference
Each maintenance object in a bundle must have a foreign key reference. Bundling zones use the foreign key reference to display the standard information string for the maintenance object.
To add a foreign key reference to the maintenance object:
· Select Admin Menu > FK Reference+ and set up a foreign key reference for the primary table of the maintenance object.
· Select Admin Menu > Maintenance Object and search for the maintenance object.
· On the Option tab, add a new option with the type Foreign Key Reference. The value is the name of the foreign key reference you just created.
Creating a Physical Business Object
Each maintenance object in a bundle must have a physical business object. The physical business object's schema represents the complete physical structure of the maintenance object, and includes elements for all fields in the maintenance object's tables. The bundling process uses this schema to generate the XML for the import bundle.
To create a physical business object for the maintenance object:
· Select Admin Menu > Business Object + and specify the maintenance object.
· Click Generate in the BO Schema dashboard zone to generate a schema that looks like the physical structure of the maintenance object.
· Save the physical business object.
· Select Admin Menu > Maintenance Object and search for the maintenance object.
· On the Option tab, add a new option with the type Physical Business Object. The value is the name of the physical business you just created.
Creating a Bundling Add Business Object
If the objects to be bundled have recursive foreign key references, you must create a bundling add business object to avoid problems with referential integrity.
To create a bundling add business object:
· Select Admin Menu > Business Object + and specify the maintenance object.
· Click Generate in the BO Schema dashboard zone to generate a schema that looks like the physical structure of the maintenance object.
· Remove all elements that are not essential. Typically, only a code and description are required.
· Save the physical business object.
· Select Admin Menu > Maintenance Object and search for the maintenance object you want to bundle.
· On the Option tab, add a new option with the type Bundling Add BO. The value is the name of the bundling add business object you just created.
Adding the Current Bundle Zone
If you want the Current Bundle zone to appear on the maintenance object's dashboard, you must add the Current Bundle zone as a context-sensitive zone for the maintenance object. To add the Current Bundle zone to the maintenance object:
· Select Admin Menu > Context Sensitive Zone and search for the navigation key for the maintenance object.
· Add the Current Bundle zone, F1-BNDLCTXT, to that navigation key.
Adding a Customized Entity Search Query Zone to the Bundle Export Portal
If you want the maintenance object to be searchable in the Bundle Export portal, you must first create an entity-specific query zone to search for the maintenance object. Then you must create a customized entity search zone that references this new query zone. Finally, you must add the customized entity search zone to the Bundle Export portal.
To make the maintenance object searchable:
· Create an entity-specific query zone to search for the maintenance object:
· Select Admin Menu > Zone and search for one of the base query zones, such as the Algorithm Search zone, F1-BNALGS.
· Click the Duplicate button in the action bar.
· Enter a name for the new zone.
· Click Save.
· Locate the User Filter parameter in the parameter list. Add SQL to search for the maintenance object(s) you want to appear in the zone.
· Save the query zone.
· Create a customized entity search zone:
Note: This step only needs to be done once. If you already have a customized search zone in the Bundle Export portal go to step 3.
· Select Admin Menu > Zone and search for the F1-BNDLENTQ Entity Search zone.
· Duplicate this zone (as described above).
· Remove any references to base query zones.
· Add the new entity-specific query zone to the customized entity search zone:
· Locate the customized entity search zone for your Bundle Export portal. This is the zone created in Step 2.
· Locate the Query Zone parameter in the parameter list. Add the name of the query zone you created in Step 1.
· Save the entity search zone.
· Add the customized entity search zone to the Bundle Export portal:
Note: This step needs to be done only once.
· Select Admin Menu > Portal and search for the Bundle Export portal, F1BNDLEM.
· In the zone list, add the entity search zone you created in Step 2. (Add the new zone after the base entity search zone).
· Save the portal.
WorkingwithBundles
Use the Bundle Export portal to create an export bundle. The export bundle contains a list of entities to be exported from the source environment. When you are ready to import the objects, use the Bundle Import portal to import the objects to the target environment.
Contents
Creating and Applying Import Bundles
Creating Export Bundles
An export bundle contains a list of entities that can be imported into another environment. To create an export bundle:
· Log on to the source environment from which objects will be exported.
· Select Admin Menu > Bundle Export+.
· Complete the fields in the Main section to define the bundle's basic properties.
Note: You can use the Entities section to add bundle entities now, or save the bundle and then add entities as described in step 5.
· Click Save to exit the Edit dialog. The export bundle status is set to Pending.
· While an export bundle is in Pending state, use any of the following methods to add entities to the bundle:
· Use the Entity Search zone on the Bundle Export portal to search for entities and add them to the bundle. If an entity is already in the bundle, you can remove it.
· To import entities from a .CSV file, click Edit on the Bundle Export portal, and then click CSV File to Upload. Specify the file name and location of the .CSV file containing the list of entities. Click Submit to upload the file, and then click Save to save the changes.
· Use the Current Bundle zone in the dashboard of the entity you want to add. (All entities that are configured to support bundling display a Current Bundle zone). This zone displays a list of all pending export bundles to which you can add the entity.
· When you check an entity into revision control, specify the export bundle on the Revision Info dialog.
· When you have added all entities, click Bundle in the Bundle Actions zone on the Bundle Export portal. The export bundle state is set to Bundled and the Bundle Details zone displays the XML representation of every entity in the bundle.
Note: The owner flags of the entities in the bundle must match the owner flag of the bundle itself. If the owner flags do not match, the system displays a warning message. Click OK to continue or Cancel to abort the bundle. If you click OK, you will need to resolve the owner flag discrepancy before you import the bundle to the target environment.
· Copy the XML from the Bundle Detail zone to the clipboard (or to a text file). You can now create an import bundle and apply it to the target environment.
Note: If you need to make additional changes to the bundle, you must change the bundle state by selecting the Back to Pending button in the Bundle Actions zone.
Creating and Applying Import Bundles
Import bundles define a group of entities to be added or updated in the target environment.
Before you create an import bundle, you must have already created an export bundle, added entities, and set the bundle's state to Bundled.
To create an import bundle and apply it to the target environment:
· If you have not already copied the XML from the export bundle, do so now:
· Select Admin Menu > Bundle Export and search for the bundle.
· Copy the XML from the Bundle Detail zone to the clipboard (or to a text file).
· Log on to the target environment.
· Select Admin Menu > Bundle Import+.
· In the Bundle Actions zone, click Edit XML.
· Paste the contents of the clipboard (or text file if you created one) into the Bundle Detail zone.
· Make any necessary changes to the XML and click Save. The status of the import bundle is set to Pending.
Note: Use caution when editing the XML to avoid validation errors.
· To remove entities from the import bundle or change their sequence, click Edit. Enter your changes and click Save to exit the Edit dialog.
· When you are ready to apply the bundle, click Apply. The import bundle state is set to Applied and the entities are added or updated in the target environment.
Editing Export Bundles
You can add or remove entities from an export bundle when it is in Pending state. You can also change the sequence of entities.
To edit to an export bundle that has already been bundled, you must change the bundle state by selecting the Back to Pending button on the Bundle Export portal.
To edit a pending export bundle:
· Open the bundle in edit mode.
· Click Edit on the Export Bundle portal.
· Make any necessary changes on the edit dialog and then click Save.
Editing Import Bundles
You can remove entities from an import when it is in Pending state. You can also change the sequence of entities and edit the generated XML.
To edit a pending import bundle:
· Open the bundle in edit mode.
· To edit the XML snapshot, click Edit XML. Edit the XML code as needed, then click Save.
Note: Use caution when editing the XML to avoid validation errors.
· To remove entities or change their sequence, click Edit. Make any necessary changes and click Save.
The topics in this section describe the revision control features in the application.
Contents
About Revision Control
Revision control creates a history of a maintenance object as devel make changes to it. It is intended to be used for configuration tool objects during the development phase of an implementation.
If revision control is enabled for an object you must check out the object to change it. While the object is checked out no one else can work on it. You can revert all changes made since checking out an object, reinstate an older version of an object, recover a deleted object, and force a check in of an object if someone else has it checked out.
Note: Revision control does not keep your work separate from the environment. Because the metadata for maintenance objects is in the central database, any changes you make to an object while it is checked out will be visible to others and may impact their work.
Many of the maintenance objects used as configuration tools are already configured for revision control, but it is turned off by default. For example, business objects, algorithms, data areas, UI maps, and scripts are pre-configured for revision control.
Contents
Configuring Maintenance Objects for Revision Control
Turning On Revision Control
Revision control is turned off by default for maintenance objects that are configured for revision control.
To turn on revision control:
· Add the base package Checked Out zone to the Dashboard portal.
· Select Admin Menu > Portal.
· Search for the portal CI_DASHBOARD.
· In the zone list for the Dashboard portal, add the zone F1-USRCHKOUT.
· Set up application security.
For users to have access to revision control, they must belong to a user group that has access to the application service F1-OBJREVBOAS.
· Add the revision control algorithm to the maintenance object that you want to have revision control.
This step must be repeated for each maintenance object that you want to have revision control.
· Select Admin Menu > Maintenance Object and search for the maintenance object that you want to have revision control.
· On the Algorithms tab of the maintenance object, add the revision control algorithm F1-REVCTL.
Configuring Maintenance Objects for Revision Control
Most configuration tool maintenance objects are pre-configured for revision control. You can configure other maintenance objects for revision control, as well.
To configure other objects for revision control:
· Create a physical business object for the maintenance object.
A physical business object is one that has a schema with elements for all of the fields for the tables in the maintenance object. Follow these steps to create a physical business object:
· Select Admin Menu > Business Object + and specify the maintenance object.
· Use the BO Schema dashboard zone to generate a schema that looks like the physical structure of the maintenance object.
· Save the physical business object.
· Select Admin Menu > Maintenance Object and search for the maintenance object for which you want to enable revision control.
· On the Options tab of the maintenance object add a new option with the type Physical Business Object. The value is the name of the physical business object that you just created.
· Add a foreign key reference to the maintenance object.
The revision control zones will display the standard information string for the object based on the foreign key reference. Follow these steps to create a foreign key reference:
· Select Admin Menu > FK Reference+ and set up a foreign key reference for the primary table of the maintenance object.
· Select Admin Menu > Maintenance Object and search for the maintenance object.
· On the Options tab of the maintenance object, add a new option with the type Foreign Key Reference. The value is the name of the foreign key reference that you just created.
· Add the Revision Control zone to the maintenance object.
· Select Admin Menu > Context Sensitive Zone and search for the navigation key for the maintenance object.
· Add the Revision Control zone, F1-OBJREVCTL, to that navigation key.
· Add the revision control algorithm to the maintenance object.
· Select Admin Menu > Maintenance Object and search for the maintenance object that you want to have revision control.
· On the Algorithms tab of the maintenance object, add the revision control algorithm F1-REVCTL.
Working with Revision Control
You use two zones in the dashboard to work with revision controlled objects when revision control is turned on.
The Revision Control zone gives you several options for managing the revision of the currently displayed object. This zone also shows when the object was last revised and by whom. This information is linked to the Revision History portal which lists all of the versions of the object.
Using the Revision Control zone you can:
· Check out an object in order to change it.
· Check in an object so others will be able to work on it.
· Revert the object back to where it was at the last checkout.
· Force a check in of an object that is checked out by someone else. You need special access rights to force a check in.
· Delete an object.
The Checked Out zone lists all of the objects that you currently have checked out. Clicking on an object listed in this zone will take you to the page for that object. The zone is collapsed if you have no objects checked out.
Contents
Checking Out an Object
You must check out a revision controlled object in order to change it.
An object must have revision control turned on before you can check it out.
Note: When you first create or update an object a dialog box informs you that the object is under revision control. You can select OK to check out the object and save your changes, or Cancel to stop the update.
· Go to the object that you want to work on.
· Select Check Out in the Revision Control dashboard zone.
Checking In an Object
You must check in a revision controlled object in order to create a new version of it. Checking in an object also allows others to check it out.
· Select a link in the Checked Out dashboard zone to go to the object that you want to check in.
· Select Check In in the Revision Control dashboard zone.
· Provide details about the version:
· In the External References field state the bug number, enhancement number, or a reason for the revision.
· In the Detailed Description field provide additional details regarding the revision.
· In the Keep Checked Out box specify if you want to keep the object checked out. If you keep the object checked out then your revision is a new version that you can restore later.
· In the Add To Bundle box specify if the object belongs to a bundle.
· Select OK to check in the object.
Reverting Changes
Reverting changes will undo any changes you made since you checked out an object.
To revert changes:
· Go to the object that you want to revert.
· Select Revert in the Revision Control dashboard zone.
· In the confirmation dialog box select OK to confirm the action or Cancel to return to the object page.
Once reverted, the object can be checked out by another user.
Forcing a Check In or Restore
You can force a check in if an object is checked out by another user and that person is not available to check it in. You must have proper access rights to force a check in or restore.
To force a check in or restore:
· Go to the object that is checked out by another user.
· Select Force Check In or Force Restore in the Revision Control zone.
The Force Check In option is the same as a regular check in. The Force Restore option checks in the object and restores it to the previously checked in version.
Deleting an Object
If revision control is turned on for an object, you must use the Revision Control zone to delete it. The object must be checked in before it can be deleted.
To delete a revision controlled object:
· Go to the object that you want to delete.
· Select Delete in the Revision Control zone.
· Provide details regarding the deletion.
· Select OK to delete the object.
The system creates a revision record before the object is deleted so that the deleted object can be restored.
Restoring an Object
You can restore an older version of either a current object or a deleted object. An object must be checked in before an older version can be restored.
To restore an object:
· Go to the Revision History portal for the object.
If the object was deleted you must search for it by going to Admin Menu > Revision History Search.
· Locate the row in the version history that has the version that you want to restore and click Restore.
· In the confirmation dialog box select OK to confirm the action or Cancel to return to the object page.
Working with Revision History
The Revision History portal lists information about each version of a revision controlled object.
You can navigate to the Revision History portal from either a link in the Revision Control dashboard zone or by going to the Revision History Search portal on the Admin Menu. If you want to find the Revision History for a deleted object, you must search for the object using the Revision History Search portal.
You can restore a previous version of the object by clicking Restore in the row for the version that you want to restore.
You can see the details of each version by clicking the broadcast icon for that version.
Searching for Revision History
You can use the Revision History Search portal to find the revision records for an object.
To search for a revision record:
· Select Admin Menu > Revision History Search to access the search portal.
· Provide search criteria in the Revision History Search zone and click Refresh.
· In the list of search results, select the link in the Details column to go to the Revision History for that object.