Scenario 1:How are CREATED and CREATED_BY columns populated using EIM?

In standard Siebel applications, 'CREATED' and 'CREATED_BY' are system columns that will be automatically populated when importing data via Enterprise Integration Manager (EIM). The starting time of the EIM server task and login information of the employee starting the EIM server task populates these columns. There is no EIM mapping from the Siebel Interface tables to the CREATED and CREATED_BY columns in any of the base tables. The following interface tables are an exception. They have a mapping into the 'Created By' column: EIM_LITERATURE, S_ACTIVITY_IF, S_APPT_IF, S_CONTACT1_IF, S_CONTACT2_IF, S_CONTACT_IF, S_FSCT_ACCNT_IF, S_FSCT_OPTY_PRD_IF, S_FSCT_OPTY_IF, S_FSCT_POSTN_IF, S_FSCT_PROD_IF, S_FUL_IF, S_FUL_ITEM_IF, S_LITERATURE_IF (and EIM_APP_QUERY for version 7). Please note that The S_ type interface tables are provided for backward compatibility with releases prior to 6.x, as they do not provide support for multiple organizations they should be used only in an environment with a single organization, or under exceptional circumstances. As a consequence, it is not possible to populate or update 'CREATED' and 'CREATED_BY' via EIM (except if the mapping already exists), And as they are systems fields it is also impossible to update them via the GUI or Siebel VB. If you need to populate, or update these system fields with a different value than the default one, and you cannot use the EIM tables above, the only solution is to create an extension column to store these values. Siebel applications support extensions made to the database and modifications made to the user interface. Given below is a one way to accomplish this: 1. Add two extension columns to a base table and give them unique names (that is, "X_CREATED_DATE", "X_CREATOR"). 2. Add two extension columns to the corresponding interface table. 3. Map extension columns in the interface table to the extension columns in the base table. 4. Configure the applications so that two new extension columns will be displayed in user interface. 5. Populate data via EIM, User Interface or VB/OLE. You might want to store a foreign key in the extension column, and as documented in the Siebel Tools Guide, if you choose to implement this, you must consult with Siebel Expert Services concerning the visibility rules applied to the foreign key table, and in order to add an EIM foreign key mapping Scenario 2:Recovery After an Aborted Run of IFMGR

