A user of a Siebel application is a record in the User business component. The S_PARTY, S_CONTACT, and S_USER tables in the Siebel Database underlie the User business component. Each user is assigned a responsibility, a user ID, and, depending on the authentication architecture being used, a password.
An employee or a partner user is a user who has a position within a division, either internal or external, in the Siebel Database. Other users, such as those who use customer applications such as Siebel eSales, do not have a position or a division. The S_EMP_PER table underlies the Employee business component, to which employees and partner users belong, in addition to the tables that underlie the User business component.
For more information about the functions of responsibilities, positions, divisions, and organizations, see Access Control.
An administrator uses different views to add employees, partner users, and other users, although each of these users has a record in the User business component.
Adding a New Employee
At a minimum, an employee must have a position, a responsibility, and a Siebel user ID.
You can also associate attributes with employee records such as skills, tools, assignment rules, and availability. By doing so, you can use the employee record and its attributes with features such as Siebel Assignment Manager and Siebel Professional Services Automation.
The following procedure creates a User record for the employee only as a stage in allowing the employee to access the database.
- Log in as an administrator to a employee application, such as Siebel Call Center, and then choose View > Site Map > User Administration > Employees.
As shown below, a new record appears in the Employees list and a corresponding form appears under the More Info view tab.
- Complete the form. Use the following guidelines.
Field Guideline Last Name Required. First Name Required. User ID Required. This field must be unique for each user. Depending on your authentication architecture, the user may or may not log in with this identifier. If you implement database authentication, this field must be the login name for a database account. Password Optional (required for some authentication implementations). - This field is editable only if you implement database or security adapter authentication. For security adapter authentication, the password is propagated to the user directory. For database authentication, the password is propagated to the database. The password is propagated to the user directory. The user uses this password to log in.
- This field is not editable if you implement Web SSO authentication. For Web SSO, you maintain the user's login password independently in the external authentication system.
For information about user authentication architectures, see User Authentication Overview.
Responsibility Required. Pick one or more responsibilities which include appropriate views for the employee. If the administrator who creates this user has a value in their New Responsibility field, then that responsibility is assigned to this user by default. For information about the New Responsibility field, see New Responsibility Field. New Responsibility If the administrator who creates this user has a value in his or her New Responsibility field, then that responsibility is assigned to this field by default. For information about the New Responsibility field, see New Responsibility Field. Position Required. To be an employee, a user must have a position. If you assign multiple positions, the position you specify as Primary is the position the user assumes when he or she logs in. Division This field is populated automatically with the division to which the Primary position belongs. Territory This field is a read-only multi-value group. You are not able to enter a value manually. When you complete the Position field, the Territory field is populated automatically with territories with which the position is associated. Organization This field value is inherited from the user who creates this user, but the field is editable. Users whose positions are in this organization have access to this employee record. For information about organization access control, see About Access Control Mechanisms
Completing Employee Setup
You can set up employees either before or after you assign them a responsibility. For more information about completing employee setup, refer to the initial setup section ofApplications Administration Guide.
Also refer to Siebel Assignment Manager Administration Guide and Siebel Professional Services Automation User Guide.
Deactivating an Employee
You can deactivate an employee by dissociating the employee record from its responsibilities, altering the user ID, and removing the employee's access to the database.
- In the Employees list, select the employee you want to deactivate.
- In the More Info view tab, delete all records from the Responsibility field.
- Change the user ID slightly, to indicate that the employee is no longer current.
You may want to establish a convention for renaming user IDs when you deactivate employees. One possible convention is to append some text such as "expired" to the user ID. For example, you might change CARD to CARD-expired. That way you can continue to see the person's name associated with previous activity in history records.
If you implemented database user authentication, you should remove the user's database account. If you implemented external authentication, then delete the user from the directory from which the user's database credentials are retrieved.
NOTE: In the case of external authentication, if the external user repository is shared by many applications—as in the case of an LDAP directory or Microsoft Active Directory—do not delete the user from the directory. In such a case, make sure that the user's database access user name and password are different from that user's directory user name and password. Otherwise the user would be able to access the database directly using some database connection tools.
Adding a New Contact User
Users who are not employees or partner users do not have positions. These users include, for example, customers who use Siebel eSales or students who use Siebel eTraining. They are called customer or contact users to distinguish them from employee and partner users.
Contacts, such as contacts at a customer account, can exist in the database without having login capability. You create such contacts as Persons in the User Administration screen. The procedure in this section applies to contact users to whom you are providing a login to the Siebel Database.
CAUTION: You can modify field values for existing contact users, such as in the event of a name change. However, changing the user ID for such a user presents special issues, because this ID may be stored in various types of records, using a field such as CREATOR_LOGIN (where a foreign key to the user record is not used instead). Values for such fields are not automatically updated when the user ID is updated. If you change the user ID, you must manually update such values in other records.
- Log in as an administrator to a Siebel employee application, and then choose View > Site Map > User Administration > Users.
As shown below, a new record appears in the All Users list and a corresponding form appears under the More Info view tab.
- Complete the fields in the More Info form, and then click Save. Use the following guidelines.
Field Guideline Last Name Required. First Name Required. User ID Required. The user logs in with this ID. Password Optional (required for some authentication implementations). - For security adapter authentication, the password is propagated to the user directory. For database authentication, the password is propagated to the database. The user uses this password to log in.
- This field is not editable if you implement Web SSO authentication. For Web SSO, you maintain the user's login password independently in the external authentication system.
For information about user authentication architectures, see User Authentication Overview.
Account Pick one or more accounts to associate to the user. Specify one as the primary account. For information about the function of the account in delegated administration, see Delegated (External) Administration of Users. Responsibility Pick one or more responsibilities which include appropriate views in the customer application, such as Siebel eService, for this user. If the administrator who creates this user has a value in their New Responsibility field, then that responsibility is assigned to this user by default. For information about the New Responsibility field, see New Responsibility Field. New Responsibility If the administrator who creates this user has a value in the New Responsibility field, then that responsibility is assigned to this field by default. For information about the New Responsibility field, see New Responsibility Field. Time Zone Choose a time zone so that times for events can be expressed in terms of this zone. User Type This field serves as a filter so that different applications can query for contact users only applicable to each particular application. Auction Privilege This field applies to users of Siebel eAuction only. For information about auction privileges, seeSiebel eAuction Guide. Work Phone # The application interprets only the digits the user provides.
- The new user appears in the All Users list.
You can promote an existing contact to a contact user by assigning user credentials and a responsibility to a Person record.
To promote an existing contact to a contact user
- Log in as an administrator to a Siebel employee application, and then choose View > Site Map > User Administration > Persons.
- Select the record of the contact to promote.
- Enter the user ID, Password, Responsibility, and New Responsibility fields as described in To add a new contact user.
Q2. What are Audit Trails and How to specify them? How to determine if a business component can be audited (ANS - The underlying business component must be derived from CSSBCBase.)?
Audit Trail Features
You can configure and activate Audit Trail from an administration screen.
Audit Scope
System administrators can specify the audit scope by the following means:
- Operations (such as update, new, delete, and copy) performed on business components
- Operations performed in a specific time period
- Only those operations performed by certain responsibilities, positions, or employees
Audit Trail Content
Audit Trail records the following information in selected business components:
- Field
- Row ID of the record being changed
- Operation being performed (Update/New/Delete/Copy)
- Original value
- Changed value
- User ID performing the operation
- Date and time the operation was performed
Audit Trail Constraints
The following cannot be audited:
- The underlying business component not derived from CSSBCBase. This is because Audit Trail's functionality resides only in business components of class CSSBCBase. The procedure To determine if a business component can be audited tells you how to determine whether or not a business component can be used in Audit Trail.
- Business components based on intersection tables.
- Virtual business components, because they are not derived from business components of class CSSBCBase.
- The merge action.
- Multivalue fields.
- Calculated fields. Typically, the value for a calculated field is derived from a table-based field. To audit a calculated field, you can audit the table-based field that was used to derive the calculated field.
- Record inserts, updates, and deletes performed through Enterprise Integration Manager (EIM), Assignment Manager or workflow policy actions (because these do not go through the Siebel Object Managers).
To determine if a business component can be audited
- Launch Siebel Tools.
- In the Object Explorer, navigate to the Business Component object type.
- In the Object List Editor, select the business component.
- In the Class field, look for CSSBCBase. If the class is CSSBCBase, the business component can be used for Audit Trail.
CSSBCBase and CSSBusComp are the most basic class types. If there is a value in the Class field that is not CSSBCBase or CSSBusComp, then there is specialized functionality that has been written in C++ related to this class.
- To see if this specialized class is related to CSSBCBase, drill down on the Class hyperlink.
- In the Super Class field, look for CSSBCBase. If the class is not CSSBCBase, drill down on the Super Class hyperlink.
- NOTE: Repeat Step 6 until the Super Class field is either CSSBCBase, CSSBusComp, or blank.
Audit Trail for Siebel Remote and Siebel Replication Users
The following information applies to remote and replication users:
- Disconnected users can use Audit Trail as well as connected users. Audit Trail will stamp transactions with local machine time.
- Remote and replication users should not use file auditing mode, only database auditing mode.
- Audit trails are synchronized or replicated along with other data.
- If the transaction is rejected during the conflict resolution, the corresponding audit trail record is not discarded.
File Auditing and Database Auditing Modes
The following information applies to file auditing and database auditing modes:
- Database auditing writes transaction records directly to the database, while file auditing writes to the Siebel file system. You can later import these files into the database. (See To import audit trail items from a file into the Siebel database.) You can schedule import batch processes for these files using workflow processes. (See the ImportAll method in Table 12.)
- If you use file auditing mode, you have to import files into the database to have a comprehensive view and to be able to query for the information you need. Otherwise, you can view records only on a file-by-file basis.
- For systems in which every user is a connected user, file auditing mode yields better performance. Systems using Siebel Remote or Siebel Sync should use database auditing.
- Purging and archiving can be done at the database level.
Audit Trail Recovery in File Auditing Mode
When running in file auditing mode, instead of writing to the Siebel file system every time a new Audit Trail file is created, your Siebel application saves Audit Trail files to a file directory on the Object Manager to improve performance. When the Object Manager closes normally, these files are uploaded to the Siebel file system simultaneously.
If the Object Manager exits abnormally, Audit Trail keeps track of which files have been uploaded to the Siebel file system and which ones have not. The next time Audit Trail starts, any files that have not been uploaded are uploaded automatically.
Audit Trail Engine Business Service
The Audit Trail Engine business service is located in the Object Manager and stays active as long as the Object Manager is active. The purpose of the Audit Trail Engine business service is to capture changes (updates and deletes) to records and to store them in the designated format (database or Siebel file system, according to the audit trail mode selected). For the various data operations, if the auditing condition is met, the business component being audited triggers the Audit Trail Engine business service.
The methods listed in Table 12 are associated with the Audit Trail Engine business service. The Start, Stop, and ImportAll methods are accessible to an administrator and allow the performance of certain tasks.
Q1. How to do DB Extract and DB Initialize?
Database Extraction for a Mobile Web Client
The database extract process retrieves data visible to a specific mobile user from the server database. It retrieves data according to routing rules that define the level of access to information for each Mobile Web Client. It creates compressed files that contain data to be loaded into a local database when a Mobile Web Client initializes the database.
The database extraction process uses the new database template created by running the Generate New Database Template component. This template lets the database extraction process provide up-to-date database schemas to either new or existing mobile clients. It is strongly recommended that you distribute all database schema changes to all mobile clients, even if the changes are of types that are not visible to the mobile clients, such as changes to private dock objects. This is important because individual tables that are currently in a private dock object may become visible to mobile clients at a later time, and problems can occur if server and local database structures do not match.
The Siebel 7.5 Database Extraction component includes an enhancement when dealing with a list of mobile users to extract. It will identify visible instances for all members of a list of nodes. Then it identifies the commonly visible instances and extracts the records only once for all these nodes. Then it extracts instances outside the common set for each node. This will help reduce the time for extracting large numbers of mobile users. The parameter that enables this is Optimal Mode.
NOTE: Multiple instances of the database extract components can be run simultaneously. In order to reduce contention, each task should be assigned to use a different temporary table called S_DOCK_INITM_n, where n is 1 to 48. Siebel Remote supports up to 100 such tasks. The Siebel Schema includes 48 S_DOCK_INITM tables. You can create additional tables based on your loads and needs by using the ddlexp and ddlimp utilities.
Before running a database extract for a client, you must make sure that your organization's reporting hierarchies are updated. Use the Position Administration view from the Application Administration screen to verify that the user you are about to extract has a valid position in your organization's hierarchy. The resulting information is used by the system's routing rules, and may affect the outcome of the database extract. For more information on positions, see Applications Administration Guide.
Administrators can start several instances of dbxtract and reduce the contention by using more than one table. The parameter is TS Table Number with a default of 1.
During the cleanup of dobjinst.dbf database tables, administrators can choose truncation or deletion of the tables. The parameter is Truncate TS Table with a default of FALSE.
CAUTION: If two instances of dbxtract use the same table, do not set TruncateTSTable to TRUE—one instance can truncate the records entered from another instance.
The Save Client Transactions feature prevents the loss of local transactions a mobile user may have entered into the local database that were not included in the server db extract. This feature is valid for normal re-extract of a mobile user's local database and will not work during a major upgrade process.
The default setting for the server parameter Save Client Transactions is TRUE. If the db extract for a Mobile Web Client occurs when this parameter is set to TRUE, Siebel Remote will invoke an action before applying the new db extract. Remote will extract transactions from the current local database that are not yet synchronized with the server and store them in the mobile user's inbox as DX files.
After the current local database is replaced with the new extract, Remote applies the DX files from the mobile user's inbox to the new local database. These include the saved transactions that were not synchronized with the server. These transactions are then sent to the server during the next synchronization session.
To run a database extract for a Mobile Web Client
- From the application-level menu, choose View > Site Map > Server Administration > Enterprise Operations.
- Click the Component Requests tab.
- In the Component Request form, click New.
- In the Component/Job field, select Database Extract from the picklist.
- In the Component Request Parameters list, click New and add the necessary parameters.
NOTE: For limited-visibility objects, attaching many children to the same parent record can degrade the router performance and the database extract performance. The reason this may happen is that for each child the visibility for all other children must be checked. Whenever there are more than 10,000 child records attached to a parent (such as contacts attached to an account), the database extract performance and router performance need to be tested thoroughly. In case performance degradation is observed, it is necessary to limit the number of children per parent.
Initializing a Mobile Web Client Database
The volume of information that must be downloaded from the Siebel Remote server to initialize a Mobile Web Client's database is usually substantial. You should establish a LAN (rather than a modem or WAN) connection between the server and the Mobile Web Client for this process.
Alternatively, the local database can be initialized from a CD-ROM or other media if compressed files have been copied into the folder specified as FileSystem parameter. For more information, see Performing a Database Extract to a CD Directory.
NOTE: To initialize a Mobile Web Client database, the TableOwner parameter in the CFG file must be set to Siebel (the default).
To initialize the Mobile Web Client database using the GUI
- Establish a connection between the Siebel Remote server and the Mobile Web Client.
- In the Mobile Web Client's Siebel program group, click the Siebel Remote icon.
- Click Continue.
- Monitor the process for errors by clicking the opposing arrows in the lower right corner of the screen.
To initialize the Mobile Web Client database from the command line
- The Mobile Web Client database can also be initialized from the command line using the stand-alone synchronizer (siebsync.exe). For information on how to use the stand-alone synchronizer, see Enabling the Stand-Alone Synchronizer.
To initialize the Mobile Web Client database during login
- Another way to initialize the Mobile Web Client is to log in to the local database when starting the application. When your Siebel application cannot find a local database, it will attempt to initialize the local database following the procedures described above.
Siebel Gateway
- Provides load balancing and high-availability across the Siebel Enterprise Server.
- The Siebel Gateway is a logical entity, not a physical server consisting of a Name Server and a Connection Broker.
Siebel Enterprise Server
The Siebel Enterprise Server is a logical grouping of Siebel Servers that supports a group of users accessing a common Siebel Database Server. The Siebel Enterprise Server can be configured, managed, and monitored as a single logical group, allowing the Siebel administrator to start, stop, monitor, or set parameters for Siebel Servers within a Siebel Enterprise Server.
You can set some Siebel Server parameters at the Siebel Enterprise Server level, and these parameters will apply to every Siebel Server and component operating within that Siebel Enterprise Server; other parameters can be adjusted at the Siebel Server or component level to support fine-tuning. If a parameter is set at the server level, then the server-specific value overrides the Siebel Enterprise Server setting for the parameter on that server.
Each Siebel Server belonging to a Siebel Enterprise Server should connect to the same schema in the same database server.
The Siebel Enterprise Server itself has no processes and, therefore, cannot have a state. However, you can start and shut down operations at the Siebel Enterprise Server level, and these actions will apply to every Siebel Server within that Siebel Enterprise Server.
Siebel Server Components
The various programs that operate on the Siebel Server are implemented as components. A component represents only a specific type of program; a component is executed or operated as a task, or instantiation of a component, on a specific Siebel Server. See the following sections for details on server components.
Component Modes
Components can execute tasks in one of three run modes—background, batch, or interactive.
- Background mode components. Background mode components execute tasks to perform background operations for the Siebel Server. After a background mode component task starts, it runs until you explicitly stop the task, or until the Siebel Server itself is shut down.
You can manually start a background mode component by using the Siebel Server Manager. Components with a Default Tasks parameter set to a value greater than zero may start automatically when the Siebel Server is started. Examples of background mode components include Transaction Router, Replication Agent, and Workflow Monitor Agent.
- Batch mode components. You must manually start these components by using the component request process in the Server Manager GUI or by the Server Manager command-line interface. Batch mode components end after the task has been performed. Examples of batch mode components include Database Extract and Enterprise Integration Manager.
- Interactive mode components. Interactive mode components start tasks automatically in response to client requests. Interactive mode component tasks execute for as long as the client maintains the session, and end when the client disconnects. Examples of interactive mode components include Synchronization Manager and Application Object Managers.
Component Types
Siebel Server supports multiple component types; each type performs a specific function or job. A component type is configured with a set of parameters that determine its behavior to create an entity called a defined component (or simply component). Components are defined at the Siebel Enterprise Server level in component groups. Component groups are then assigned to one or more Siebel Servers within the Siebel Enterprise Server on which they can execute tasks.
Component Groups
Component groups are functional areas that involve logical groupings of Siebel Server components and multiple operating system processes. A component group consists of one or more components, which may be running in one or more operating system processes. Component groups act as:
- The unit of deployment on, or assignment to, a Siebel server. In general, you include in a Siebel Server the group of components that are deployed on one or more servers.
- A unit for monitoring functionality of the interrelated components within the group (you can get a summary of the operational status at the component group status, which is determined by the individual states of the constituent components.
- A unit of control, whereby you can make available or unavailable the interrelated components in a single step, such as Siebel Remote or Workflow Management.
Component Processes (Shells)
The Siebel Server runs each component in its own separate process (or shell). These shells provide the interface for a component to communicate with shared memory, and use infrastructure facilities for logging, events, networking, and so on. A shell performs the following actions when it is forked off:
- Initializes the logging/networking facility.
- Determines which component to run. The component is specified as a DLL (personality DLL), which is run by the Siebel Server either as part of the input parameters or as part of a network message.
- Attaches to shared memory.
The Siebel Server forks an appropriate shell based on the component mode (interactive, batch, or background) and whether the component is object manager-based, multithreaded, or both. Table 6, Table 7, and Table 8 define the shell types created in various scenarios.
NOTE: To conserve system resources and minimize the number of processes started on the Siebel Server, disable components and component groups that you do not plan to run. See Configuring Component Groups and Server Components for further details.
| Table 6. Interactive Mode Components | ||
| Multithreaded | Object Manager Based | Shell |
| False | False | siebsess |
| True | False | siebmtsh |
| True | True | siebmtshmw |
| Table 8. Background Mode Components | ||
| Object Manager Based | Shell (Created at Bootstrap) | Shell (Created at Runtime) |
| False | siebproc | siebsh |
| True | siebprocmw | siebshmw |
Examples of Siebel Server shells:
- A background component that is not object manager based is brought up in a siebproc shell. For example, Transaction Processor (TxnProc).
- An interactive component that is multithreaded and not object manager based is brought up in a siebmtsh shell. For example, Server Request Broker (SRBroker).
- A multithreaded, object manager-based component is brought up in a siebmtshmw shell. For example, Call Center Object Manager (SCCObjMgr).
Parameters Controlling Number of Shells
The following parameters configure shell (process) start up for interactive, batch, and background mode components.
Siebel Remote Server Components
This section discusses the Siebel Remote server components that operate on the Siebel Server and provides an overview of the administration tasks you need to perform for each component.
- Creating Siebel Server Directories for Mobile Web Clients
- Generate New Database
- Database Extract
- Synchronization Manager
- Transaction Processor
- Transaction Router
- Transaction Merger
Creating Siebel Server Directories for Mobile Web Clients
Each registered Mobile Web Client requires a separate directory on the Siebel Remote server. The Database Extract program creates the appropriate directory and its subdirectories for each Mobile Web Client.
NOTE: The installation program also places a directory called txnproc in the docking subdirectory within the Siebel server root directory. Do not modify the contents of this directory under any circumstances.
The following example shows a portion of the server directory tree after you run Database Extract for Mobile Web Clients named Adams and Scott:
Generate New Database
The Generate New Database component creates the local database template for a given database schema version. The component reads the database schema definition from the Siebel repository, then creates Siebel tables and indexes in a database template file stored on the Siebel Remote server in the dbtempl subdirectory.
The Local Database Initialization program uses the local database template when initializing a new database on the Mobile Web Client.
Administration of the Generate New Database Component
You must generate a new database template whenever the Siebel database schema changes in cases such as:
- Immediately upon installing the Siebel database server
- Following an upgrade to a new version of Siebel applications
- Extending the database schema using Siebel Tools—except when using Siebel Anywhere to deliver a database schema upgrade kit
If your deployment requires a different collation template not provided by Siebel eBusiness Applications, please contact Siebel Expert Services for assistance in creating a new collation template.
Optimal Size for Local Databases
The recommended size for the SQL Anywhere local database depends upon several factors. These include the Mobile Web Client user's position and responsibilities. Also, the Data Routing Model assigned to the client impacts the volume of data to be stored in the local database. The local database should not be larger than 700 MB. For further information on this subject, or if a local database will exceed this number, contact Siebel Systems.
Synchronization Manager
The Siebel Remote server starts a Synchronization Manager task for each incoming synchronization request from a Mobile Web Client. For each request, the Synchronization Manager:
- Verifies the Mobile Web Client status and password (if Siebel Remote authentication is enabled)
- Transfers the local database template and local database extract if applicable
- Exchanges transaction files
- Transfers file attachments to and from the Siebel File Server
Each Synchronization Manager task services only one Mobile Web Client at any one time, but many synchronization tasks can be started concurrently. This behavior is configured by a Synchronization Manager parameter called Max Task. The Synchronization Manager component must be enabled for Siebel Remote mobile users to be able to connect to the Siebel Remote server for synchronization. Synchronization Manager tasks start automatically; you do not need to start tasks for this component manually.
Starting Siebel Remote Server Components
Use Siebel Server Manager to set values for start-up parameters for the following Siebel Remote server components:
The default parameter values for each component are described in the following sections.
The following procedures describe how to configure these server components.
To start Transaction Processor - srvrmgr command line
start task for comp txnproc with
Values are from Start-Up Parameters for
NOTE: When logging into srvrmgr command line, indicate the server name. Otherwise srvrmgr will default to the Enterprise Server. For details regarding the Server Manager command-line interface, see Siebel Server Administration Guide.
To start Transaction Processor - GUI
- In Siebel 7, the Transaction Processor cannot be started manually through the GUI Server Manager unless the Siebel Server is up and running. The component has been defined to start one task when the Siebel Server is started if the component is enabled. If the component is not started, navigate to Site Map > Server Administration > Servers > Server Components tab, and start the component. A new task should be started.
To start Transaction Router - srvrmgr command line
- From the srvrmgr command line, enter:
start task for comp txnroute with
Values are from Start-Up Parameters for the
To start Transaction Router - GUI
- In Siebel 7, the Transaction Processor cannot be started manually through the GUI Server Manager unless the Siebel Server is up and running. The component has been defined to start at least one task when the Siebel Server is started if the component is enabled. If the component is not started, navigate to Site Map > Server Administration > Servers > Server Components tab, and start the component. A new task should be started.
To start Transaction Merger - srvrmgr command line
- From the srvrmgr command line, enter:
Values are from Start-Up Parameters for
To configure Transaction Merger - GUI
- In Siebel 7, the Transaction Processor cannot be started manually through the GUI Server Manager unless the Siebel Server is up and running. The component has been defined to start at least one task when the Siebel Server is started if the component is enabled. If the component is not started, navigate to Site Map > Server Administration > Servers > Server Components tab, and start the component. A new task should be started.
To configure Synchronization Manager - srvrmgr command line
- Synchronization Manager is started automatically by the Siebel Server using the default configuration. It does not need an explicit configuration. For information on using Siebel Server Manager to manage and administer server components, see Siebel Server Administration Guide.
Starting and Stopping Siebel Remote Server Components
Use the Siebel Server Manager to start and stop any Siebel Remote server components.
To enable the Remote component group
- In the command-line interface, change to the Siebel Server bin subdirectory.
- Enter the following command to invoke the Line Mode Server Manager:
This will enable all Siebel Remote components: Synchronization Manager, Transaction Processor, Transaction Router, Transaction Merger, Replication Agent, Database Extract, Parallel Database Extract, and Generate New Database.
- From the GUI, synchronize the components by navigating to View > Site Map > Server Administration > Enterprise Configuration > Batch Component Admin.
- Click Synchronize.
To disable the Remote component group
To enable Remote component group for a specific server
This will enable Remote only on certain Application servers in the enterprise, rather than on all of them.
To disable individual components of the Remote component group
No comments:
Post a Comment