Siebel Classic Flipcard Magazine Mosaic Sidebar Snapshot Timeslide Jan 15 Siebel Projects Siebel Projects: A Project is a Siebel

Tools Construct that organizes object definitions into unique named groupings. An object definition must be assigned to a project to be modified. The Tools OE and OBLE display by project option allows filtering of object types and definitions in that project. The use of projects allows only one developer at a time to be making changes to the same set of object definitions. After you create a new project, you must exit Tools and come back in if you want to see your project in the dropdown list. Projects with suffixes usually contain UI Object Layer Definitions. E.g. The project Oppty (SSE) contains definitions pertaining to the Opportunity functional area with primarily UI definitions. * Projects without suffixes usually contain BO Layer definitions. * Suffixes include SSE, SSV, TAS, FS and WWW (Siebel Sales Enterprise, Siebel Service Enterprise, Target Account Selling, Field Service and World Wide Web). Project Check Out: For local modification and testing. Copying all object definitions in one or more projects on the server and overwriting those on the local machine. Checked-out object definitions are left in a locked state, as are local projects, preventing other developers from modifying the same project. Getting Projects: A newly initialized DB contains only a skeletal Repository without any projects. Get populates the local DB with a copy of all projects in the server Repository. Get is similar to Check Out but does not place locks. Initial Get is required before compiling against the local repository. .SRF files must be based on full set of Vanilla Object definitions plus any changes you add or make. Get for refresh used if you require object definitions modified by other developers. (Your work may depend on latest definition enhancements by others). (You may want to be sure that your changes work with those of others). Project Check In: Only projects that have been checked out can be checked in!! Upon check-in, the older version of the locked-project is overwritten and unlocked (although there is an option to maintain lock). Check in all dependant projects at the same time to ensure a consistent configuration on the server.

Only check in projects if local testing is complete!! Project Diff button can be invoked via Check in window. (details of changes made to checked out projects and avoids errors). Locally locking projects: Locking Projects directly = used when prototyping ideas with no effect on others and if you dont intend to save work Be aware that the local projects will get overwritten next time you do a get. Posted 15th January 2008 by J N Labels: Siebel Projects 1 View comments Jan 15 Siebel Application Architecture: Siebel Application Architecture: Data Objects Layer: Provides layer of abstraction over RDBMS (Insulates application and developer from DB Administration). Contains Data Object Definitions (e.g. Table, Column, and Index), that map directly to the corresponding DB structure. If enterprise migrates to different RDBMS, structures at this layer remain unchanged. Application is extended via changes at this level. Application is configured using Business Obj. and User Interface Obj. layers. Key Issues: How is the information managed in my business? What are the Information Relationships? How does the information map to the data model? Who gets to see the data? An intersection table represents a many-to-many relationship as two one-to-many relationships. S_OPTY_ORG (Many-to-Many Accounts to Opportunities) E.g. tracking of primary purchasing organization and secondary organizations (integrators/subcontractors). S_OPTY_REL (Many-to-Many Opportunities related to each other) E.g. A subsequent opportunity is related to a previous opportunity. S_OPTY----S_OPTY. C.Taylor-Smith Siebel Revision Notes Configuring and Application using Siebel Tools 2 S_CON_PRD_INT_M E.g. an insurance companys policies (products) are stored in S_PROD_INT, however a policy can be purchased by many contacts and a visa versa, hence the table S_CON_PRDINT. A Car insurance policy could have multiple drivers on one policy and the S_CON_PRDINT_M table stores these associations. N.B. A column is S_CON_PRDINT points to the primary contact for a particular policy. S_PER_ORG_UNIT Many to Many (accounts to contacts) E.g. a contact associated with corporate and regional offices within the same account. S_ACT_CONTACT Many-to-Many (Activities to contacts) E.g. Sending a proposal may need to be associated with many contacts. S_ORG_GROUP Contacts>--Groups (e.g. households).