Enterprise Interface Manager (EIM) performs many SQL statements on an interface table while preparing rows for being inserted or updated into the base tables during import. Once the interface table has been prepared (all rows have been validated and any foreign key values have

there is additional support for EXPLICIT primary key updating and the information given below can be applied equally to both types of primary key updates other than where the information refers specifically to IMPLICIT primaries. EIM uses set-based processing for all preparation steps (1 through 7) and for inserting new rows (step 9). EIM will usually use row-by-row processing for the actual updates to maximize the granularity of the transaction log. Summary In order to maximize performance of importing.ifb) file will cause EIM to only commit after the entire batch (for all interface tables and for primary processing) has been completed and to roll back the transaction on error. Regardless of whether set-based or row-by-row processing is done. typically the database will run out of transaction log (sometimes called rollback) space. However. it resolves "primary child keys" within base tables imported from all interface tables of the batch. Note that steps 1 through 9 processing occur completely for each interface table in the order specified in the batch file. but not the corresponding addresses in the event of an unrecoverable failure after the S_ORG_EXT inserts but before the S_ADDR_ORG inserts. etc. the database will roll back the transaction itself. It is possible to configure your database with a very large amount of transaction log space in which case this option is feasible. EIM will operate on all rows for each target base table (one at a time). Another problem is that EIM will obtain many locks during the course of processing the (potentially long running) transaction. when importing from S_ACCOUNT_IF (or EIM_ACCOUNT in Siebel version 6. but an unrecoverable failure will halt processing before primary key updating (step 10) is complete. Like updating. This will result in primary child keys not being correctly set (usually left as NULL if not satisfied during regular imports). it proceeds to update existing rows with data from the interface table (step 8) and insert new rows (step 9). In Siebel 2000.) This solution is ideal if the database configuration can support it. populating only S_ORG_EXT (Account headers) and S_ADDR_ORG (Address children of S_ORG_EXT). which will reduce concurrency of the database. aborting the EIM process. For example.) may leave some of the tables inserted or updated but others not. Because of the large amount of space required by updates. primary key processing (which is always updating) will use row-by-row processing when transaction logging is turned on. Please note the primary key updating referred to be that of the implicit primary key processing carried out by Siebel in versions prior to Siebel 2000. if transaction logging is turned on. Lastly. Because all processing occurs in a table-by-table manner. Another possibility is that the regular importing will succeed for some or all tables. but step 10 occurs for all interface tables after the normal import processing has occurred for all interface tables. but can be a significant issue for continuous updates in a running installation. For example. This is not an issue during initial load. an unrecoverable failure while running EIM (such as SQL server shutdown. causing the EIM run to hang or fail. it is possible for new Accounts to have been inserted into S_ORG_EXT. Controlling the SQL Transaction Granularity The most obvious way to fix this is to use the database-supplied transaction control operations to provide an "all or nothing" model for interface manager. (More likely.x). . a maximally cautious setting of: COMMIT EACH TABLE = FALSE COMMIT EACH PASS = FALSE ROLLBACK ON ERROR = TRUE in the configuration (.been looked up).

Scenario:. However. For example. To allow for custom processing at the start of one of these processes. This is not ideal. However. since it requires extra queries and updates when the records are visited the first time. Re-running EIM After A Failure A simpler and less configuration intensive option is to re-run the batch during which the failure occurred. The common primary keys are handled quickly and seamlessly by the Siebel Client. EIM allows administrators to define processes that import. This is normally not recommended as this processing can be slow since it must check all rows in the base tables (not just the ones newly imported).If possible. it will re-validate all primary keys for the base tables. . This will result in the import being completed (possibly with some warnings about "all rows being duplicates" for tables which had been successfully imported before the failure). On the second run of EIM. Note that no batch number is required because no data will be imported. In some cases the client may display inconsistent behavior before the primary keys are patched up (either by EIM or the Client) on some more complex views such as Territory Administration. As the users visit the records. the rows already exist. EIM allows users to specify a single user-defined SQL statement for each EIM process. However some primary key processing may not have been done in this case because it is only scheduled for newly imported rows. export.3 Running Multiple SESSION SQL statements for Enterprise Integration Manager Processes Background Enterprise Integration Manager (EIM) is a powerful and flexible tool provided by Siebel eBusiness Applications to enable a two-way information exchange with other enterprise applications. In general. EIM did not complete and the processing was not done. This is the reason that primary keys not set properly by EIM are usually not noticed by users. For example. the account address primaries are patched up automatically with no user visible effect (other than a slight slowdown the first time the record is seen). it is better to fix the primary keys using EIM than to leave them for the Client to fix up. which are invalid as the records are visited. primary key processing was scheduled to be done for the successfully imported rows in S_ORG_EXT after the initial import. this option is strongly recommended because it provides the best reliability and error recovery. It is possible to re-run implicit primary key processing in absence of actual import using a special batch identified by setting the PRIMARY KEYS ONLY = TRUE property. in the S_ACCOUNT_IF example given above. The interface tables specified in the batch are only used to determine which base tables should be operated on. the client will reset the primary keys appropriately. The Siebel Client and Primary Keys The Siebel client application (siebel. however.exe) will also patch up primary keys. so the implicit primary key processing is not rescheduled since normally primary key processing does not need to be done for existing rows. Primary key update processing only operates on base tables. which correspond to the interface tables specified in the batch. delete and merge data.

to import only the opportunities that were generated by a specific campaign (for example. as well as the parameters of the process. Upgrade Campaign). Since EIM allows only one SESSION SQL statement per process. the contents of which specify the kind of process to perform. Users can either set the BATCH NUMBER for this dummy process to an unused batch number. In these configuration files. users who want to execute multiple SQL statements are faced with a dilemma. Within each EIM process definition.000. users can define a single SQL statement to be executed at the beginning of the EIM session. or use an unused EIM table.ifb files).This SQL statement is sent directly and un-interpreted to the database server before any other SQL statements for the process. Solution The method used is to break up the original EIM process into 2 separate processes. The new configuration file should look like this: [Siebel Interface Manager] LOGIN USER = "SADMIN" LOGIN PASSWORD = "SADMIN" RUN PROCESS = Import New Opportunities . use the following SESSION SQL to delete all the other opportunities from the EIM table: SESSION SQL = "delete from EIM_OPTYwhere src_name <> 'Upgrade Campaign' and if_row_batch_num = 1 and if_row_stat = 'FOR IMPORT'" To assign a specific sales cycle code (example: High Revenue Qualification) to those opportunities with revenue exceeding $100. use the following procedure to accomplish the task. or even perform updates to Interface table data. export. each with a SESSION SQL. For example. users define processes to import. EIM reads the configuration files (. Create a shell process to call both processes. This technical note explains how to cause multiple SQL statements to be executed at the start of an EIM process Summary At the beginning of an EIM session. execute another SQL statement. Assume that the following configuration file is used: [Siebel Interface Manager] LOGIN USER = "SADMIN" LOGIN PASSWORD = "SADMIN" RUN PROCESS = Import New Opportunities [Import New Opportunities] SESSION SQL = "delete from EIM_OPTYwhere src_name <> 'Upgrade Campaign' and if_row_batch_num = 1 and if_row_stat = 'FOR IMPORT'" TYPE = IMPORT BATCH NUMBER = 1 TABLE = EIM_OPTYROLLBACK ON ERROR = TRUE To add another SESSION SQL. since only one SQL statement is allowed per process. This statement is called the SESSION SQL and is executed before the rest of the SQL statements. create a dummy process that contains the other SESSION SQL. However. delete or merge data. Users can use this SESSION SQL statement to validate interface table data against existing base table data.

pass 100: No rows exist in IF table for this batch.[SESSION SQL Step] SESSION SQL = "delete from EIM_OPTY where src_name <> 'Upgrade Campaign' and if_row_batch_num = 1 and if_row_stat = 'FOR IMPORT'" TYPE = IMPORT BATCH NUMBER = 9999 TABLE = EIM_OPTY [Opportunity Import Step] SESSION SQL = "update EIM_OPTY set stg_name = 'High Revenue Qualification' where prod_revn > 100000 and if_row_batch_num = 1 and if_row_stat = 'FOR IMPORT'" TYPE = IMPORT BATCH NUMBER = 1 TABLE = EIM_OPTYROLLBACK ON ERROR = TRUE [Import New Opportunities] TYPE = SHELL INCLUDE = SESSION SQL Step INCLUDE = Opportunity Import Step When EIM runs. The SESSION SQL defined in [Opportunity Import Step] will be executed and the resulting opportunity rows will be imported into the Siebel base tables.1. -----------------------------------------------------------------------Process [SESSION SQL Step] had all rows fail on EIM_OPTY for batch -9999 in step 1. users can execute as many SESSION SQL statements as necessary to complete their custom processing. table aborted) No rows exist in this interface table.15 failure log (pid 172). With this technique. This means that no rows exist to be imported from this interface table. (severity 2. the first process will be called and the delete statement will be executed first. which correspond to this batch number. EIM processing will continue with the second process. processing was discontinued. Scenario:4 Deleting Data Through Interface Manager Background Siebel eBusiness Application provides three mechanisms for deleting records through Enterprise Integration Manager (EIM).2 [217] . Since there was a problem with the configuration of this interface table. However. EIM will then generate a failure in the failure log: IFMGR: Interface Manager v2. This technical note briefly covers these scenarios and then gives . processing of other interface tables will continue.

For further information.5 all the _IF tables have been deactivated. The example SQL statements provided in this technical note would change depending on which release is installed. These are: 1. The EIM provides full transaction control. Deleting all rows for a named table 2. the columns must be available in the base table. export. and customer service applications. accounting. Siebel eBusiness Application provides a powerful mechanism for two-way information exchange with other enterprise applications such as manufacturing. Of the available operations. Three mechanisms are available for specifying which rows should be deleted: 1. (last_upd < '1993-01-01') If method 3 is to be used. the WHERE clause specifies one or more columns in the base table. The source or campaign associated with a specific contact (this is not exposed . 1993 had to be deleted. deleting allows for the purging of data from the Siebel eBusiness Application tables. then the following line would be used in the EIM configuration file to delete those accounts: delete matches = EIM_ACCOUNT. including support for bulk import. A column from a joined table represented by a many-to-many relationship (normally represented in the Siebel eSales UI as a multi-value group) An example of each scenario would be: 1. delete. Check the Interface Tables Reference Guide to determine which fields comprise the user key and the names of the required fields. The SIC codes for an account 2. In Siebel 7. Customer must use EIM_ table for all interface jobs. the suggested interface tables are called EIM_*. Although Siebel 2000 and Siebel 7 continue to support the S_*_IF tables. Siebel version 7 information: The new S_PARTY table introduced in Siebel version 7 has many implications on performing DELETE with EIM. order entry. For example. example: EIM_CONTACT. if all accounts that had not been modified since January 1. please refer to the ALERT 0359: EIM EXPORT / DELETE functionality for S_PARTY based tables in Siebel version 70. Summary Through the EIM server module. This document assumes a working knowledge of EIM and SQL statements. There are two specific situations where the columns that are not in the base table for the delete processing may need to be specified. Deleting data rows identified by user key values in the corresponding interface table 3. A column from a joined table representing a one-to-many relationship (normally represented in the Siebel eSales User Interface (UI) as a picklist) 2.details of how to delete records that cannot be removed by directly utilizing these mechanisms. Deleting data rows identified by a WHERE-clause expression in the configuration file In method 3 mentioned above. and merge operations through Siebel Interface tables.

because users must look to the non-base tables to qualify the match (column NAME in S_INDUST for example 1 and column NAME in table S_SRC for example 2.in the default configuration. Perform the delete processing. 2. Make sure that the interface table is empty Although the interface table need not actually be empty.NAME. then do so. Export user key columns for the base table into the interface table. if the user keys of the records to be deleted could somehow be placed into the appropriate interface table then method 2 could be used to delete these records (remember that this method uses the records in the interface table to drive which base table records should be deleted). Approach 1 The steps to achieve the required results are as follows: 1. The if_row_batch_num . This process demonstrates exporting data into the Siebel . Export only the user key columns so that the size of the interface table is minimized. 4. S_ORG_EXT. In this example. 3. account interface table. Delete those records that do not match the criteria for deletion from the interface table. but is given here as it is a good basis for an example that follows) These two scenarios cannot be solved by using method 3 indicated above.). This technical note describes a method that allows for the deleting of rows that fall into either of the two categories. 1. Export user key columns for all records in the base table into the interface table. [Export All Accounts] TYPE = EXPORT BATCH = 1 TABLE = EIM_ACCOUNT ONLY BASE COLUMNS = S_ORG_EXT. all of the user key columns for S_ORG_EXT are exported into EIM_ACCOUNT (if there is some way of reducing this list. Make sure that the appropriate interface table is empty. this step is included to highlight the behavior that any records left in the interface table before the delete step WILL be deleted from the corresponding base table unless the batch numbers are modified accordingly to exclude them.LOC. All example SQL statements have been written to run against an Oracle database. 2. given the columns that users can qualify against. is 1 for the rows to be exported. . The configuration file for this process would look like: [Siebel Interface Manager] USER NAME = "SADMIN" PASSWORD = "SADMIN" PROCESS = Export All Accounts . Step Details The following example explains how to delete all those accounts with a particular SIC code. otherwise export all rows). However.

for example. Delete from the interface table those accounts that do not match the criteria for deletion This step will clear from the interface table those rows that SHOULD NOT be deleted from the base table. in general. then the following SQL statement would be used against EIM_CONTACT to remove these rows or accounts: DELETE FROM EIM_ACCOUNT // Delete accounts with no match WHERE ACCNT_NAME NOT IN (SELECT NAME // Get name. should. 10. be possible. 4. which will remove from the interface table all those rows that are not to be deleted from the base table during delete processing. the following SQL would be required: DELETE FROM EIM_ACCOUNT // Delete accounts with no match WHERE ACCNT_NAME NOT IN (SELECT NAME // Get name. loc for accounts FROM S_ORG_EXT WHERE (ROW_ID IN (SELECT OU_ID FROM S_ORG_INDUST WHERE INDUST_ID IN (SELECT ROW_ID FROM S_INDUST WHERE SIC = '10')))) Note that in this example all accounts that have the specified SIC code are deleted.BU_ID EXPORT ALL ROWS = TRUE 3. Perform the delete processing . In the example. accounts that do not have a specific SIC code are being removed form the interface table. loc for accounts FROM S_ORG_EXT WHERE (ROW_ID IN (SELECT OU_ID FROM S_ORG_INDUST WHERE INDUST_ID IN (SELECT ROW_ID FROM S_INDUST WHERE SIC = '10'))) AND ROW_ID NOT IN (SELECT OU_ID FROM S_ORG_INDUST WHERE INDUST_ID IN (SELECT ROW_ID FROM S_INDUST WHERE SIC <> '10'))) Variations on the DELETE statement.S_ORG_EXT. even if they also have other SIC codes. If the SIC code is. To keep those accounts that also had other SIC codes.

[Delete Accounts With SIC] TYPE = DELETE BATCH NUMBER = 100 TABLE = EIM_ACCOUNT DELETE ROWS = TRUE DELETE EXACT = TRUE Approach 2 The second approach is to merge steps 1 and 2 from Approach 1.PAR_ROW_ID AND (S_ORG_EXT. Before running EIM. In the example. the following configuration file contents would perform a delete of the required rows.NAME) IN (SELECT NAME FROM S_ORG_EXT WHERE (ROW_ID IN (SELECT OU_ID FROM S_ORG_INDUST WHERE INDUST_ID IN (SELECT ROW_ID FROM S_INDUST WHERE SIC = '10'))) AND ROW_ID NOT IN (SELECT OU_ID FROM S_ORG_INDUST WHERE INDUST_ID IN (SELECT ROW_ID FROM S_INDUST WHERE SIC <> '10'))) . delete all accounts with SIC code '10' and which have no other SIC code): INSERT INTO EIM_ACCOUNT (PARTY_UID.ROW_ID) SELECT S_PARTY.Now that the interface table contains the user key for those rows to be deleted. The if_row_batch_num is 100 for the rows . be sure to set the appropriate values for IF_ROW_STAT ('FOR_IMPORT') and IF_ROW_BATCH_NUM (100 in this example): [Siebel Interface Manager] USER NAME = "SADMIN" PASSWORD = "SADMIN" PROCESS = Delete Accounts With SIC . EIM can be used with the delete operation. the interface table is directly populated with the required row set to be deleted. the following SQL would populate the interface table EIM_ACCOUNT with those account user key that would need to be deleted (in this example. In the example. S_PARTY.S_PARTY. 100. account table.ROW_ID FROM S_PARTY.PARTY_UID. 'FOR_IMPORT'. to be deleted. IF_ROW_STAT. This can be further extended to perform the delete in multiple phases or batches etc.ROW_ID = S_ORG_EXT. PARTY_TYPE_CD. S_PARTY.PARTY_TYPE_CD. IF_ROW_BATCH_NUM. This process demonstrates deleting data from the Siebel . That is. S_ORG_EXT WHERE S_PARTY.

Another Example As another example. The EIM configuration file is as follows: [Siebel Interface Manager] USER NAME = "SADMIN" PASSWORD = "SADMIN" PROCESS = Delete Contacts For Source . 'FOR_IMPORT'. always take extra care because once the records are deleted they are removed from the Siebel database. the above technique shows how.ROW_ID NOT IN (SELECT PER_ID FROM S_OPTY_CON CON.The benefit of this approach is that it should.ROW_ID AND ORG.PR_DEPT_OU_ID AND SRC. S_SRC SRC.). Siebel applications provide the columns required to qualify records for delete (or for that matter export) in the appropriate interface table. S_SRC SRC WHERE CON. In this example.ROW_ID AND SRC. Whenever deleting records using EIM. 100. CON. That is. . The account name and location are also extracted so that the correct contact is deleted (the contact last name and first name is unique to an account location so be sure that the correct contact for the correct account or location is deleted). The SQL statements required to populate the interface table S_CONTACT_IF would be as follows: INSERT INTO EIM_CONTACT (PARTY_UID. to be deleted. require less system resources (example: database structures such as rollback segments and system resources such as CPU and disk I/O) to achieve the same result. if a user wanted to delete all contacts associated with a specific source (PC Expo 1996) for which no corresponding opportunity exists. in general. Use the second approach to populate the interface table (EIM_CONTACT) before running the delete process in Interface Manager. The if_row_batch_num is 100 for the rows . This process demonstrates deleting data from the Siebel .ROW_ID) SELECT PERSON_UID. a contact can only be linked to one source. Consider all steps that should be taken prior to the delete to allow for quick recovery should the delete be incorrect (example: backup. 'Person'. contact table. [Delete Contacts For Source] TYPE = DELETE BATCH = 100 TABLE = EIM_CONTACT DELETE ROWS = TRUE DELETE EXACT = TRUE Comments Generally.NAME = 'PC Expo 1996') Notes: • • The interface table column ROW_ID has been set to the contact ROW_ID to make sure uniqueness (the field is a required field).NAME = 'PC Expo 1996' AND CON. through the use of SQL statements and a working knowledge of the Siebel eSales data model.ROW_ID = CON. all contacts for the campaign where no opportunity was generated are to be deleted. export etc. IF_ROW_STAT.ROW_ID FROM S_CONTACT CON. S_ORG_EXT ORG WHERE CON. IF_ROW_BATCH_NUM.SRC_ID = SRC. the contacts were originally loaded and associations made to the source. PARTY_TYPE_CD.SRC_ID = SRC. This alleviates the need to know both SQL statements and the Siebel eSales data model. However. Upon completion of the campaign.

This is true for any release before Siebel 6. navigate to Site Map > Data Administration > Accounts This will display either the 'Account Administration View' for Siebel eBusiness Applications. a primary position must be assigned to each account. the above SQL statements will work well for small data sets. In general.21 (build 10257) and beyond the format is changed to "XXXXX-XXX". This is the normal behavior before Siebel 6.2. and EIM is run to process the set.x and version 7.x.1. Siebel Technical Account Manager or Systems Integrator). log on to the application using the administrator username and password and navigate to Screens > Marketing Administration > Accounts in Siebel eBusiness Applications. From Siebel release 6. MidMarket Edition version 7. In Siebel eBusiness Applications.1. Scenario: 5 The ROW-Ids generated using EIM look like "1+9W+6961". the records will be deleted and it will be very difficult to reverse the operation.users can define record sets that would not otherwise be possible.x or Siebel Workgroup Applications version 5. If the SQL statements that defines the record set to be deleted is written incorrectly. Is the plus sign ("+") delimiter correct behavior? Yes. the plus sign ("+") delimiter is added for the row id if the record originates from an EIM import. Through the user interface: After importing accounts through the Data Integration Manager (EIM).2. but care should be taken in writing such SQL statements for large data sets where database and other system resources should be carefully considered. The format of the Row Id is one of the following: 1. Also true for siebel7. 2.1. This can be accomplished in a number of ways: 1. always use the standard mechanisms within EIM for deleting records wherever possible.2. If the above technique is to be used. MidMarket Edition version 6.x or the 'Account .21 (build 10257). then make sure that an individual experienced in writing SQL statements that also has a working knowledge of the Siebel Sales Enterprise data model is involved (such as the local DBA. 3. CP-NS For records created by the Siebel eBusiness Applications.x.0 releases Scenario:6 How can Accounts be viewed after importing them through the Data Integration Manager (EIM)? In order to see imported accounts using the views in the Account screen. MidMarket Edition user interface. CP+NP+NS For records created by Data Integration Manager (EIM).21 (build 10257). MidMarket Edition version 6. Also.

