Module 3: Table Selection Integrating Siebel Applications Training Integrating Siebel Applications Module 3: Table Selection COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Integrating Siebel Applications Training Module Objectives After completing this module you will be able to: To identify the interface (EIM) tables and columns to use to import data into and delete data from Siebel base tables and columns Document data mappings between EIM tables and Siebel base tables Why you need to know: EIM uses Interface tables to move data between Siebel and other applications COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

EIM Table Determination Data Mapping Associating Records Topics EIM Table Determination Data Mapping Associating Records Primary Records Importing Notes Creating the Field Mapping document

Analyze the Source Data Determine the Source data that needs to be imported Determine the relationships between the data Determine the Source tables and columns Table Table External entity Account Address External entity Customer Name... Attribute Contact Table External entity

Determine Destination Field Determine the Base Table and columns by looking in the Client Determine the Destination Applet Use Siebel Tools to map the applet control or list column to the Business Component Identify the Business Component Fields Identify the column that is mapped to the BC field

EIM Table Determination The EIM Interface Table report shows mapping from a single EIM table to one or more Siebel base tables EIM column (source) to base table column (destination) mapping Column attributes (user keys, foreign key tables, required fields) Ex. EIM_ACTIVITY is mapped to S_EVT_ACT, S_ACT_EMP, and other base tables Select the EIM table that best maps to the target base tables and columns Pick the EIM table that maps the most columns that you need to migrate The main base table is known as the primary target base table. Ex. S_EVT_ACT is the primary target base table for EIM_ACTIVITY. Processing on an EIM record occurs for every specified mapped base table. Processing MUST include the primary target base table. EIM performs multiple passes and steps on the EIM record to load data into every specified base table.

Determine Base Required Columns Integrating Siebel Applications Training Determine Base Required Columns Using Siebel Tools to determine required columns is not as straight-forward as referencing the documentation. It is a two-step process. EIM does not recognize non-system default columns. In Siebel Tools, you can query for the required non-system columns. Notice that even though a default is specified and implemented in the database as a database constraint, EIM preprocesses data and does not recognize the default values. Determine required base table columns that do not have defaults (EIM does not recognize non-system default values) Query Column Finding Non-System Columns An alternative method of locating required, non-system columns is to query for required columns with Type equals Data(Public). Result = required base columns Defaults not recognized by EIM COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

LOV values, for bounded LOVs EIM Validations Field size Field data type LOV values, for bounded LOVs The data in the EIM column is validated against the LOV display values. The LOV display values are those for the Language used to execute the EIM Job If the value is not valid: EIM updates the IF_ROW_STAT of the record to “PICKLIST_VALUE”. EIM fails to load any data for this record into that base table. Required fields for EIM and Base tables Uniqueness within EIM and Base tables Foreign Key relationships Parent Child Associations

Mapping Considerations Integrating Siebel Applications Training Mapping Considerations Understand how to enter organization data Fill in _BU column with name of the organization Leave _BI column blank Populated with foreign key during import processing ROOT_PARTY_FLG ROOT_PARTY_FLG is for Oracle implementations only. It was added to support performance for Oracle. A query to obtain top-level Positions, Organizations, or Access Groups can use either: 1. WHERE ROOT_PARTY_FLG='Y' or 2. WHERE PAR_PARTY_ID is NULL Oracle cannot use an indexed access path for option 2 because there are no index entries for NULL, so ROOT_PARTY_FLG was added. ROOT_PARTY_FLG is set to 'Y' for top-level Positions, Organizations, and Access Groups as it applies only to these Party sub-types. It is set to 'N' for other party subtypes. COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Mapping Considerations – continued Integrating Siebel Applications Training Mapping Considerations – continued This is important: In the EIM Interface Tables report within Siebel Tools, notice that for organization data, the documented mapping is to an EIM table column ending in “_BI” with datatype varchar (15). For example, for the EIM_ACCOUNT table, the mapping to the S_ORG_EXT..BU_ID column is listed as ACCNT_BI. Instead of using the _BI column, use the corresponding _BU column, populating it with the name of the organization. EIM resolves to the foreign key during import processing. In the above example, you would use the ACCNT_BU column on EIM_ACCOUNT, populating it with the name of the organization, by default, “Default Organization”. ROOT_PARTY_FLG ROOT_PARTY_FLG is for Oracle implementations only. It was added to support performance for Oracle. A query to obtain top-level Positions, Organizations, or Access Groups can use either: 1. WHERE ROOT_PARTY_FLG='Y' or 2. WHERE PAR_PARTY_ID is NULL Oracle cannot use an indexed access path for option 2 because there are no index entries for NULL, so ROOT_PARTY_FLG was added. ROOT_PARTY_FLG is set to 'Y' for top-level Positions, Organizations, and Access Groups as it applies only to these Party sub-types. It is set to 'N' for other party subtypes. COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Every EIM table has the following 3 required columns: EIM Table Columns Every EIM table has the following 3 required columns: ROW_ID NOT the same as the ROW_ID in the base tables Used in conjunction with IF_ROW_BATCH_NUM to uniquely identify a record in the EIM table IF_ROW_STAT Used by EIM Process to store the status of the record IF_ROW_BATCH_NUM Used to identify a set of records. Multiple records with the same IF_ROW_BATCH_NUM value forms a BATCH. EIM Process loads data on a batch basis. It selects all records in a particular batch for processing.