S_CONTACTS>--S_ORG_GROUP Business Objects Layer: Business Object Definitions built on Data Object Definitions and/or other Business Object Defs. No direct reference to RDBMS Structures!! Provides interface to retrieve and manipulate data from underlying SQL tables. Major Obj. types in this layer: Business Component Business Object Business Components: Associate columns from one or more tables in Data Object Layer into a single logical entity. - E.g. Activity BC / Opportunity BC Map to a main table that provides most important columns. Comprise fields, which map to a column in a table. Enable relationships with other BCs to be established based on Primary-foreign key relationships built-in to the Data Model. Business Objects: Define a major area of business functionality (e.g. Opportunities, Accounts and Contacts. Are collections of business components that are logically related. One BC in collection serves as the master (e.g. Opportunity in Opportunities). - The child in this instance could be activity. The master BC name is typically the same as that of the BO. Parent/Child relationship between Opportunity BC and Activity BC = created using a link. The Same BC can be used in multiple BOs. User Interface Objects Layer: A Visual representation of underlying BOs and BCs Provides means to customize the display Defines Application, screens, views, applets and reports including; User interface layout & navigation. User interface controls. User Interface Organization: C.Taylor-Smith Siebel Revision Notes Configuring and Application using Siebel Tools 3 An applet maps to one business component. Each applet control that displays data maps to a field in applets business component. A view maps to one business object & presents a subset of its data. A view is a collection of one/more applets. A screen is a collection of views pertaining to a functional area of application & contains views which map to the same business object A BC is a reusable object type, the advantage being that you only have to define the physical to logical relationship once => No need to revisit tables when defining each applet. Vanilla applications (SSE, SSV, SME etc.) merely expose different portions of BO layers. Posted 15th January 2008 by J N Labels: Siebel Application Architecture 0 Add a comment Jan 15 Understanding Siebel Business Object Types Understanding Siebel Business Object Types Business object types are object types from the Business Objects Layer in the architecture. Business object definitions are built on data object definitions, and selectively combine and

associate data object definitions into logical constructs that are useful for application design. Business object definitions provide the data for user interface object definitions. Business Component. A Business Component is a logical entity that associates Columns from one or more Tables into a single structure. Business Components provide a layer of wrapping over Tables, and the Applets reference Business Components rather than the underlying Tables. This design creates convenience (all associated Columns together in one bundle), developer-friendly naming, and the isolation of the developer role from the system administrator role. Configuring the Business Component D Object definitions for Business Components have the following important properties: Name Property. The Name property is the name of the Business Component used for identification by other object definitions. Table Property. The Table property specifies the base Table for the Business Component. Class Property. The name of the class determines the behavior of the Business Component. The majority of the major Business Components have a Class property value of CSS BusComp. (The Class property actually refers to the C++ class that defines the behavior of this kind of Business Component.) NOTE: You should not modify the Class property value, except when performing highly specialized programming work. No Delete Property. The No Delete property is a TRUE/FALSE property indicating whether the user in Siebel Enterprise Applications can delete records of this Business Component and, through the Business Component, rows of the base Table. When No Delete is TRUE, the Edit Delete Record menu option and the Delete command button, if present, are disabled in Siebel Enterprise Applications. NOTE: Applet, Link, Multi Value Link and Pick List object types also have No Delete, No Insert, and No Merge properties, but the typical place to configure this behavior is at the Business Component level. The ability to define these properties in these object types avoids the need to create multiple Business Components that are otherwise identical. The TRUE setting in these properties in a Business Component overrides the corresponding property in other object definitions. No Insert Property. No Insert is a TRUE/FALSE property indicating whether the user can create records of this Business Component and, indirectly, rows of its base Table. When No Insert is TRUE, the Edit Add New Record menu option in Siebel Enterprise Applications is disabled.

No Update Property. No Update is a TRUE/FALSE property indicating whether the user can edit values in the Fields of this Business Component and the corresponding Columns of its base Table. When No Update is TRUE, List Columns and Controls in Applets associated with this Business Component have read-only behavior. NOTE: The Applet and Pick List object types also have the No Update property, but the usual

place to configure this behavior is at the Business Component level. The ability to define these properties in these object types avoids the need to create multiple Business Components that are otherwise identical. The TRUE setting in these properties in a Business Component overrides the corresponding property in other object definitions. No Merge Property. No Merge is a TRUE/FALSE property indicating whether the user can merge two existing records of this Business Component and the corresponding rows of its base Table. When No Merge is TRUE, the EditMerge Records menu option in Siebel Enterprise Applications is disabled. The Merge feature supports the consolidation of records that are unnecessarily duplicated by users, such as multiple accounts with different spellings, or in the combining of accounts, opportunities, contacts and so on in the sales environment. When records are merged, only one record of the records being combined continues to exist, and it receives the child records of the others. For example, when accounts are merged, the resulting account has all of the contacts and addresses of the merged account records. Sort Specification Property. The value in the Sort Specification property, if present, is the name of a Field or list of Fields that imposes a sort order on the records returned to an Applet that is associated with this Business Component. Search Specification Property. The value in the Search Specification property, if present, is a conditional expression used to restrict the records retrieved. The expression is based on the values of Fields in the Business Component. When this property is blank, there is no restriction imposed on the records retrieved.

Field. A Field object definition associates a Column to a Business Component. This is how Columns from Tables are assigned to a Business Component and provided with meaningful names that the customer developer can easily change. Alternately, a Fields values can be calculated from the values in other Fields in the Business Component. Fields supply data to Controls and List Columns in the user interface. Field is a child object type of Business Component. A Field represents information from a database column obtained through the corresponding Column object definition. Columns may be from the base Table, extension Tables, and joined Tables of the Business Component. Alternately, a Field may be a calculated Field whose values are derived from the values in other Fields in the Business Component, but not stored in the database. In the Field object definition (for other than calculated Fields), the Column and Join properties together specify the Table and Column from which the Fields data is obtained. The Join property, if blank, indicates that the Column is obtained from the Business Components base Table. If nonblank, the Join property identifies the Join object definition that supplies data from an extension Table or other joined Table. Based on the Join property, the Table supplying the Fields data is identified. The Column property identifies the Column to use within the specified Table. The Field object has the following essential properties: Name property. The Name property uniquely identifies the Field within its parent Business Component. Join property. This property is blank if the Column is from the Business Components base Table (as specified in its Table property). The Join property identifies a Join object definition in

the same Business Component if the Column is from a joined Table or extension Table. NOTE: For an extension Table, the Join identified in the Join property has the same name as the extension Table, but it is not visible in the Object Explorer because it is an implied Join Column property. This property identifies the Column object definition on which the Field is based. Calculated Fields have a blank Column property; all other Fields have a non-blank Column property. Type property. This is the Field's data type. Calculated and Calculated Value properties. These properties are used to define a calculated Field. Read Only property. If the Read Only property is TRUE, the Field value cannot be changed by the user. Read-only Fields, when displayed in Applets, display data that is for the users information only, and may not be edited. Required property. If the Required property is TRUE, a value must be entered in this Field by the user before the record can be accepted. A message box will inform the user that an entry in the Field is required, if the user attempts to leave the record without entering a value in this Field. Validation property. A non-blank Validation property value contains a conditional expression based on this Field (and, optionally, others in the Business Component) that must evaluate to TRUE before the record can be accepted.

Join A Join object definition creates a relationship between a BusinessComponent and a Table that is not the Business Components base Table. The Join allows the Business Component to build Fields using Columns from then on-base (joined) Table. The Join uses a foreign key in the Business Component to obtain rows on a one-to-one basis from the joined Table, even though the two do not necessarily have a one-to-one relationship. For example, an Account can have multiple Contacts, and each Contact identifies one Account in its foreign key. This makes it possible to generate, by means of a Join between Contacts and Accounts, a list of Contacts with Account information about each. Join Specification. Join Specification is a child object type of Join that provides details about how the Join is implemented within the Business Component. A Contact Business Component record represents a contact person at an account. Therefore, one Account record has one or more Contact records, meaning that there is a one-to-many (master-detail) relationship between the Tables holding account and contact information. A detail record (or row) in a master-detail relationship always has one master record (or row). The master-detail relationship is implemented with a foreign key Column in the detail Table. Multiple rows in the detail Table have the same foreign key value pointing back to the same row in the master Table. Returning to the accounts and contacts example, you can look at accounts (S_ORG_EXT Table rows) from the perspective of contacts (S_CONTACT Ta b l e rows). Each detail Table row (S_CONTACT) has exactly one master Table row (S_ORG_EXT) in the one-to-many relationship. The one account row for each contact row makes it possible to treat account rows as if they were

appended onto the ends of the contact rows. This provides account information about each contacts account, along with the other contact information. A Business Component whose base Table is a detail Table in a master-detail relationship can include columns from the master Table as Fields. This is the principle behind a Join. A Join is always one-to-one and it is always between a Business Component and a Table. Once a Join is created, you can create additional Fields in the Business Component based on Columns in the joined Table.

Configuring the Join Business Component. The Business Component is the parent object definition of the Join. Because of the Join, Fields in the Business Component (called joined Fields) can represent Columns from the joined Table. Joined Field. A joined Field in the Business Component represents a Column from a Table other than the Business Components base Table. Therefore, a joined Field must obtain its values through a Join. A joined Field has the name bof the Join in its Join property. Together the Join property and Column property identify the Column and how to access it. Join. Join is a child object type of Business Component. The Join object uniquely identifies a join relationship for the parent Business Component and provides the name of the destination (joined) Table. The Join object definition identifies the joined Table in the Table property. The name of the base Table is already known to the Business Component. Typically, a Join object definition is given the same name as the joined Table. Join Specification. The Join Specification object definition is a child of the Join object definition. It identifies the foreign key Field in the Business Component and the primary key Column in the joined Table (that the foreign key points to). The Source Field property identifies the foreign key Field. The Destination Column property identifies the primary key Column in the joined Table. Typically, it is given the same name as the source (foreign key) Field. A non-blank Destination Column property value is required if the Join occurs on a Column other than ROW_ID. A blank value in the Destination Column property means that the destination Column is ROW_ID, which is typically the primary key in Tables in Siebel Enterprise Applications. NOTE: In rare circumstances, there can be multiple Join Specifications in a single Join. For example, the Sub Campaign Business Component has a Join to the S_LANG Table that has two Join Specifications. Foreign Key (Source) Field and Foreign Key Column. The foreign key Field is identified in the Source Field property of the Join Specification. It represents a foreign key Column in the base Table, pointing to rows in a particular Table used in Joins. For example, in the Contact Business Component, the foreign key Field to the Join on accounts data is the Account Id Field, which represents the PR_DEPT_OU_ID Column in the base Table. Joined Table. The joined Table is the master Table in the master-detail relationship. It provides Columns to the Business Component through the Join. The joined Table is identified in the Table property of the Join object definition. Primary Key (Destination) Column. The Join Specification identifies the primary key Column in the joined Table (in the Destination Column property). Every standard Table in standard Siebel Enterprise Applications has a ROW_ID Column that uniquely identifies rows in the Table.

ROW_ID is the destination in most Joins. The value in the ROW_ID Column is a unique systemgenerated number. Mapped Column. Columns in the joined Table are available for use in Fields in the Business Component.

Creating a Join for an Existing BC 1. Find the Foreign Key column from Contact (Detail) to Account (Master) Go to Table column view and run a query in foreign key table (table to be joined) to find the foreign key column in the base table which refers to the primary key column in the table to be joined. 2. Add Field to BusComp Required to Construct Join (Place holder) and attach the Foreign Key column identified in step 1. 3. Create a Join for the Selected BusComp The Join declares the Destination table (where the data resides) (Name of Join is always the name of the joined table)

4. Create a Join Specification for the join (Typically, it is given the same name as the source (foreign key) Field) The Join Specification defines how to get from the Source to the Destination Specifies what field in the Source business component will match what COLUMN on the Destination table (S_ORG_EXT). Give the foreign key field as Source Field and the primary key column of the joined table (usually Row ID) as the Destination Column. Source field = Foreign Key field (FK column in Base Table) Destination Column = Primary Key Column (in Joined Table) 5. Add fields (Single Value Fields) to the BC, reference the Join and attach columns from the joined table to those fields. Summary: First map foreign key column in the Base table to Foreign key field in the BC in the BC-Fields view, declare a join in the same name as joined table, and then in the join specification, map the PK column (Destination Column) in the joined table to the same Foreign key field (Source Field).

Link. A Link implements a one-to-many relationship between Business Components. The Link object type makes master-detail Views possible. A master-detail View displays one record of the master Business Component with many detail Business Component records corresponding to the master. A pair of Links also may be used to implement a many-to-many relationship. The synchronization between the master and detail Business Components in a master-detail View is accomplished with a Link between the two Business Components and the inclusion of the

Link and Business Components in a Business Object. The object definitions are as follows: Link. The Link object definition specifies a master-detail relationship between two Business Components. It identifies the master and detail Business Components, the key Field in the master Business Component, and the foreign key Field in the detail Business Component. Master Business Component. The master Business Component is the one in the one-tomany relationship. The name of this object definition is specified in the Parent Business Component property in the Link object definition. Detail Business Component. The detail Business Component is the many in the one-to-many relationship. The name of this object definition is specified in the Child Business Component property in the Link object definition. NOTE: The Calendar Business Component should not be used as the master or detail Business Component in a Link. Source (Primary Key) Field. The source Field, also known as the primary key Field, is a Field in the master Business Component that uniquely identifies records in the Business Component. It represents the ROW_ID Column from the Business Component's base Table. The name of this Field is specified in theSource Field property in the Link object definition. Destination (Foreign Key) Field. The destination Field, also known as the foreign key Field, is a Field in the detail Business Component that points back to the master record in the Business Component. Account Id and Opportunity Id are typical foreign key Fields. A foreign key Field represents a foreign key Column from the detail Business Components base Table, such as PR_DEPT_OU_ID (the base Table for the Account Business Component). The name of this Field is specified in the Destination Field property in the Link object definition. NOTE: In a Link based on an intersection Table, that is, one in which the Inter Table, Inter Parent Column and Inter Child Column properties are non-blank, you do not specify the Source Field or Destination Field properties. Steps Identify the foreign key column in the Child BC pointing to the PK of Parent BC. Create a Field in child BC (Activity) for holding the foreign key column(Logical FK). Create a field in Parent BC (Contact) for holding the PK column (ID) (Logical PK) Create a Link and declare Parent BC, Child BC, Destination Field as Logical FK field (step 2), Source Field as,Logical PK.(step 3) 5. Add child business component to appropriate business object as BO component and specify link (on the child business component) (no link on parent)

1 Multi Value Link. A Multi Value Link is used in the implementation of a multi value group. A multi value group is a user-maintainable list of detail records associated with a master record. The user invokes the list of detail records from the master record when it is displayed in a list or form Applet. For example, in an Applet displaying the Account Business Component, the user can click an ellipsis icon to the right of the Address text box to see a dialog box displaying multiple Address records associated with the currently displayed account. It also provides the means for the user to add, delete or modify individual records. Multi Value Link is a child object type of Business Component. A Multi Value Link implements a special use of the Link object type, which is the maintenance by the user of a list of records

attached t o a Control or Li st Column i n an Appl et . The group of attached detail records is called a multi value group. A multi value group Applet is a dialog box that displays multiple records of data associated with one Control in the originating Applet. For example, a multi value group Applet may be used to list the addresses, industries, or sales team members associated with an Account. The relationship between the Business Component of the originating Applet and the Business Component of the multi value group Applet is one-to-many; that is, a master-detail relationship. This master-detail relationship, as with all master-detail relationships in Siebel Enterprise Applications, is implemented with a Link (in addition to other object types). A Multi Value Link is necessary to adapt a Link for multi value group Applet use. NOTE: The relationship between the two Business Components is one-to-many in the context of the Multi Value Link and multi value group. There may be, in fact, a many-to-many relationship (for example, between opportunities and positions), but in the context of the multi value group, only one master-detail relationship is presented. In the Account Form Applet, the Address, City, State, Zip and Country text boxes display the values from the corresponding Fields in the primary record in the Business Address Business Component. The primary record is indicated in the multi value group Applet with a checkmark in the List Column labeled Primary. The user may select a different primary record by clicking the Primary List Column in a different record. The Fields in the master Business Component (Account in the illustration) that are populated by the primary record in the multi value group Business Component are called Multi Value Fields. Multi Value Fields are populated with data from a record in the detail Business Component because of the Multi Value Link. Multi Value Link is a child object type of Business Component that defines a master-detail relationship (based on a Link) to embed in the Business Component. These embedded master-detail relationships are used to expose Fields from the detail Business Component as Fields directly in the master Business Component. Ie, records in detail Bc are grouped(as MVGs) and mapped to fields in master Bc directly (as MVFs). These fields can be presented directly in applets based on master BC and the detail records can be dynamically selected from that applet. NOTE: Most, but not all, Multi Value Links are set up to designate a primary record. Those that do not designate a primary use the first record retrieved from the detail Business Component.

Configuring the Multi Value Link D A Multi Value Link is based on a Link object definition; the Link is referenced in the Destination Link property of the Multi-Value Link object definition. It is the Link object definition that specifies the one-to-many relationship between the master and detail Business Components. The MultiValue Link object definition performs two roles: 1. To give Fields in the master Business Component access to primary record Field values through the Link. 2. To enable embedding of detail data in the same Business Component as master data, so both can appear in the same Applet.

Multi Value Field is a distinct object type, but only in the sense that it can be accessed in the Object Explorer. It is only a representation of the Field object type.Multi Value Fields are those Fields that have a non-blank Multi Value Link property and a Multi Valued property value of TRUE; all other Fields are Single Value Fields. A Multi Value Field has a blank Column property setting because its values are obtained from the current record in the detail Business Component, rather than from the master Business Component's base Table. The roles of the object definitions are explained as follows: Master Business Component. The master Business Component is the master in the masterdetail relationship specified in the Link. Fields from this Business Component are displayed in the Applet from which the multi value group Applet is initiated. The master Business Component in the Account Addresses dialog box example is Account. NOTE: The Account Addresses dialog box example is illustrated .The explanations of object definitions below refer to this example. Multi Value Fields. Multi Value Fields are Fields in the master Business Component that are populated by the current (typically primary) record in the detail Business Component through the Multi Value Link and Link object definitions. Each of these Fields has the name of the Multi Value Link specified in its Multi Value Link property, and a Multi Valued property setting of TRUE. A Multi Value Field has a blank Column property setting because its values are obtained from the current record in the detail Business Component, rather than from the master Business Component's base Table. Key Field. The key Field in the master Business Component is the primary key for that Business Component. The key Field is referenced in the Source Field property of the Link object definition. n Multi Value Link. The Multi Value Link object definition defines the relationship between the Link object definition and Fields in the master Business Component, using the following properties: Destination Link property. Identifies the Link. Destination Business Component property. Identifies the detail Business Component. Primary Id Field property. Identifies the Field in the detail Business Component that designates which record is the primary. In the example, the Multi Value Link is called Business Address. Link. The Link object definition specifies a master-detail relationship between the two Business Components. It identifies the master and detail Business Components, the primary ID Field in the master, and the foreign key Field in the detail. The Link object definition may be used in other contexts, such as master-detail Views or other Multi Value Links. The Multi Value Link identifies the Link in its Destination Link property. In the address example, the Link is Account/ Business Address. Detail Business Component. The detail Business Component supplies the detail records in the master-detail relationship. In the address example, this is Business Address.

Foreign Key Field. The foreign key Field contains row ID values that point back to records in the master Business Component and uniquely identify the master for each detail Business Component record. The foreign key Field is used in the specification of the Link; the Link identifies the foreign key Field in its Destination Field property. In the address example, the foreign key Field is Account Id. NOTE: There is no foreign key Field specified in a Link based on an intersection Ta b l e. n Primary Id Field. The primary ID Field in the master Business Component holds the row ID value of the primary record for each multi value group in the detail Business Component. It is identified in the Primary Id Field property of the Multi Value Link. The primary ID Field allows the primary detail record to be identified for each master record.

Multi Value Group Applets F A multi value group Applet, also known as an MVG Applet, is a dialog box that provides the means to display and maintain a set of records of data from another Business Component associated with the currently displayed Business Component record. The multi value group Applet is invoked from a Control or List Column in the originating Applet. Configuring the Originating Applet Originating Applet. This object definition contains the Control or List Column that invokes the multi value group Applet. In the example, the originating Applet is called Account Entry Applet. The originating Applet contains the Control or List Column that invokes the multi value group Applet. The originating Applet has the following important property: Business Component Property. This property identifies the originating Business Component. The originating Control or List Column has the following important properties: n Field Property. This property identifies the originating Field in the originating Business Component. n Multi Value Group Applet Property. In this property, enter the name of the multi value group Applet to be invoked. n Originating Business Component. This object definition is the Business Component of the originating Applet. This Business Component (in the example, the Account Business Component) supplies the data presented in the originating Applet (Account Entry Applet). Configuring the Originating Business Component F The originating Business Component is the Business Component of the originating Applet. The data values that appear in the originating Field and other Multi Value Fields are obtained from corresponding Fields in a record in the multi value group Business Component. The record from which these values are obtained is the one indicated as primary. The originating Business Component has no essential properties for the configuration of a multi value group. However, the Field and Multi Value Link child object definitions are significant. The originating Field is the Field specified in the Field property of the originating Control or List Column. Other than its relationship with the originating Control, its role is identical to that of the other Multi Value Fields sharing the Multi Value Link. (Recall that a Multi Value Field is a Field with a non-null Multi Value Link Property). Each of the Multi Value Fields participating in the multi value group has the name of the Multi Value Link in its Multi Value Link property. The Multi Value Fields in the originating Business Component have the following important properties: Multi Value Link Property. This property identifies the Multi Value Link that provides values, by way of the Link object, from the multi value group BusinessComponent. Field Property. This property identifies the Field in the multi value group Business Component that, by way of the Multi Value Link and Link object definitions, provides values for the Field in the originating Business Component.

Multi Value Fields. These are the Fields in the originating Business Component that are populated by the Multi Value Link. Data population relationship is indicated by the presence of the Multi Value Links name in their Multi Value Link property. The Field property in each identifies the corresponding Field in the multi value group Business Component that provides its data. Multi Value Fields used in this multi value group situation are Street Address, Address Id, City, Country, Fax Number, Postal Code, and State. Multi Value Link. The Multi Value Link object is a child of the originating Business Component. It identifies the Link that provides the Field values from the multi value group Business Component. In the example, the Multi Value Link is Business Address.

Link. The Link object definition specifies the master-detail relationship between the originating and multi value group Business Components. This makes possible the Multi Value Link object from which the Fields in the originating Business Component obtain their values. In the example, the Link is Account/ Business Address. Creating a Multi Value Group 1. Create a Multi Value Link in the Parent BC uA Link must exist that defines the relationship between the Parent (Source) and Child (Destination) business components. uAdd a Multi Value Link in the Parent BC that references that Link. uAlso give Destination BC and set the Primary Id Field Property. 2. Add Multi Value Fields to the Parent BC uAdd Multi Value Fields that reference the Multi Value Link 3. Create a Multi Value Group Applet uCopy from another MVG Applet to obtain the proper controls uAdd list columns as appropriate (This property identifies the Field in the multi value group Business Component from which the List Column displays data.) 4. Add Controls to the Parent Applet uAdd controls to the parent applet to display the MVFs or child fields uFor the control that should pop up the MVG Applet Set the Runtime property to TRUE Set the MVG Applet property A Glyph after a control or after the data in a list column will be the visual cue for the user Business Object. A Business Object implements a business model (logical database diagram), tying together a set of interrelated Business Components using Links. The Links provide the one-to-many relationships that govern how the Business Components interrelate in the context of this Business Object. The set of relationships established in a Business Object provides the foundation for Views and Screens. Every View has a Business Object assigned to it. A master-detail View can implement only a one-to-many relationship supported by its underlying Business Object. Many Views are built based on the same Business Object. Typically only one Screen is associated with one Business Object. The Business Object collects a logical grouping of Business Components and a set of Links that associate them. Some of the same Business Components and Links may appear in other Business Objects. The same two Business Components may have a one-to-many relationship in one Business Object, and the opposite one-to-many relationship (or no relationship) in another Business Object. However, within the context of one Business Object, there is an unambiguous set of relationships between the Business Components in the grouping. When a particular Business Object is active because a View that uses it is active, the population of data records in Business Components in the Business Object is based on the relationships in the Business Object. The benefit of Business Objects is reusability. The same Business Component can be used in various different sets of relationships by including it in multiple Business Objects. Business Object Component. A Business Object Component object definition is used to include a Business Component and,

generally, a Link in the Business Object. The Link specifies how the Business Component is related to another Business Component in the context of the same Business Object. A Business Object Component can be used to include a Business Component in the Business Object without a Link. To accomplish this, you enter a blank value in the Link property of the Business Object Component. A Link-free Business Object Component allows you to incorporate a Business Component in the Business Object for use in Views based on the Business Object, even though the Business Component does not have one-to-many relationships with other Business Components in the context of that Business Object. Posted 15th January 2008 by J N Labels: Siebel Business Object Types 0 Add a comment Jan 14 Siebel Communications Server What Is Siebel Communications Server? 1 Siebel Communications Server enables users of Siebel eBusiness Applications to send outbound communications to groups of contacts, prospects, or employees using email, fax, or page. Siebel Communications Server was introduced in version 6.0 of the Siebel eBusiness Applications. Siebel Communications Servers outbound communications functionality is available for Siebel eMarketing, Siebel Workflow, and Siebel Paging. 1. Siebel eMarketing supports outbound HTML or plain-text newsletters and email. Special Siebel application views, in addition to those described in this book, provide access to this functionality. 2. Siebel Workflow supports outbound plain-text email and fax by calling the business service methods of Siebel Communications Server. You can also call these methods from a script. 3. Siebel Paging supports modem-based TAP paging. For all these usage contexts, you configure communication adapters and profiles in Siebel Communications Server. Siebel eMail Response, a separately licensed product, provides inbound communications capabilities and enables agents to respond to email, uses some of the same communication adapters as Siebel Communications Server. It also uses Communications Servers server component, Communications Manager, for sending response email. Siebel Communications Server employs the following Siebel Server components: Communications Manager Server Request Processor Server Request Manager All three components must be running for communication requests to be processed successfully. Features of Siebel Communications Server Communication Adapters and Profiles Different types of communications can be sent using Siebel Communications Server, based on the messaging systems you support. Communications Server includes several communication adapters (often simply called adapters), each of which enables communication with a particular messaging systemwhether for email (such as Microsoft Exchange Server), fax, or page. Your messaging systems must also be configured to receive and process messages from Siebel Communications Server. Administrators can configure the adapters and create communication profiles (often simply called profiles). Each profile specifies which adapter is to be used for a particular purpose, how the adapter will be used for communications using the profile, and the

sender of communications that will be sent using the profile. Packages and Package Items Users of Siebel Communications Server create packages and specify one or more package items for them. Packages represent individual messages meant for a particular delivery method such as email, fax, or page. A communication profile is specified for each package. Package items are content elements contained within each package. Package items may be Literature items or files from the Siebel File System. They may be either plain text or HTML , and they can be specified as part of the message body or as attachments to the packages message. Multiple package items specified for the message body are concatenated into a single message body per package. Package items can provide their own content, or can serve as templates and retrieve data from a Siebel business component to be merged into the message body or into an attachment. Communication Requests Users create communication requests to specify which packages will be sent, and to whom. The user specifies a recipient group type for the request, which identifies the type of recipient to which the packages will be sent. For example, after specifying Account Contacts as the recipient group, the user then chooses one or more accounts in order to send to all contacts associated with the accounts. If the recipient group is simply Contacts, the user chooses each individual recipient from all contact records. Each request is then submitted to Siebel Communications Server (by way of Server Request Processor and Server Request Manager) for processing and in order to send the packages as messages to the intended recipients, using the appropriate messaging system. Configuring Your Communications 1. Set up your Siebel Server machine and Siebel Communications Server to interface to different messaging systems that Communications Server supports 2. Configure and administer the Siebel Communications Server server component 3. Configure Siebel Communications Server communication adapters and profiles 4. Configure the Siebel application to define additional recipient groups for your communications, based on Siebel business objects and business components Administering Siebel Communications Server Siebel Communications Server runs as a Siebel Server component called Communications Manager. This server component uses generic configuration parameters and does not need to be configured. The Communications Manager component is started automatically when the Siebel Server is started. For any machine on which you do not want to run Communications Manager, you can configure the Siebel Server not to start it. Communications Manager is a request-mode server component. It relies on the services of the Server Request Processor and Server Request Manager server components. All three components must be running on the Siebel Server for communication requests to be dispatched successfully. If a messaging system server is restarted, then the Communications Manager server component that connects to it must also be restarted. If you have more than one Siebel Server, and you want all communications that are processed using a particular communication profile to use a specific Siebel Server, you can configure an adapter parameter to specify the Siebel Server name. To do this, set the value of the Siebel Server adapter parameter, which is supported for all Siebel-provided communication adapters, to the name of the Siebel Server that is to handle the delivery of the communications. The value of the Siebel Server parameter must exactly match the actual name of the Siebel Server. As with other adapter parameters, you can either specify a default value or provide an override value for

a particular communication profile. Working with Communication Adapters and Profiles Adapters and profiles are used both by Siebel Communications Server (for Siebel eMarketing, Siebel Workflow, and Siebel Paging) and by Siebel eMail Response. Siebel Communications Server includes several communication adapters, each of which enables communication with a particular messaging system, whether for email (such as Microsoft Exchange Server), fax, or page. Communication adapters are in the form of library files: For Microsoft Windows NT, the library files are DLLs and have the extension .dll. 2. For UNIX, the library files are object files and have the extension .so. As the Siebel administrator, you can configure the adapters that you will need, then create communication profiles (also called profiles). Each profile specifies which adapter is to be used for a particular purpose, how the adapter will be used for communications using the profile, and the sender of communications that will be sent using the profile. You configure each communication profile by overriding default values of adapter parameters. Adapters for Outbound and Inbound Communications Different Siebel products use different adapters: 1. Adapters that have the Outbound flag set can be used by Siebel Communications Server and Siebel eMail Response. The Modem-based TAP Paging adapter is used by Siebel Paging only. 2. Adapters that have the Inbound flag set (Extended MAPI, Microsoft Exchange Server, and Internet SMTP/POP3 Server adapters) can be used by Siebel email Response. Siebel-Provided Communication Adapters The adapters provided by Siebel Systems are: Extended MAPI. Supports MAPI-compliant systems such as Microsoft Exchange Server, Lotus Notes, or SMTP/POP3 servers. Note that the extended MAPI interface is used, not the socalled simple MAPI functionality. This adapter is for both outbound and inbound communications. Internet SMTP/POP3 Server. Supports any Internet mail server that supports the SMTP protocol for outbound email or the POP3 protocol for inbound email. This adapter supports HTML email and plain-text email. This adapter is for both outbound and inbound communications. Microsoft Exchange Server. Supports Microsoft Exchange Server. This adapter uses the same library file as the Extended MAPI adapter, but uses different adapter parameters and is somewhat easier to deploy. This adapter is for both outbound and inbound communications. Microsoft SMTP Service. Supports SMTP service on Microsoft Internet Information Server (IIS) version 4.0 or later, to run on Windows NT Server version 4.0. This adapter supports HTML email and plain-text email. This adapter is for outbound communications only. Modem-based TAP Paging. Supports paging over a modem using TAP (Telocator Alphanumeric Protocol). This adapter is used by Siebel Paging, which is a separately licensed module. This adapter is for outbound communications only. Adapter Settings In the Adapters and Profiles view, the following information is displayed by default for each adapter: Adapter name

 Whether the adapter is for inbound or outbound communications, or both A brief description Adapter parameter names and values The only adapter data you should modify directly are the default values for the adapter parameters, which are shown in the Adapter Parameters list applet. The Library Name field in the Communication Adapters list applet contains the name of the library file for each adapter. This field is hidden by default, but can be displayed by right-clicking and choosing the Columns Displayed command from the shortcut menu. Working with Adapter Parameters Adapter parameter data is displayed in the Adapter Parameters list applet in the Adapters and Profiles view. For each adapter parameter, a flag indicates whether the parameter requires a value; usually, values for such parameters would be specific to your site. For each required parameter, you must do one or both of the following: 1. Enter a new default value 2. Override the default value in any profile based on this adapter Depending on your implementation, you will not need to change default values for most other parameters. Posted 14th January 2008 by J N Labels: Siebel Communications Server 0 Add a comment Jan 14 Siebel Implementation Process Siebel Implementation Process 1. Stage SPA00 - Plan and Activate 2. Stage SRP00 - Release Planning 3. Stage SRQ00 - Requirements Definition 4. Stage SFA00 - Functional Analysis & Design 5. Stage STA00 - Technical Analysis & Design 6. Stage SCF00 - Configuration 7. Stage SDM00 - Data Migration 8. Stage STS00 - Testing 9. Stage SDP00 - Deployment 10. Stage SUT00 - User Training 11. Stage SCE00 - Control and End Stage SRQ00 - Requirements Definition Step Tasks Output Step 0100 - Acquaint Project Team with Business Task 010 - Prepare Siebel Application Demo Task 020 - Demo Siebel to Business Community Siebel Business Requirements Document Step 0200 Conduct Siebel Awareness Sessions

Step 0300 Identify Siebel Business and Reporting Requirements Task 010 - Capture Business Requirements Task 020 - Capture Reporting Requirements Siebel Business Requirements Document Step 0400 Define Organizational Structures & Positions /Responsibilities Step 0500 - Prioritize and Establish Baseline Requirements

Stage SFA00 - Functional Analysis & Design Step Tasks Output Step 0100 Create Business Object Model Task M00 - Milestone SFA M00 Functional Analysis & Design Started Task 010 - Define Business Processes Task 020 - Map Business Processes to Business Objects Task 030 - Create Business Object Model Task 040 - Validate Business Object Model Task M01 - Milestone SFA M01-Business Object Model Complete Siebel Business Object Model Step 0200 Develop High Level Screen Design Task 010 - Define Business Transactions Task 020 - Identify Screens Task 030 - Map Business Transactions to Screens Task 040 - Create Transaction Groups High Level Screen Design Step 0300 Identify Required Views, Applets and Reports Task 010 - Identify Views Task 020 - Identify Applets Task 030 - Identify Reports Task 040 - Consolidate Gap Analyses Task 050 - Create Views/Applets/Reports Reusability Matrix Task 060 - Define Navigation Between Views

Task 070 - Assign Siebel Visibility Classes High Level Screen Design Siebel Screen Visibility Checklist Siebel Screen Design Checklist Siebel Screen Data Elements Views/Applets/Reports Cross Reference Matrix Step 0400 Create Business Component Model Task 010 - Extract Business Components from Views and Applets Task 020 - Extract Business Components from Business Objects Siebel Business Component Model Step 0500 Refine Business Component Model Task 010 - Map Conceptual Business Components to Standard Siebel Business Components Task 020 - Specify Changes to Standard Siebel Business Components Task 030 - Map Data Elements to Business Components Siebel Business Component Model Step 0600 Design Views, Applets and Reports Task 010 - Design Screen Layouts (Applets and Views) Task 020 - Design Report Layouts Siebel Screen Visibility Checklist Siebel Screen Design Checklist Siebel Screen Data Elements Applet Design Specification Report Design Specification Step 0700 - Create and Review Functional Specification Task 010 - Document Changes to Tables, Business Components, UI Task 020 - Document Functional Specification Task 030 - Conduct Functional Design Review (Internal) Task M02 - Milestone SFA M02 -Functional Analysis & Design Finished Functional Specification

Technical Analysis & Design Step Tasks Output Step 0100 Define Technical Architecture

Step 0200 Perform Capacity Planning Task 010 - Assess Network Bandwidth Requirements Task 020 - Determine Database Sizing and Tuning Requirements

Capacity Planning Documentation Step 0300 Conduct Siebel Technical Reviews Task 010 - Conduct CapacityPlanning Review Task 020 - Conduct InfrastructureStrategy Review Task 030 - Conduct Data MappingReview Siebel Review Results Step 0400 Document Design Specification and Procure Components Task 010 - Document DesignSpecification Task 020 - Initiate Procurement Task M01 - Milestone STA M01 Technical Analysis & Design Finished Design Specification

Stage SCF00 - Configuration Step Tasks Output Step 0100 Set Up Development Environment Task M00 - Milestone SCFM00 -Configuration Started Task 010 - Set up Network Connectivity Task 020 - Set Up Siebel File System Task 030 - Install Siebel GatewayServer Task 040 - Install Siebel Servers and Enterprise Server Task 050 - Install Siebel Database Server Task 060 - Install Web Server Task 070 - Install Third Party Software Task 080 - Install Siebel Client Task 090 - Install Siebel Tools Task 100 - Set Up Configurators Task 110 - Create Database Extract for Configurators Task 120 - Initialize Local Database Environment Setup Step 0200 Initiate Configuration Task 010 - Assign Functional Areas to Configurators Task 020 - Analyze and Refine Projects Configuration Guidelines Step 0300 - Implement Database Extensions Task 010 - Implement Extensions Task 020 - Test Extensions Task 030 - Apply Changes to Master Database Task 040 - Create Local Database Extract Task 050 - Reinitialize Local Databases Physical Database Schema Step 0400 - Set Up Static Data

Task 010 - Set Up Positions and Responsibilities Task 020 - Set Up LOV's List of Values User Settings Step 0500 - Customize Siebel Business Objects Task 010 - Create/Modify Business Objects and Components Task 020 - Validate Siebel Configuration Siebel Local Database Step 0600 - Customize Siebel Presentation Objects Task 010 - Configure Presentation Objects Task 020 - Unit Test Configuration Objects Siebel Local Database Step 0700 - Create Siebel VisualBasic Scripts Task 010 - Create Siebel Visual Basic Scripts Task 020 - Unit Test Siebel VB Scripts Siebel Local database Siebel Repository File Step 0800 - Conduct Quality Review Task 010 - Conduct Quality Review and Fix Problems Task 010 - Conduct Configuration Review (Siebel) Configured Application Step 900 - Evaluate Release Modification Requests Task 010 - Capture User Feedback Task 020 - Prepare Estimates for Changes Task 030 - Review and Prioritize Changes Task M01 - Milestone SCF M01-Release is Complete Project Management Plan Step 1000 - Prepare for Deployment Task 010 - Develop Operations Manual Task 020 - Prepare Rollout Plan Task 030 - Conduct Production Readiness Review Task M02 - Milestone SCF M02 Release is Production-Ready Approved Deployment Package

Data Migration Step Tasks Output Step 0100 Determine Data Migration Strategy Task M00 - Milestone SDM M00 Data Migration Started Task 010 - Inventory Data Sources Task 020 - Acquire External Data Task 030 - Assess Data Integrity Task 040 - Determine Automated vs.Manual Migration Approach Task 050 - Determine TransitionApproach Task 060 - Determine Migration

Backup and Recovery Strategy Task 070 - Develop Migration Tests Task 080 - Finalize Data Migration Plan Data Migration Plan Step 0200 Design Migration Process Task 010 - Design Data MigrationRoutines Task 020 - Verify Siebel InterfaceData Mapping Task 030 - Design Manual Processes Siebel Data Migration Script Manual Entry Procedures Step 0300 Construct Migration Process Task 010 - Build Data ExtractionRoutines Task 020 - Write Data Load Scripts Task 030 - Create Batch Processes Data Extraction Routines Data Load Scripts Batch Processes Step 0400 Test Migration Routines Task 010 - Unit Test MigrationRoutines Task 020 - IntegrateTest FullMigration Process Tested Data Migration Process Step 0500 Perform and Verify Data Load Task 010 - Execute Data ExtractionRoutines Task 020 - Execute Data LoadRoutines Task 030 - Verify Data Load Task 040 - Reconcile Automatic DataMigration Routines Task 050 - Conduct Manual DataConversion Task M01 - Milestone SDM M01 -Data Migration Finished Data Load

Testing Step Tasks Output Step 0100 Set up Testing Environment Task M00 - Milestone STS M00 -Testing Started Task 010 - Set up Network Connectivity Task 020 - Set Up Siebel File System Task 030 - Install Siebel Gateway Server Task 040 - Install Siebel Servers and Enterprise Server Task 050 - Install Siebel Database Server Task 060 - Install Web Server Task 070 - Install Third Party Software Task 080 - Install Siebel Client Task 090 - Set up Dialup Connectivity Task 100 - Set up Internet Access

Step 0200 Prepare Testing Server Task 010 - Build Testing Database Task 020 - Confirm Data Migration Task 030 - Set Up Users Task 040 - Create Predefined Queries Task 050 - Verify Positions and Responsibilities Task 060 - Verify LOV's Task 070 - Define and Test Translations Task 080 - Set Up Correspondence Templates Task 090 - Establish Call Center Administration Task 100 - Set Up Siebel Marketing Encyclopedia Task 110 - Create Database Extract for Remote Users Step 0300 Develop Test Plans Task 010 - Create User Acceptance Test Plan & Cases Task 020 - Create System Test Plan Task 030 - Select and Procure Automated Testing Tool Step 0400 Conduct Testing Task 010 - Conduct User Acceptance Testing Task 020 - Conduct System Performance Testing Task M01 - Milestone STS M01-Testing Finished

Deployment Step Tasks Output Step 0100 Set Up Production Environment Task M00 - Milestone SDP M00 Deployment Started Task 010 - Set up NetworkConnectivity Task 020 - Set Up Siebel File System Task 030 - Install Siebel GatewayServer Task 040 - Install Siebel Servers and Enterprise Server Task 050 - Install Siebel DatabaseServer Task 060 - Install Web Server Task 070 - Install Third PartySoftware Task 080 - Install Siebel Client Task 090 - Set up Dialup Connectivity Task 100 - Set up Internet Access Environment Setup Step 0200 -

Prepare Production Server Task 010 - Build Database Task 020 - Confirm Data Migration Task 030 - Set Up Users Task 040 - Create Predefined Queries Task 050 - Verify Positions and Responsibilities Task 060 - Verify LOV's Task 070 - Define and TestTranslations Task 080 - Set Up CorrespondenceTemplates Task 090 - Establish Call Center Administration Task 100 - Set Up Siebel Marketing Encyclopedia Task 110 - Create Database Extractfor Remote Users Local Database Extract Physical Database Schema List of Values User Settings Queries Translations Correspondence Templates Call Center Parameters Populated Marketing Encyclopedia Step 0300 Roll Out Release Task 010 - Establish/Test ProductionSupport Infrastructure Task 020 - Implement BackupProcedures Task 030 - Deploy Application Task 040 - Verify Connectivity toDatabase Task M01 - Milestone SDP M01-Release Accepted Deployed Release Step 0400 Prepare for Next Release Task 010 - Review Results of ReleaseRollout Task 020 - Refine Release Strategy Task M02 - Milestone SDP M02 -Next Release Go-Ahead Project Management Plan Posted 14th January 2008 by J N Labels: Siebel Implementation Process 0 Add a comment Jan 12 Siebel Data Migration and EIM Tables Siebel Data Migration and EIM Tables ETL is Extraction Loading and Transformation of data. There are different tools like DataStage and Informatica which can be used for the ETL purpose. These tools give a facility to read the data from different databases or systems and ETL data to other databases or systems. These tools are used for data cleansing, transformation and data validations. Data Sources for Data Migration Data sources for the Siebel applications can be the data from Legacy system, other OLTP systems, EDW (Enterprise Datawarehouse), or independent systems for different departments of the company. The data from external data sources needs a lot of data cleansing, data

transformation, data validations and data massaging before loaded into the Siebel applications. What is EIM Siebel Enterprise Integration Manager (EIM) is a server component in the Siebel EAI component group that transfers data between the Siebel database and other corporate data sources. This exchange of information is accomplished through intermediary tables called EIM tables. The EIM tables (or Interface Tables) act as a staging area between the Siebel application database and other data sources. Need of EIM Tables In the Siebel application database, there are application tables (known as base tables),which Siebel applications use. For data to come from other corporate data sources (external databases) into Siebel application tables, the data must go through EIM tables. So the data exchanges between the Siebel database and external databases occur in two parts: 1. Load data into EIM tables. 2. Run Siebel EIM to import the data from the EIM tables into the Siebel base tables. EIM is the primary method of loading mass quantities of data into the Siebel database. EIM should be used to perform bulk imports, updates, merges, and deletes of data. EIM tables are used as the staging tables for the data to be loaded from the external databases. EIM uses several columns common to every EIM table. Several columns are mandatory. Others are conditionally mandatory, depending on the conditions of your import. To determine mandatory columns, use Siebel Tools to view each column in an EIM table and the EIM tables target base table columns. 1. Mandatory Columns ROW_ID For an EIM table row to be eligible for processing, you must initialize its ROW_ID. The ROW_ID, in combination with the value of IF_ROW_BATCH_NUM, must yield a unique value. The ROW_ID values in the EIM tables are not the ROW_ID values that are assigned to the row when it is loaded into the base table. Generally the running sequence number can be assigned to this column. IF_ROW_BATCH_NUM You must set the values in this column to the same integer, greater than or equal to 0, as an identifying number for all rows to be processed as a batch. The maximum value is 2147483647. Use this column as the first key of any new indexes created on an EIM table. IF_ROW_STAT EIM updates this column after processing the row to indicate the status of the record. The IF_ROW_STAT column is not used by EIM when determining which rows to process. When populating the EIM tables, you can set this column to any value except NULL. You can initially set this value to FOR_IMPORT to indicate that the row has not been imported. 2. User Key Columns These are the columns which are mapped with the user key column into the base tables. 3. Default Value Columns These columns are the ones which are required for the visibility on UI. These columns are assigned with some hard coded values as identified by the EIM person required for further processing. The values are generally like Y, N, Siebel Administrator, Default Organization etc 4. Data Columns These are the columns which hold the data coming from the source systems.

5. Extended Columns EIM tables can be extended for your specific need. If there is a need to store some source data which do not have any place holder, the EIM table can be extended with new columns and those columns are known as extended columns. Lookup on Siebel Base Tables As mentioned earlier, Siebel doesnt recommend accessing the base tables directly. So if there is a need of doing a lookup against any base table, what to be done? To resolve this issue, data can be retrieved in to the XML format. Siebel gives the facility to export data into the XML format. ETL tool can read these XML files and create the required lookup files. These look up files can be used for the lookup purpose. EIM Process This is the second part of the data migration. After data is loaded into the EIM table using ETL tools, EIM process is used to load the data into base tables. These processes read the data from the EIM tables and load it in to the appropriate base tables. Generally not much transformation is done into EIM process. EIM process can be run either navigating through Administration - Server Management > Jobs in the GUI or from the command line interface. EIM Configuration file (.IFB) is used to define the EIM process. Data Load Strategy in EIM Tables As mentioned earlier EIM tables are like the staging tables. Generally the data load strategy used for the staging area is truncate and load. A similar approach with a little different strategy is taken for EIM tables. Data is always inserted into the EIM tables. To avoid the unique key constraint with the existing (previous load) data the existing IF_ROW_BATCH_NUM is updated with the SYSDATE+IF_ROW_BATCH_NUM (concatenation). This way the previous data is retained and new data is also inserted. This approach is taken to enable the possibility of any finding/debugging on the previous data. This data can be retained for few days. Posted 12th January 2008 by J N Labels: Siebel Data Migration and EIM Tables 0 Add a comment Jan 12 Siebel Server Administration Siebel Server Administration Siebel DB Server: Stores Data Schema (table objects, index objects, constraints and triggers) Holds repository objects (BO, BC, View definitions and visibility rules) Customer data Relational store (No Bus logic in stored procedures or triggers) Multiple SDB installations can reside on a single instance of the RDBMS Each Siebel DB needs its own unique DB /table owner Setting up SDB Server: 1. Install RDBMS on DB Server 2. Install SDB Server scripts On CD ROM \Siebel\DBSRVR\Setup.exe Setup.exe copies BAT files and SQL scripts to DBSRVR subdirectory 3. Edit and execute the following scripts: GRANTUSR.SQL creates the DB Owner role and SADMIN user SIEBENV.BAT Sets environment variables INSTALL.BAT Creates Siebel tables and indexes

IMPREP.BAT Imports Siebel repository data 4. Review log files Siebel File System: Stores marketing literature, coresspondence templates and attachments File system object has 2 components: 1. DB Record 2. Physical file on the server Files = stored and transferred in compressed format 3 parts: 1. DB Table holding literature items 2. Siebel Row id for record 3. Revision number All Siebel file system files have a SAF extension Setting up Siebel File System: Can be on any machine that supports LFN (standalone, Siebel Server or DB Server) Must be one for each Siebel DB table owner 1. Create Siebfile directory on machine Register path in Siebel Server Define in client config 2. Establish SFS connectivity Siebel Server(s) and clients require network connectivity Must have R&W access to SFS directory Siebel Enterprise Server: Logical grouping of servers with the same DB and tableowner which point to the same GW Server and can be administered as a group with server manager 1. To install, run SGW Server install program once for each enterprise On CD ROM \Siebel\Siebsrvr\setup.exe 2. Start SGW Name Server Service Enables administrators to start up and shut down the enterprise and set parameters across all servers within the enterprise Siebel Server: Runs Siebel Server programs Is an NT Service Requires a TCP/IP connection to GW Server in the enterprise Runs components which support back-end processing e.g. EIM, Assignment Manager and Workflow Manager 1. Install from CD ROM \Siebel\Siebsrvr\setup.exe on each machine that will be a Siebel Server 2. Start Siebel Server NT Service Recommended HW: Application Server dual pentium pro 166, 128 MB RAM Running Thin Client / Siebel Remote Dual Pentium pro 200, 256 MB RAM, 60 MB Hard Disk. Siebel Remote Servers require an extra 10MB Hard Disk for each mobile client RAID 1 / 5 Can install multiple servers on one machine although each must have its own port SRVR setup.log in Siebel_Server root Siebel GW Server: Logical entity made up of: 1. Name Server Consistent configuration store Dynamic registry of Siebel Server Availability 2. Resonate dispatch (optional) Connection brokering for thin clients and Assignment Manager

Load balancing of CPU usage Install on all servers before Siebel software!! \Thirdpty\resonate\setup.exe Can support many enterprise servers, although not recommended Install once for all Siebel Servers in the enterprise (on 1st Server you set up) \Siebel\GTWYSRVR\Setup.exe Share GTWY_Server directory Configuration information = also in a backing file \admin\siebns.dat (in case GW Name Server Service is unavailable) GTWYsetup.log is in the GTWY_Server root. Siebel Server Manager: Allows common control, admin and monitoring across disparate programs Resides on Siebel client and should connect to Siebel Server and GW Server Embedded in Siebel Client application Installation and implementation process: 1. Install 3rd Party SW 2. Install Siebel Enterprise a) Siebel File System b) Siebel GW Server c) Siebel Server and Enterprise Server d) Siebel DB e) Client Install 3. Implement Siebel Enterprise a) Define Organization b) Import Data c) Assignment Manager 4. Configure Siebel and Implement Siebel Remote C.Taylor-Smith Siebel Revision Notes Server Administration 3 3rd Party SW included: Acrobat 3.0 Fulcrum Search Builder 3.7 Sybase SQL anywhere 5.5.04 ODBC Drivers Actuate developer workbench 3.0.6 Resonate Central Dispatch Not included: Word PPT RDBMS Network Connectivity SW Operating System Siebel Client: Siebel supports 3 types: Stationary Runs Siebel Client program Direct, native communication to DB (LAN, WAN, internet) Mobile Runs Siebel Client Program Local DB TCP/IP to Siebel Server (LAN, WAN, Internet, Dial in) Thin Client Accesses Siebel Client through Web Browser TCP/IP to GW Server Over Internet

