Siebel EIM tables are crucial in facilitating the seamless data exchange between the Siebel database and external databases. They serve as an intermediary step between the primary tables within the Siebel database and external data sources. These tables are intentionally designed to be straightforward and uncomplicated, making them easily accessible and manageable by external programs.
To harness the power of EIM for tasks such as merging, updating, or importing data, it is imperative first to populate the EIM tables with the relevant data. This data population can be achieved using various methods supported by the database, ensuring flexibility in the data integration process. Once the EIM tables are successfully populated with the necessary data, an EIM job can be initiated to process this information efficiently.
It's important to note that each EIM table is typically associated with a specific group of base tables, allowing for the seamless import or export of data in a single cohesive batch. This streamlined approach simplifies data management and enhances the efficiency of data operations within the Siebel system.
EIM Table Columns:
IF_ROW_BATCH_NUM: For all rows to be processed as a batch, you must set the values in this column to the same integer, which should be greater than or equal to 0. The maximum allowable value is 2147483647. Additionally, using this column as the primary key for any new indexes created on an EIM table is advisable.
ROW_ID: To ensure an EIM table row is ready for processing, you must initialize its ROW_ID. The ROW_ID, in conjunction with the IF_ROW_BATCH_NUM value, must result in a unique value. It's important to note that the ROW_ID values in EIM tables differ from the ROW_ID values assigned to rows when loaded into the base table. EIM-generated ROW_IDs follow the XX-XXX-XXX format, whereas regular Siebel row IDs have the X-XX format.
IF_ROW_STAT: EIM automatically updates this column after processing each row to indicate the record's status. During the population of EIM tables, you can set this column to any value except NULL, such as FOR_IMPORT, indicating that the row has not been processed yet.
IF_ROW_STAT_NUM: After processing, this column holds a zero (0) if a row was successfully processed to completion. In processing failure, this column contains the pass number where the pass failed.
IF_ROW_MERGE_ID: This column offers two possible values:
NULL: Identifies the surviving or merged-into-row.
ROW_ID: Identifies the ROW_ID number in the EIM table where the row will be merged.
Temporary columns: EIM employs temporary columns for data manipulation during processing, denoted by names starting with T_ and indicating the table or column for which they are used. Since EIM uses these columns internally during processing, it's essential not to manipulate them in the EIM tables.
EIM Table and Column Mappings:
In the Enterprise Integration Manager (EIM) realm, the synergy between EIM tables and Siebel base tables hinges on EIM table mappings. These mappings serve as the backbone for the seamless flow of data. It's essential to note that the predefined EIM mappings within Siebel are non-negotiable and remain fixed without the option for remapping. However, there may be scenarios where specific base tables lack mappings to their corresponding EIM tables. To bridge this gap, the EIM Table Mapping Wizard becomes a valuable tool, allowing for the addition of these critical mappings.
Creating New EIM Table Mappings to Existing Base Tables:
When the need arises to forge fresh EIM table mappings into an existing base table, two specific scenarios warrant attention:
1. Extending Existing Mappings: If mappings already exist between the EIM table and the base table, you can extend these mappings to accommodate new requirements.
2. Enhancing Extension Table Mappings: In the case of an extension table serving as the base, and mappings already exist from the EIM table to the corresponding base table, you can augment and refine these mappings.
For instance, consider a scenario where you intend to introduce a new column within EIM_ACCNT_DTL. This new column can be mapped to a freshly created extension column in S_ORG_EXT or an existing column within the extension table, such as S_ORG_EXT_X.
If you opt to create an extension column tied to a base table and subsequently execute the EIM Table Mapping Wizard, expect the Wizard to perform the following pivotal actions:
1. Establish New Extension Column Mapping: The Wizard will configure the mapping for the newly introduced extension column, ensuring its integration into the data flow.
2. Comprehensive Mapping Coverage: The Wizard will diligently create mappings for all previously unmapped columns within the base table, encompassing unmapped Siebel base columns. This meticulous mapping ensures data integrity and thorough coverage within the mapped plains, enhancing the overall data management process.
Explicit Primary Mappings:
Within the Siebel Data Model, explicit primary mappings are pivotal in establishing relationships between parent and child base tables. These relationships are founded on primary foreign keys, commonly called primaries. Primaries serve as the backbone for implementing essential business logic within the Siebel Data Model, enabling functions like identifying the primary position for an account.
Moreover, primaries are instrumental in optimizing system performance by mitigating redundant subqueries. This efficiency boost occurs when data from both the parent and primary child tables are displayed simultaneously. Primary foreign keys are typically column names prefixed with PR_ and are officially designated as primaries in the data model.
When both the parent table and the primary child table of a primary foreign key find themselves mapped to the same EIM table, you'll encounter an explicit preliminary mapping for this primary foreign key under the table mapping of the immediate child table. For example, consider the scenario where the Parent Table is S_PROD_INT, and the Child Table is S_PROD_LN_PROD. In this case, you would encounter an Explicit Primary Mapping such as S_PROD_INT.PR_PROD_LN_ID (Product Line Id).
How to Check Base Tables Mapped to an EIM Table:
If you're curious about which base tables are mapped to a particular EIM table, you can follow these steps:
• Launch Siebel Tools.
• In the Object Explorer, navigate to the Types tab.
• Click on the EIM Interface Table.
• In the EIM Tables window, select the specific EIM table you wish to investigate.
• Expand the EIM Interface Table in the Object Explorer.
• Click on EIM Table Mapping.
• The EIM Table Mappings window will present a comprehensive list of base table mappings linked to the selected EIM table. To delve deeper, expand EIM Table Mapping and focus on Attribute Mappings, where you can identify the mappings between the base and EIM table columns.
How to Identify EIM Tables for Populating a Base Table:
Conversely, if you need to determine which EIM tables are capable of populating a particular base table, you can proceed as follows:
• Launch Siebel Tools.
• Within the Object Explorer, access the Flat tab.
• Click on the EIM Interface Table.
• Utilize a query to search for the desired base table in the Target Table properties.
• The Name property will yield a comprehensive list of all EIM tables capable of populating the specified base table.
EIM Table Mappings to Base Tables without User Keys & Related Topics:
Notably, specific EIM tables contain mappings to base tables lacking any user keys. This characteristic is often observed in tables with names starting with S_NOTE*.
When it comes to EIM processes involving base tables that lack user keys, there are a few essential points to remember:
DELETE: Let's begin with deletion. Whether dealing with base tables with user keys or those without, you can employ "DELETE ALL ROWS" and "DELETE MATCHES" to remove data from your target base tables. However, it's crucial to understand that tables without user keys often function as secondary tables. They usually need to be linked as child tables to their parent tables to delete data from these tables.
IMPORT (Update): The challenge arises when you try to update data within base tables that lack user keys. EIM faces difficulty uniquely identifying the records for updates, making this a cumbersome process.
EXPORT: On the flip side, exporting data from base tables without user keys doesn't deviate from the standard export process applied to tables with user keys. EIM treats them similarly when it comes to data export.
MERGE: Unfortunately, the merge operation is a no-go for base tables without user keys. This limitation means you'll need to explore alternative data integration and consolidation.
IMPORT (Insert): Importing data into base tables without user keys is feasible. However, it's essential to note that EIM won't check or prevent duplicate records from entering these tables. If you run an import batch multiple times, you'll likely end up with identical records, as EIM cannot verify if the records exist in the base tables without user keys.
These considerations highlight the nuances of working with base tables lacking user keys within the EIM framework.
Comments
Post a Comment