Technical Document Enterprise Integration Manager

Technical Document Enterprise Integration Manager
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.
10/17/2008 Confidential Page i

Revision History
Version Date Description of Revisions

0.1 14-Sep-2004 Creation of Document.
0.2 03-Nov-2004 Updated the comments of self review.
10/17/2008 Confidential Page ii

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
10/17/2008 Confidential Page iii

ACRONYMS:.............................................................................................................34
10/17/2008 Confidential Page iv

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.
Siebel Interface Table
External
Database
EIM
External
Flat
Files
External Data Sources Siebel Base Tables
10/17/2008 Confidential Page 1

2.0 EIM Functions:
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.
• Import new and revised data into Siebel Base Tables

• Export existing data from Siebel Base Tables
• Delete existing data from Siebel Base Tables
• Merge existing data in Siebel Base Tables
2.1 Importing Data:
Data importing comes into picture under following business requirements:
• 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
2.2 Exporting Data:
Data exporting is done under the following business requirements:
• Transferring Siebel data to a non Siebel applications

• Archival of data
2.3 Deleting Data:
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.
2.4 Merging Data:
Merging of data arises in situations where you need to de-duplicate (removal of duplicates)
the data.
2.5 Process Flow between EIM & Database:
• 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.

3.0 Siebel Interface Tables:
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:
• Mandatory columns needs to be populated

• All the required columns has to be populated
• Populate the IF_ROW_BATCH_NUM with appropriate batch number
• Set the IF_ROW_STAT column with meaningful values
Every Siebel interface table has 4 types of temporary columns as defined below:
• UNQ column
• EXS column
• RID column
• STA column
Each of the temporary columns has a naming format as follows:

T_<base table without prefix S_>__<temporary column type>
Example: T_ORG_EXT__UNQ, T_ORG_EXT__EXS, T_ORG_EXT__STA, T_ORG_EXT__RID
There are few exceptions for this naming rule.

Examples: T_ACCNTPOST__STA, T_OPTYPOSTN__RID, T_PRODLNPOSTN__RID
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.

3.1 Column Mapping:
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.
This column mapping can be achieved in 2 ways:
• Using bookshelf (<Siebel Bookshelf Path>\ITR.pdf)

• Using Siebel Tools
 Siebel Tools  Flat Tab  EIM Table Mapping
 In object list editor, query for the base table in “Destination Table” Column
 List of EIM tables are listed
 Find out the appropriate EIM table
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
Steps in column mapping can be briefed as follow:
• Identify the kind of data in question and Siebel base table

• Identify the EIM table to achieve the functionality
• Identify mapping between Siebel base table and EIM table columns

4.0 Configuration File:
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.
These EIM parameters are classified as follows:
• General Header Parameters

• General Process Parameters
• Import Process Parameters
• Export Process Parameters
• Delete Process Parameters
• Merge Process Parameters
4.1 General Header Parameters:
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
• LOG TRANSACTIONS TO FILE

 This parameter specifies whether the transactions to be logged to a file or
docking transaction table.
 Valid values are TRUE or FALSE.
 If set to TRUE, the transaction details are logged into the directory
<SIEBEL_FILE_SYSTEM>EIM.
 If set to FALSE, the transaction details are logged into the S_DOCK_TXN_LOG
table.
 This parameter doesn’t make sense, if DOCKING: TRANSACTION LOGGING
parameter in System Preferences is set to FALSE.
• 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

• [Siebel Interface Manager]

 This is a special and mandatory keyword that needs to be specified, which
tells the EIM task, that this particular file contains the parameters for EIM.
• 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
4.2 General Process Parameters:
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.
• COMMIT EACH PASS

 Optional parameter that specifies whether the process needs to do a commit
after every EIM passes.
 Pass is defined as one SQL DML statement that got executed.
 Default value of this parameter is TRUE.
 This parameter should be set to FALSE while using in delete or merge
process. Since it commits after each pass, and in case of any failures, the
database is left corrupted with dangling foreign key references, etc…
 Example: COMMIT EACH PASS = FALSE
