As indicated above, ADM supports three different data types—administrative data, repository data, and files—each of which is associated with separate exporting mechanisms.In this section, we will discuss both the manual and the automated export mechanisms for all data types.We will start with creating the ADM package, a directory structure, which must be populated with data objects.
Creating the ADM package
The ADM package is a folder structure that is created and managed by the ADM Packager command line utility (admpkgr).We must use this utility to:
Next, we will discuss the procedure to create an empty package structure. Sealing and verifying the package is discussed after the exporting procedures.
Creating the empty package structure
As the ideal location for the ADM package is the admpackages folder in the Siebel Management Server's installation directory, the following tasks are typically executed on the machine that hosts the Siebel Management Server. However, the package can also be generated on a different machine and copied to the Siebel Management Server at a later time.
To create an empty ADM package structure, we open a command shell and navigate to the root installation folder of the Siebel Management Server.This is where the admpkgr command line utility is situated.We use a command similar to the following to create a new empty package structure:
admpkgr init C:SIA81mgmtsrvradmpackagesEVAL_PACKAGE
The init command is followed by the full path to the root folder of the new package. As a result of the above example command, a new folder named EVAL_PACKAGE is generated in the admpackages folder of the Siebel Management Server installation directory. The following screenshot shows the folder structure generated by the ADM Packager:
Each package contains three main folders—database, file, and repository.The file folder has subfolders that represent a part of the folder structure of the target Siebel servers.In order to generate additional language-specific folders such as "deu" for German or "fra" for French, we can edit the admpkgr.bat file using a text editor of our choice.In the file, we locate and modify the line SET LANG_DIR="ENU".The LANG_DIR variable can hold a comma-separated list of three letter codes for the supported Siebel languages
Examples for language-specific data are the localization files (.xlf) for BI Publisher reports.
It is possible to remove unused folders and create new subfolders in the file folder during the export and packaging process.On your demonstration machine, use the ADM Packager as described to create an empty package.
Exporting administrative data using the Application Deployment Manager screen
Administrative data such as List of Values (LOV) or responsibilities can be exported from the graphical user interface provided by views in the Application Deployment Manager screen in the Siebel Web Client.
The following procedure describes how to create an ADM deployment project and use it in an ADM export session.Deployment projects are defined once as a list of data objects and the associated filters.They can be reused for multiple export sessions.he example refers to preconfigured List of Values (LOV) data for the Todo Type field in Siebel Activities. The process is similar for each supported ADM data type:
Alternatively, we can click the select button in the Deployment Filter field and choose one of the existing predefined queries for the respective object However, because of the fact that predefined queries reference business component fields and ADM operates on integration object components,field name differences can lead to invalid filters when working with predefined queries. Developers can assist in the task of finding the correct field names for the filter specification.
For example, to write the files to the database folder of the EVAL_PACKAGE package—using the network share created on the admpackages folder—we could specify a path similar to the following:osappeval1ADM_PACKAGESEVAL_PACKAGEdatabase
In the above example, osappeval1 is the name of the server where the Siebel Management Server resides and ADM_PACKAGES is the name of the network share created on the admpackages directory.
The file with the .ini suffix must be deleted.It does not contain any data for the ADM deployment.The pair of XML files—the data file and an accompanying descriptor file—must be kept as is and must not be modified or renamed.This process of exporting administrative data using the graphical user interface can be repeated for other data types as often as needed until the set of data to deploy into the target enterprises is complete.
All database export files must be either written directly to the database folder of the ADM package or copied there at a later point in time.The latter is a common scenario when project teams use version control tools to keep all modified and new objects until deployment time.
Exporting administrative data using the ADM Batch Processor server component
As we have learned above, the export of administrative data is a manual and therefore time consuming and error prone task.To automate the export, we can use the ADM Batch Processor server component.
The ADM Batch Processor is a batch component and is part of the ADM component group. It can be invoked via the Siebel Server Manager (srvrmgr) command line or using the Jobs view in the Administration - Server Management screen in the Siebel Web Client.Next, we will describe how to invoke the ADM Batch Processor using the Siebel Server Manager command line.
Because of the number of parameters to set, it is beneficial to use an input file that contains the start task command.The following is an example of a command that invokes the ADM Batch Processor and directs it to export List of Values (LOV) data:
The command must be in a single line.The example above has been broken into separate lines for better readability.
When using the ADM Batch Processor, the following parameters must be set:
The ADM Batch Processor writes two files to the specified directory, one file that carries the data and the accompanying descriptor file.For naming the files, the server component uses the value of the admprefix parameter and the identifier number of the Siebel server task.If we use the ADM Batch Processor server component as in the example above, no deployment project needs to be created in the Application Deployment Manager screen.However, if we wish to use the definitions of a deployment project, we can do so by using the admproject parameter and the name of an enabled deployment project as its value.If we use the admproject parameter, the only other mandatory parameter is admpath.
Exporting repository data using Siebel Tools
In addition to migrating administrative data, Siebel Application Deployment Manager is capable of exporting and migrating repository object definitions from one Siebel enterprise (typically, the development environment) to one or more target enterprises (typically, test or production environments).
As Siebel Tools is the application used by developers to create or modify repository objects, it provides the necessary ADM functionality to export these objects. In the following, we will discuss the techniques to export repository objects using the graphical user interface of Siebel Tools.
ADM supports two scenarios for migrating repository changes:
In a Hot-Fix scenario, a small number of object definitions are typically hand-picked and then exported and migrated to the target enterprise. It is quite common that for example an error has been discovered in a business service method's script, which must be quickly fixed and issued to the production environment in a small timeframe.
A Mid-Level Release is considered as a certain time slice in a project, which involves the creation or modification of several dozens of repository objects.A Mid-Level Release represents all changes made to the repository since a certain point in time.Changes to the database schema, such as the creation of new tables or the addition of columns to existing tables are considered part of a major release and should not be migrated using ADM.The utilities that should be used for these purposes will be discussed in the final section of this chapter.
Exporting repository object definitions for Hot-Fixes
The following procedure describes how to export repository object definitions for a Hot-Fix:
A new subdirectory with the Hot-Fix label as its name will be generated in the ADM directory of the Siebel Tools installation folder.It will contain a Siebel Tools Archive file (.sif), an accompanying XML descriptor file, and a log file. All files except the log file must be copied to the repository folder in the ADM package directory to complete the export process.The screenshot below shows the Generate Hot-Fix dialog in Siebel Tools:
The Hot-Fix has a label of EVAL—the name of the new subdirectory and currently contains a single object definition of type Business Service.
Exporting repository object definitions for mid-level releases
The following procedure describes how we can use Siebel Tools to create a Mid-Level Release.We will specify a start timestamp and then retrieve all object definitions created or modified since then.
The screenshot below shows the Generate Mid-Level Release dialog in Siebel Tools:
Similar to Hot-Fixes, a new directory with the Mid-Level Release label as its name is generated in the ADM folder of the Siebel Tools installation directory. Depending on the export options, we find either a single or multiple Siebel Tools Archive files (.sif).When we choose to export to one .sif file per object,the utility generates subdirectories for each object type to avoid name conflicts. As usual, they are accompanied by XML descriptor files and .log files.Copying the .sif and accompanying XML descriptor files to the repository folder of the ADM package directory completes the export of a Mid-Level Release.
Exporting repository data using the consoleapp utility
The two procedures described above—exporting repository object definitions for Hot Fixes and Mid-Level Releases—must be carried out manually in the Siebel Tools user interface.Similar to exporting administrative data automatically using a script, we can leverage a utility named consoleapp to automate the export of repository data to the ADM package.
The consoleapp—"console application"—utility is a generic interface that allows administrators to invoke business service methods from the command line. The Siebel repository contains a pre-built business service named Siebel Tools Export Support for ADM, which supports the automated export of repository data to an ADM package directory.
Source: Siebel Application Deployment Manager Guide, Version 8.1
Before we launch the consoleapp command line utility, we must verify that the DataSource parameter in the Siebel Tools configuration file (tools.cfg) points to the data source that contains the repository object definitions we wish to export.We can issue a command similar to the following from the Windows command shell to export one or more object definitions:
The above example script has been broken into separate lines for better readability. The syntax of a consoleapp.exe invocation is as follows:consoleapp <application configuration file path> <language code> <username> <password> <Business Service name> <Method
name:Param_1=Value_ 1,Param_2=Value_2, …,Param_ N=Value_ N>
In the example above, the application configuration file path points to the Siebel Tools configuration file (tools.cfg). We are using ENU (English - United States) as the language code and SADMIN as the username to log in to the console application.
The business service to be invoked is Siebel Tools Export Support for ADM. The method of the business service is named Export. The following parameters can be passed to the Export method:
As a result of the above command,which should be part of a command shell script, the export file (.sif) and accompanying descriptor XML file are written directly to the repository folder of the ADM package directory.The main benefit of using the consoleapp utility is that we have full control over the file names and the output folder.In addition, the command line invocation technique allows us to create any type of shell script or small application to wrap the consoleapp call and parameter settings.
Copying files to the ADM package
As indicated earlier in this chapter, Siebel Application Deployment Manager supports the migration of files from one source enterprise to multiple target enterprises.We must copy files such as Siebel web templates (.swt) to the appropriate subdirectory in the fileAppServer folder of the ADM package structure.There is no specialized utility provided by Oracle to copy the files. We must rely on the copy functionality of the operating system or other file transport automation tools such as robocopy or ftp.
The following table provides an overview of the various supported file types and the destination folder in the ADM package directory:
About deploying Siebel Repository Files
There are several considerations about deploying the Siebel Repository File (.srf) using ADM.
Most projects therefore abstain from using ADM to deploy Siebel Repository Files. Administrators can follow the procedure below to deploy a new .srf file. The procedure is applicable when there are two or more Siebel Servers in the enterprise and a load balancing mechanism is in place.It provides a safe path with minimal impact on running sessions.
Sealing the ADM package
Once the package is populated with all administrative data,repository data, and files that are part of the release, we must use the admpkgr command line utility again to generate an XML descriptor file that contains information about the package content.It is recommended to delete all empty directories from the package structure in order to avoid warnings being displayed during the remaining steps.
A command similar to the following, issued from the Siebel Management Server's root directory, will generate the descriptor file:
admpkgr generate C:SIA81mgmtsrvradmpackagesEVAL_PACKAGE
The above command will generate a package descriptor file and an accompanying XML schema definition (.xsd) file in the package root directory.Once the descriptor file is generated, the package content must not be changed. If changes are made to the package content, we must delete the descriptor file and the schema file and repeat the above command to generate a new package descriptor.
Validating the ADM package
In order to verify that the content of an ADM package matches the package descriptor file, we can use the validate command of the admpkgr command line utility as shown in the following example:
admpkgr validate C:SIA81mgmtsrvradmpackagesEVAL_PACKAGE
The above command validates the content of the EVAL_PACKAGE directory against the descriptor file.We should see a message indicating that the package directory was successfully validated. If this is not the case, the package content has been modified and the ADM package is not valid.On your demonstration machine, you can use the Developer Web Client and Siebel Tools to create and validate an evaluation package.In the adm packages directory of the Siebel Management Server installation folder, you will also find a sample package that you can inspect (and deploy).
Siebel - CRM Related Interview Questions
|Siebel - CRM Interview Questions||Siebel System Admin Interview Questions|
|Salesforce Admin Interview Questions||Salesforce Developer Interview Questions|
|Siebel EAI Interview Questions||Advanced jQuery Interview Questions|
|Cap Gemini Siebel CRM Interview Questions||Siebel EIM Interview Questions|
|AppleScript Interview Questions||Salesforce Crm Interview Questions|
|Windows Workflow Foundation Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.