SISNAPI (Siebel Internet Session API protocol) is a thin layer on top of TCP/IP, used for communication between ActiveX thin client, Siebel Web engine and Siebel Object manager. Administering the enterprise: Server manager command line: SRVRMGR.EXE in Siebel_Server_Root\Bin Login: SRVRMGR /g /e /u /p /s points to a specific server If you unset server, you can point to a different server Server parameters are either Dynamic take effect immediately for newly initiated tasks Static Take effect upon server restart Changes inherit downwards Possible to change groups of parameters using \admin\siebcfg.dat (server configuration file) Import changes with the configuration editor utility Server_Root\Bin\Srvredit.exe Component processes = one of three modes: Server (run forever when started) Task (perform task & exit upon completion) Session (Created dynamically in response to a client request and serves request as long as the session is maintained) Information logs: (Server Administration Servers Server information logs) Component level details Drill down LogID hyperlinks Physically stored as trace files (.trc) in the Siebel_Server_Root\Log\ directory Each restart of Siebel Server Servive moves trace files to the \LOGARCHIVE directory The default = to save files after 10 restarts (configurable parameter) Steps to Define Organization in Siebel: 1. Define Organizational heirarchy (in application administration Organization screen) 2. Understand visibility 3. Define positions 4. Define reponsibilities 5. Set up users as employees BO visibility classes: Enterprise: (All) Limited (Certain Users) Personal (Owned by an individual e.g. contact / quote / opportunity) Limited visibility teams and access lists: A member of a team can view / update related resources and delete other members (manual asignment) Membership can be automated (Assignment Manager) 3 Types: Account Team Opportunity Sales Team Access List Positions are added to teams and lists and users are affiliated with one / more teams!! Siebel is position-based Positions are static and allow for team selling Employee can only sit in one position at a time and must select EDIT -> Change Position to view from another. Primary position: Can merge / delete records Can submit forecasts Assigned manually or automatically If record = imported via EIM it will only have visibility through the marketing administration List

