Exporting and Packaging Configuration Changes - Siebel - CRM

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:

  • Create the empty package structure
  • Seal the package content with a descriptor file
  • Validate the package content against the descriptor file

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:

Figure:-

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:

  1. Log in to the Siebel Web Client using an administrative account.
  2. Navigate to the Application Deployment Manager screen, Deployment Projects view.
  3. Create a new (or copy an existing) deployment project.
  4. Enter a name for the new deployment project.
  5. Ensure that the Export to File and Session Configurable flags are checked.
  6. In the lower list applet, click New and select LOV from the Data Type Name dropdown list.
  7. Choose Upsert as the deployment method.
  8. In the Deployment Filter field, enter [Value]='TODO_TYPE'. This filter ensures that only records for the List of Values type "TODO_TYPE" are exported.
  9. 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.

  10. Click the Validate Filter button in the upper list applet.If no message is displayed, the filter is valid. If an error message appears, correct the syntax of the deployment filter and validate again until no error is displayed.
  11. Click the Enable button in the upper list applet.Once a deployment project is enabled, it can no longer be modified. We would have to copy the deployment project record and modify and enable the copied record.
  12. Navigate to the Deployment Sessions view.
  13. Click the New button and select the deployment project created before from the dropdown list in the Project Name field.
  14. Press CTRL+S to save the record. This populates the lower list applet with the data objects.
  15. Click the Deploy button in the upper list applet.
  16. In the Export dialog box, enter either a valid UNC path or an absolute path to an existing folder where the export files should be written to.
  17. 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.

  18. . Click the Export button to start the data export.
  19. Verify that the Status field displays a value of Export Completed, which indicates successful export of the data.
  20. Navigate to the export folder and verify the existence of three new files.The ADM export process uses the Session ID as a prefix for the files and the data type names—for example LOV—to distinguish the files.The following screenshot shows a completed ADM deployment session and the resulting files in the database folder of the ADM package directory:

Figure:-

completed ADM deployment session and the resulting files in the database folder

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:

  • admpath: a valid UNC or absolute path where the files should be written to. It is recommended to provide the path to the database folder of the ADM package directory.
  • admdatatype: the name of the ADM data type
  • admfilter: the search specification to filter the data
  • admeaimethod: the EAI method to use when data is imported in the target enterprise; upsert (update or insert operations are carried out automatically), or synchronize (update, insert, or delete operations are carried out automatically)
  • admprefix: the prefix to be used for the output file names

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:

  • Hot-Fix
  • Mid-Level Release

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:

  1. Log in to Siebel Tools,connecting to the database that contains the object definitions to export.
  2. Navigate to the object definition. For example, click Business Service in the Object Explorer pane and then query for the Siebel Account business service in the list.
  3. Right-click the object definition and select Add to Hot-Fix…
  4. In the Generate Hot-Fix dialog, specify a label for the Hot-Fix.
  5. If you wish to add more object definitions to the Hot-Fix, use the Object Explorer and the list view to select them and repeat the above steps.
  6. Once all object definitions are added to the list in the Generate Hot-Fix dialog, click the Export button.

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:

Figure:-

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.

  1. Log in to Siebel Tools, connecting to the database that contains the object definitions to export.
  2. From the View menu, select Options.
  3. In the General tab, set the Changed Date to the date and time which defines the begin of the Mid-Level Release.
  4. Click OK.
  5. From the Tools menu, select Generate Mid-Level Release…
  6. In the Generate Mid-Level Release dialog, specify a label for the Mid-Level Release.
  7. Click the Generate List button.
  8. Verify that the list is populated with object definitions that have been created or modified after the start date.
  9. Optionally, remove object definitions from the list by selecting them and pressing the Delete key.
  10. Choose an export option. It is recommended to choose "One SIF per object" when the list of object definitions is long to avoid the generation of a single large file.
  11. Click the Export button.
  12. Click OK to confirm the success message.

The screenshot below shows the Generate Mid-Level Release dialog in Siebel Tools:

Figure:-

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:

Table:-

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:

Table:-

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.

  • ADM cannot be used to deploy a .srf file that already exists on the target server. This is because the file is locked when the Siebel server processes are running.
  • ADM is not capable to shut down and restart the Siebel Server components or the entire Siebel Server. This step must be done manually.
  • If the ADM package does not contain repository objects or if these objects are of type "Workflow Process" or "Task", it is not necessary to deploy the .srf file.

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.

  1. Bring all non-system server components such as application object managers to a paused status.This ensures that no new tasks are started for the server components on this Siebel server.
  2. Monitor the active sessions on all non-system server components on the Siebel server and wait until the active session count is zero.
  3. Shut down the Siebel server service.
  4. Copy the new .srf file to the correct language-specific subdirectory in the Siebel Server's object folder.
  5. Start the Siebel server service.
  6. Verify that the Siebel Server starts up without errors.

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).


All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Siebel - CRM Topics