1. Mandatory Columns for Data Import and Deletion
• When performing import and merge processes or DELETE EXACT in Siebel EIM, populate the following columns in the EIM tables: ROW_ID, IF_ROW_STAT, IF_ROW_BATCH_NUM. Additionally, for merge processes, populate the IF_ROW_MERGE_ID column. Avoid using spaces as values in these required columns, as spaces are not equivalent to NULL values.
2. Limitations on Manual Column Mapping
• Siebel Tools does not support manually creating mappings to existing Siebel base columns. Be aware of this limitation when working with column mappings in Siebel EIM.
3. Creating Explicit Primary Mappings
• To create an explicit primary mapping, both the parent and primary child tables must be mapped to the same EIM table. Suppose you already have a direct preliminary mapping. In that case, you can set the primary explicitly during import or update by configuring the primary flag column in the EIM table.
4. Special EIM Tables for Deletion
• EIM_NOTE_DEL and EIM_SKLI_DEL are specialized EIM tables used for deleting records from S_NOTE* and S_*SKILL_IT tables, which do not follow the standard U1 user essential structure.
5. Considerations for Unicode Implementation
• If you plan to implement Unicode support in your system, ensure the EIM configuration file is saved as a Unicode text file to handle character encoding properly.
6. Exception to Batch Number Component Parameter
• The batch number component parameter can be set to 0 as an exception. In this case, the batch number in the EIM configuration file (if specified) will be used as the batch number for processing.
7. Logging Transactions to File
• If you enable the LOG TRANSACTIONS TO FILE parameter, ensure the Siebel Server has write access to the file system's EIM directory. Specify the file system directory using the Uniform Naming Convention (UNC) during installation.
8. Handling User Credentials in IFB File
• When launching EIM, the handling of user credentials depends on whether it's started from the command line or Siebel application. Be cautious with the PASSWORD PARAMETER in the IFB file and consider specifying credentials in EIM Server Component parameters for security.
9. User Name Parameter in IFB File
• Like the password, the USERNAME PARAMETER in the IFB file depends on how EIM starts. It's advisable to specify user credentials in EIM Server Component parameters if you want to avoid exposing them in the.IFB file.
10. Parameter Configuration for Multiple Processes - If your configuration file contains multiple process sections, remember to include the parameter settings within each corresponding process section if you want a specific parameter to apply to various processes. This ensures that the parameter acts as intended for each method.
11. Commit Strategy for Delete Processes
• It's advisable not to use the COMMIT EACH PASS parameter in delete processes. When a commit happens after each table or pass, errors causing an exit from the process may leave orphan records and unresolved references behind. Instead, committing for the whole batch allows for the rollback of other table deletes in case of errors.
12. Optimal Commit Approach for Delete Operations
• Avoid using the COMMIT EACH TABLE parameter in delete processes. Committing after each table or pass can result in issues if errors cause the process to exit prematurely, leading to orphan records and dangling references. Opt for saving for the entire batch to facilitate the rollback of table deletes in error scenarios.
13. Use of INCLUDE Parameter in Shell Processes
• The INCLUDE parameter is exclusively intended for use in shell processes. Shell processes utilize the INCLUDE statement to invoke a sequence of functions within a single run, providing a convenient way to streamline operations.
14. Limitations of SESSION SQL Parameter
• Be aware that the SESSION SQL parameter cannot be used for inserting or updating data in Siebel base tables. EIM sends SQL statements directly to the database, which may result in data loss for Siebel Remote and Siebel Replication Manager scenarios.
15. Performance Considerations for Table Export and Merge
• To optimize performance, restrict the number of tables exported or merged within a single process section to a maximum of five tables. This practice helps maintain efficient processing.
16. Handling Backslashes in IFB File
• In the IFB file, be cautious when using a backslash followed by a space. EIM interprets the space character as "escaped," potentially causing errors due to incomplete parameter definitions when a new line character follows.
17. Limitations on Updating User Key Columns
• EIM allows updates only for non-user key columns. Modifying existing user key columns is not supported. For updates involving user key columns in tables like S_ORG_EXT, S_PROD_INT, S_PROD_EXT, and S_PARTY, use specific EIM tables with a "UK" postfix.
18. Handling Rows with Blank Required Columns
• If there are rows with required columns containing only blank values, the entire EIM process will fail at this stage. Such rows will not be imported or updated.
19. Considerations for Database Character Set
• When data exists in a database using a different character set, the import process may not function correctly until the database is recreated to align with the required character set.
20. Special Columns in Siebel EIM Tables
• Siebel EIM tables include unique columns that must be populated before rows can be successfully imported.
21. Impact of Transaction Logging for Mobile Web Clients
• If you have active mobile Web clients, avoid turning off the "Enable Transaction Logging" system preference in the Administration - Siebel Remote screen. After imports, turning off this preference can disrupt synchronization between the server and mobile Web client databases.
22. Using Performance-Enhancing Parameters
• Parameters such as ONLY BASE TABLES, IGNORE BASE TABLES, ONLY BASE COLUMNS, and IGNORE BASE COLUMNS can enhance EIM performance.
23. Interaction of COMMIT EACH PASS and COMMIT EACH TABLE
• Note that COMMIT EACH PASS and COMMIT EACH TABLE interact cumulatively. If both parameters are set to TRUE, a commit occurs at the end of each pass and at the end of each table.
24. Interaction of COMMIT EACH TABLE and COMMIT EACH PASS
• Similarly, COMMIT EACH TABLE and COMMIT EACH PASS interact cumulatively. When both parameters are set to TRUE, a commit occurs at the end of each pass and each table.
25. Purpose of COMMIT OPERATIONS Parameter
• WITH TRANSACTION LOGGING ENABLED, the COMMIT OPERATIONS parameter is valid exclusively for row-by-row processing. It does not apply to set-based processing operations.
26. INSERT ROWS Parameter Consideration
• Set the INSERT ROWS parameter to FALSE for tables with an EIM table that lacks mappings to all required columns. This prevents EIM from attempting to insert rows as new records when they cannot be resolved to existing documents, avoiding "Cannot insert null" errors.
27. MISC SQL for Initial Data Loading
• Utilize the MISC SQL parameter for initial data loading (with DOCKING TRANSACTIONS = FALSE). Remember that mobile users do not log transactions when using MISC SQL to set primary child foreign keys.
28. Limitations of NET CHANGE Parameter for Long Columns
• NET CHANGE = TRUE does not function for long columns. When updating a long column, ensure NET CHANGE is set to FALSE.
29. Constraints on PARTY_TYPE_CD Column
• Custom values are not permitted in the PARTY_TYPE_CD column, which must contain one of the predefined values.
30. Conditions for Populating PAR_PARTY_ID Field
• The PAR_PARTY_ID field should only be populated when PARTY_TYPE_CD is set to Organization or Position. Positions apply to child positions, while for Organizations, they pertain to internal organizations. Divisions and Accounts have PARTY_TYPE_CD set to Organization but do not require PAR_PARTY_ID population.
31. Transaction Logging in Export Operations
• Export operations in Siebel do not trigger transaction logging, as Siebel base table values remain unaltered.
32. Optimizing Table Count in Export Processes
• To enhance performance, it's advisable to limit the number of tables to be exported within a single process section to five or fewer.
33. Exporting Rows from Child Tables
• Rows from child tables of related child tables will not be exported until they have been mapped. This relates to the EXPORT MATCHES WHERE clause fragment.
34. Limitations of Complex SQL WHERE Clauses
• Complex SQL WHERE clauses, including subqueries, are not supported in EXPORT MATCHES. This parameter can be used only against a target base table or against a non-target base table that is an extension table of S_PARTY when the target table is S_PARTY.
35. Criteria Column Validity
• When using criteria (in "...criteria..."), ensure that the column names included are from either the target base table or the table specified for the EXPORT MATCHES parameter.
36. Caution with EIM for Deleting Organizations
• Avoid using EIM for deleting organizations, as it can result in unintended data integrity loss. Similar caution should be exercised when deleting data from the product base tables.
37. Handling Records with Non-Required Foreign Keys
• When deleting records, note that if a non-required foreign key is part of the user key and clearing it creates a conflict, the record will still be deleted.
38. Transaction Logging for Delete Operations
• To capture appropriate transactions for later docking, ensure that transaction logging is active during delete operations if you have active mobile Web clients.
39. Deleting Records Based on User Keys
• When deleting records based on user keys, specify the DELETE EXACT parameter.IFB file.
40. Required DELETE Parameters
• For delete operations, you must use one of the following DELETE parameters described in this section: DELETE EXACT, DELETE MATCHES, or DELETE ALL ROWS.
41. Appropriate Use of ONLY BASE TABLES
• Do not use ONLY BASE TABLES with the target base table and non-target base tables, as EIM table records cannot specify just one form to be deleted.
42. Avoid Using DELETE MATCHES for S_PARTY-Based Tables
• Please refrain from using the DELETE MATCHES parameter to delete rows from S_PARTY-based tables, as it may inadvertently delete all matching records from the database.
43. Caution with DELETE ALL ROWS
• Use the DELETE ALL ROWS = TRUE setting with extreme caution, as it deletes all rows in the named base table, including seed data. Selective row deletion is recommended using DELETE EXACT or DELETE MATCHES expressions.
44. Clarification on ONLY BASE TABLES
• ONLY BASE TABLES should not be used with target base tables and non-target base tables, as EIM table records cannot specify single forms for deletion.
45. DELETE ALL ROWS for Target Base Tables
• The DELETE ALL ROWS = TRUE setting should be used cautiously, as it deletes all rows in the target base table.
46. Caution with Merging Data in Products and Positions Tables
• Merging data in Products and Positions base tables using EIM is not recommended, as it can lead to inadvertent data integrity loss.
47. Transaction Logging for Merge Operations
• To capture appropriate transactions for later synchronization, ensure that transaction logging is enabled during merge operations if you have active mobile Web clients.
48. Optimizing Table Count in Merge Processes
• For performance reasons, it's advisable to limit the number of tables to be merged in a single process section to five or fewer.
49. Influence of Transaction Logging Preference
• EIM will ignore the specified parameter if the "Enable Transaction Logging" preference is unchecked in the Remote System Preferences view of the Administration - Siebel Remote screen.
50. Use of UPDATE ROWS Setting in Merge Operations
• When using UPDATE ROWS = <Table_Name>, FALSE in a Merge operation, exercise caution as inappropriate use may result in dangling foreign vital pointers.
51. EIM Behavior in Merge Operations
• EIM behaviour in merge operations involves repointing foreign keys in dependent child records without merging data in the base record. This applies to all columns in the base table and may lead to unintended data loss in extension columns.
52. Impact of Activating Flags
• Activating flags (Error, Trace, SQL Trace Flags) can directly affect performance. Typically, these flags should be activated only during EIM process testing, and their use in a production environment should be limited to necessary cases.
53. Limited Use of IGNORE BASE COLUMNS Parameter
• The IGNORE BASE COLUMNS parameter should not be used in merge or export processes and is intended solely for import and delete operations.
54. Unique Constraint Considerations in Parallel EIM Jobs
• Running parallel EIM jobs on the same base tables may result in unique constraint errors if batches being processed have the same values for particular index fields.
55. Handling Deadlocks in DB2 Database
• When running EIM processes in parallel on a DB2 database, deadlocks may occur when multiple methods access the same EIM table simultaneously. To prevent this, set the UPDATE STATISTICS parameter to FALSE in the EIM configuration file, which applies specifically to DB2 databases.
Comments
Post a Comment