• COMMIT EACH TABLE

 Optional parameter that specifies whether the process needs to do a commit
after processing each base table.
 Default value of this parameter is TRUE.
 This parameter should be set to FALSE while using in delete or merge
process.
 The reason behind this is, since it commits after each pass, and in case of any
failures, the database will be left corrupted with dangling foreign key
references, etc…

 Example: COMMIT EACH TABLE = FALSE
• IGNORE BASE TABLES

 Optional parameter that specifies which base tables has to be ignored for the
process for the particular EIM table.
 This parameter improves the EIM performance.
 Example: IGNORE BASE TABLES = S_PARTY_PER, S_ORG_BU
• 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.
 Default value depends on the DOCKING: TRANSACTION LOGGING parameter
defined in the System Preferences.
 Example: LOG TRANSACTIONS = FALSE
• ONLY BASE TABLES

 Optional parameter that specifies which base tables has to be considered for
the process for the particular EIM table.
 Example: ONLY BASE TABLES = S_PARTY, S_ORG_EXT, S_ADDR_ORG,
S_ORG_BU, S_ACCNT_POSTN
• ROLLBACK ON ERROR
 Optional parameter that specifies whether a rollback has to be made if any
failure occurs during the EIM process.
 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”
• SKIP BU_ID DEFAULT

 Optional parameter that specifies whether to use the default BU_ID defined in
the repository.

 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.
• USE ESSENTIAL INDEX HINTS

 Optional parameter specified for MS SQL Server and Oracle databases.
 When set to TRUE, it enables a subset of index hints for MS SQL server.
 Default value is TRUE.
• USE INDEX HINTS

 Optional parameter specified for Oracle databases only.
 When set to TRUE, EIM issues optimizer hints to the database in order to
improve the performance.
 Example: USE INDEX HINTS = TRUE
• USING SYNONYMS
 Optional parameter that specifies whether to use the account synonyms
during the import process.
 Valid values are TRUE or FALE.
 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.
4.3 Import Process Parameters:

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”)
• IGNORE BASE COLUMNS

 Optional parameter that specifies which base columns has to be ignored for
the particular EIM process.
 You should not ignore the user key columns or required columns.
 Example: IGNORE BASE COLUMNS = S_ORG_EXT.HOME_PH_NUM
• ONLY BASE COLUMNS

 Optional parameter that specifies which base columns has to be considered
for the particular EIM process.
 You should include all the user key columns and required columns.
 Example: ONLY BASE COLUMNS = S_ORG_EXT.NAME, S_ORG_EXT.LOC
• UPDATE ROWS
 Optional parameter that specifies whether to update the column values in the
base table with that of in EIM table.
 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:

 Where X: is mapped to \\CRMDEV02\siebsrvr\INPUT
• 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 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.
 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.
 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
• TRIM SPACES

 Optional parameter that specifies whether to remove the trailing spaces from
the column values before importing.
 Example: TRIM SPACES = FALSE
4.4 Export Process Parameters:
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
• CLEAR INTERFACE TABLE

 Optional parameter that specifies whether to remove the old records from the
EIM table whose batch number corresponds to, as defined in the IFB file.
 Example: CLEAR INTERFACE TABLE = FALSE
 If this parameter is set to false, and some rows already exist in the EIM table
for the specified batch, EIM will throw a warning.
• EXPORT ALL ROWS

 This parameter specifies whether to export all rows from the Siebel base
tables that were mapped to the particular EIM table specified in the IFB file.
 Valid values are TRUE or FALSE. Default value is FALSE.
 Example: EXPORT ALL ROWS = FALSE
 When you do an export on party EIM tables, set this parameter to FALSE. If
not EIM will export all party records.
• 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.
4.5 Delete Process Parameters:
This section describes the parameters that are specific to EIM Delete process only.
• CASCADE DELETE ONLY

 Optional parameter that tells whether to delete the child records when a
parent record is deleted.
 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
• CLEAR INTERFACE TABLE

 Optional parameter that specifies whether the existing rows for the particular
