5 Ongoing Maintenance

Once you set up the attributes and run the scripts to create the database entities, the flex attributes are available for viewing by all users in the system. Once these scripts are run, an indicator appears in the CFAS Maintenance screens displaying the group sets, groups, or attributes that have been activated.

This chapter describes the considerations for maintaining and upgrading the flex attributes that are in use. It includes the following sections:

Modifying Attributes
Deleting Attributes
Security Considerations
Upgrading CFAS

Modifying Attributes

Once the flex attributes are activated, the changes that you can make at the group set, group, and attribute level are minimal. After activation, only the following can be updated using the CFAS Maintenance screens:

Label - You can change the labels set at the group sets, groups, and attributes level at any time.
Display Order - You can change the display order in which the group sets, groups, and attributes appear in the menus or attributes screens after the attributes are activated.
Validation Functions - You can change the qualifier, validation and default function names at any time, but the functions will only apply to the changes made next time a user adds new attributes to an entity or updates existing attributes. Also, changes to the code inside these functions can be updated at anytime.

Additionally, you can continue to add new attributes, groups, and group sets even after an entity has had others activated. You must follow the same process of planning the attributes, adding them in the CFAS Maintenance screens, and then the last step being to run the database activation scripts.

Note:

Although changes can be made directly in the database, it is not recommended.

For reasons that require modifying an active attributes' properties or deleting the attribute, a suggested approach is outlined below:

Backup the data in backup tables using the easy access view at the group set level for each group set defined for the entity.
Using a tool like SQL Developer or SQL plus, go to the CFAS metadata table and set the attribute's ACTIVE_IND to 'N' and commit.
Ensure there is a staging table defined at the group set level. If none set the group_set's active indicator to 'N' where the attribute is linked to.
Go to the setup up screen and update the attribute's properties - change the data type, widget type etc. or click the delete button (if deleting the metadata).
When the metadata updates are done, run the cfagen.ksh script to update the objects. Make sure the view and staging tables are created properly with the updated attribute.
Truncate the CFA custom extension table linked to the base table.
Using the backup tables you created earlier, load the staging table with the corrected data. This needs to be done per group set.
Run the CFA load script for each group set/staging table to load the data back to the extension table.

Deleting Attributes

Once the attributes have been activated, they cannot be deleted at any level using the CFAS Maintenance screens. This includes entity, group set, group, and attributes.

Although you can delete attributes directly in the database, it is not recommended. To delete attributes in the database, it is recommended that you follow instructions in this guide to make the necessary changes.

Note:

You must delete attributes in a hierarchical manner. Entities cannot be deleted first. You must first start with attributes, and then proceed up the levels to entity.

Security Considerations

The CFAS screens use the same form level security as that exists in other parts of RMS. You must plan to provide access to a specific group of users who will be responsible for managing and approving the addition of CFAS attributes beyond the initial implementation. This group of users will be responsible for developing and enforcing the standards for how attributes are set up for the organization.

Users with access to the base form records will also have access to the relevant CFAS records. You can restrict the access to the CFAS records by using the qualifier function and adding security filtering.

Upgrading CFAS

The CFAS functionality is built in such a way that upgrading to future versions of RMS or applying base patches should require minimal conversion and retrofitting. At a high level, the following are the basic steps for porting CFAS to a newer version:

For the basic group sets, groups, and attributes, you must port the data that is used to build the screens over to the updated database. If there are any changes made to the structure of these tables, a small conversion may need to be done to the metadata as part of this effort.
Once this has occurred, run the cfagen.ksh batch script again to recreate the database entities in the updated database.
Then, port the data from the metadata tables to the updated database tables.
If any custom functions were created, you may need to retrofit based on the changes in the latest release. You will also need retrofit any custom changes that were made in the RMS functionality to use the flex attributes into the new code.