21Releasing Products and Other Versioned Objects
Releasing Products and Other Versioned Objects
This chapter discusses how to release new versions of products. For users who use separate development and production environments, it also covers how to migrate products between these two environments. This chapter includes the following topics:
About Versions of C/OM Objects
The information in this chapter applies to how versioning works for the following customer order management objects:
Customizable Products. For general information about customizable products, see Products with Attributes and Designing Products with Components.
Product Classes. For general information about product classes, see Products with Attributes.
Attribute Definitions. For general information about attribute definitions, see Products with Attributes.
Variable Maps. For general information about variable maps, see Siebel Order Management Infrastructure Guide.
Signals. For general information about signals, see Siebel Order Management Infrastructure Guide.
This chapter discusses how to work with versions of products with components, but the instructions also apply to the other objects, using the appropriate view.
This type of versioning allows you to create and administer multiple development and production versions of an item can be created and administered independently. It allows you to develop, test, and deploy items either in your production environment or in a separate development environment. It support a four-stage process for introducing new items: development, testing, approval, and production.
About Avoiding Duplicate Versioned Objects During Product Data Migration
Starting in Siebel 7.8, the import function for product data uses the object identifier to determine whether records being imported already exist in the target database. In earlier versions, the import function used a name-based identifier.
The object identifier refers to the value in the OBJECT_NUM column of the versioned object table, S_VOD, for the corresponding versioned object. Object identifiers are initially set as the value of the row ID. They are always persistent and are referenced in other tables, including S_PROD_INT. For this reason, it is now absolutely mandatory to preserve the object identifiers of versioned objects across multiple environments in order to consistently export and import these object definitions across different environments. This behavior affects all versioned objects: Products, Classes, Attributes, Signals, and Variable Maps.
Guidelines to Avoid Duplicate Versioned Object Records
Follow these guidelines to avoid creating duplicate versioned object records:
Use a single master database for product administration. This database ensures that object identifiers of objects can be preserved and easily migrated to different environments.
All other databases must have the same object identifier for products, attribute and class records as the master database. As needed, data from the master product administration database must be replicated to other environments, ensuring that the object identifiers are preserved across the databases.
Never manually create objects with the same name in two databases. They are different objects and do not merge into one record, using the import function or Application Deployment Manager (ADM). If the object identifier is different for the same object in the two databases, the versioned object is treated as a different object during the import even if the names match, hence the two objects are not merged. Instead, an existing object definition can be moved from one database to another using import or ADM, so that the object identifier is preserved.
The product, attribute, and class master must initially be a copy of the upgraded production database.
How Duplicate Objects Are Created
When you migrate customizable product (CP) data using product export and import or Application Deployment Manager (ADM) and the joint workspace data type, you can create duplicate records in the destination environment database when the CPs in the two environments have the same name but have different object identifiers. The S_PROD_INT.CFG_MODEL_ID column stores the versioned object identifier.
For example, assume that the source environment includes the product records shown in the following and the target environment includes the product records shown in the second table in this topic.
Table Example of Data in Source Environment
| Product Name | Row ID | CFG_MODEL_ID |
|---|---|---|
Product A |
1-A |
1-A |
Product B |
1-B |
1-B |
Table Example of Data in Target Environment
| Product Name | Row ID | CFG_MODEL_ID |
|---|---|---|
Product A |
1-A |
1-A |
Product B |
1-C |
1-C |
After the data migration, the target application includes the records shown in the following table.
Table Example of Data in Target Environment After Migration
| Product Name | Row ID | CFG_MODEL_ID |
|---|---|---|
Product A |
1-A |
1-A |
Product B |
1-C |
1-C |
Product B (1-B) |
1-B |
1-B |
Product A is imported correctly to the target environment, because it has the same identification number in both environments.
Product B has different identification numbers in the two environments. Therefore, when it is imported, a duplicate product with the name Product B (1-B) is created. Product B (1-B) contains the latest changes of the product that were made in the source environment, while the original Product B in the target environment is unchanged.
Possible Symptoms of Duplicate Records
The following symptoms probably mean you have duplicate records:
The original versioned object definitions are not updated.
New object definitions with the imported object identifier are created and have a long name made up of the product name and row ID.
The quote and order transaction data refer to outdated product definition.
If you customize these products in a quote or order record, the quote uses the outdated definitions instead of the updated product definitions that you imported.
Duplicate product, attribute and class records are in the target environment.
Name-Based Import
If you have failed to create a master product database and you already have multiple databases with different object identifiers for the same objects, object identifier-based import fails. In this case, you can use name-based import. Name-based import is not recommended. Use it only as a last resort.
Name-based import is done using the ISS Authoring Import Export business service. For more information, see Siebel Order Management Guide.
Creating Time Slice Reports for Product Versions
You can produce time slice report for a customizable product versions. This report lists dependent objects that expire prior to the end date of the version.
If dependent objects expire, the product version may not work as intended. After viewing the time slice report, if necessary, you can change the end dates of existing versions of the dependent objects or create new versions of the dependent objects with later end dates.
The time slice report produced in Customizable Products, then Versions view only takes account of objects that have already been released. To produce the report for objects that have not been released, you must use Workspace Projects view and select the Use Project checkbox for the objects.
The time slice application preference determines the output format of time slice reports (XML or CSV). For information about setting application preferences, see Siebel Applications Administration Guide.
To create a time slice report for objects that have been released
Navigate to the Administration - Product screen, then the Product Definitions view.
In the Products list, select the desired customizable product.
In the Versions list, select the version you want to run the report on.
From the Versions list menu, select Create Time Slice Report.
To create a time slice report for objects that have not been released
Navigate to the Administration - Product screen, then the Workspace Projects view.
In the Workspace Projects list, add a new record and complete the necessary fields.
The Use Project checkbox must be selected.
In the Contents view, add all the objects that you want to run the report on.
From the Workspace Projects list menu, select Create Time Slice Report.
Releasing Products for Use
To make a customizable product available to users, you must release it. Releasing a customizable product creates a new version of it and makes this version available for use, if versioned data was changed.
If no versioned data was changed, a new version of the product is not created when you release the product. However, if the release date falls between the existing versions, a new version record is created even if no versioned data was changed.
You cannot modify or delete a released version of a customizable product. After you release a version, the workspace retains the image of that version, so it can be used as a starting point for the next version.
Before you release a customizable product, whether it is available to users depends on these fields:
Start Date. When you release a product, it becomes available to users on the start date, and it remains available until the next start date of a version of the product. Start date is precise to the minute and second. For example, if you release a product with the start date of January 1, 2006 12:00:00 and another released version of the same product has the start date of July 1, 2006 12:00:00, then the newly released version will be available to customers from January 1 12:00:00 through June 30, 2006 12:00:00. This lets you release several versions of a product and have them become available based on dates.
End Date. The end date for a version is entered automatically, based on the start date for the version that is next chronologically. This local date and time are converted to Greenwich Mean Time, so the version is available at the same times for all servers connected to this database.
Active. When you release a product, it is only available to users if the Active checkbox of the current version is selected.
When remote users synchronize databases, they receive all released versions of a customizable product not already on the local computer.
Observe the following guidelines when using start dates for products with components:
Carefully coordinate configuration rules that have effective dates with the start date of the customizable product. If you know that you must release a new version of the product because of time-sensitive configuration rules, consider using a version start date rather than effective dates on configuration rules.
If you want to release two versions such that the second version supersedes the first version on its start date, be sure to fully analyze the possible business impacts of the new version on in-process, and existing quotes.
The start date cannot be modified after a version is released. Instead, you can release a new version to replace or intercede an existing version.
To release a customizable product
Navigate to the Administration - Product screen, then the Product Definitions view.
In the Products list, select and lock the desired customizable product.
In the Versions list, enter a date in the Start Date field of the Work Space record.
Click Release to release a new version of the product.
A new record appears in the Versions list. Its version number displays in the Version field. The Required State Date field becomes read-only.
Deleting Product Versions
If you no longer want to use a version, you can release a new version to replace the version you do not want to use, as described in Replacing Earlier Product Versions.
If you have a large number of inactive versions for a given product, you can delete the versions using the CleanupSingleObject method of the ISS Authoring Import Export Service. For more information, see Siebel Order Management Guide.
Replacing Earlier Product Versions
Product versions are visible to customers on the dates between the values in the start date and the end date. You enter a value in the Start Date field when you create the version. The value in the End Date field is entered automatically, based on the start date of other versions that come after the start date of this version.
If you create a new version with the same start date as an existing version, the existing version will have a end date that is the same as its start date, so it will never be visible to customers. The version is never visible to customers, because there is no time between its start date and its end date.
To replace an earlier version of a customizable product
Navigate to the Administration - Product screen, then the Product Definitions view.
In the Products list, select and lock the desired customizable product.
Enter a date in the Start Date field of the Work Space record in the Versions list that is identical to the Start Date of the version you want to replace.
You can copy the start date from the version you want to replace and paste it in to the Work Space record.
Click Release to release the Work Space record as a new version of the product.
Displaying Product Versions that Are Available to Customers
When you replace earlier versions of a product, you create version records that are never visible to customers because their start date and end date are the same.
In the Versions list, you can use the Time Filter button to filter out versions that have been replaced and view only versions that will be visible to customers.
This button is a toggle. After you have used it to hide versions that have been replaced, click it again to display all versions.
To display only product versions that are visible to customers
Navigate to the Administration - Product screen, then the Product Definitions view.
In the Products list, select the desired customizable product.
In the Versions list, click Time Filters.
Versions whose Start Date and End Date are identical disappear, so only versions that will be visible to customers appear.
In the Versions list, click Time Filters again.
All versions appear.
Reverting to Earlier Versions of Products
If you release a customizable product and then make changes to its current work space, you can discard all the changes and revert to a version of the product that you released earlier.
When you revert, the entire contents of the current work space is discarded. This includes the product's structure, attributes user interface, rules, links, resources, and scripts. You choose an earlier version, and an instance of it is then loaded into the current work space.
To revert to an earlier version
Navigate to the Administration - Product screen, then the Product Definitions view.
In the Products list, select the desired customizable product.
In the Versions list, select the version you want to revert to.
In the Versions list, click Revert To Selected Version.
Save the current work space.
Releasing Multiple Products Using Workspace Projects
The instructions in earlier topics of this chapter describe how to release versioned items one at a time. You can also release a number of versioned items at the same time by using the Workspace Projects view.
If you are modifying and releasing products one at a time, use the methods described in the earlier topics of this chapter.
If you are modifying many products and other versioned items as part of one project and you want to release them all at one time, use the method described in this topic.
To release multiple products simultaneously
Navigate to the Administration - Product screen, Workspace Projects, and then the Contents view.
In the Contents list, select all the items you want to release.
Click Release New Version.
To release all locked products
Navigate to the Administration - Product screen, Workspace Projects, and then the Contents view.
Make sure all objects in the Contents view are locked.
In the Contents view, click Release All.
Managing Products Using Workspace Projects
You can also use the Workspace Projects view to manage objects and create relations among them, without having to release them.
To manage objects using Workspace Projects view, perform the tasks in the following high-level process:
Create any new objects you need in the appropriate views for each object.
For example, create products in the Administration - Products, then the Products view, product classes in the Administration - Products, then the Product Classes view, and so on.
Navigate to the Administration - Products, then the Workspace Projects view and add a new record to the Workspace Projects list.
In the Administration - Products, Workspace Projects, and then the Contents view, create new records and add all these objects to this Workspace Project.
In the Workspace Project record, select the Use Project check box.
Selecting this check box activates the Workspace Project and makes the workspaces of these objects visible to each other for the duration of the session, even though the objects have not been released.
Drill down on the item in the Contents list, and associate the objects to each other, as needed.
After drilling down on them, the objects appear in the usual views you use to work with them, and you can associate them in the usual ways.
Test the objects using Scenario Tester, as described in Process of Testing Products with Scenario Tester.
Note: For objects explicitly listed in the active Workspace Project, workspace are used. For all other objects, the released versions active on the test date are used as needed.Release the objects together using Workspace Projects, or release the objects individually, as needed.
Migrating Products Among Environments
Some businesses develop new versions of products in the same environment that they use for product that are already in production. Other businesses use separate environments for development and for production.
If you use separate environments for development and production, you can migrate product data from the development to the production environment in either one of two ways:
Migrating Products Using Import and Export in Workspace Projects View. This method allows you to move versioned data and related objects.
Migrating Products Using Application Deployment Manager (ADM). This method allows you to move both versioned and unversioned data.
Migrating Products Using Import and Export in Workspace Projects View
Using import and export in Workspace Projects view, you can migrate the versioned data that you can add to the Workspace Projects list, and you have the option of migrating related objects. When you export objects, a dialog box appears with these options:
Object(s) Only. Exports only the objects in the Workspace Projects list.
Full Structure. Exports the objects in the Workspace Projects list and related objects, such as attribute definitions and product classes. If you use this option, the related objects are imported automatically when you import the objects in the Workspace Projects list.
In either case, all the objects are exported to a single XML file. When you import this XML file, they are imported as separate objects.
The data that is exported depends on the value in the Testing Date field and Use Project flag of the Workspace Project header. If no base date is entered, it depends on the value in the Effective Start Date field.
Each object is imported in a single transaction. Extend text fields only and avoid extending FK columns or adding child entities. An inconsistent product definition might result in the case of one object failing to import due to an invalid FK or child entity, and other objects import correctly.
It is recommended not to extend integration objects because the preconfigured import is staged in the Workspace version and does not take effect until you release new product versions. However, an extension which is non-versioned takes immediate effect after the import.
The recommended approach is to use preconfigured IO to migrate product headers and versioned objects, and extend the production ADM object to migrate the customer's extension.
To migrate product data using export and import in Workspace Projects view
In the development environment, navigate to the Administration - Product screen, then the Workspace Projects view.
In the Workspace Projects list, in the record for workspace containing the objects you want to migrate, enter the necessary information in the fields shown in the following table.
Field Comments Effective Start Date
This date is used for publishing. If no Testing Date is entered, this value is the date that the application uses to determine what versions must be exported for dependent items when the user chooses to export the full structure of the items in the Workspace Project
Base Date
This date is used for temporarily setting arbitrary time mainly for testing and development when Workspace Project is activated. Enter the date used as the date for dependent items for full structure export. If both Effective Starting Date and Base Date are filled, Base Date is used.
If you are exporting from an active Workspace Project (Use Project is checked):
All root objects, listed in the content, use Workspace Project versions
- All referenced objects (resolved through dependencies) use a published Workspace Project version effective for Base Date
If you are exporting from a non-active Workspace Project (Use Project flag is not checked):
All root objects, listed in the content, use a published Workspace Project version effective for Base Date
All referenced objects (resolved through dependencies) use a published Workspace Project version effective for Base Date
If Base Date is not specified, Effective Start Date is used. If both Effective Start Date and Base Date are not specified, then current time is used.
Use Project
If Use Project is checked, the workspaces of the objects in the Contents list are exported.
If Use Project is not checked, the relevant versions of those objects are exported.
In the Workspace Projects menu, select Export Contents.
In the Export Versioned Object dialog box, click Object(s) Only or Full Structure.
Save the files that are exported.
In the target environment, navigate to the Administration - Product screen, then the Workspace Projects view.
In the Workspace Projects list, add a new record and complete the necessary fields.
The contents will be imported into this new Workspace Project.
In the Workspace Projects menu, select Import Contents.
In the VOD Import dialog box, click Browse and select the file to import, and then click Import.
The imported file appears in the Workspace Projects list.
Migrating Products Using Application Deployment Manager (ADM)
You can also migrate products using Application Deployment Manager. You use the Joint WorkSpace content object to migrate key fields and versioned content for product itself, and you use the Product (ADM) content object to migrate the non-versioned content of product.
If you are migrating non-standard fields, you must customize the Product (ADM) content object.
For information about how to use ADM, see Siebel Application Deployment Manager Guide.
Importing and Exporting Product Promotions
Product promotions can be imported and exported as follows:
Navigate to the Administration - Product screen, then the Workspace Projects view.
In the Workspace Projects menu, select Export Contents.
The Export Full Structure option invokes method ExportFullVod of the ISS Authoring Import Export Service.
Navigate to the Administration - Product screen, then the Product Promotions view.
In the Product Promotions menu, select XML Export option.
In this case, method ExportVOD of ISS Authoring Import Export Service is invoked.
Note: The XML file generated contains the definition of the promotion. Only one promotion can be exported at a time.
For more information about methods of the ISS Import Export Authoring Service, see Siebel Order Management Guide.