batch number should be deleted.
 Default value depends upon the type of delete being done.
 For DELETE EXACT, default value is FALSE, for others, it is TRUE.
 Example: CLEAR INTERFACE TABLE = FALSE
• DELETE ALL ROWS

 Optional parameter that specifies whether to delete all the rows from the base
table.
 Care should be taken while setting this parameter to TRUE in case of party
EIM tables.
 In case of party EIM tables, always use DELETE MATCHES when deleting
records of particular party type.
 Example: DELETE ALL ROWS = TRUE
• DELETE EXACT
 This parameter tells the EIM to use user key matching algorithm with rows in
the EIM table to perform deletion.
 Example: DELETE EXACT = TRUE
 Always use this parameter to delete records from the non target base tables.
• DELETE SKIP PRIMARY

 This parameter tells whether to do a cascade update on the primary child
column in the parent table.
 If the primary address record is deleted, then the primary address column in
the parent table is set to NULL, when this parameter is set to TRUE.
 If set to FALSE, NO_MATCH_ROW_ID gets stored in the primary child
column of the parent table.
 Example: DELETE SKIP PRIMARY = FALSE
• 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.
 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.
4.6 Merge Process Parameters:
This section describes the parameters that are specific to EIM Merge process only.
• SET BASED LOGGING

 This parameter specifies whether to enable the set based logging.
 When enabled, a separate log entry will be generated for all the rows in each
table that were processed by EIM. This allows greater performance.
 When disabled, each and every row processed by EIM will have an entry in
the transaction table.
 Example: SET BASED LOGGING = TRUE
• UPDATE ROWS
 This parameter specifies whether foreign references in the named table
should be updated.
 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.
4.7 Extended Parameters:
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.
Extended parameters are of two types namely:

• User-Defined Extended Parameters

• Predefined Extended Parameters
4.7.1 User-Defined 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 GUI, follow the steps:
• Click on site map, select Server Administration.

• Select Enterprise Operations  Component Requests view tab.
• Create new record and select “Enterprise Integration Manager” in the component
request form.
• In the Component Request Parameter list applet, create new record and click on the
select button in name field.
• Select Extended Parameters in the Job Parameters window and click OK, which will
return to the Component Request Parameter list applet.
• In value field, type parameter and value in the following format:
 name1=value1,name2=value2……name_n=value_n
• Example: FIRST_NAME=Hary
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\"
4.7.2 Predefined Extended Parameters:
Some extended parameters are predefined in Siebel applications which follows the same
name=value format. Below is a list of predefined extended parameters:
• CURRENT_USER – Logon name of the current user.

• PASSWORD – Password of current user.
• CURRENT_DATETIME – Current date & time information.
• ROOT_DIR – Home directory of Siebel server.
• SIEBEL_FILE_DIR – Siebel File System directory.
• LANGUAGE – Language of Siebel server installation.
• TABLE_OWNER – Name of the table owner.
• ODBC_DATA_SOURCE – Connect string for the ODBC data source.
• MAX_NEST_SUBST – Maximum level of nesting in parameter substitution.
• NUM_IFTABLE_LOAD_CUTOFF
• IfbFileName
• TraceFlags
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”

5.0 Import Process:
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.
5.1 Import Process Steps:
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.

Those columns are:
• 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.
5.2 Manual Importing Procedure:
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.
5.3 Different IF_ROW_STAT Values:
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.
IMPORT_REJECTED: Rows which were eliminated as a result of FILTER_QUERY.
IN_PROGRESS: This value is set in the first step, the initialization step, of the import
process.
NOT_ALLOWED: This value is set when a particular operation is not permitted.
PARTIALLY_IMPORTED: The rows got successfully imported for target table but failed for
one or more non-target tables.
PICKLIST_VALUES: Required bounded pick list value could not be resolved.
REQUIRED_COLS: One or more required columns were found NULL.
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.
5.4 Recommended Importing Order:

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:
• Administrative Data (Ex: List of Values)

