| Oracle® Retail Merchandising System Custom Flex Attribute Solution Implementation Guide Release 14.1 E55111-01 |
|
 Previous |
 Next |
| Oracle® Retail Merchandising System Custom Flex Attribute Solution Implementation Guide Release 14.1 E55111-01 |
|
Previous |
Next |
This appendix describes the CFAS-specific database scripts. It includes the following:
Once the attributes are created using the CFAS Maintenance screens, they are not available for use immediately from the RMS base forms. Once set up, you must then run the cfagen.ksh script to create the relevant database objects for the attributes and activate them for use.
The purpose to make the attributes available only after running this script is to allow for simulation of the newly added or modified attributes without affecting other users accessing the existing CFAS user interface.
During activation, the CFAS Database Create script create the following supporting tables:
Extended Entity Extension table
Access views at the Attribute Group or Group Set level
Optional staging tables to allow data import from external sources
Once these objects are created, the ACTIVE_IND at each level of the CFAS hierarchy is set to 'Y'. Users will now be able to see these changes to the CFAS UI when accessed from the base RMS forms.
You must run this script for the following scenarios:
New CFAS enablements.
New group sets or groups for the extended entity.
New attributes created within the group.
Modified attributes that affect the object, that includes (but not limited to) the VIEW name or VIEW_COL_NAME changes, data type changes, and so on.
|
Note: The CFAS Maintenance screens only support modification of a few attribute properties. Modifications to the database definitions of the attribute (the view column or the view including mappings to the extension table) are not supported and not recommended.In case you want to make such changes, see Modifying Attributes. |
Since this script builds or recreates CFAS-related database objects, it is recommended that this script be run by users who own the database schema.
Syntax
cfagen.ksh <connect> <Level E for entity or G for group set> <Entity/Group Set ID> <Gen synonym Y/N> <Drop existing STG table Y/N>
Where,
<connect> – use this argument to specify the relevant user name to connect to the database.
<Level E for entity or G for group set> – the level you want to generate. Set the argument to E for entities and G for attribute group sets.
<Entity/Group Set ID> – the entity or attribute group set ID.
<Gen synonym Y/N> – use this argument to indicate whether you want to generate relevant synonyms.
<Drop existing STG table Y/N> – use this argument to indicate whether you want to drop the existing staging tables.
Although the CFAS user interface is designed for manual data input, the CFAS framework also allows for bulk loading attributes to the CFAS extension database tables using a load utility. This utility is handy when upgrading from earlier versions of RMS or adding a new attribute with data already existing the system.
The CFAS load script selects the information from the staging table defined at the group set level (CFA_ATTRIB_GROUP_SET.STAGING_TABLE_NAME) and loads the information to the CFA extension table depending on the metadata definitions. The staging table is structured the same way as the easy access view - the attribute names are spelled out instead of the extension column names. This is for the ease of data mapping.
Syntax
cfastgload.ksh <connect> <input staging table> <delete rec in staging table Y/N> [input process id]
Where,
<connect> – use this argument to specify the relevant user name/wallet to connect to the database.
<input staging table> – the relevant staging table name to load.
<delete rec in staging table Y/N> – use this argument to indicate whether you want to delete the records in the staging table.
<input process id> – use this argument to specify the relevant process ID.
The CFAS migration script enables you to migrate or promote CFAS metadata from one environment to another efficiently. You can use this script to migrate updated CFAS metadata from a test environment to a production environment in your implementation without the risk of any manual errors.
This section describes how you can use the CFAS migration script and highlights some important considerations that you must review before running the script. It includes the following topics:
To migrate or promote the CFAS metadata into the target environment, do the following:
Make the CFAS metadata or attributes changes and compile them in the source environment.
Run the CFAS migration script specifying the necessary arguments. For more information on the syntax, see Syntax. When you run the script, an output file with the level name and ID is generated. This file includes the merge statements for the metadata recorded you want to promote.
Compile the CFAS custom package specification/definition.
Run the migration output file in the target environment, and then commit the changes.
Run the CFAS Database Create script (cfagen.ksh).
Run the output file from the CFAS Database Create script.
Compile the CFAS custom package body.
cfamigrate.ksh <connect> <level> <ID>
Where,
<connect> – Use this argument to specify the relevant user name to connect to the database.
<Level> – Use this argument to indicate the CFAS metadata hierarchy level at which the changes were made. The following are the valid level values:
L for all levels. This creates a complete copy of the CFAS metadata.
E for entity level. This creates a complete copy of the metadata from entity to attribute, but no codes and record groups.
S for group set. This gets a snapshot from the group set to attribute.
G for group. This gets a snapshot from the group to attribute.
A for attribute. This gets a snapshot of the attribute only.
C for codes. This gets a snapshot of the code type and detail.
R for record group. This gets a snapshot of the record group only.
<ID> – The CFAS metadata hierarchy ID at which the changes were made. This is optional in some levels. Specify an ID based on the following:
When the migration level is L, E, C, or R, no ID is required. All the metadata will be exported.
When the migration level is S, G, or A, an ID is required. Enter a specific ID to export only that metadata. If no value is entered, all records will be exported.
|
Note: When you run the script, an output file with the level name and ID is generated. This file includes the merge statements for the metadata recorded you want to promote. |
Before you run the CFAS migration script, review the following considerations:
If the migrating metadata are not at the All level and the attribute is using a new Code Detail or Record Group, then those must be migrated first.
No delete is migrated.
I f the migrated metadata is already available in the target/destination environment, the record will be updated as if it is has been activated regardless of its current status.
Do not promote any backend update in the source environment with this tool.
Since the sequence ID for the metadata can be out of sync between environments, the migration tool relies on other means to ensure record uniqueness:
For Code Detail, code_type.
For Rec Group: rec_group_name.
For Entity: base_rms_table.
For Group Set: base_rms_table and group_set_view_name.
For Group: group_set_view_name and group_view_name.
For Attribute: group_view_name and view_col_name.
If the migrated metadata does not match any of the existing records in the target/destination environment by the above column, then it is considered as new and will be inserted into the target/destination environment.
For example, consider that an inactive metadata in the source environment was migrated to another environment. Once migrated, some of the columns were changed in the source environment. When migrated again, these columns will be considered as new record in the target/destination environment.