view until a primary position is assigned. View visibility: Personal list My own (owner) Managers list My teams individual whos reports are primary on a team All List All records with a primary Marketing Administration List All records in the DB Responsibilities: Group of views to which the user has access Application administration responsibilities User sees a union of all responsibilities upon login (unlike positions where you must change). Employee data = stored in S_EMPLOYEE View definitions = stored in S_APP_VIEW Responsibilities + affiliated employees = in S_RESP Relationship between responsibility and view = in S_APP_VIEW_RESP An employee has 1 / more positions and responsibilities, although there is no direct relationship between position and reponsibility!! Setting up employees in Siebel: 1. Create in DB (e.g. Oracle) 2. Define in Siebel Application Last name & First name Login name Must match DB login id Should match network access login Responsibilites Position Skills Do not delete employees? Logins are not case-sensitive!! Stored in Upper case in S_EMPLOYEE Application Administration Employees employee skills for service reps Application Administration Positions Position Skills for Sales Reps Assignment Manager: Ensures most knowledgeable, available agents are automatically assigned ownership of data Compares Obj. attributes to assignment rules and object attributes to people skills Predefined assignment objects: Opportunity, Account, Contact, Campaign, Service Request, Product Defects, Activities You can create more! Assignment rule types: All, above minimum = Candidates score >= minimum score All, Must Assign = Use all people, highest candidate even if below minimum) wins One, Best fir = highest scoring employee / position On, Random Assignment Criteria: (Assignment Administration Assignment Criteria View) Methods: Compare to Object Compares values to Object attribute Compare Object to person Compares Object attribute to persons skill Additional criteria flags: Include / Exclude Required Wildcards Defining candidates: All people Explicitly select potential assignees Positions (sales data)