• Business Units (Organizations)
• Positions
• Accounts
• Contacts
• Employees
• Products
• Opportunities
• Personal Accounts
• Quotes
• Documents
• Forecasts
• Fulfillment
• Marketing Campaigns
• CPG Promotion Management
• CPG Product Movement
• Service Requests
• Product Defects
• Activities and Appointments
• Notes
• File Attachments
In some cases, the import order might change slightly depending upon the business
requirements.

6.0 Export Process:
This section describes the steps involved in an export process, manual procedure to be
followed to accomplish an EIM export process.
6.1 Export Process Step:
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.
6.2 Manual Exporting Procedure:
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.
• Exporting all data rows

• Exporting selected data rows
• Exporting all columns or selected columns

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:
• In the ADMIN directory, open the file named eim_export_lookup_bu_name.sql.

• Locate the appropriate SQL statement for the base table that you are exporting.
• If necessary, modify the SQL statement as required and run it.
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.

7.0 Delete Process:
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.
7.1 Delete Types:
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.
7.2 Delete Process Steps:
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.
7.3 Manual Deleting Procedure:
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.

8.0 Merge Process:
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.
8.1 Merge Process Steps:
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
Winner Record Loser Record
HP Regional HP WW
Hary Potter Peter Parker Hary Potter Oliver Twist
After Merge
HP Regional
Hary Potter Peter Parker Hary Potter Oliver Twist
CONFLICT_ID Set

8.2 Manual Merging Procedure:
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:
IF_ROW_BATCH_NUM ACCOUNT NAME ROW_ID IF_ROW_MERGE_ID

100 HP India 201 NULL
100 HP Regional 202 201
100 HP WorldWide 203 201
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.

9.0 Running EIM:
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.
9.1 Running EIM through GUI:
• Open Siebel Client.

• Go to Server Administration Screen.
• Select Enterprise Operations  Component Request view tab.
• In the Component Request list applet, create a new record.
• In the Component/Job field select Enterprise Integration Manager.
• In the Component Request Parameter list applet, add new record for setting the EIM
parameter.
• Once all the parameters are added, click the menu button in the Component Request
form applet, and click Submit.
9.2 Running EIM through 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.

9.3 Error Flags:
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.
9.4 SQL Trace Flags:
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.
9.5 Trace Flags:
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:
• Server Administration  Component  Component Event Configuration view tab.

• Select the event type and set the appropriate log level.
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:
Event Type Log Level

SQL Tracing 4
SQL Summary 4
Task Configuration 4
Component Tracing 3
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.
• Attachment Imported – Indicates whether the file attachment was encoded,

compressed and copied to the Siebel file server with the new name.
• Attachment (Old) Deleted – Indicates whether an existing file was replaced and
deleted.
• Attachment Not Found – Indicates that the file cannot be found in the INPUT
directory.
• Attachment Identical – Indicates the attachment found in the INPUT directory is
same as that of in the Siebel file server.

10.0 Debugging EIM:
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.
Siebel Base Table Temporary _STA Column Name

S_PARTY T_PARTY__STA
S_ACCNT_POSTN T_ACCNTPOST__STA
S_ADDR_ORG T_ADDR_ORG__STA
S_CTLG_CAT_ORG T_CTLG_CATORG__STA
S_ORG_BU T_ORG_BU__STA
S_ORG_EXT T_ORG_EXT__STA
S_ORG_REL T_ORG_REL__STA
S_PARTY_PER T_PARTY_PER__STA
 If IF_ROW_STAT_NUM and any of _STA column matches, then you can

conclude the error has occurred in that particular table.
• Once you have found out the error and the table in which it occurred, you need to
identify the table’s column where it failed.
• To identify the column either you should inspect the EIM table rows or set the trace
flags, error flags and SQL flags as explained in the previous section.
• Once you run EIM by setting these flags, it will generate a detailed log file using
which you can identify the failed column.
• Once the column is identified, make necessary changes. The changes might be in the
data in EIM tables or in the IFB file.
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:
• Server Administration  Server  Server Components.

• Query for Server Request Processor in the Server Component Applet.
• Click on the Shutdown button and then Startup again.