LOV values, for bounded LOVs EIM Validations Field size Field data type LOV values, for bounded LOVs The data in the EIM column is validated against the LOV display values. The LOV display values are those for the Language used to execute the EIM Job If the value is not valid: EIM updates the IF_ROW_STAT of the record to “PICKLIST_VALUE”. EIM fails to load any data for this record into that base table. That is reason we use ‘DAN’ for running Activity_Status.ifb file. Required fields for EIM and Base tables Uniqueness within EIM and Base tables Foreign Key relationships Parent Child Associations

Basic Entities Accounts – EIM_ACCOUNT Addresses – EIM_ADDR_PER Contacts – EIM_CONTACT Opportunities – EIM_OPPORTUNITY Activities – EIM_ACTIVITY Product – EIM_PRODUCTS

Associating Records – 1 : M Relationship Examples of Associating records Account Addresses, Contact Addresses, Account Contact Contacts can have multiple addresses (1:M relationship) which are associated with an intersection table. The association is made when a row is inserted into the intersection table and appropriate row ids are entered into the proper columns i.e.: S_CON_ADDR – the 2 columns are Accnt_id and Addr_per_id multiple rows in EIM_CONTACT are needed to create multiple rows in S_CON_ADDR Verify the tables that need to be populated Add a record in the UI Query the database to determine that the actual tables were populated Verify in the EIM Interface Table object in Siebel Tools that the desired base tables are included in the Table Mapping section for the EIM Table

Associating Records - 1:1 relationships Records that are part of a 1:1 relationship can be associated when the child record is inserted or as a separate batch job. Example: An Opportunity is associated to one and only one Account, we use the initial batch, EIM_OPTY to create the Account association. To populate columns from the S_ORG_EXT_X table for Account records can’t be added using EIM_Account, you need to use EIM_ACCOUNT1 table as a separate batch job.

LOV Language Parameter There are two settings for LOV in the EIM Configuration file ENU (English – American) as the LOV Language, typical LOVs EIM as the LOV Language EIM as an LOV Language: In the base tables, there are various base table extension columns that store codes, but we display the full text in the Siebel GUI. Ex. Account Segment field is stored as “N”, “M”, “K”, “S”, etc. But “National”, “Major”, “Key”, “Small” is displayed in the GUI. The translation is stored in Siebel’s LOV (List of Values) to translate the stored value to the display value. The full text is known as the Display Value, and the code is known as the LIC (Language Independent Code). When loading data via EIM, EIM requires that the display value be loaded into the EIM table column. When using this setting, records are created in Siebel’s LOV with Language = EIM where the display value and the LIC value were the Code Values. The code would fit in the EIM column, and the LOV allowed for the data to be loaded correctly into the base table.

Integrating Siebel Applications Training Foreign Key Mappings Indirect EIM Table Column to Base Table Column Mappings (Foreign Key Mappings) The value in the EIM column(s) contains the user keys for the foreign key table. The value(s) is/are resolved by the EIM process into a Siebel ROW_ID for the foreign key table. If the value is resolved successfully: EIM loads the base table column with the foreign key Siebel ROW_ID value. If the value is NOT resolved successfully: EIM does not load data into the foreign key column. Unless the foreign key column is also a required field or a user key field, EIM will continue to process other columns in the EIM record for that base table. Ex. BU On EIM_ACCOUNT, the ACCNT_BU column maps to the S_ORG_EXT column BU_ID, which is a foreign key to S_BU. The ACCNT_BU field contains the user key NAME for the S_BU table. Show a foreign key mapping on the EIM_ACCOUNT mapping printout. COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Integrating Siebel Applications Training Workaround for Updating User Keys Since EIM uses User Key fields to determine if a base table record needs to be inserted or updated, EIM is usually unable to update the values that make up the user key. Example: On EIM_ACCOUNT, NAME, LOC, and ACCNT_BU form the user key. We cannot use EIM_ACCOUNT to update the NAME, LOC, or BU_ID fields on the S_ORG_EXT table. The User Key EIM tables are used to update the user keys. Ex. For Account Information, the EIM_ORG_EXT_UK table can be used to update the NAME, LOC, and BU_ID fields on the S_ORG_EXT table. Currently, Siebel does not provide EIM UK tables for all entities. For example, Contacts do not currently have a UK EIM table. COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Integrating Siebel Applications Training Summary Review Question: What is the role user keys in EIM? Answer: The user key determines if a record already exists in the database table. After completing this module you should be able to: Determine correct interface (EIM) tables and columns to use to import data into and delete data from Siebel base tables and columns Document data mappings between EIM tables and Siebel base tables The higher quality the mapping, the easier it will be to actually run the EIM process COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED