Document Objective
Siebel EIM is a process provided by the Siebel CRM package, in order to import the legacy
data, export, delete or merge existing data. This document explains the basics of EIM,
different functions of EIM, configuring the IFB file, EIM task tracing techniques and
debugging different kinds of errors.
This document requires the users to have prior Siebel CRM and Oracle SQL knowledge.
Revision History
Table of Contents
1.0 INTRODUCTION:................................................................................................1
2.0 EIM FUNCTIONS:...............................................................................................2
2.1 IMPORTING DATA:...................................................................................................2
2.2 EXPORTING DATA:..................................................................................................2
2.3 DELETING DATA:....................................................................................................2
2.4 MERGING DATA:....................................................................................................2
2.5 PROCESS FLOW BETWEEN EIM & DATABASE:......................................................................2
3.0 SIEBEL INTERFACE TABLES:..............................................................................3
3.1 COLUMN MAPPING:.................................................................................................4
4.0 CONFIGURATION FILE:......................................................................................5
4.1 GENERAL HEADER PARAMETERS:....................................................................................5
4.2 GENERAL PROCESS PARAMETERS:...................................................................................6
4.3 IMPORT PROCESS PARAMETERS:.....................................................................................8
4.4 EXPORT PROCESS PARAMETERS:...................................................................................11
4.5 DELETE PROCESS PARAMETERS:...................................................................................11
4.6 MERGE PROCESS PARAMETERS:...................................................................................13
4.7 EXTENDED PARAMETERS:..........................................................................................13
4.7.1 User-Defined Extended Parameters:............................................................14
4.7.2 Predefined Extended Parameters:................................................................14
5.0 IMPORT PROCESS:...........................................................................................16
5.1 IMPORT PROCESS STEPS:.........................................................................................16
5.2 MANUAL IMPORTING PROCEDURE:.................................................................................18
5.3 DIFFERENT IF_ROW_STAT VALUES:..........................................................................19
5.4 RECOMMENDED IMPORTING ORDER:...............................................................................19
6.0 EXPORT PROCESS:...........................................................................................21
6.1 EXPORT PROCESS STEP: .........................................................................................21
6.2 MANUAL EXPORTING PROCEDURE:.................................................................................21
7.0 DELETE PROCESS:...........................................................................................23
7.1 DELETE TYPES:...................................................................................................23
7.2 DELETE PROCESS STEPS:.........................................................................................23
7.3 MANUAL DELETING PROCEDURE:..................................................................................24
8.0 MERGE PROCESS:............................................................................................25
8.1 MERGE PROCESS STEPS:.........................................................................................25
8.2 MANUAL MERGING PROCEDURE:..................................................................................26
9.0 RUNNING EIM:................................................................................................27
9.1 RUNNING EIM THROUGH GUI:..................................................................................27
9.2 RUNNING EIM THROUGH COMMAND LINE INTERFACE:............................................................27
9.3 ERROR FLAGS:....................................................................................................28
9.4 SQL TRACE FLAGS:..............................................................................................28
9.5 TRACE FLAGS:....................................................................................................28
10.0 DEBUGGING EIM:..........................................................................................30
11.0 FAQS:............................................................................................................32
ACRONYMS:.............................................................................................................34
1.0 Introduction:
Siebel EIM (Enterprise Integration Manager) is server task that deals with the exchange of
data between intermediary tables called interface tables and Siebel base tables.
External
Database
EIM
External
Flat
Files
Siebel EIM can be used to achieve four kinds of functionality in which all the functions deal
with the data directly. The functions are viz.
• Initial implementation of Siebel application (Loading product data from the legacy
database)
• Maintaining the Siebel database in long run (Importing archived data)
• Periodical updating of data into Siebel database from a non Siebel database
In the process of maintaining Siebel database, you will land up on certain requirements
where you need to delete the existing data like removal of obsolete data. Ex: Obsolete
products.
Merging of data arises in situations where you need to de-duplicate (removal of duplicates)
the data.
• Data has to be loaded into EIM tables (Interface tables). This is applicable for import,
delete or merge operation. For export function, this step is not required.
• Edit the EIM Configuration file. In short called as IFB file, this file defines the
parameters like type of EIM, the EIM table used, the batch number, etc…
• Run the EIM task either through GUI or command line.
• Verify the results. EIM generates log file for every task and you can use this log file
for debugging.
Interface tables act as staging area which holds the data that has to be imported, data
exported from the Siebel base tables, data to be deleted and that to be merged. EIM
process operates upon these tables and does the specified operation.
Every interface table has columns that get mapped to base tables, few mandatory columns
and many temporary columns. The mandatory columns are ROW_ID, IF_ROW_STAT and
IF_ROW_BATCH_NUM.
The temporary columns are those that are used by EIM task to manipulate data values at
run times. These temporary columns store the ROW IDs of records, status of the record,
uniqueness of the records, whether the record already exists in the database. Some
temporary columns store the ROW ID values of deleted, merged, exported rows.
Every interface table, while loading data into, has to satisfy certain prerequisites as stated
below:
Every Siebel interface table has 4 types of temporary columns as defined below:
• UNQ column
• EXS column
• RID column
• STA column
The temporary columns that have suffix UNQ, stores Y or N values if the interface record’s
user keys are not same as another interface record’s user keys in the same batch.
The temporary columns that have suffix EXS, stores Y or N values if the interface record can
be mapped to an existing base record (i.e. base record exists for the same user keys).
The temporary columns that have suffix RID, stores the ROW_ID of the record already
existing in the base table or generated ROW_ID for new records in the interface table.
The temporary columns that have suffix STA, stores the pass number of the EIM process
where it failed. Example: If the EIM process failed while processing a record in the
S_ORG_EXT table, the temporary column T_ORG_EXT__STA is set the EIM pass number at
that point of time.
Prior to loading data into the EIM table, it’s essential to find out what data goes into which
column in the base table, which interface table need to be used to achieve this and what is
the mapping among these columns.
It’s a best practice, Siebel suggests, you should document the mapping among the source
data, EIM table and base table. You can use the mapping format as shown in the excel sheet
embedded below.
EIM Mapping
Format.xls
Any EIM process reads a configuration file, where different kinds of parameters are set for
an EIM process. The configuration file, in short IFB file, defines the type of process, EIM
table involved, batch number, and lots of other parameters.
An IFB file has two sections – Header and Process sections. The header section defines the
parameters that are common to all the processes defined in the file. The process section
defines parameters which are specific to that particular section.
This file is stored in the <SIEBSRVR>\ADMIN path, from where the EIM task reads. If this
file is not stored in this directory prior running EIM task, the absolute path of the file has to
be specified in the task. If not, an error will be thrown.
This section describes the parameters that will be used by all the processes defined in the
configuration file.
• CONNECT
Specifies the ODBC source name of the database to be used
• PASSWORD
Specifies the password that needs to be validated for running the EIM
process.
If you have not specified this in Component Parameters, this needs to be
specified in the IFB file.
Example: PASSWORD = SADMIN
• PROCESS
Identifies the process section that has to be executed defined in the IFB file.
Example: PROCESS = Import Organizations
• TABLEOWNER
This parameter specifies name of the user who owns the Siebel database
tables.
• USER NAME
Specifies the logon name of the user for running the process.
If you have not specified this in Component Parameters, this needs to be
specified in the IFB file.
Example: USER NAME = SADMIN
This section describes the parameters that are generic to all EIM processes. The parameters
defined in this section have a scope limited to this process only.
• BATCH
Required field that specifies the batch number, which is used to identify the
set of records that should be considered for this EIM process.
This batch number corresponds to the number specified in the
IF_ROW_BATCH_NUM column of the EIM table.
Valid values are 0 to 2147483647 (231 – 1).
Batch numbers can be specified in ranges or as a comma delimited format.
Example: BATCH = 100 – 110, BATCH = 100, 103, 120.
If batch number is specified wrongly in IFB file, the EIM throws an error
stating, no records found for the stated batch number.
• INCLUDE
Optional parameter that specifies which other sub-process needs to be
included in the process in question.
Example: INCLUDE = Import Contacts
• LOG TRANSACTIONS
Optional parameter that tells whether to log transactions or not.
Valid values are TRUE or FALSE.
Default value depends on the DOCKING: TRANSACTION LOGGING parameter
defined in the System Preferences.
Example: LOG TRANSACTIONS = FALSE
• ROLLBACK ON ERROR
Optional parameter that specifies whether a rollback has to be made if any
failure occurs during the EIM process.
Valid values are TRUE or FALSE.
Default value is FALSE.
This parameter should be set to TRUE while using in delete or merge process.
In case of any failure, the database will be roll backed to the last commit
point and thus avoiding the database corruption.
Example: ROLLBACK ON ERROR = TRUE
• SESSION SQL
Optional parameter that specifies a user defined SQL statement to be sent to
database for execution before any other SQL statements.
This parameter can be used to set tracing for performance analysis.
Only one SESSION SQL parameter is allowed per process section.
This parameter cannot be used to insert or update any data in Siebel tables.
Example: SESSION SQL = "UPDATE EIM_CONTACT SET PP_START_DT =
SYSDATE WHERE IF_ROW_BATCH_NUM = 200”
If set to FALSE, the BU_ID defined in the repository is used for BU_ID
columns in the base tables.
If set to TRUE, the values set in the interface table is used.
This parameter is only limited to insert, delete and merge process, because
the foreign key must be resolved for these processes.
Example: SKIP BU_ID DEFAULT = TRUE
• TABLE
Required parameter that specifies the EIM table to be used for the process.
Example: TABLE = EIM_ACCOUNT
For performance reasons, the number of tables should be limited to fewer
than five for a merge or export process.
• TRANSACTION SQL
Optional parameter that specifies a user defined SQL statement to be sent to
database before other SQL statements are processed and immediately after
every commit or rollback operation.
If both SESSION SQL and TRANSACTION SQL parameters are specified, the
latter gets executed immediately after the former.
Only one TRANSACTION SQL parameter can be defined per process section.
• TYPE
Required parameter that specifies the type of EIM process.
Typical process types are IMPORT, EXPORT, MERGE, DELETE and SHELL.
SHELL process defines that this process has other sub-processes that needs
to be executed.
• USING SYNONYMS
Optional parameter that specifies whether to use the account synonyms
during the import process.
Valid values are TRUE or FALE.
Default value is TRUE.
In order to improve the performance, set this parameter value to FALSE, but
care must be taken while specifying this parameter.
Refer FAQs for further explanation on Account Synonyms.
This section describes the parameters that are specific to EIM import processes. The
parameters defined in this section have a scope limited to this process only.
• COMMIT OPERATIONS
Optional parameter that specifies the commit frequency while logging the
transactions.
Value specifies the number of records processed before a commit is done.
Applicable only if DOCKING: TRANSACTION LOGGING is set in System
Preferences.
Default value is 0, which means commit has to be made at the end of EIM
process.
Example: COMMIT OPERATIONS = 100
• FILTER QUERY
Optional parameter that lets the user to specify an SQL statement which
filters the records that needs to be processed.
This query runs before the import process starts.
The IF_ROW_STAT column of those records that fails this query for the
particular batch as specified in the process section will be set as
“IMPORT_REJECTED”.
Example: FILTER QUERY = (IF_ROW_STAT <> “IMPORTED”)
• UPDATE ROWS
Optional parameter that specifies whether to update the column values in the
base table with that of in EIM table.
Valid values are TRUE or FALSE.
Default value is TRUE.
Example: UPDATE ROWS = S_ORG_EXT, FALSE
• ATTACHMENT DIRECTORY
Optional parameter that specifies the directory path containing the
attachments to be imported.
This directory path should exist on one of the Siebel server machine.
In case of remote machine, map the path to a drive and specify the drive
name to this parameter.
Default value is <SIEBEL_HOME>\INPUT
Example: ATTACHMENT DIRECTORY = X:
• DEFAULT COLUMN
Optional parameter that lets you to specify a value for the EIM table column.
This parameter applies only to Import process.
This value will be only used if the EIM table column is null.
Example: DEFAULT COLUMN = ACCNT_BU, “HP Americas”
• FIXED COLUMN
Optional parameter that lets you to specify a value for the EIM table column.
This parameter applies only to Import process.
This value will be used overriding the value in the EIM table column if any.
Example: FIXED COLUMN = ACCNT_BU, “HP Americas”
• INSERT ROWS
Optional parameter that specifies whether to insert records into the particular
base table or not.
Valid values are TRUE or FALSE.
Default value is TRUE.
Example:
INSERT ROWS = S_ORG_EXT, FALSE
INSERT ROWS = EIM_ACCOUNT, FALSE
If the specified table is an EIM table, the value applies to all the base tables
that were mapped to this EIM table.
• MISC SQL
This parameter is used to specify the type of primary need to be set while
updating the primary child.
Types of primaries are explicit primary and implicit primary.
If set as explicit primary, EIM will consider the record where the primary child
column in the EIM table is set.
Example: MISC SQL = EXPR_S_POSTN_PR_EMP_ID
If set as implicit primary, the first child record of the parent as specified in the
EIM table will be considered as child record.
Example: MISC SQL = IMPR_S_POSTN_PR_EMP_ID
In cases, we might tell EIM to use explicit primary whenever specified and
implicit primary if not. This can be set as shown below.
MISC SQL = EXPR_S_POSTN_PR_EMP_ID, IMPR_S_POSTN_PR_EMP_ID
• NET CHANGE
Optional parameter that specifies how to handle the non user key null
columns in the EIM table.
Valid values are TRUE or FALSE.
Default value is TRUE.
If set to TRUE, the null values in the non user key null columns will be
ignored.
If set to FALSE, the null values in the non user key null columns will be
applied to the base tables also.
Example: NET CHANGE = FALSE
This parameter applies only to Import process.
• TRIM SPACES
Optional parameter that specifies whether to remove the trailing spaces from
the column values before importing.
This parameter applies only to Import process.
Valid values are TRUE or FALSE.
Default value is TRUE.
Example: TRIM SPACES = FALSE
This section describes the parameters that are specific to EIM export processes. The
parameters defined in this section have a scope limited to this process only.
• ATTACHMENT DIRECTORY
Optional parameter that specifies the directory path to where the attachments
have to be exported.
This directory path should exist on one of the Siebel server machine.
In case of remote machine, map the path to a drive and specify the drive
name to this parameter.
Default value is <SIEBEL_HOME>\OUTPUT
Example: ATTACHMENT DIRECTORY = X:
Where X: is mapped to \\CRMDEV02\siebsrvr\OUTPUT
• EXPORT MATCHES
This parameter optionally specifies criteria that need to be satisfied before
exporting the data from the base tables.
Example: EXPORT MATCHES = S_ORG_EXT, (NAME LIKE “HP%”)
The literal specified, is the condition that occurs after the WHERE clause in an
SQL statement.
This section describes the parameters that are specific to EIM Delete process only.
Optional parameter that tells whether to delete the child records when a
parent record is deleted.
Valid values are TRUE or FALSE.
Default value is FALSE.
If set to FALSE, EIM deletes the parent record and sets the foreign key
column in the child records to NULL.
Example: CASCADE DELETE ONLY = TRUE
• DELETE EXACT
This parameter tells the EIM to use user key matching algorithm with rows in
the EIM table to perform deletion.
Valid values are TRUE or FALSE.
Default value is FALSE.
Example: DELETE EXACT = TRUE
Always use this parameter to delete records from the non target base tables.
• DELETE MATCHES
Optional parameter that specifies a conditional expression to select the
records which has to be considered for deletion.
Example: DELETE MATCHES = S_ORG_EXT, (NAME LIKE “HP%”)
The literal specified inside the parentheses is the condition that occurs after
the WHERE clause in any SQL statement.
This parameter can be used only to delete records from the target base table.
• DELETE ROWS
This parameter specifies whether rows from the particular table should be
deleted.
Example: DELETE ROWS = S_ADDR_ORG, FALSE This example restricts
the deletion of records from the S_ADDR_ORG table.
Care should be taken while setting FALSE value, because it might result in
dangling foreign key references.
• UPDATE ROWS
This parameter specifies whether foreign references should be updated.
Valid values are TRUE or FALSE.
Default value is TRUE.
Example: UPDATE ROWS = S_CONTACT, FALSE
This above example restricts any update including the updating of foreign key
references in the S_CONTACT table while performing the EIM Delete.
Care should be taken while setting FALSE value, because it might result in
dangling foreign key references.
This section describes the parameters that are specific to EIM Merge process only.
• UPDATE ROWS
This parameter specifies whether foreign references in the named table
should be updated.
Valid values are TRUE or FALSE.
Default value is TRUE.
Example: UPDATE ROWS = S_CONTACT, FALSE
This above example restricts any update including the updating of foreign key
references in the S_CONTACT table while performing the EIM Merge.
Care should be taken while setting FALSE value, because it might result in
dangling foreign key references.
Apart from the parameters defined at the component level and IFB file, it is also possible to
define dynamic parameters at task level. These parameters are called as extended
parameters.
User can define dynamic parameters and values either through the GUI or command line
interface. Common uses of this type of parameters include setting EIM batch number
dynamically, setting values to the variables defined in the SQL query used in the IFB file.
To define the parameters through command line interface, follow the steps:
• In the command line, use the keyword ExtendedParams to define the name=value
format.
• Example: ExtendedParams=\"BatchNum1=200001,BatchNum2=200002-200003\"
Some extended parameters are predefined in Siebel applications which follows the same
name=value format. Below is a list of predefined extended parameters:
The parameter NUM_IFTABLE_LOAD_CUTOFF is used to tell EIM whether to load all the
schema mappings. The feature is disabled by default in which the value is set to -1. When
enabled, EIM loads all schema mappings. To enable this parameter, set the value to a
positive number that is one less than the number of EIM tables used in the process. If the
parameter value is set to the number equal to the number of EIM tables used in the
process, it effectively disables this feature.
Example: ExtendedParams=\”NUM_IFTABLE_LOAD_CUTOFF=-1”
This section describes the steps involved in an import process, manual procedure to be
followed to accomplish an EIM import, different values of IF_ROW_STAT column and
recommended EIM importing order for different entities.
Whenever an EIM import process runs, it internally performs a sequence of tasks. Each task
involves multiple passes where one pass is defined as an execution of one SQL statement to
achieve a certain internal operation.
Step1:
This step is the initialization step where EIM compares the IF_ROW_BATCH_NUM with the
batch number specified in the configuration file. If no records are found for the particular
batch number, EIM gets terminated. It also sets all the temporary columns to NULL. When
EIM starts at this step, the IF_ROW_STAT column value is set to “IN_PROGRESS”. In
addition, it also checks whether required columns are null. If any of the required columns
was found null, the whole EIM process stops at this point.
Step2:
EIM applies any DEFAULT COLUMNS and/or FIXED COLUMNS values defined in the
configuration (IFB) file.
Step3:
EIM applies the filter queries defined for this import process. Those records which were
eliminated are set with value “IMPORT_REJECTED” in the IF_ROW_STAT column. The
IF_ROW_STAT_NUM and __STA columns for these records are set with a value of current
EIM pass number.
Step4:
EIM resolves and generates the foreign key references for the rows that already exist in the
Siebel base tables. Once resolved, it writes these foreign key values into the temporary
columns of the interface table. If the foreign key fails for any required columns, then EIM
eliminates those records from further processing and sets their IF_ROW_STAT to
“FOREIGN_KEY” and IF_ROW_STAT_NUM & _STA columns with the corresponding EIM pass
number.
In addition to foreign key generation, EIM also validates for the list of values for the
bounded pick lists. The failed rows are eliminated from further processing and their
IF_ROW_STAT column is set to “PICKLIST_VALUES”. Besides the EIM pass number is stored
in the IF_ROW_STAT_NUM and _STA columns.
Step5:
EIM fetches the appropriate ROW_ID of the records which already exist in the base table
and writes those values into the corresponding _RID temporary column of those records.
During this step, it also sets _EXS temporary column of these records to Y.
Step6:
EIM generates ROW_ID for new records. These records are those whose _EXS temporary
column is set to N. Once ROW_ID is generated, these values are stored in the corresponding
_RID temporary column of the records.
Step7:
EIM eliminates rows whose user keys contain invalid values. A scenario like missing value in
one of the user key columns comes under this classification. EIM eliminates those failed
records and set their IF_ROW_STAT value to “REQUIRED_COLS” and IF_ROW_STAT_NUM &
_STA temporary columns to the current EIM pass number.
EIM also resolves and generates foreign key references for the new rows that do not exist in
the base table. Once resolved, it writes these foreign key values into the temporary columns
of the interface table. If the foreign key fails for any required columns, then EIM eliminates
those records from further processing and sets their IF_ROW_STAT to “FOREIGN_KEY” and
IF_ROW_STAT_NUM & _STA columns to the corresponding EIM pass number.
Step8:
EIM updates the contents of existing base table rows with the values from the interface
table that have successfully passed all the previous steps. In case of any update done, EIM
writes the transaction detail to the master transaction log if and only Docking Transaction
Logging parameter is enabled in the System Preferences.
If duplicates were found in the EIM table, then the row which EIM encounter first will be
considered for updating and rest other duplicate rows are ignored. These duplicate rows
were set value “DUP_RECORD_EXIST” in IF_ROW_STAT column and the current EIM pass
number in IF_ROW_STAT_NUM and _STA temporary columns.
Step9:
EIM inserts the new records from the interface table into base tables. It writes these new
rows to the master transaction log if and only Docking Transaction Logging parameter is
enabled in the System Preferences.
If duplicates were found in the EIM table, then the row which EIM encounter first will be
considered for updating and rest other duplicate rows are ignored. These duplicate rows
were set value “DUP_RECORD_EXIST” in IF_ROW_STAT column and the current EIM pass
number in IF_ROW_STAT_NUM and _STA temporary columns.
Step10:
EIM updates the primary child columns in this step. An example: Setting the primary
address for an account. To achieve this, the column ACC_PR_ADDR should be set to Y for
the particular record in the EIM table.
Step11:
EIM runs MISC SQL parameters as last step of import process. There are certain primary
child columns which should be set using both MISC SQL and primary child column in the EIM
table.
• S_CONTACT.PR_OU_ADDR_ID
• S_CONTACT.PR_HELD_POSTN_ID
• S_ORG_EXT.PR_BL_PER_ID
• S_ORG_EXT.PR_SHIP_PER_ID
• S_POSTN.PR_POSTN_ADDR_ID
• S_POSTN.PR_EMP_ID
These are the only six columns in Siebel Horizontals, where MISC SQL has to be specified, in
order to update the primaries. If MISC SQL is not set, though the EIM import succeeds, the
primary child won’t be set in the Siebel base table. For further information on MISC SQL,
check the Import process parameters section defined in the previous pages.
EIM import is a substantial effort where many things should be planned, many prerequisites
to be met before performing the process itself.
Identify and Validate Data: Determine whether the data to be imported already exist in
the database. Check for the completeness of the data. If required, do some data massaging
before importing. Determine the count of entities so that it might help in estimating the
time and resources needed.
Identify column mapping and User Keys: Determine the base table where the data will
get stored finally. Now identify the mapping between the data and Siebel base columns.
Identify the EIM table to achieve this process and the mapping between the data and EIM
table columns. Identify the user keys and required columns that need to be populated.
Hardware and Software Environment: Check whether the Siebel application is properly
installed and all the required components for EIM are in running state. Check whether ample
memory resources are available. Check whether the currently available disk space will be
able to store the data after import process. Speak to your DBA regarding the future
database size.
Backup existing database: Before performing any significant change to the underlying
database, it is recommended to take a backup of database. This will ease the recovery in
case of any major failure.
Copy File attachments to Server directory: Copy all the attachments to be imported to
the input directory under the Siebel server root directory. Optionally you can set different
directory path, by specifying it in the ATTACHMENT DIRECTORY parameter in the IFB file.
The default file attachment path is <SIEBEL_HOME>\INPUT, which can be changed using
the above parameter.
Load and verify EIM tables: Use any data loading tools like SQL Loader, DTS, etc… to load
the legacy data into the EIM tables. Once the data is loaded verify check the number of
loaded rows against the legacy database. Also check the contents of data loaded into the
EIM table.
EIM Configuration File: Create the configuration file for this import process. Use
default.ifb in the <SIEBEL_HOME>\ADMIN directory as a template.
Test the Import Process: Test your EIM import process for a small batch of 100 records.
If required, change the parameter settings in the configuration file.
Run the Import Process: In case of huge volumes of data, split the data into multiple
batches with approximately 1000 to 5000 records per batch. Smaller the batch it is easier to
identify the problems. Run the EIM process either through GUI or command line interface.
Verify Results: There are different types of error that might occur during an import
process. Identify these errors, debug them and run EIM once again as a separate batch, by
changing the batch number for the failed rows.
Depending upon the type of failure, the IF_ROW_STAT column of the interface table records
are set with different kinds of values.
AMBIGUOUS: Two rows in the base table have same user key but different conflict IDs.
DUP_RECORD_EXISTS: One or more rows that exist in the interface table exactly matches
with base table record.
DUP_RECORD_IN_EIM_TBL: One or more rows have the same user key of another row
within the interface table.
FOREIGN_KEY: When a required foreign key column in the target table could not be
resolved.
IMPORTED: The rows got successfully imported for both target and not-target base tables.
IN_PROGRESS: This value is set in the first step, the initialization step, of the import
process.
PARTIALLY_IMPORTED: The rows got successfully imported for target table but failed for
one or more non-target tables.
ROLLBACK: When EIM encounters an error during a roll back operation, this value is set.
SQL_ERROR: This value is set, when EIM fails importing, when the transaction logging is
enabled.
Whenever an import process is done, you should make sure that any reference data needed
must already exist in the Siebel database. If this is not followed errors like FOREIGN_KEY,
PICKLIST_VALUES might occur. So, any administrative or referential data should be
imported first, followed by other data. The recommended order is as follows:
In some cases, the import order might change slightly depending upon the business
requirements.
This section describes the steps involved in an export process, manual procedure to be
followed to accomplish an EIM export process.
Whenever an EIM export process runs, it internally performs a sequence of tasks. Each task
involves multiple passes where one pass is defined as an execution of one SQL statement.
Step1:
EIM performs an initialization process on EIM tables. It checks the CLEAR INTERFACE TABLE
parameter defined in the IFB file. If this parameter is set to TRUE, it deletes all the rows in
the EIM table for the specified batch number. If this parameter is set to FALSE and if some
rows exist for the specific batch number, a warning is issued.
Step2:
In this step, EIM uses the export parameter settings to select the records. It checks if
EXPORT ALL ROWS parameter is set to TRUE. If so, it ignores any EXPORT MATCHES
parameters defined in the IFB file and exports all the rows. If EXPORT ALL ROWS is set to
FALSE, it uses the EXPORT MATCHES parameters to locate those specific rows. Once the
rows to be exported were identified, it exports all the data into the particular EIM table and
sets the IF_ROW_STAT value to EXPORTED for rows that were successfully exported.
Step3:
In case of parent tables, EIM locates and exports the child data to their respective EIM
tables.
Before you start the export process, it is necessary to take care of the following things.
Prepare EIM Tables: Check whether your interface table doesn’t have any records with
IF_ROW_BATCH_NUM value equivalent to the batch number specified in the IFB file. If it
exists EIM behaves in the following ways depending upon the setting of the CLEAR
INTERFACE TABLE parameter.
• If the parameter is set to TRUE, EIM deletes all those existing rows for the specified
batch number.
• If the parameter is set to FALES, EIM issues a warning.
Edit Configuration File: Create your configuration file by defining your requirements. The
modifications that should be made in the IFB file depend on different scenarios as shown
below.
When you need to export all the rows set the value of EXPORT ALL ROWS parameter as
TRUE. If you want to export specific rows, specify the EXPORT MATCHES parameter with
appropriate condition expression. If you want to export particular columns use the ONLY
BASE COLUMNS or IGNORE BASE COLUMNS parameter in the IFB file.
BU Name Pulling: EIM export process, exports only the ROW_ID of the BU into _BI
columns of the EIM table. In order to fetch the values of the BU names, follow the steps:
Verify Export Results: Check the count of records in the EIM table with IF_ROW_STAT
value equivalent to EXPORTED against the count of the records you need to export.
This section explains different types of deletes, the steps involved in a delete process,
manual procedure to be followed to accomplish an EIM delete process.
There are three ways in which you can achieve the deletion of records through EIM. They
are as follows:
• DELETE EXACT – Where EIM uses a user key matching algorithm to identify the rows
that needs to be deleted. This is done by matching the user key of the record in the
interface table with that of the records in the base table. Once a match occurs, EIM
deletes this record.
• DELETE MATCHES – Where EIM deletes those records that match the conditional
expression set in the IFB file using the parameter “DELETE MATCHES”.
• DELETE ALL ROWS – Where EIM deletes all the rows from the base table irrespective
of any conditions or user key matching.
Whenever an EIM delete process runs, it internally performs a sequence of tasks. Each task
involves multiple passes where one pass is defined as an execution of one SQL statement.
Step1:
EIM performs an initialization process on EIM tables. It checks the CLEAR INTERFACE TABLE
parameter defined in the IFB file. If this parameter is set to TRUE, it deletes all the rows in
the EIM table for the specified batch number. The default value of the parameter depends on
the type of delete (as explained in previous section) being performed.
Step2:
In this step EIM performs the actual deletion of the records. If the DELETE EXACT parameter
is set to TRUE in the IFB file, EIM performs a user key matching process to identify those
records that need to be deleted and deletes the same.
If the DELETE MATCHES parameter is defined in the IFB file, EIM uses this conditional
expression and selects those records from the target base table and deletes them.
If the DELETE ALL ROWS parameter is set to TRUE in the IFB file, EIM deletes all the rows
from the target base table.
Step3:
As a final step, EIM sets the IF_ROW_STAT of those records to “DELETED” in the EIM table.
Also, when there’s a reference to this record in some other table, that record is deleted if
the referenced column is a mandatory, otherwise the reference column is cleared.
Whenever a parent record is deleted, the child records are also deleted, if the foreign key
column in the child table is mandatory, otherwise the foreign column is cleared.
The deletion of child record is decided based on the CASCADE DELETE ONLY parameter
defined in the IFB file.
Before you start the export process, it is necessary to take care of the following things.
Identify the Data: As a first step, identify the data you want to delete from the base table.
Now check once or twice, whether you have selected the right data for deleting. Once the
data is identified, decide what type of delete (explained in previous section) needs to be
used.
Prepare EIM Table: Depending upon the type of delete, decide what data should be loaded
into your EIM table. If you are achieving a delete through DELETE EXACT, you must load the
data into EIM table in the mandatory columns with IF_ROW_STAT set to “FOR_DELETE”, the
user key columns of the corresponding target and non-target table.
Edit Configuration File: Depending upon the type of DELETE you use, make changes in
the configuration file. The configuration parameters are explained in the previous section.
Always set the COMMIT EACH PASS & COMMIT EACH TABLE parameter to FALSE and
ROLLBACK ON ERROR to TRUE, to avoid dangling references in case if a failure occurs
during an EIM delete.
Verify Results: After executing the EIM task, verify the results by examining the EIM table.
EIM stores the ROW_ID of the deleted rows in the EIM table, in T_DELETED_ROW_ID
column. Query for the count of records whose IF_ROW_STAT = “DELETED”. Verify this count
is equal to the count of records considered for deletion earlier.
EIM Merge uses the rows in the EIM table and the IFB file parameter settings to achieve the
merge process. Apparently, EIM merge is a combination of deleting one or more rows and
updating of foreign key references wherever required. This section explains the steps
involved in the merge process, manual procedure to achieve merging.
Step1:
EIM performs an initialization process on EIM tables. As in any EIM process, this steps
checks whether the mandatory columns are loaded.
Step2:
EIM selects the records from base tables, whose user key match that of in the EIM table.
Step3:
EIM deletes the records from the target base table that are specified in the EIM table. It also
updates the foreign key references in the child entities of the deleted records to point to the
survived record.
• For deleted rows, EIM sets the T_DELETED_ROW_ID to the ROW_ID of the deleted
row in the base table.
• EIM also sets the T_MERGED_ROW_ID of the deleted rows with the ROW_ID of the
survived record.
• While merging, when duplicate child entities are found among the parents being
merged, the child records of the deleted row is made to point to the survived record
and CONFLICT_ID is set for those duplicate child records. Below example portrays
the Account and Contact relationship before and after merge.
Before Merge
HP Regional HP WW
After Merge
HP Regional
CONFLICT_ID Set
Identify the Data: As a first step, identify the data you want to merge from the base table.
Within, identify the survivor records and loser records.
Prepare EIM Table: Load the user key of both the survivor records and loser records into
the EIM table. Set the IF_ROW_MERGE_ID for the loser records with a value of the ROW_ID
of survivor record in the EIM table. The following example explains the above statement:
Verify Results: After running the EIM process, test your results by examining the EIM
table. Query for the records with IF_ROW_STAT = “MERGED”, which gives the count of the
merged records. Query for the records with IF_ROW_STAT = “MERGED_INTO”, which gives
the count of the survivor records.
Before running an EIM process, make sure all the components required for EIM task are up
and running, the configuration file is stored in the <SIEBEL_HOME>\ADMIN directory and
the data is loaded into the EIM table. EIM can be run in two ways: Through GUI and
Command Line interface.
• Start the srvrmgr program in the command line interface. Use the below syntax to
connect to the server manager.
• srvrmgr –g <gateway> -e <enterprise> -s <Siebel server> -u <User name> -p
<password>
• Once connected to server manager, execute the start task command as shown below.
• start task for component EIM with config=<IFB file name>
• If required give the parameter (name=value) pair separated by commas.
The excel sheet embedded below gives all the parameters of the EIM component. It also
gives the parameter alias to be used while specifying the parameters through the command
line interface, description of those parameters. The other detail like Current Value, Value on
Restart and Effective Immediately shows the out of box values of these parameters after a
fresh installation.
EIM Parameters.xls
In order to trace the EIM task in terms of SQL statements, ODBC calls and other errors you
can set the appropriate parameters to do this. The three important parameters responsible
for this are:
• Error Flags
• SQL Trace Flags
• Trace Flags
Activating or setting these flags will have a direct effect on performance. Care must be
taken, so that these flags are not used while running EIM task in production environment.
Typically, these flags should be used in a testing or development environment only.
These flags are set to log the details when some error occurs during the EIM process.
Typical values used for setting this flag are 0 and 1. With a setting of Error Flag = 1, EIM
records detailed explanation of rows that were not processed successfully during the EIM
process.
Setting this flag will create a log of SQL statement shot during the EIM. Typical values are 1,
2 and 4. A value of 8, will record all SQL statements that make up the EIM process.
These flags are used to trace various EIM operations like component tracing, SQL summary,
task configuration, worst queries that took lots of time, summary of whole EIM process,
etc... To use this flag, it’s necessary to configure the component event level as follows:
Log level value ranges from 0 – 5. The table listed below gives more detail about the logging
level.
Level Description
0 Fatal
1 Errors
2 Warnings
3 Informational
4 Details
5 Diagnostic
To set the event logging for EIM component, you should set the levels for the following
event types as shown below:
Once you configure the event levels according to your requirement, you can set the
appropriate value for the Trace Flags and run the EIM.
Typical values of trace flags are 1, 2, 4, 8 and 32. To activate multiple trace flags, set the
value which is equivalent to sum of the trace flag values. Different trace flag values and
their descriptions are given shown below:
Trace Flag 1: Setting a value of 1 will create step-oriented log of the task. The log created
thus can be used to determine the amount of time EIM spends on each step of the whole
process or each EIM table processed.
Trace Flag 2: Setting a value of 2 will record traces of all substitutions of user parameters.
Trace Flag 4: Setting a value of 4 will record traces of all the user key overrides.
Trace Flag 8: Setting a value of 8 will record traces of all interface mapping warnings.
Trace Flag 32: Setting a value of 32 will record traces of all file attachment status. This
trace log has 4 kinds of labels depending upon the file attachment process.
Once an EIM process has run, there might be lots of surprises waiting for the Siebel
Administrator in the form of errors. These errors might occur due to record failure, database
failure, not enough tablespace in the database, etc… This section explains how to debug
different kinds of errors that occurs in EIM. Debugging style differs from environment to
environment, database to database, and the kind of error.
General EIM errors like AMBIGUOUS to REQUIRED_COLS can be resolved as shown in below
steps:
• Check the IF_ROW_STAT column of the EIM table and understand what the problem
actually is.
• Check the IF_ROW_STAT_NUM and identify the number in this column. This number
is the EIM pass number where the failure occurred.
• Check the _STA temporary columns of the EIM table that has the same number value
as in IF_ROW_STAT_NUM. Once this is done, you can identify the base table where
the failure occurred.
In EIM_ACCOUNT table, you have 7 _STA columns for each base table catered
by this EIM table.
Sometimes you can see your EIM task staying the Queued state. This is because, the
component Server Request Process is in unavailable state. To make this component in
running state, you should make sure that you have applied all the patches for your Siebel
server. Then shutdown the component and startup again as shown below:
• Once this is done, restart your Siebel Gateway and Siebel Server where the Server
Request Processor component resides.
Now you will find your Server Request Processor up and running. The workaround for this
scenario will be running your EIM task through Command Line interface.
There might be some scenarios where your EIM will stay in the Active state for long time
and if you query your EIM table, you will find the IF_ROW_STAT value of the records set to
IN_PROGRESS. This happens when a lock was acquired on the particular EIM table by some
other applications. Common examples are, not committing the table once inserting the
records into the EIM table.
If you get any errors like invalid configuration file, then check the IFB file whether you have
specified all the required configuration parameters.
Most of the EIM errors can be able to resolve immediately like configuration file not found,
invalid configuration file parameters, while there might be errors like insufficient space. This
means not only enough space available in the disk, but also in the database. You should
check whether enough space is available in the Siebel Data tablespace and also check
whether auto extent option is enabled for this tablespace. This kind of error, sometimes,
might be very difficult to judge and conclude.
If your database gets shut down automatically, when your EIM is running, then it’s a
problem with the database. Check whether your database is applied all the required
patches, whether the windows service is configured properly for the database.
11.0 FAQs:
1. When I tried to set the primary employee for the position through EIM, it is not
getting updated. Why?
While updating the primary employee for position, apart from setting the POSTN_PR_EMP
column in the EIM table, you should also define the MISC SQL parameter in your IFB file.
For further information on How to set MISC SQL, MISC SQL for other Primary Childs, refer
previous section.
2. Although setting the trace flags, I’m not able to see log information in the log
file. Why?
You should configure your component event levels as described in the previous section Trace
Flags.
4. Can I use more than one IFB file for an EIM process?
No, it’s not possible. You can use shell process in case if you want to do more than one
operation in a single EIM task.
6. What is the use of DELETE SKIP PRIMARY parameter in EIM DELETE operation?
The default value of this parameter is TRUE which doesn’t update the primary child column
in the parent record when the primary child record is deleted. If set to FALSE, the primary
child column is set to “No Match Row Id”.
7. How will I get the position details when I need to populate these values in the
EIM table?
The query listed below will fetch all the positions and their details in the underlying Siebel
database.
SELECT A.NAME "Position Name", B.NAME "Position Division",
B.LOC "Position LOC", C.NAME "Position BU Name"
FROM SIEBEL.S_POSTN A, SIEBEL.S_ORG_EXT B, SIEBEL.S_BU C
WHERE A.OU_ID = B.ROW_ID AND B.BU_ID = C.ROW_ID
10. My EIM Delete fails by setting the IF_ROW_STAT column to AMBIGUOUS. Why?
Whenever EIM encounters more than one record with same user key values but different
CONFLICT_ID values, EIM cannot proceed with the delete operation and hence it sets the
value “AMBIGUOUS” in the IF_ROW_STAT column.
Appendix A:
Acronyms:
CPG – C P G
CRM – Customer Relationship Management
DML – Data Manipulation Language
EIM – Enterprise Integration Manager
GUI – Graphical User Interface
IFB – InterFace Builder
ODBC – Open DataBase Connectivity
SQL – Structured Query Language