Target Table Definition¶
Target File Definition stores the meta data associated with an IFS views of the specified environment and extra fields are introduced to facilitate functionalities in the container tables. It holds information about Field Type, Field Length as well as, Flags for Mandatory, Keys, Input and Updatable. Also Enumeration values, which are useful in meta data validation.
Definition Extraction¶
It is possible to extract the Meta Data from the Master Target Environment to update the Target Table Definition. This is extra useful for extracting the Custom Fields, that might have been defined in the Master Environment. Same function is also used to update the Table Definition with User Defined Fields, that can be defined inside Smart Data Manager.
Column names (including custom fields), data types, data sizes, flags, references, enumeration values and default values will be extracted from the environment specified by the user at the time of target table definition creation via the target table scope. Configurations associated with client fields will be reflected in the database fields as we consider database fields for further processing not the client fields. User can manually override the flags at the end of the extraction according to his need.
During the definition extraction standard views of the IFS logical units that have APIs with New__ and Modify__ implementation methods are used (queried from a dynamic LOV created using oracle’s DBA_VIEWS) and further their custom logical unit’s views (Post fixed with CLV) are considered too. Custom fields with references are not supported by the Smart Data Manager and they are automatically set to out of scope. Custome fields will have the created by field value as Environment Name it was extracted from, user defined fields will be 'USER' and others will be 'SYSTEM'.
During the re-extraction, definition changes are identified. If the user agrees to go ahead with the changes, those changes will be reflected in the container tables. This comparison is done using a temporary table that has same structure as target table definition. If
- Only Meta Data Validation Flags (Mandatory, data type, data length, enumeration) Changed or Both Meta data and basic data validation flags changed - Update the respective meta data lines input/output/basic data container. Also mark records as ‘Not Validated’
- Only Basic Data Validation Flag Changed - Update the respective meta data lines output/basic data container. Also mark records which are basic data validated as ‘Meta Data Validated’
- Only Duplication Flag Changed - Update the unique columns in input container
For the regular fields:
View | Field Name | Field Description | Field Type | Field Size | References | Flags | Enumeration Name | Enumeration Value | Default Values |
---|---|---|---|---|---|---|---|---|---|
dba_tab_columns | X | X | X | X | |||||
dba_col_comments | X | ||||||||
Connected Standard API | X | X |
For the custom fields (Please note that custom view is used):
View | Field Name | Field Description | Field Type | Field Size | References | Flags | Enumeration Name | Enumeration Value | Default Values |
---|---|---|---|---|---|---|---|---|---|
dba_tab_columns | X | X | X | X | |||||
dba_col_comments | X | ||||||||
custom_field_attributes | X | X | X | ||||||
Connected Standard API | X |
Flag Changes¶
User will be able to select a maximum of five columns for the duplication check and will be able to specify autogenerated (key fields which are not insertable are automatically set to autogenerated at the time of definition creation), out of scope (fields identified as read only using the flags are automatically set to out of scope at the time of definition creation), basic data extraction and basic data validation flags. Custom fields with references are automatically set to out of scope. Changes in the duplication control flags and basic data validation flags will be immediately reflected in the container tables.
Flags and references are cross checked against the tables of Object References, SDT Alternative References and SDT Alternative Flags and values are overridden accordingly along with a comment in the comment field. .At the end of the extraction information associated with client fields are copied to the data base fields.
- Object References:
A new type of Reference Value called *ConObjReference(KEY_REF) will be added by the tool in the reference column. Reference Field is the field where the *CONOBJREFERENCE Code should be place as Reference (usually the LU_NAME column). Key Reference Field is the field where the Key-References are stored.
- SDM Alternative References:
There are references in the IFS logical units whose reference name is different from the actual logical unit they are referring to. Such special references in a target file along with their actual references they are referring to are specified here as it is needed in the basic data validation in the output and basic data containers. Further it is required to state whether they are considered for the basic data validation or basic data extraction.
- SDM Alternative Flags and Values:
Some fields in the IFS logical units have flag values different from their actual usage. This may be due to the facts like handling those at the API level or at the client side which cannot be grab from the logical unit level. So, those type of information should be handled in a separate manner. This will not alter standard flags in the environment and this is useful in meta data validation
These Alternative Flags and Values can be defined in different ways.
- Using an Asterix, will set the values for all Customer Projects
- Using a Template Project, will set the values for Customer Projects using this Template Project.
- Using the Customer Project will set the values only for the Customer Project itself.
Additional Fields¶
In addition to the fields defined by the system including the custom fields user is able to define fields on their own under ‘User Defined Target Fields’ (Described under Extra Configurations). These will be checked each time definition is extracted.
Apply Transformation Rules¶
This is similar to transformation rules application discussed under input container section. The only difference is when storing the values in the table attached, the source will be ‘ALL’. During the data transfer from mapping to input container these transformation rules will be prepopulated in the respective target field. This is the location to define transform rules applicable to all, despite the source.