x and version 7. Here are some options that can be tried to improve Enterprise Integration Manager (EIM) performance: Check to make sure all the standard indices are in existence for the tables involved. will be used to set the primary position in the account in S_ORG_EXT.PRIV_FLG using EIM. . This specification can be enforced by adding FIXED COLUMN=CON_PRIV_FLG. an explicit primary position can be set using the primary column.x) or EIM_ACCOUNT (in Siebel eBusiness Applications MidMarket Edition version 6.x.PR_POSTN_ID. MidMarket Edition. 3. For example. 'N' in the ifb file.x. Using EIM: Import positions into S_ACCNT_POSTN via S_ACCOUNT_IF (in Siebel Workgroup Applications version 5. A territory rule must be defined for the Account assignment object. For contacts loaded using EIM. the ACC_PR_POSTN column when set to "Y". Scenario: 7 Can the PRIV_FLG column of S_CONTACT base table be updated using EIM? No. the only supported value for the PRIV_FLG is "N". Scenario: 8 How can I tune my EIM batches to improve performance? This FAQ is also applicable to Siebel Enterprise Application. However. 2. specifying the Account assignment object. add the required position.x).Administration View (SWG)' for Siebel Workgroup Applications version 5. Currently it is not possible to update the S_CONTACT. Limit tables and columns to be processed using ONLY BASE TABLES/COLUMNS configuration parameters to minimize the work that EIM has to perform. The S_CONTACT. All accounts will be displayed regardless of whether or not a position is assigned to an account. in EIM_ACCOUNT table. Select the account and in the 'Account Team' multi value field (MVF).PRIV_FLG is not part of the user key to the S_CONTACT table. Employees holding this position can view this account in the Account Screen. In Siebel eBusiness Applications MidMarket Edition version 6. Assignment Manger must be run in batch mode. Using Assignment Manager: Positions can be assigned to accounts using Assignment Manager. it is included in the criteria used by Enterprise Integration Manager (EIM) to locate an existing row in the S_CONTACT table.x and version 7. identifying which positions are to be assigned to the accounts.

preferably less than 2000 rows in a single batch. Siebel Systems has highly recommended the Oracle rule-based optimizer because it provides the consistent behavior needed for effective performance tuning. Avoid using the UPDATE PRIMARY KEYS parameter in the IFB file. which means EIM does not use use append mode for insert at EIM process step 9. Try different batch sizes. Version 7. this is documented in the Bookshelf: Siebel Enterprise Integration Manager Administration Guide > Frequently Asked Questions > Performance Questions. How can I tune my EIM batches to improve performance? . For Siebel eBusiness Application Version 6. Delete batches from interface tables on completion. large batch sizes are not the most efficient. Please refer to Siebel Enterprise Integration Manager Administration Guide. The default value is FALSE. If you need to improve step 9 performance. Perform regular table maintenance on interface tables. * Delete and Merge performance is improved if you create some specific temporary indices first. ORACLE INSERT APPEND MODE. The database administrator will know how to detect and correct fragmentation in the EIM interface tables. set "Trace Flags"=1 and "SQL Trace Flags"=8 and rerun the batch. The resulting task log will identify slow running steps and queries. This will definitely improve performance. Creating Temporary Indexes for more details * If using Oracle database. Note: For Siebel eBusiness Application Version 7. this is documented in the Bookshelf: Siebel Enterprise Integration Manager Administration Guide > Advanced Usage > Questions and Answers > Q. Leaving old batches in the EIM interface table will waste space and could adversely affect performance. avoiding a deadlock when running parallel EIM processes. EIM jobs that have no interface or base tables in common can be run in parallel. This allows users to run with smaller batch sizes and yet avoid the startup overhead on each batch. Try using batch ranges (BATCH = x-y). however. it must be balanced with the need for mobile users to re-extract afterwards.IFB file to indicate to EIM that account synonyms do not need to be checked. ensure that Oracle rule-based optimizer is used. Run independent EIM jobs in parallel. If all else fails.5. Set the USING SYNONYMS parameter to false in the . Frequent insert or delete operations on interface tables can cause fragmentation in the table. Often.Consider switching off Siebel transaction logging during the EIM run. you can set the value to TRUE. Siebel Systems recommends that customers use a batch size no more than 5000 rows.

It also allows users to generate a selective report of only the EIM tables a customer is using. INTEGRATION_ID is an alternative user key in S_PROD_INT. 4. such as NAME and VENDR_OU_ID. whiles S_ORG_EXT. EIM does NOT log any transactions for mobile users. Note that when using MISC SQL in Siebel 7 to set Primary Child Foreign Keys. S_POSTN. Note that S_PARTY table is the target base table. Any data schema change will have impact on EIM behavior.exe Utility Siebel Data Model changes from release to release. utleimdiff. . A marker transaction will be created in S_DOCK_TXN_LOG table. Users should only use this parameter in their initial data loading.Scenario: 9 What’s New in Enterprise Integration Manager (EIM) Siebel 7? Background Enterprise Integration Manager (EIM) is one of the server components in EAI Component Group. 3. MISC SQL Parameter MISC SQL parameter is introduced in Siebel 7 to allow EIM to set certain Primary Child Foreign Keys.exe utility can be used to find differences in all interface tables between two repositories. These schema changes have direct impacts on EIM behavior. EIM_PROD_INT_UK EIM_PROD_INT_UK in version 7 can be used to update user key columns in S_PROD_INT. S_EMPLOYEE table becomes obsolete in version 7. S_POSTN now become the extension tables of S_PARTY table. Summary 1.PR_OU_ADDR_ID. utleimdiff. S_USER.dx files stored in the File_System\EIM directory. 6. EIM Table Mapping Wizard EIM Table Mapping Wizard is introduced in Siebel 7 to assist adding custom extensions to the Data Model: • • • Add new customer columns to existing Siebel Table Add new extension table Add new intersection table 5. The results can be used to help existing users prepare their interface tables for EIM data loading. LOG TRANSACTIONS TO FILE LOG TRANSACTIONS TO FILE is introduced in version 7 to allow EIM to log transactions into . 2. EIM engine uses this new user key to update traditional user key columns. S_PARTY Table S_PARTY table has been introduced into Siebel Data Model in version 7. This document provides an overview of the new enhancements and new changes in Siebel 7 EIM area.PR_EMP_ID. such as S_CONTACT. S_CONTACT.

Tables such as S_ORG_EXT and S_CONTACT are no longer the target tables of Interface Tables such as EIM_ACCOUNT and EIM_CONTACT. the following syntax may be used: [Delete Accounts] TYPE = EXPORT BATCH = 1 TABLE = EIM_ACCOUNT DELETE MATCHES = S_ORG_EXT. the data model changes mentioned above may have a significant impact on the expected results of EXPORT and DELETE processing carried out by EIM. the following syntax may be used: [Export Accounts] TYPE = EXPORT BATCH = 1 TABLE = EIM_ACCOUNT EXPORT MATCHES = S_ORG_EXT. (NAME Like 'Siebel%') Note that during export process. This is because tables such as S_ORG_EXT and S_CONTACT are no longer the target tables of the Account and Contact Interface Tables. Although the Enterprise Integration Manager (EIM) functionality has not changed in Siebel version 7. EXPORT MATCHES Following syntax should be used for all base tables where target base table is S_PARTY table: (1) For example. (CREATED > '2002-07-10') Note that records will always be cascade deleted starting from matching S_PARTY record. Change Request 12-8TF4SO has been logged to address this Product Defect. EXPORT and DELETE functionality operate from the target table (S_PARTY) and then cascades down to the "children" tables (S_ORG_EXT. for exporting data into EIM_ACCOUNT table. (2) If an EXPORT MATCHES criteria is to be specified against the S_PARTY table. This causes the following behavior to occur: EXPORT ALL ROWS = TRUE will cause all records (regardless of "party type") from the S_PARTY table to be exported to the specified Interface Table.EIM EXPORT / DELETE functionality for S_PARTY based tables in Siebel version 7 Description The introduction of the S_PARTY table in Siebel version 7 means that tables such as S_ORG_EXT and S_CONTACT become extension tables to the S_PARTY table. then the table name is required: [Export Accounts] TYPE = EXPORT BATCH = 1 . S_CONTACT etc). multiple records may be exported into EIM_ACCOUNT table depending on the number of dependent objects for the Party object. For DELETE MATCHES process.

however caution should be applied based on the recommendations made above Likelihood of Occurrence The behavior described above is standard EIM functionality that has not changed in Siebel version 7. DELETE MATCHES should be used to remove data from the S_PARTY table . (CREATED > '2002-05-01') Change Request 12-AYTER7 has been raised to address this documentation change. get exported. ensure that only those records in S_PARTY that to be deleted.CON_PER_RESP = 'Y'. INCORRECT USAGE COULD RESULT IN A DELETION OF YOUR ENTIRE DATABASE. This Alert has been written to ensure that the impact of the Data Model changes introduced in Siebel version 7 on the functionality described above is fully understood. This is because EXPORT will export all records from the S_PARTY table to the specified Interface Table. . The value is always set to "No Match Row Id" in S_CONTACT. if the match criterion for EXPORT is not specific enough.PR_RESP_ID even with EIM_EMPLOYEE.as documented in the EIM Administration Guide. then unintended records might be exported and deleted. It is recommended that any EIM tasks that are currently used in Siebel 2000 should be thoroughly tested in Siebel version 7 to ensure that all EIM processes behave as expected. (CREATED > '2002-07-10') (3) For all other interface tables where base tables is not S_PARTY. Change Request 12-ABM2X3 has been logged to address this Product Defect.TABLE = EIM_ACCOUNT EXPORT MATCHES = S_PARTY. if the specific party type is not provided. Primary Responsibility cannot be set for Employees using Enterprise Integration Manager (EIM) Description After running the EIM import process to import employee and their responsibilities through interface table EIM_EMPLOYEE into base table S_CONTACT and S_PER_RESP tables. the primary responsibility cannot be set. WARNING: STRONG CAUTION IS RECOMMENDED IN USING THIS APPROACH. If using EXPORT and then DELETE EXACT. DELETE EXACT should be used with caution if carried out in conjunction with the EXPORT processing described above. As described above. syntax for EXPORT MATCHES or DELETE MATCHES remains the same as in previous versions: EXPORT MATCHES = (CREATED > '2002-05-01') DELETE MATCHES = EIM_ACTIVITY. it will result in the deletion of all the S_PARTY rows followed by a cascade delete of all child rows. If this is followed by an EIM DELETE task. An alternative to the "EXPORT then DELETE" approach is to use SQL to select records in S_PARTY to be deleted into the interface table followed by DELETE EXACT.

COM Interface or User Interface to set or update Primary Child Foreign Keys listed above.PR_RESP_ID is set to "No Match Row Id". Likelihood of Occurrence No transactions will be logged for mobile users when using MISC SQL within an EIM process in Siebel 7 to set the Primary Child Foreign Keys listed above. Change Request 12-BGA6EK has been raised requesting providing this information in EIM documentation.5 . page 4-15.0). Afterwards. Possible symptoms S_CONTACT. or Set the Primary responsibility through Siebel Visual Basic (SVB). Enterprise Integration Manager (EIM) does NOT log any transactions for mobile users Description MISC SQL parameter is introduced in Siebel 7 to allow EIM to set the following Primary Child Foreign Keys: S_CONTACT. Workaround or Resolution Use MISC SQL only during initial EIM data loading. In Siebel 7. it is recommended to use Siebel Visual Basic. please refer to Enterprise Integration Manager Administration Guide (7. this has been documented in the Siebel Bookshelf 7. BI columns should be _BU columns in EIM interface tables Description . when importing records into S_PER_RESP and S_CONTACT base tables using EIM_EMPOYEE interface table. When using MISC SQL in Siebel 7 to set Primary Child Foreign Keys. EIM does NOT log any transactions for mobile users.PR_OU_ADDR_ID S_CONTACT.PR_BL_PER_ID S_ORG_EXT.PR_POSTN_ADDR_ID S_POSTN.Likelihood of occurrence This behavior will be encountered if an EIM import process is performed. Workaround or Resolution Set the Primary responsibility manually in the user Interface (UI).PR_SHIP_PER_ID S_POSTN. For more information about the usage of MISC SQL.PR_HELD_POSTN_ID S_ORG_EXT.PR_EMP_ID Note that when using MISC SQL in Siebel 7 to set Primary Child Foreign Keys.5 > Enterprise Integration Manager Administration Guide > Importing Data > Editing the Configuration File for Importing Processing > Header and Process Parameters.

Please note that the Interface Tables Reference of Siebel Version 6 and 7.x. Likelihood of Occurrence This occurs when S_PARTY record specified in EIM_ACCOUNT is a new one based on S_PARTY_U1 and the associated S_ORG_EXT record is a duplicate of existing one in terms of S_ORG_EXT_U2 (NAME.0. This reference gives the impression that _BI columns need to be populated. Workaround or Resolution . Change Request 12-ABM2XH has been logged to address this Documentation Defect. As a result. The Interface Tables Reference lists _BI columns instead of _BU columns. the S_ORG_EXT_U2 index is violated when EIM tries to insert the record into S_ORG_EXT. _BU columns of interface tables should be populated instead of _BI columns.5 lists _BU columns correctly. sometimes EIM tasks error out with ODBC error indicating that the unique S_ORG_EXT_U2 is violated (actual error messages generated vary depend on different databases platforms). This Alert is only applicable for Version 7. These _BI columns will be populated by the EIM process based on the value in _BU columns.Before running the EIM process. Possible Symptoms Not Applicable Likelihood of Occurrence Not Applicable Workaround or Resolution Not Applicable Enterprise Integration Manager (EIM) does not prevent inserting S_PARTY records when S_ORG_EXT records that violate the unique index S_ORG_EXT_U2 are rejected Description When running import through Enterprise Integration Manager (EIM) using EIM_ACCOUNT. Possible Symptoms An incomplete EIM job with new S_PARTY rows inserted without associated S_ORG_EXT rows. EIM only checks if there is an existing S_ORG_EXT record that references (by PAR_ROW_ID) the S_PARTY row. Since S_ORG_EXT is considered a one-to-one extension table of S_PARTY. BU_ID). No record is returned since the S_PARTY record is a new one. LOC.

. Answer:• • 2) In maintaining database. Questions:1) Under What are the circumstances one chose between EIM and EAI for data transfer. the interface table should be populated in a way that when there is a new S_PARTY record. when users have very thin updates( 1-10 columns) to a narrowly defined set of siebel base tables (maximum 3). the corresponding S_ORG_EXT one must also be new in terms of S_ORG_EXT_U2.To avoid the situation. When business requirements dictates the real-time feeds be available from other enterprise applications that their employees must utilize inorder to accomplish their jobs .

Sign up to vote on this title
UsefulNot useful