• 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.
3. What does IFB stands for?

IFB stands for InterFace Builder.
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.
5. What is the effect of setting Docking Transaction Logging parameter to TRUE in

case of EIM export?
Any transaction logging won’t take place, since export process doesn’t change any data
values. Also any parameter setting for transaction logging is ignored.
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
8. Is it valid to set the configuration file in such a way to restrict inserts or

updates in the target base table?
Yes. You can disable the inserts or updates done to the target base table and still it won’t
throw any error, provided the user keys and required column’s values are available.
9. Why am I getting “NOT_ALLOWED” in the IF_ROW_STAT column after EIM

import?
Possible reason could be the misuse of the INSERT ROWS or UPDATE ROWS parameter.
When you set the INSERT ROWS parameter to false and you try to import new record, you
will get this error. When you set the UPDATE ROWS parameter to false and you try to make
changes to this particular record, you get this error.
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.
11. What is an Account Synonym? How it affects my EIM?

A synonym is nothing but an alias name given for any account. These synonyms can be
entered by the Siebel Administrator through Synonym Views. Whenever you do an EIM
Import on accounts, EIM not only checks the user key in the base table but also checks the
associated Synonyms for that account to find a match. This makes EIM time consuming. To
suppress this behavior, you must set the USING SYNONYMS parameter to FALSE.

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

Technical Document Enterprise Integration Manager

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Technical Document Enterprise Integration Manager

Hochgeladen von

Copyright:

Verfügbare Formate

Technical Document Enterprise Integration Manager

10/17/2008 Confidential Page i

Version Date Description of Revisions

10/17/2008 Confidential Page ii

10/17/2008 Confidential Page iii

10/17/2008 Confidential Page iv

Siebel Interface Table

External Data Sources Siebel Base Tables

10/17/2008 Confidential Page 1

2.0 EIM Functions:

• Import new and revised data into Siebel Base Tables

2.1 Importing Data:

Data importing comes into picture under following business requirements:

2.2 Exporting Data:

Data exporting is done under the following business requirements:

• Transferring Siebel data to a non Siebel applications

2.3 Deleting Data:

2.4 Merging Data:

2.5 Process Flow between EIM & Database:

10/17/2008 Confidential Page 2

3.0 Siebel Interface Tables:

• Mandatory columns needs to be populated

Each of the temporary columns has a naming format as follows:

Example: T_ORG_EXT__UNQ, T_ORG_EXT__EXS, T_ORG_EXT__STA, T_ORG_EXT__RID

There are few exceptions for this naming rule.

10/17/2008 Confidential Page 3

3.1 Column Mapping:

This column mapping can be achieved in 2 ways:

• Using bookshelf (<Siebel Bookshelf Path>\ITR.pdf)

Steps in column mapping can be briefed as follow:

• Identify the kind of data in question and Siebel base table

10/17/2008 Confidential Page 4

4.0 Configuration File:

These EIM parameters are classified as follows:

• General Header Parameters

4.1 General Header Parameters:

• LOG TRANSACTIONS TO FILE

10/17/2008 Confidential Page 5

• [Siebel Interface Manager]

4.2 General Process Parameters:

• COMMIT EACH PASS

• COMMIT EACH TABLE

10/17/2008 Confidential Page 6

 Example: COMMIT EACH TABLE = FALSE

• IGNORE BASE TABLES

• ONLY BASE TABLES

• SKIP BU_ID DEFAULT

10/17/2008 Confidential Page 7

• USE ESSENTIAL INDEX HINTS

• USE INDEX HINTS

4.3 Import Process Parameters:

10/17/2008 Confidential Page 8

• IGNORE BASE COLUMNS

• ONLY BASE COLUMNS

10/17/2008 Confidential Page 9

 Where X: is mapped to \\CRMDEV02\siebsrvr\INPUT

10/17/2008 Confidential Page 10

4.4 Export Process Parameters:

• CLEAR INTERFACE TABLE

• EXPORT ALL ROWS

4.5 Delete Process Parameters:

• CASCADE DELETE ONLY