Employees (Service data) Assignment Administration Assignment Workload view Create rules to prevent employee overload Specify max load Assignment Administration Employees view = used to select potential candidates Assignment Manager calculates the score for each employee / position Highest score = best match To use scores, rank criteria from least to most important Once rules are defined, release them (Assignment rules view click release) AM only recognizes released rules. This will restart AM and regenerate new rulecache.dat Default assignee parameter = used to determine which position will have visibility to unassignable items (set using tools SADMIN is default) Running AM: Spawns a separate thread for each assignment request Loads DB tables for rule and object definitions into memory 2 phases: 1. Qualification Attribute matching Skills matching 2. Assignment AM runs in 3 modes: Batch Dynamic Interactive Batch: Administrator submits batches of objects for assignment / reassignment AM selects optimal position(s) / employee(s) and assigns them to the object Used when: Territory realignment Employee promotion Rule change affecting objects already assigned Change of AM config in tools Used EIM to perform initial loads with triggers disabled Existing Assignment is inaccurate Dynamic: Automatically invoke AM to intelligently assign new objects (inserts / updates) changed by: Connected clients Siebel Remote EIM Thin Clients To run in dynamic mode: Run generate triggers once Re-run only if the developer makes changes to an object in tools Ensure server request manager is running Automatically spawns AM thread to service an Assignment request Start a Workflow monitor task Group: Assignment Group Use Action Agent: False Interactive: End-User Requests Assignment and is presented with a list of qualified people available Can be used for all assignment types To use, update client configuration settings for GW address and request server.

