1. Using Siebel Tools
  2. How LOVs Work in Workspaces

How LOVs Work in Workspaces

How List of Values (LOV) or multilingual LOV (MLOV) data is created or updated in Siebel CRM has evolved relative to earlier releases. In particular, LOVs are now Workspace-enabled, allowing parallel development and sandboxing. This topic summarizes some of the key changes in the LOV framework that were made starting in Siebel CRM 17.0 and continuing in subsequent Siebel CRM update releases. Changes described for LOVs also apply to MLOVs.

LOVs can be optionally created or updated in the following contexts:

  • In the Design Repository by developers.

  • In the Runtime Repository by administrators.

Note: When you create an LOV in an Integration Workspace (IWS_A), the LOV is automatically created in every Integration Workspace whether existing or new (for example, in IWS_B, IWS_C and so on) but will be inactive in those Workspaces. To make the LOV available in IWS_B, you must deliver the current Workspace to its parent which activates the LOV in the parent, and so on up the delivery tree until you get to MAIN. The behavior is similar when rebasing a child Workspace – that is, any LOVs active in the parent will become active in the child Workspace. For more information about working with LOVs, see Siebel Applications Administration Guide.

LOV Changes for Design Repository

Because LOVs are Workspace-enabled, they are managed in the Design Repository (DR) environment in Workspaces, just like other repository objects, such as applets or business components. Unlike traditional repository objects, however, LOVs are stored at the Integration Workspace level. This allows one developer to create all the LOVs needed for a feature and the other developers to have them available in their sibling Workspaces, without the need for a rebase.

At the database level, all Integration Workspaces contain a full copy of all LOV records. This is done for two reasons: for performance and to avoid duplicate key errors during delivery.

When a developer creates a new LOV, that LOV will be active in that Workspace, with Workspace Inactive Flag = False (WS_INACTIVE_FLG = N). This record is propagated to all other Integration Workspaces as inactive, with Workspace Inactive Flag = True (WS_INACTIVE_FLG = Y). This ensures that no duplicate record can be created in another Workspace, while maintaining the sandboxing of LOVs to the Workspace in which they are created.

When the Integration Workspace is delivered to its parent, the copy of the LOV in the parent is updated to also be active, reflecting that it is now available in that parent and can be migrated to Runtime Repository (RR) environments by the Siebel Migration Application (along with any repository changes in that same Migration package).

When other Integration Workspaces are rebased, active LOVs are propagated into their child Integration Workspaces, making them available there as well.

The new columns in the S_LST_OF_VAL table that support the Workspace-enablement of LOVs are as follows:

  • WS_ID (Workspace Id) stores the ROW_ID value of the corresponding Workspace record from the S_WORKSPACE table.

  • WS_SRC_ID (Workspace Source Id) stores the ROW_ID value of the original LOV record (from the Workspace in which the record was created). When an LOV record is propagated to other Workspaces, the WS_SRC_ID value remains the same, ensuring that there is one logical record per LOV across all Workspaces. Delivery and rebase processes have no additional complexity as a result.

  • WS_INACTIVE_FLG (Workspace Inactive Flag) is a Boolean column that stores the inactive flag (Y is inactive, N is active) for the LOV record in a given Workspace, as previously explained.

    WS_INACTIVE_FLG must be N for the LOV to show up in the List of Value Administration View for the current Workspace context. WS_INACTIVE_FLG itself is not visible in the user interface but rather is managed by the delivery and rebase processes.

    Note: WS_INACTIVE_FLG is not to be confused with the existing ACTIVE_FLG column, which has always been part of the S_LST_OF_VAL table. ACTIVE_FLG maps to the Active field in the List of Value Administration View and allows an administrator to hide a row from end users at runtime by unchecking the Active checkbox.
Note: As noted, while developers typically appear to make LOV changes in their Developer Workspaces, the actual LOV records are maintained at the parent Integration Workspace level. The same LOV can therefore also be changed directly in the Integration Workspace. It is possible to allow updates to only be made at the Integration Workspace level by setting the system preference DisableSeedUpdOnDevWS = True.

LOV Changes for Runtime Repository

While LOV data can be managed in the Design Repository (DR) environment using Workspaces and migrated to Runtime Repository (RR) environments in conjunction with repository objects in the same source Workspace, this data can also be managed in the RR environments themselves.

