| Siebel EIM > EIM Overview
EIM (Enterprise Integration Manager) Overview
EIM supports the following 4 modes of operation:
o Import
o Delete
o Merge
o Export
Example of an IFB file
[Siebel Interface Manager]
PROCESS = Import_All
;comment
LOG TRANSACTIONS TO FILE = FALSE
USING SYNONYMS = FALSE
USER NAME = "SADMIN"
PASSWORD = "heslo"
PROCESS = Import Everything
[Import_All]
TYPE = SHELL
INCLUDE = Delete_Filenet_Attachment
INCLUDE = Delete_Agreement
[Delete_Filenet_Attachment]
TYPE = DELETE
BATCH = 1000
TRANSACTION SQL = "ALTER SESSION SET OPTIMIZER_MODE = CHOOSE"
LOG TRANSACTIONS = FALSE
[Siebel Interface Manager] = header. This section should have at least one PROCESS value. Can contain constants and variables.
Header section only parameters
CONNECT
LOG TRANSACTIONS TO FILE
USERNAME
PASSWORD
TABLEOWNER
PROCESS
After the header, we declare and describe processes. Each processes have property/value pairs.
We will describe some of the commonly used tables.
e.g.
1) ONLY BASE TABLES = BASE_TABLE1, BASE_TABLE2
This property asks EIM to update only these base tables. EIM tables can still be updated as necessary.
2) IGNORE BASE TABLES = BASE_TABLE1, BASE_TABLE2
This can be used to exclude tables to update and can be a performance enhancer.
3) FIXED COLUMN = COLUMN_NAME, ‘value’
This updates the column to a default value. This reduces performance and should not be used.
4) SESSION SQL = "Alter session set optimizer_mode = all_rows"
This SQL should be without semi colons. We can have only one SQL per process. We cannot execute several.
5) There are 3 parameters; the default values are shown in bold.
ROLLBACK ON ERROR = TRUE|FALSE
COMMIT EACH PASS = TRUE|FALSE
COMMIT EACH TABLE = TRUE|FALSE
For all merge and Delete operations, the values should be like this. (ROLLBACK ON ERROR = TRUE, COMMIT EACH PASS = FALSE, COMMIT EACH TABLE = FALSE)
6) Besides specifying which tables should be updated, we can also set restrictions on the operations of each table.
INSERT ROWS = BASE_TABLENAME, TRUE|FALSE
UPDATE ROWS = BASE_TABLENAME, TRUE|FALSE
DELETE ROWS = BASE_TABLENAME, TRUE|FALSE
INSERT ROWS = TRUE is the default, it is a good idea to state this specifically so that the interface’s intention is not ambiguous.
Full use of INSERT ROWS and UPDATE ROWS will mean that any occurrences of PARTIALLY_IMPORTED should be treated as rightful errors.
7) If NET CHANGE is set to FALSE, we can update columns to NULL.NET CHANGE = TRUE by default.
NET CHANGE = TRUE|FALSE
8) We can set the ifb file to delete all rows only if they match a value.
DELETE MATCHES = EIM_ACCOUNT, (CUST_STAT_CD = ‘Inactive’)
This will delete only those rows that have CUST_STAT_CD = ‘Inactive’ .
This is used specially for cases where index keys are missing or cannot be used to map data.
9) Batch numbers and ranges
BATCH = 1000
BATCH_RANGE=1000-1200
Each batch number can contain a number of rows. Depending on the mode (e.g. Delete/Merge), tables used and database used, there are limits to how many rows can be used per batch number.
e.g. For deleting activities in Oracle, the maximum suggested limit is 140000 rows per batch number.
IMPORTANT Columns
There are some columns used to check status and debugging.
IF_ROW_BATCH_NUM
ROW_ID
IF_ROW_MERGE_ID
IF_ROW_STAT
The value of IF_ROW_BATCH_NUM is set in the BATCH or BATCH_RANGE parameter in the IFB file.
ROW_ID is a unique number that identifies each row within a batch number. ROW_ID and IF_ROW_BATCH_NUM together form a unique ID.
IF_ROW_MERGE_ID is a unique number of each row that will be merged into. In a merge process one row is deleted and the contents of the deleted row are inserted into another row. The row that is not deleted has a IF_ROW_MERGE_ID. IF_ROW_MERGE_ID and IF_ROW_BATCH_NUM together make a unique combination.
IF_ROW_STAT – This is the status of the row that is being changed. The initial status is usually ‘FOR_IMPORT’, ‘FOR_MERGE’,’FOR_DELETE’. The status changes during and after the IFB process.
IF_ROW_STAT values
AMBIGUOUS
There are two rows in the base table that have the same user key but different conflict IDs. EIM cannot distinguish these rows.
DUP_RECORD_EXISTS
The row exactly matches rows that already exist in the destination tables. This error occurs in Step 8. Note that a row may have a duplicate in the target base table, but not in other destination base tables. In this situation, EIM adds the new relation (a child or intersection table) in the other destination base tables, and does not mark the EIM table row as a duplicate.
DUP_RECORD_IN_EIM_TBL
The row was eliminated because it is a duplicate (has the same user key) of another row in the EIM table with the same batch number. In this case, MIN(ROW_ID) is the record processed, and the other records with the same user key are marked as DUP_RECORD_IN_EIM_TBL.
Do not confuse DUP_RECORD_IN_EIM_TBL with DUP_RECORD_EXISTS. DUP_RECORD_EXISTS status indicates that the same record already exists in the base table, while DUP_RECORD_IN_EIM_TBL status indicates that there are two or more EIM table records having the same user key values.
FOREIGN_KEY
A required foreign key column in the target table could not be resolved.
IMPORTED
The row was successfully processed against all its destination base tables. This status is set after the import has been completed.
You can check the import status by using database commands to query the appropriate EIM tables for rows whose IF_ROW_STAT value is not equal to IMPORTED. The result is a list of rows that were not successfully imported.
IMPORT_REJECTED
A user-specified filter query failed for this row. This error occurs in Step 3 if the user has specified FILTER QUERY expressions.
IN_PROGRESS
In Step 1, EIM sets IF_ROW_STAT to this initial value for all rows in the batch. If rows still have this status value after EIM exits, a failure occurred that aborted processing for this table.
NON_UNIQUE_UKEYS
The user key was not unique in all the user key specifications on the table.
PARTIALLY_IMPORTED
The row did not fail for the target table (although it may have been a duplicate), but did fail during processing of a secondary base table. This status is set after the import has completed.
PICKLIST_VALUE
A required picklist value in the target table could not be resolved. This error occurs for NULL or invalid bounded picklist values.
REQUIRED_COLS
One or more required columns for the target table were NULL. This error occurs for missing user key columns in when inserting new rows .
ROLLBACK
EIM encountered an error, such as an SQL database failure, and rolled back the transaction. This status is only used when ROLLBACK ON ERROR = TRUE.
SQL_ERROR
An SQL error occurred during an attempt to import this row. This error occurs for rows processed when Enable Transaction Logging is set to TRUE.
We can check status of rows being updated with an SQL like this – select count(*), IF_ROW_STAT from tablename where IF_ROW_BATCH_NUM =’BATCH_NUMBER’;
The T-Columns
There are several columns that start with t_ in eim tables. These can be used to debug columns.
Usually there is a t column based on EIM table column name.
e.g. ADDR_PER column will have a column called T_ADDR_PER__STA in some EIM table.
If the T_column__STA columns have values, it means that there has been an error in this row.
Several columns are just preceeded by T_. e.g.
T_DELETED_ROW_ID
T_ADDR_PER_PER_ID
T_MERGED_ROW_ID
You can use T_DELETED_ROW_ID to find out which row was deleted in a merge. T_MERGED_ROW_ID to find out which row remains in a merge. And so on. T_ columns are not well documented in Siebel.
Calling EIM jobs from the command line
Only some users have rights to run EIM jobs (or server manager to be exact). These users must have ‘Siebel Administrator’ in responsibility and must have SSE_ROLE plus CONNECT in Database plus must belong to SSE_ROLE in UNIX groups.
The format of the command is
$SIEBEL_ROOT/bin/srvrmgr -g $GATEWAY:$GPORT -e $ENTERPRISE -s $APPSERVER -u $SUSER -p $SPASS -c "run task for component eim with config="$IFB", traceflags=3, errorflags=1, SQLFlags=8, ExtendedParams="BatchRange=$BATCH", Process="$PNAME""
First go to siebsrvr and load . ./siebenv.sh
Errorflags,Sqlflags and Traceflags
Error Flags:
By setting the Error Flags to appropriate levels, a detailed explanation of rows that were not successfully processed, can be obtained.
Setting the task parameter "Error Flags" = 1 can be used to write a detailed description of the cause of each error to the task log during processing.
SQL Trace Flags:
The SQL Trace flags parameter is used for logging SQL statements that make up the EIM task.
Setting the SQL Trace Flags parameter to 8 creates a log of the summary SQL statements that make up the EIM task.
Since it dramatically impedes EIM performance and created a large log file, hence this option is recommended only for test environments.
The lower values for SQL Debug Flags (1, 2, and 4) are used for logging at the ODBC level.
Trace Flags:
Trace flags contain logs of various EIM processing steps. Siebel 7.x onwards, Event Logging needs to be set for the EIM component, in order to activate Trace Flags.
For settingEvent Logging, the following sequence needs to be followed:
1. Click the Server Administration screen tab.
2. From the Show drop-down list, select Component.
3. Select Enterprise Integration Manager as the component.
4. Click Component Event Configuration.
5. Perform a query and enter the Log Level values for the following:
EVENT TYPE LOG LEVEL VALUE
SQL Tracing 4
SQL Summary 4
Task Configuration 4
Component Tracing 3
Trace Flags are bit-based. Available Trace Flags include 1, 2, 4, 8, and 32. To activate multiple trace flags, the Trace Flags parameter has to be set to the sum of individual trace flag numbers. For example, to log trace flags 2 and 4, the Trace Flags parameter needs to be set to 6.
Setting Trace Flags to 1:
Setting the Trace Flags parameter to 1 creates a step-oriented log of the task. This can be used to determine the amount of time EIM spends on each step of the EIM task, or for each interface table processed.
Setting Trace Flags to 2:
Setting the Trace Flags parameter to 2 creates a file log that traces all substitutions of user parameters.
Setting Trace Flags to 4:
Setting the Trace Flags parameter to 4 creates a file log that traces all user-key overrides.
Setting Trace Flags to 8:
Setting the Trace Flags parameter to 8 creates a file log that traces all Interface Mapping warnings.
Setting Trace Flags to 32:
Setting the Trace Flags parameter to 32 creates a file log that traces all file attachment status. The trace file contains four labels, three of which are used to trace file attachment processes as described.
LABEL DESCRIPTION
Attachment Imported
Indicates whether the file attachment was encoded, compressed, and copied to the Siebel file server with the new name
Attachment (Old) Deleted
This label applies only to updates and indicates whether an existing file was replaced and deleted
Attachment Not Found
Indicates that the file attachment cannot be found in the input directory
| 