Workflow Manager: 1. Set up conditions on object 2. Create actions Email Page Insert into DB Update DB Launch External Application Configuring components to support WM 1. Run generate triggers DB triggers to identify which records may be policy violations If new policies = created / old ones expire run generate triggers to delete the old & enable new Parameters: EXEC values = TRUE or FALSE determines if SQL script file runs automatically (T) or manually (F) Trigger file name name and output location for SQL script file Remove TRUE will generate drop-trigger statements If trigger fires against a WF condition, there is an insert into S_ESCL_REQ 2. Start WF Manager Agent Checks escalation request table for violation of WF policies Generates requests for WF action agents in action request table S_ESCL_ACTN_REQ Purges requests from S_ESCL_REQ after processing 3. Start a WF action agent Processes requests in S_ESCL_ACTN_REQ for a single group Invokes all actions linked with the policy being processed Email and page actions are logged in S_APPSERVER_REQ and executed by email server and page server Purges S_ESCL_ACTN_REQ 4. Start email manager task 5. Start Page Manager Task EIM Troubleshooting and Performance: Trace flags = 1 will provide a step-oriented look at the task Trace flags = 2 creates a log with trace substitution of user parameters Trace flags = 3 Traces all IF mapping warnings Log detail = prefaced by [TRC] Error flags document: Step and pass of failure Number of rows that failed Error severities SQL used to view row (s) failed Log detail = prefaced by [ERR] IF_ROW_STAT interface table provides high level error information: FOR_IMPORT Record not processed by EIM IN_PROGRESS Failure occurred which aborted further processing of this table SQL_ERROR SQL error occurred while trying to import row IMPORT_RESTRICTED User-specific filter for row failed FOREIGN_KEY Required FK column in target could not be resolved PICKLIST_VALUE Required pick list value in target could not be found REQUIRED_COLUMNS 1/ more required columns in target table were null DUP_RECORD_EXISTS Row = exact match to target table PARTIALLY_IMPORTED Did not fail for target, but did secondary IMPORTED Fine .IFB file Problems If using ONLY BASE COLUMNS parameter, user key must be included Make sure youre referencing the same columns / tables

Make sure header + process titles are referenced correctly Especially when using TYPE=SHELL ONLY_BASE_TABLE must include target table Post volume load tasks: Enable triggers if using AM Set docking transaction logging = TRUE if supporting mobile users Monitor table fragmentation on base tables with large volumes of data Advanced performance tuning: Cleanse data for duplicates prior to running EIM EIM executes queries against IF tables to scan for duplicates Keep batch sizes small (5,000) Maintain IF tables Delete processed records Check for fragmentation caused by constant insert / delete operations Use IF tables that map to multiple base tables e.g. S_ACCOUNT_IF for accounts, addresses, industries, installed products etc. Disable DBMS transaction logging for large loads to IF tables and turn off after load Disable triggers (e.g. for WF and AM) Update / recreate indexes for B-Tree balancing Posted 12th January 2008 by J N Labels: Siebel Server Administration 3 View comments Jan 12 Siebel Remote DB Server stores Master Transaction Log. S_DOCK_TXN_LOG Contains NET change only. Transactions are automatically purged after they are routed to the Remote Servers. Siebel Server: \ROOT\DBTEMPL Contains DB template used by mobile client during initialization of local DB. \ROOT\DOCKING\\INBOX Contains files that are uploaded by client. \ROOT\DOCKING\\OUTBOX Contains files to be downloaded to the client. Generate New DB will put the following in the Siebel_Server\Root\Dbtempl\db35r23 directory: Dicdata.dat Data dictionary file Siebel.ddz Compressed data definition language Env_1252.dbz Compressed DB template file containing schema. DB Extract: Snapshot file contains user-specific data (000001.uaf) Required to initialize local client DB (database.uaf) 2 Stages to extract: 1. Enterprise visible data -> Enterpse.dat & Enterprise visible literature files -> Enterpse.toc 2. User-Specific data, 1 user at a time. User-specific data -> database.dat Literature files owned by user -> 000002.toc Enterpse.dat & Database.dat are combined to form 00001.uaf. Enterpse.toc & 00001.toc are combined to form 0001.toc. Transaction Processor: Copies transactions from master transaction log to Siebel Servers. (Sequential 0000001.dx files in \DOCKING\TXNPROC) Marks visibility of all transactions in master transaction log on DB Server.

Purges Master Transaction Log when transactions have been routed to all Siebel Servers. Run only one Transaction Processor per Siebel Server!! Transaction Router: Processes transactions from TEXNPROC\*.dx for each mobile user. Uses visibility rules to route to the correct outbox Multiple router tasks can be started on the same Siebel Remote Server Visibility Checking: If non-visibility event, router checks the users dobjinst.dbf for the account in question. If there is an entry, route the transaction. If a visibility event, checks the shared visdata.dbf file on the Siebel Remote Server. If its the first time the transaction is routed to a user on this Siebel Remote Server, the router checks the DB and caches additional visibility data in visdata.dbf \Docking\visdata.dbf automatically recreated if deleted. \user\dobjinst.dbf created during DB extract. (If deleted, re-extract mobile client and restart transaction router). Synchronization Manager: Automatically started upon client request to synchronize Multi-threaded When the maximum number of threads is reached, a new SM process is started. SM component must be enabled. Validates the mibile client Validates and decompresses transaction files Handles transfer of literature, correspondence and Attachments. Transaction Merger: Applies uploaded transactions in the inbox in order the mobile clients synchronize. Asynchronous merger (after the client has disconnected) At least one per Siebel Remote Server Local DB and File System: Local DB file = Siebel\Local\SSE_DATA.dbf Diccache.dat = used by server programs to enhance performance when loading repository Dicdata.dat = copy of diccache.dat (downloaded to client and used for synchronization) Generate New DB copies diccache.data to dbtempl\dicdata.dat and then down to client upon synchronization. Local DB initialization: Applies DB schema and snapshot file to local DB Automatically invoked if: No local DB is detected DB extract is in Inbox on the server. Steps to enable Siebel Remote on the Server: 1. Verify server specs 2. Enable encryption 3. Set Siebel Remote system preferences 4. Review Routing Rules 5. Generate DB template 6. Register Mobile Clients 7. DB Extract 8. Configure Remote Server Components Server HW requirements: Dual P Pro 200, 256 MB RAM 60MB HD for SW + 10 MB for each mobile client, 3 x RAM Virtual Memory. N.B. Disable local access to all list view!! (else client automatically attempts to fix FK relationships when displaying data on screen).

To run a DB extract, you can specify comma delimited users / use a wildcard (e.g. J*) to extract groups of users. Steps to enable Siebel Remote for Clients: 1. Verify Client Specs 2. Update cfg 3. Initialize mobile client status 4. Synchronize 5. Set Synchronization preferences 6. View Results Client HW requirements: Win 95 / 98 / NT 4.0 P133, 24 MB RAM, 300MB HD for SW + Local DB. For monitoring synchronization, check upload statistics and download statistics view. Conflicts resolution: Client Wins Rule / Server Wins Rule If transaction merger rejects update, the client is notified. If a record is duplicated, then a row is added and a system internal flag is set (CONFLICT_ID). Recovery: Siebel Remote Server Recovery is automatic When system returns to operational state, restart transaction merger, processor and router! Full recovery from full DB Server media failure may involve re-synchronizing server and client 1. Stop Trans Router, Merger and Processer on Remote Server 2. Suspend docking by disabling synchronisation manager 3. Return DB server to operational state 4. Notify clients who were routed transactions since last DB archive of need to re-initialize DB 5. Run DB extract for affected client 6. Run DB initialization on client Client DB failure: Run DB extract Initialize local DB Siebel Anywhere allows distributers to distribute software upgrades to mobile users, Siebel Servers and Replication Manger DBs including: SRFs New Siebel SW Customer extensions to DB schema 3rd Party files or Applications Patches Upgrade kit wizard is used to create kits. Siebel Anywhere Kits view -> select kit and then click Kit Activate. Create a test employee and login as him Siebel anywhere upgrade kits view -> click apply Posted 12th January 2008 by J N Labels: Siebel Remote 0 Add a comment Jan 12 Assignment Manager and Workflow A Sales Organization can benefit by using Workflow to email customers informing them of discounts associated to new product campaigns Assignment Manager to assign accounts to appropriate account reps based on geographic location Siebel Assistants to define product volume discounts that will automatically be used in

quotes eConfigurator to create complete and valid product packages for customer purchase Pricer to create product pricing models automatically used in quotes and orders Script Engines to automate verbal interaction between Telesales reps and customers A Call Center can benefit by using Workflow to page Field Service reps when urgent service requests are opened Assignment Manager to assign Service Requests to agents based on product knowledge Siebel Assistants to define activities associated to common problems and service calls State Model to allow only certain agents to change the priority or status on service requests CTI to automatically route in-bound and out-bound calls based on specified criteria Script Engines to help ensure agents are communicating consistently with customers Use WF to Automate and apply consistency to your companys business practices Create application integration flows Examples When a Gold customer reports a high severity problem, address it within 1 hour When a critical service request is opened, page the service request owner Use AM to automatically assign work to positions or employees based on defined criteria Ensures assignment to the most qualified or available candidates Examples Assign service requests to the most available field service technicians Assign sales positions in California to California opportunities Use state model to define _ How data fields can be changed from one state to another _ Who can make these changes _ Ensures that appropriate staff can authorize transactions _ Examples Limit who can change the status of a Service Request from Pending to Closed Limit who can change the status of an Expense Report from Submitted to Approved Siebel Assistant Activity Plan Are sets of activities that move opportunities and accounts through a sales cycle from prospect to close, for example: Activities for closing a deal Activities for initial meeting with new customer Provide additional information to support field service reps, such as tools, skills, instructions, and steps, for example: Activities for repairing CD-ROM Activities for service contract renewal Tools and parts required for equipment service Can be invoked automatically or on demand at specific points in the sales or service process Script Wizard Provides Fast prompted method for populating the fields of one Siebel applet Control over which answers that an agent or customer may choose Reduced agent training periods Smart Script Automates the entire customer interaction from start to finish Both types of scripts are Reusable and modifiable, to make their administration more efficient Administered through the Siebel client Main differences between Script Wizard and SmartScript Playback of a Script Wizard script takes place in a wizard dialog box SmartScripts operate as their own business entity, allowing for greater association with other business entities within Siebel eBusiness applications Script Wizard can work with data for one business entity, while SmartScript can capture data