For example, a developer can create new LOVs in the DR environment for new or existing LOV types in order to perform testing and provide a base set of LOVs to migrate to the RR environment with a new or updated feature. At the same time, an administrator can add more values directly into the RR environment on an as-needed basis, without having to first put it into the DR environment and perform migration.

Runtime repository environments use only a MAIN Workspace (that is, there are no Integration or Developer Workspaces). MAIN supports multiple versions, which allows rollback to a last known stable version in the event of an issue with newly migrated objects. During a full repository migration from the DR to the RR, a full set of LOVs are copied into the target environment as version 0. As incremental migrations are performed, the MAIN version number increases by one, and any new or modified objects, including repository objects and LOVs, are tagged with the new version number. For this reason, there could be two or more physical records in the database representing the same logical record: one with an earlier version and others with later versions.

Each of the physical records (instances of the same logical record) for an LOV share the same WS_SRC_ID, but have different versions, allowing the Application Object Manager to select the correct instance at runtime. Each of these instances has an arbitrary ROW_ID value, just like any other newly created record. The WS_SRC_ID value is the same as the source DR record's WS_SRC_ID value, tying all instances and versions of an LOV logically together across all DR and RR environments.

Additionally, the following columns apply for LOV records in the Runtime Repository:

  • WS_MIN_VER (Workspace Minimum Version) stores the minimum repository version in which this LOV record is valid. This value is 0 for any LOV record added through full repository migration. For any LOV record added or updated through incremental repository migration, the value represents the number of times incremental repository migration has occurred to that point, including the migration in which this LOV record migrated. A new record is created for an update.

    For example, where an LOV record was updated in the fifth incremental repository migration, WS_MIN_VER is set to 5 for the new record, which is valid as of MAIN version 5. (If you later roll back to an earlier version of MAIN, then an older record can become valid again. At runtime, the Object Manager picks the record with the largest WS_MIN_VER value that is less than or equal to the version to which you rolled back.)

  • WS_MAX_VER (Workspace Maximum Version) stores the maximum repository version below which this LOV record is valid. 10000 is the hardcoded maximum version and is the WS_MAX_VER value for any LOV record that has not been superseded through subsequent updates. Where incremental repository migration updated an existing LOV record, this value is reset for the original record to match the WS_MIN_VER value for the new version of the LOV record.

    For example, where an LOV record was updated in the fifth incremental repository migration, WS_MAX_VER is set to 5 for the prior version of this record, which is valid in MAIN version 4 but not in MAIN version 5. (If you later roll back to a prior version of MAIN, then such a prior version of the record can become valid, where the WS_MAX_VER value is higher than the repository version you are rolling back to.)

As noted, Siebel CRM enables users such as business administrators to use the Siebel application user interface to update LOV records directly in the Runtime Repository (in QA or production environments). As explained later in this topic, a conflict could occur as a result of an LOV record being updated directly in the Runtime Repository. A system preference is provided to help you manage such conflicts.

Managing Conflicts in LOV Record Versions During Migration

A conflict could occur as a result of an LOV record being updated directly in the runtime repository. If a record that originated in the Design Repository is updated in the runtime repository, is later changed in the Design Repository as well, and an incremental repository migration is performed, then the two versions of this record would conflict.

Because the record originated in the Design Repository, both records would have the same value for WS_SRC_ID, which stores the ROW_ID value of the LOV record in the source Workspace. WS_SRC_ID serves as a unique identifier across all environments, as described earlier. (A new record created in the Runtime Repository would not have a WS_SRC_ID value from the Design Repository, so would present no conflict to be resolved.)

To allow LOV records that originated in the Design Repository to be updated using multiple methods without conflicts during incremental repository migration, use the Seed Migration Priority system preference to designate which updates have priority. In the downstream or target environment (the Runtime Repository), set the system preference as follows:

  • Seed Migration Priority = Target (the default) gives priority to the updates made in the Runtime Repository.

  • Seed Migration Priority = Source gives priority to updates made in the design repository.

Additional LOV Changes

You can use EIM for bulk loading of LOV records in the Design Repository or in the runtime repository. For information about importing LOV data using EIM, see Siebel Enterprise Integration Manager Administration Guide.

Related Books

For more information about working with LOVs in the Siebel application user interface and about rolling back to a prior version of the Runtime Repository, see Siebel Applications Administration Guide.

For more information about performing repository migrations, see Siebel Database Upgrade Guide.

For information about importing LOVs using EIM, see Siebel Enterprise Integration Manager Administration Guide.