The primary effect of activating a workspace is to cause G2 to invoke all
initiallyrules upon them. The invocation of
initiallyrules is described in the section Activating the Parent Workspace of a Rule.
Activating a workspace also activates all enabled items that reside upon the workspace. The activation status of an item determines whether it is active. In general, the activation status of an item propagates from its top-level workspace. For example, if you create an item on an active and enabled workspace, the item and its subworkspace are also active and enabled.
disable choices for the item. By default, a workspace is enabled until you interactively disable it using the
disable menu choice. When you disable an item, the workspaces in the hierarchy below the item are no longer active.
Activating Top-Level Workspaces
Each time you start or restart the current KB, G2 automatically does the following:
Executable items (for example, rules and procedures) must be enabled and activated to be eligible to be invoked.
An activatable subworkspace is the subworkspace of an item whose parent item has been configured using this configuration statement:
Instance-configurationattribute, as described in Chapter 7, Configurations.
An activatable subworkspace does not inherit its activation status from the top-level workspace. Instead, you must activate an activatable subworkspace programmatically using the
Note: A deactivated workspace is not excluded from existence checks in a KB such as
the count of each kb-workspace.
Activating and deactivating activatable subworkspaces programmatically provides a technique for turning portions of a KB on or off. By activating and deactivating appropriate portions of the workspace hierarchy, you can implement modes in your application, activating those branches which are relevant to the current mode while deactivating branches used to model competing modes.
How Activating and Deactivating Affects Items
When you first create an activatable subworkspace, it is active. Subsequently resetting or restarting the KB renders the subworkspace deactivated and it must then be activated programmatically.
initially rules upon that subworkspace, and resets variables and parameters that have initial values to those values. Default attribute values changed since instantiation are not reset.
deactivate actions. For a description of these actions, see activate and deactivate.