destined for multiple entities Script Wizard does not require knowledge of programming, while SmartScript does Workflow Send pages and emails based on record updates Update service requests status based on actions Create application integration workflows WF & AM Assign urgent services request within 30 minutes Assignment Manager Assign accounts based on geography Assign opportunities based on product knowledge Assign service requests to most available agents State Model Allow only managers to change the status of an expense report from submitted to approved Control when a service request priority can be changed from high to low Siebel Assistants Activity Plans Define the steps to be taken for an introductory sales call Define the steps and tools required for a specific service repair call Siebel Assistants -Assessments Determine an opportunitys potential of closing before spending any more time on it Rate an accounts potential for product upgrade or resell Siebel Assistants Volume Discounts Define a discount of 10% on all laptops on the North American price list Apply a discount to the entire sale or portion of the sale Script Wizard Automatically update fields in a single applet based on customer answers to defined questions Reduce telesales and call center agent training time by providing scripted customer dialogs SmartScript Automate the interaction between call center agents and customers Automatically update fields in multiple applets based on customer answers to defined questions (CTI) Integrate your Siebel eBusiness application with your telephone system Route all hardware-related incoming calls to hardware specialists eConfigurator Configure a valid customer solution and include the solution as part of a quote Ease your customers ability to select and buy the right products over the Internet Pricer Compete effectively on price Posted 12th January 2008 by J N Labels: Assignment Manager and Workflow 0 Add a comment Jan 12 Siebel EAI Components Siebel EAI Components 1 Siebel EAI consists of the following components: Siebel Business Integration Manager Siebel eBusiness Connectors; for example, the Siebel eBusiness Connector for SAP R/3

Siebel Business Integration Manager 1 The Siebel Business Integration Manager provides the development and run-time tools for you to configure and deploy integration between the Siebel system and other applications. At a high level the Business Integration Manager allows you to: Define and configure the content of the messages flowing through the integration points, such as in Siebel business objects, SAP BAPI, SAP IDOC, and XML document definitions. Define, using a GUI-based tool, the interaction sequences and business process flows to exchange messages with an external application. Select the transport and integration technology, such as COM, CORBA, MQSeries, SAP BAPI, SAP IDOC, or other third-party middleware adapters for these business process flows. Define the data transformation between the messages, using Siebel eScript to convert the objects and relationships as viewed by one application to the objects and relationships as viewed by the other. Use XML as a common format for exchanging data. Major components of the Siebel Business Integration Manager include: Integration Objects. Integration objects help you define the messages that are exchanged between the Siebel system and other applications. These messages can represent Siebel business objects or external metadata such as SAP BAPIs or SAP IDOCs. You define integration objects using Siebel Tools. Business Services. Business services are modules that perform specific functions. Examples of EAI business services include adapters, XML format converters, or a modular piece of business logic like a tax calculation function. Siebel provides several pre-built business services, and you also can write your own business services using Siebel VB or Siebel eScript. Business services run within the Siebel Object Manager. You can trigger or invoke business services from various contexts within the Siebel environment, including user interface events, Siebel Workflow actions, inbound message requests; and from external applications using COM, CORBA, or any of the provided transport mechanisms. XML Format. Siebel XML is a Siebel-published format to represent Siebel information. You can use third-party XML transformation tools to build mappings between Siebel XML messages and other applications. EAI Siebel Adapter. The EAI Siebel Adapter is a pre-built business service that interacts with the Siebel Object Manager to receive messages from and insert messages into the Siebel database. Transport Adapters. Transport adapters are also pre-built business services. They act as an interface between the Siebel system and external applications and technologies, such as middleware. For example, the EAI MQSeries Server Transport knows how to send messages to and receive messages from an IBM MQSeries queue. Workflow Process Designer. The Siebel Workflow Process Designer is a GUI-based drag-anddrop environment in which you create integration message flows. These integration message flows often combine elements described previously the EAI Siebel Adapter and transport

adaptersto create a logical flow of information between the Siebel system and the external application. Business Integration Manager. The Business Integration Manager is a multithreaded server that performs the task of executing the integration message flows that are defined using the Workflow Process Designer. Depending on your integration needs, you can choose one or more of these components to build your integration. You can combine these components in many different ways to accomplish your integration. It is important to understand them thoroughly before designing the integration to make certain you get the greatest benefit from your chosen solution. Choosing an Integration Solution : One of the main design decisions that you need to make before embarking on your integration project is whether you want to do the data transformation within Siebel or outside of Siebel. Your choice of which integration components to use depends on the decision you make. Data Transformation External to the Siebel Environment 1 If your organization is using a third-party product to manage the data mapping and data transformation between Siebel eBusiness Applications and your external systems, your objective is to efficiently move data into and out of Siebel applications in a standard format using a standard transport. Using the EAI Siebel Adapter, you can query data from Siebel applications, transform that data into an XML format using a pre-built business service, and send the XML string to your external system using IBM MQSeries, HTTP, or a file. You can also receive an XML string from IBM MQSeries, HTTP, or a file, transform it to the Siebel internal memory format, and update the Siebel applications with any new information. Your organization might want to use COM or CORBA to transport data into and out of Siebel applications. If this is the case, you can design your process to pass data, in either XML format or in the Siebel internal memory format, directly to your external system using scripts in business services. Scripting provides you with complete flexibility in defining the processes that you want to support between the Siebel applications and your external system. A Sample Business Scenario 1 Consider a sample business scenario where you want to send all changes to contact information in the Siebel database to an external mainframe system through the IBM MQSeries transport mechanism. 1. The first step in this process is to define and configure the message that needs to be exchanged. In this case, you want to exchange contact information. The first task, therefore, is to use Siebel Tools and define the integration object for the Contact message you want to exchange. Siebel Tools provides an Integration Object Builder that walks you through the process of defining your integration object. 2. Now that you have defined the message, you need to define what you want to do with this message. The contact message needs to be sent to the external system using the EAI MQSeries Server Transport. You can now use the Siebel Workflow Process Manager to model this integration message flow and to send the message. 3. An integration message flow is a sequence of business services that are connected together. You need to identify all the business services that are needed for this flow. 4. To send contact information whenever a new contact is added or updated, you need the following business services:

 EAI Siebel Adapter. This business service queries the integration object that you created in the first step. It generates the results in an internal Siebel memory format. (property set) EAI XML Converter. This business service converts the internal memory message called the Siebel Message into a Siebel XML format, ready to be sent to the transport adapter. EAI MQSeries Server Transport. This business service puts the converted XML document on the queue that you previously defined for this particular flow. Each transport adapter takes certain inputs. For the EAI MQSeries Server Transport, you specify the destination queue as part of the input. Data Transformation Inside the Siebel Environment 1 The Business Integration Manager supports the ability to perform data mapping and data transformation in the Siebel environment. You can create connectors to your external systems without using any third-party software. The Business Integration Manager includes flexible tools for defining your data mapping and transformation rules as part of your integration workflow process. When performing the data transformation within the Siebel environment, you use two types of integration objects. The internal integration object is the same as the integration objects discussed in the previous section. Internal integration objects mirror the data structure of a Siebel business object and contain a subset of business components and fields. External integration objects mirror the data structure of an external system. You define integration objects of both types in Siebel Tools. The EAI Siebel Adapter performs the same function whether the data transformation is performed inside or outside of the Siebel environment. The XML Converter and the transports also perform the same function, whether used within the Siebel environment or outside the Siebel environment. The only difference is that when used outside the Siebel environment, these business services perform operations on external integration object instances as opposed to performing operations on internal integration object instances when used within the Siebel environment. You define data mapping and data transformation rules using business services. In the prebuilt external adapters, Siebel EAI has provided many mappings and transformation rules. Business services provide a flexible scripting environment for mapping data from the Siebel data structure to an external data structure. Within a business service, Siebel provides a set of methods that allow you to perform operations on integration object instances. An example of an integration workflow process that performs data transformation in the Siebel environment follows. In this example, an order is created in Siebel, then passed to an external application. The external application returns the order status and an order number. The steps to define this process are Identify the Siebel business object that you would like to update. For that business object, identify the components and fields that you expect to update. Identify the object in the external system with which you would like to integrate. Determine the mapping between the Siebel business object and the external object. In Siebel Tools, create a new internal integration object using the Integration Object Wizard. Only select the components and fields that you would like to update. In Siebel Tools, create a new external integration object. In Siebel Tools or in the Siebel client, define the data mapping and data transformation using business services. In the Siebel client, define an integration workflow process. 8. Add any exception handling to the integration workflow process. Test the integration workflow process using the process simulator. 10. Add a mechanism for invoking the integration workflow process from the Siebel

Understanding Siebel Integration Objects 2 Siebel integration objects allow you to represent Siebel business objects, SAP IDOCs, and SAP BAPIs as common structures that the EAI infrastructure can understand. Integration objects adhering to a set of structural conventions can be traversed and transformed programmatically, using Siebel eScript objects, methods, and functions, The Structure of Siebel Integration Objects The Siebel integration object provides a structure that accommodates many types of data. Most specifically, pre-built EAI integration objects describe the structure of Siebel business objects, SAP IDOCs, and SAP BAPIs. Most integration projects will require the use of an integration object that describes Siebel business objects, either in an outbound directiona query operation against a Siebel integration objector an inbound directiona synchronize operation against a Siebel integration object. Creating Siebel Integration Objects You use the Integration Object Builder in Siebel Tools to create new Siebel integration objects. This wizard walks you through the process of selecting objects, either from the Siebel repository or from an external system, on which you can base your new Siebel integration object. The Integration Object Builder builds a list of valid components from which you can choose the components to include in your Siebel integration object. Keep in mind that the Siebel integration object represents the structurethat is, the metadata representationof an object. Caution: The Integration Object Builder provides a partial rendering of your data in the integration object format. You must review the integration object definition and complete the definition of your requirements. In particular, you should confirm that user key definitions or other identifiers are defined properly. You might need to enter user keys manually or inactivate unused keys in Siebel Tools. You should not expect to use the integration object without modification. Choose a project in which your new Integration Object will exist. The project must be locked. Choose a business service that interfaces with the source system, whether that is the Siebel application or an external application. Choose the source object. This is the object that will be the model for the new Siebel integration object. Type a unique name in the field for the new Siebel integration object. The name of an integration object must be unique among all other integration objects. Representing Multi-Value Groups 2 Multi-value groups (MVGs) are used within Siebel business components to represent database multi-valued attributes. MVGs can be one of two types: regular MVGs and MVG Associations.It is important to note that two business components are used to represent an MVG, To create a Siebel integration component to represent this construct(MVG), it is necessary also to create two integration components: The first integration component represents the parent business component. In the example, this is the Account business component. This integration component contains only the fields that are defined in the parent business component, but which are not based on MVGs. The Multi Value Link column and the Multi-Valued column contain null values for these fields. The second integration component represents the MVG business component. In the example, this is the Business Address business component. The second integration component has one integration field for each field based on the given MVG in the parent business component. An integration component user property will be set on this integration component to tell the EAI Siebel Adapter that it is based on an MVG business component. If the MVG is a regular MVG, the user property is named MVG. If the MVG is an Association MVG, then the user property is named MVGAssociation. In both cases, the value of the user property is Y.

The EAI Siebel Adapter needs to know the names of the MVG fields as they are known in the parent business componentin this example, Accountand also the names of the MVG fields as they are known in the business component that represents the MVGin our example, Business Address. To represent both names, each field is assigned an integration component field user property that contains the entry MVGFieldNameor AssocFieldName if the user property is MVGAssoc. Its value is the name of the field shown in the parent business componentin this example, Business Address. Representing Pick Lists 2 If an integration component field is created for a Siebel business field, and the business field is based on a pick list, as shown in the example in Figure 2-18, the integration component field must have a user property with the name of PICKLIST and a value of Y.The corresponding integration component field must have a user property named PICKLIST with a value of Y. Figure 2-19 shows an example in Siebel Tools of the integration component field Account Role, with a user property PICKLIST set to a value of Y. Representing Associations 2 Siebel business objects are made up of business components that are connected by a link. An association is a business component that represents the intersection table that contains these links. The integration component definition of associations is similar to that of MVGs. User properties Association and MVGAssociation on the integration component denote that the corresponding business component is an associated business component or an associated MVG, respectively. For fields that are defined on MVG associations, External Name denotes the name of the business component field as it appears on the parent business component, and the user property AssocFieldName denotes the name of the business component field as it appears on the MVG business component. Understanding User Keys 2 User keys uniquely identify Siebel business components. In the context of Siebel business objects, user keys are a group of fields whose values must uniquely identify only one Siebel business component record. Integration components within a corresponding integration object also contain user keys. User keys play a valuable role in the operation of an integration component. For example, if a Siebel business component has new values to set in the database, user keys can be used to determine whether or not to perform an insert or update. Integration component user keys are built by the Integration Object Builder based on values in the underlying table of the business component upon which the integration component is based. NOTE: Integration objects that represent Siebel business objects, and which are to be used in Insert or Update, Synchronize, or Execute operations, must have at least one integration component user key defined. In Siebel Tools, the Integration Component User Key specifies which of the integration component fields should be used for a user key. The Siebel Integration Object Builder computes the user keys by traversing several other Siebel types, including the business object, business component, table, and link types. Not all user keys, however, will meet the requirements to be used as the basis for integration object user keys. For the sake of understanding how the Integration Object Builder determines valid integration component user keys, you can simulate the process of validating the user keys. Not all user keys will necessarily be valid for a given business component. Multiple business components can map to the same underlying table; therefore, it is possible that a tables user key is not valid for a particular business component but is specific to another business component. Each User Key Column defined for a given user key mus t be exposed to the businesscomponent

you are interested in. When the Integration Object Builder creates these integration component user keys, it makes every attempt to use the appropriate table user keysthat is, the user keys that will help uniquely identify a given record. In some cases, you might find that certain integration component user keys created by the Integration Object Builder are not useful for your particular needs. In that case, you can manually inactivate the keys you do not want to use, by checking the Inactive flag on that particular user key in Siebel Tools. You can also inactivate user key fields within a given user key. NOTE: It is important to remember that user keys are groups of fields that, in combination, uniquely identify business components. By inactivating integration component user keys or user key fields, you might cause unexpected and undesirable results. User Properties : You can define user properties for your integration objects. These user properties help determine special processing and behavioral requirements of integration objects for a specific EAI adapter.

Generating the schema of an integration object is another task you might want to perform at certain points in your integration project. You perform this task in the same way for any type of integration object. The difference in integration objects will determine what you do with the output schema. Choose the EAI XML DTD Generator business service. generates an XML DTD of the integration object you selected. You can use this DTD to help you map external data directly to the integration object. The DTD serves as the definition for the XML elements you can create using an external application or XML editing tool. Overview of Business Services. A business service is an object that encapsulates and simplifies the use of some set of functionality. Business components and business objects are objects that are typically tied to specific data and tables in the Siebel data model. Business services, on the other hand, are not tied to specific objects, but rather, operate or act upon objects to achieve a particular goal. More specifically, you can create business services to perform data transformation between Siebel and external systems. You will find the data transformation business services to be of the most interest as regards Siebel EAI. For more information about writing your own data transformation business services, see Chapter 5, Transforming Integration Data. EAI business services provide methods that allow the Siebel client or Siebel eScript to work with external data or Siebel business objects and business components in the form of a property set. A business service is much like an object in an object-oriented programming language. A service has properties and methods, and maintains a state. Methods take arguments that can be passed into the object programmatically or, in the case of EAI, declaratively by way of workflows. Property Sets 3 Property sets are used internally to represent EAI data. A property set is a logical memory structure that is used to pass that data between business services. The property set consists of four parts:

The Type field-Can be used to describe what type of object is being represented. The Value field-Can be used to hold serialized data, such as a string of XML data. A table containing name-value pairs-Can be used to represent column names and data, field names and data, or other types of name-value pairs. An array of child-level property sets-Can be used to represent instances of integration objects for example, a result set might contain an Account with some set of contact records from the database. Each contact record is represented as a child property set. Property sets have methods, which are described in the Siebel Object Interfaces Reference. You can create a business service and its functionality in several ways to suit your particular needs. 1. Create at design-time in Siebel Tools using Siebel VB or Siebel eScript. NOTE: For the purpose of using Siebel EAI, you must create business service scripts in Siebel eScript. Design-time business services are compiled in the Siebel repository (*.srf). General business services are based on the class CSSService; however, for the purposes of Siebel EAI, you will base your data transformation business services on the CSSEAIDTEScriptService class. Defining Business Service Methods 3 Business services contain related methods that provide the capability to perform a particular task or set of tasks. Defining Business Service Method Arguments 3 Each method can take one or more arguments. The argument is what gets passed into the method, and consists of some data or object that the method processes to complete its task. 3 Type the name of the argument in the Name field. 4 Enter the data type in the Data Type field. 5 Check the Optional check box if you do not want to require that the argument be required for the method. 6 Choose a Type for the argument: _ Input - This type of argument serves as input to the method. _ Input/Output - This type of argument serves as both input to the method and output from the method. _ Output - This type of argument serves as output from the method. Defining and Writing Business Service Scripts 3 Business service scripts supply the actual functionality of the business service in either Siebel VB or Siebel eScript. As with any object, the script you provide is attached to the business service. You must write your data transformation scripts for integration projects in Siebel eScript. 2.Create at run time in the Siebel Client using the Business Service Administration screens. Run-time business services are stored in the application database.

Siebel EAI Adapters and Transports EAI Adapters Overview Siebel EAI adapters are business services that perform the work of managing data transport and conversion between external data sources and the Siebel integration object structure. The main adapter you will use is the EAI Siebel Adapter. This adapter interfaces between Siebel business objects and business components and an integration object instance. You can also use the Siebel XML adapters, either the EAI-specific adapters or the more generalized XML Converter and XML Gateway. Using the EAI Siebel Adapter 4 The EAI Siebel Adapter is a general-purpose integration business service that allows you to: 1. Read a Siebel business object from the Siebel data model into an integration object. 2. Write an integration object whose data originates externally into a Siebel business object. The EAI Siebel Adapter is based on the CSSEAISiebelAdapterService class. Using the EAI Siebel Adapter Methods 4 The EAI Siebel Adapter supports the following methods: _ Upsert _ Query _ Delete _ Synchronize _ Execute Siebel XML Adapters Siebel eBusiness Applications provide XML adapters to facilitate the movement of data in XML format between Siebel eBusiness Applications and external applications. There are two types of XML conversion provided by these adapters: 1. EAI XML Conversion. Conversion type applied to Siebel integration object messages. It uses the integration object definitions in the Siebel repository to provide validation and flexibility in mapping integration objects to XML. 2. Standard XML Conversion. Conversion type that can be applied to XML formats defined by external systems. These formats do not need to be registered in the Siebel repository, providing additional flexibility. However, you must use a data transformation service if you want to convert external XML representations to integration objects. Standard XML conversion is also used to serialize business service method arguments for saving to a file or sending to an external system. The following XML Adapters are currently provided by Siebel: EAI XML Converter XML Converter EAI XML Write to File EAI XML Read from File XML Gateway

You can set one of three different styles on the output integration objects from the EAI XML Converter and the EAI Read from File adapters. The different styles are: Siebel Hierarchical. Property set format that matches a Siebel business object structure. This is the default format generated by most EAI business services. XML Hierarchical. You can specify components to be represented as either XML elements or XML attributes, based on the integration object definition. XML Flat. A string of XML elements. Using the EAI XML Converter. 4 Use the EAI XML Converter when you want to convert a Siebel integration object property set for example, the output of the EAI Siebel Adapterto an XML document or when you want to convert an XML document to a Siebel integration object property set. You can specify most parameters to the EAI XML Converter as either business service method arguments or as user properties on the business service. A business service method argument always takes precedence over a user property. Using the XML Converter Use the XML Converter when you want to convert an arbitrary property set to XML or convert an XML document that is not an EAI integration object message to a property set hierarchy. Most parameters to the XML Converter can be specified either as business service method arguments or as user properties on the service. A service method argument always takes precedence over a user property. Using the EAI XML Write to File Adapter 4 Use the EAI XML Write to File Adapter when you want to create an XML document from a property set hierarchy and write the resulting document to a file. This adapter supports both standard and EAI XML conversion. Most parameters to the EAI XML Write to File Adapter can be specified either as business service method arguments or as user properties on the service. Using the EAI XML Read from File Adapter 4 Use the EAI XML Read from File Adapter when you want to create a property set hierarchy in the Siebel environment from an XML document stored as a file. This adapter supports both standard and EAI XML conversion. Most parameters to the EAI XML Read from File Adapter can be specified either as business service method arguments or as user properties on the service. A service method argument always takes precedence over a user property. Using the XML Gateway 4 The XML Gateway is a general-purpose adapter that can use any EAI transport to pass XML between Siebel applications and external applications.

Overview of Business Services. A business service is an object that encapsulates and simplifies the use of some set of functionality. Business components and business objects are objects that are typically tied to

specific data and tables in the Siebel data model. Business services, on the other hand, are not tied to specific objects, but rather, operate or act upon objects to achieve a particular goal. More specifically, you can create business services to perform data transformation between Siebel and external systems. You will find the data transformation business services to be of the most interest as regards Siebel EAI. For more information about writing your own data transformation business services, see Chapter 5, Transforming Integration Data. EAI business services provide methods that allow the Siebel client or Siebel eScript to work with external data or Siebel business objects and business components in the form of a property set. A business service is much like an object in an object-oriented programming language. A service has properties and methods, and maintains a state. Methods take arguments that can be passed into the object programmatically or, in the case of EAI, declaratively by way of workflows. Property Sets 3 Property sets are used internally to represent EAI data. A property set is a logical memory structure that is used to pass that data between business services. The property set consists of four parts: _ The Type field-Can be used to describe what type of object is being represented. _ The Value field-Can be used to hold serialized data, such as a string of XML data. _ A table containing name-value pairs-Can be used to represent column names and data, field names and data, or other types of name-value pairs. _ An array of child-level property sets-Can be used to represent instances of integration objectsfor example, a result set might contain an Account with some set of contact records from the database. Each contact record is represented as a child property set. Property sets have methods, which are described in the Siebel Object Interfaces Reference. You can create a business service and its functionality in several ways to suit your particular needs. 1. Create at design-time in Siebel Tools using Siebel VB or Siebel eScript. NOTE: For the purpose of using Siebel EAI, you must create business service scripts in Siebel eScript. Design-time business services are compiled in the Siebel repository (*.srf). General business services are based on the class CSSService; however, for the purposes of Siebel EAI, you will base your data transformation business services on the CSSEAIDTEScriptService class. Defining Business Service Methods 3 Business services contain related methods that provide the capability to perform a particular task or set of tasks.

Defining Business Service Method Arguments 3 Each method can take one or more arguments. The argument is what gets passed into the method, and consists of some data or object that the method processes to complete its task. 3 Type the name of the argument in the Name field. 4 Enter the data type in the Data Type field. 5 Check the Optional check box if you do not want to require that the argument be required for the method. 6 Choose a Type for the argument:

_ Input - This type of argument serves as input to the method. _ Input/Output - This type of argument serves as both input to the method and output from the method. _ Output - This type of argument serves as output from the method. Defining and Writing Business Service Scripts 3 Business service scripts supply the actual functionality of the business service in either Siebel VB or Siebel eScript. As with any object, the script you provide is attached to the business service. You must write your data transformation scripts for integration projects in Siebel eScript. 2.Create at run time in the Siebel Client using the Business Service Administration screens. Run-time business services are stored in the application database. Posted 12th January 2008 by J N Labels: Siebel EAI Components 0 Add a comment Loading Send feedback