5 Extending Life Cycles

This chapter provides information on extending Oracle Communications Unified Inventory Management (UIM) entity life cycles. An entity life cycle refers to an entity having a start to its life, an end to its life, and a defined state at any given point during its life. Life-cycle state transition definitions are part of the UIM metadata, and these definitions can be extended to solve specific business requirements.

An entity can be defined as life-cycle managed in the metadata. Life-cycle managed entities transition through various states throughout the life cycle. The states are determined by the transition definition specified for the entity in the metadata.

The information presented in this chapter describes statically extending UIM, which can result in backward compatibility issues. See "Backward Compatibility" for the implications regarding this type of extension.

Note:

Before you begin reading about extending life cycles, you should have an understanding of the following concepts described in UIM Concepts:

  • Business Interactions

  • Life Cycles

About Business Interactions

Business interactions represent business transactions or events that affect products, services, and resources in inventory. They include service requests, sales orders, and network planning projects. Business interactions are modeled in inventory to facilitate change in the inventory, provide traceability, and enable transaction cancellations and changes. They can involve current business transactions, such as service orders, or future planned events, such as grooming projects.

In the UIM user interface (UI), you can switch between business interactions and current inventory by choosing Current on the menu bar. The Current menu has the following options:

  • Current: Switches from a business interaction to current inventory.

  • Recent BIs: Lists the five most recently accessed business interactions.

  • Search: Opens the Business Interaction Search page. Accessing a business interaction from the Search page switches the current business interaction to the selected business interaction, and also adds the selected business interaction as an option on the Current menu.

Business interactions tie in with transition definitions because the business states through which an entity transitions depend on whether the entity is within the context of a business interaction or current inventory. Each transition definition can define different <from> and <to> business states for business interaction versus current inventory. See Example 5-4, "Create Transition".

Understanding Metadata File Content

Extending an entity to be life-cycle managed, and extending life-cycle state transitions, is done through the metadata files and involves the definitions of:

  • Entities

  • Enumerations

  • Transitions

Understanding Life-Cycle Managed Entity Definitions

This section builds upon the information presented in "Understanding Entity Definitions".

An entity can be defined as life-cycle managed and business-interaction enabled in the metadata. A business-interaction enabled entity is, by inheritance, automatically a life-cycle managed entity. Conversely, an entity can be defined as life-cycle managed in the metadata without being a business-interaction enabled entity. The elements and attributes used to define an entity as life-cycle managed and business-interaction enabled are defined in the uim-plugin.xsd file. For example, the <lifecycle> element is used to define an entity as life-cycle managed, and the <businessInteractionEnabled> element is used to define an entity as business-interaction enabled.

Example 5-1 is an excerpt from the ocim-number-entites.xml file that shows the TelephoneNumber entity definition. The definition includes the declaration of the life-cycle managed and business-interaction enabled capabilities, which are bolded in the example. The <lifecycle> element defines the stateType attribute, which defines a value of InventoryState. InventoryState is an enumeration and is described in "Understanding Life-Cycle Managed Enumeration Definitions".

Example 5-1 Entity Definition

<entity type="ocim:TelephoneNumber" interface="oracle.communications.inventory.api.entity.TelephoneNumber" accessControlled="true">
.
.
.
    <!-- **************** Capabilities ******************-->
    <lifecycle stateType="ocim:InventoryState"/>
    <consumable prefix="TN" attribute="telephoneNumber"
    assignmentStateType="ocim:AssignmentState">
        <consumer name="ocim:Service" ConfigurationItemEnabled="true"/>
    </consumable>
    <referenceEnabled prefix="TelephoneNumber" attribute="telephoneNumber"/>
    <characteristic spec="ocim:CharacteristicSpecification">
        <characteristicName name="ocim:TNCharacteristic"
        interface="oracle.communications.inventory.api.entity.TNCharacteristic"
        table="TN_CHAR"/>
    </characteristic>
    <businessInteractionEnabled history="true" visibilityState="SHOW"/>
    <groupEnabled/>
.
.
.
</entity>

Understanding Life-Cycle Managed Enumeration Definitions

This section builds upon the information presented in "Understanding Enumeration Definitions".

About Life-Cycle States

Life-cycle managed entities transition through various states throughout the life cycle. These life-cycle states are defined as enumerations. There are two types of life-cycle states that an entity transitions through: Business states and object states.

  • A business state represents the current state as a result of a business action such as validate, approve, issue, complete, or cancel.

  • An object state represents the current state as a result of an object activity such as create, update, or delete.

Business state enumerations are defined in the *-enum-entities.xml and *-enum-types.xsd metadata files. Numerous business state enumerations are defined in the metadata upon installation of UIM, and you can extend the business state enumerations to solve business requirements.

Object state enumerations are defined in a Java class and cannot be extended. The object state enumerations are:

  • PLANNED

  • QUEUED

  • ACTIVE

  • INACTIVE

  • CANCELLED

  • DELETED

Understanding Business State Enumerations

Example 5-2 is an excerpt from the ocim-enum-entities.xml file, which defines the InventoryState enumeration type.

Example 5-2 Enumeration Type Definition

<enum type="ocim:InventoryState" enumType="oracle.communications.inventory.api.entity.InventoryState" adminState="true"/>

Example 5-1, "Entity Definition" defined the TelephoneNumber entity to be life-cycle managed, and the definition included the stateType attribute value of InventoryState, which is an enumeration.

Example 5-3 is an excerpt from the ocim-enum-types.xsd file, which defines the enumeration values for the InventoryState enumeration type. The enumeration type and enumeration values indicate that the TelephoneNumber entity may transition through up to eight business states during its life cycle.

Example 5-3 Enumeration Values Definition

<xs:simpleType name="InventoryState">
    <xs:annotation>
        <xs:documentation>Inventory Status</xs:documentation>
    </xs:annotation>
    <xs:restriction base="xs:string">
        <xs:enumeration value="PLANNED"/>
        <xs:enumeration value="PENDING_INSTALL"/>
        <xs:enumeration value="INSTALLED"/>
        <xs:enumeration value="PENDING_UNAVAILABLE"/>
        <xs:enumeration value="UNAVAILABLE"/>
        <xs:enumeration value="PENDING_REMOVE"/>
        <xs:enumeration value="END_OF_LIFE"/>
        <xs:enumeration value="PENDING_AVAILABLE"/>
    </xs:restriction>
</xs:simpleType>

Understanding Transition Definitions

Note:

Transition definitions for current inventory are defined within the <live> element; <live> displays as current in the UIM UI.

A transition defines the intermediate step from one business state to another business state, or from one object state to another object state. For example, within the context of a business interaction, the create transition moves an entity from inception to the initial PENDING_INSTALL business state, and the createComplete transition moves an entity from the PENDING_INSTALL business state to the INSTALLED business state. Similarly, the create transition moves an entity from inception to the initial QUEUED object state, and the createComplete transition moves an entity from the QUEUED object state to the ACTIVE object state.

Transition definitions are defined in files that start with uim- and end with -transitions.xml. For example, uim-default-transitions.xml. The transition definition files are located in the UIM_Home/cartridges/tools/ora_uim_entity_sdk.zip/src/uim_poms_lib.jar file.

You can extend business state enumerations, but you cannot extend object state enumerations. For transitions, you can extend both business state and object state transitions.

Example 5-4 is an excerpt from the uim-default-transitions.xml file, which defines the Create transition for the business state:

  • From inception to PENDING_INSTALL within the context of a business interaction

  • From inception to INSTALLED within the context of current inventory

The example also defines the Create transition for the object state:

  • From inception to QUEUED within the context of a business interaction

  • From inception to ACTIVE within the context of current inventory

Example 5-4 Create Transition

<transition name="Create" priority="0" default="true">
    <objectActivity value="CREATE"/>
    <businessState type="ocim:InventoryState">
        <attribute name="adminState" isCharacteristic="false"/>
        <businessInteraction>
            <from/>
            <to>PENDING_INSTALL</to>
        </businessInteraction>
        <live>
            <from/>
            <to>INSTALLED</to>
        </live>
    </businessState>
    <objectState>
        <businessInteraction>
            <from/>
            <to>QUEUED</to>
        </businessInteraction>
        <live>
            <from/>
            <to>ACTIVE</to>
        </live>
    </objectState>
</transition>

Understanding How Transitions Are Triggered

Transitions can be triggered automatically from within custom code or manually from within the UIM user interface.

For information on the life cycle management interfaces that are available when writing custom code to automatically transition an entity's life-cycle state, Custom code can be called from:

  • Customized user interface

  • Rulesets

  • Web services

You can manually transition an entity's life-cycle state from the Actions menu on the Summary page of any entity that is defined as life-cycle managed. The Actions menu options reflect the applicable transitions defined for the entity, based on the entity's current state.

Note:

Manually transitioning through an entity's life cycle by selecting the options on the Actions menu implies that the correct life-cycle state is dependent on user interaction to initiate the transition.

Example 5-5 is an excerpt from the uim-default-transitions.xml file, which defines the Activate and Deactivate transitions. The Activate and Deactivate transitions are shown in Figure 5-1, "Summary Page Actions Menu".

The example defines the Activate transition for the business state:

  • From UNAVAILABLE to PENDING_AVAILABLE within the context of a business interaction

  • From UNAVAILABLE to INSTALLED within the context of current inventory

The example defines the Activate transition for the object state:

  • Nothing is defined within the context of a business interaction

  • From INACTIVE to ACTIVE within the context of current inventory

The example defines the Deactivate transition for the business state:

  • From INSTALLED to PENDING_UNAVAILABLE within the context of a business interaction

  • From INSTALLED to UNAVAILABLE within the context of current inventory

The example defines the Deactivate transition for the object state:

  • Nothing is defined within the context of a business interaction

  • From ACTIVE TO INACTIVE within the context of current inventory

Example 5-5 Activate and Deactivate Transitions

<transition name="Activate" priority="0" default="true">
    <businessAction type="ocim:ResourceAction" value="ACTIVATE"/>
    <businessState type="ocim:InventoryState">
        <attribute name="adminState" isCharacteristic="false"/>
        <businessInteraction>
            <from>UNAVAILABLE</from>
            <to>PENDING_AVAILABLE</to>
        </businessInteraction>
        <live>
            <from>UNAVAILABLE</from>
            <to>INSTALLED</to>
        </live>
    </businessState>
    <objectState>
        <live>
            <from>INACTIVE</from>
            <to>ACTIVE</to>
        </live>
    </objectState>
    .
    .
    .
</transition>
<transition name="Deactivate" priority="0" default="true">
    <businessAction type="ocim:ResourceAction" value="DEACTIVATE"/>
    <businessState type="ocim:InventoryState">
        <attribute name="adminState" isCharacteristic="false"/>
        <businessInteraction>
            <from>INSTALLED</from>
            <to>PENDING_UNAVAILABLE</to>
        </businessInteraction>
        <live>
            <from>INSTALLED</from>
            <to>UNAVAILABLE</to>
        </live>
    </businessState>
    <objectState>
        <live>
            <from>ACTIVE</from>
            <to>INACTIVE</to>
        </live>
    </objectState>
    .
    .
    . 
</transition>

Figure 5-1 shows the Telephone Number Summary page Actions menu, which reflects the applicable transitions defined for the TelephoneNumber entity based on its current state. The telephone number, shown in the context of current inventory, has an inventory status of Installed, so Deactivate is the only available transition option. If you select Deactivate, the inventory status changes to Unavailable, and Activate becomes the only available transition option. When in the context of a business interaction, the value of the Inventory Status field reflects the states defined for <businessInteraction> based on the entity's current state. When in the context of current inventory, the value of the Inventory Status field reflects the status defined for current (live) based on the entity's current state.

Figure 5-1 Summary Page Actions Menu

Description of Figure 5-1 follows
Description of ''Figure 5-1 Summary Page Actions Menu''

About Transition Groups

A transition group provides the ability to associate a group of transition definitions with a specification. A transition group requires a name, which is used to associate it with a specification. A transition group can be associated with multiple specifications. By default, transition definitions defined within a transition group are templates. Templates are transition definitions that are not active/searchable until the group in which they are defined is associated with a specification. Within a uim-*-transitions.xml file, the <transitionGroup> element can define the templateOnly optional attribute, which defaults to true. If set to true, the transition definitions in the group are active/searchable, even though they are not yet associated with a specification.

Example 5-6, "Transitions Definition" shows an example of a transition group.

Extending Life Cycles through the Metadata Files

You extend life cycles by creating new metadata files.

Caution:

Do not make modifications to the existing metadata files. See "Backward Compatibility" for the issues involved with modifying the existing metadata files.

The metadata files are contained in the UIM_Home/cartridges/tools/ora_uim_entity_sdk.zip/src/uim_poms_lib.jar file.

You can use Oracle Communications Design Studio to create new metadata files. For example, you can import the ora_uim_entity_sdk.zip file and create any new XML or XSD files within the imported project.

This section builds upon information presented in Chapter 4, "Extending the Data Model". Any new metadata files you create must reside in ora_uim_entity_sdk project to be picked up by the generator. See "Applying Metadata Static Extensions" for more information.

Extending Entity Definitions

You can extend an entity definition to be business-interaction enabled, life-cycle managed, or both.

Defining an Entity as Life-Cycle Managed

The presence of the <lifecycle> element in the entity definition defines an entity as life-cycle managed. stateType is a required attribute of the <lifecycle> element. The value of stateType is an enumeration type that is defined in the ocim-enum-entities.xml file. This file defines several enumeration types that can be specified for stateType. Each enumeration type defines a set of enumeration values that represent the states of a specific life cycle. initialState is an optional attribute of the <lifecycle> element. initialState defines an enumeration that represents the default initial life-cycle state.

To define a new entity as life-cycle managed, add the <lifecycle> element to the entity definition in the new *-entities.xml file. See "Defining New Entities" for more information.

To define an existing entity as life-cycle managed, add the <lifecycle> element to the existing entity by extending the entity definition in the new *-entities.xml file. See "Extending Existing Entities" for more information.

Any new entity files you create must end with -entities.xml and reside in the ora_uim_entity_sdk/src/api directory, to be picked up by the entity generator.

Defining an Entity as Business-Interaction Enabled

The presence of the <businessInteractionEnabled> element in the entity definition defines an entity as business-interaction enabled. history is an optional attribute of the <businessInteractionEnabled> element. The history attribute is a boolean: if it is set to true, the version object is kept in the data store; if it is set to false, the version object is deleted. (Versioning is not covered in this guide. For information about versioning, see UIM Concepts.) visibilityState is also an optional attribute of the <businessInteractionEnabled> element. visibilityState defines an enumeration that is the default initial display level for the business-interaction enabled entity.

To define a new entity as business-interaction enabled, add the <businessInteractionEnabled> element to the new entity definition in the new *-entities.xml file. See "Defining New Entities" for more information.

To define an existing entity as business-interaction enabled, add the <businessInteractionEnabled> element to the existing entity by extending the entity definition in the new *-entities.xml file. See "Extending Existing Entities" for more information.

Any new entity files you create must end with -entities.xml and reside in the ora_uim_entity_sdk/src/api directory to be picked up by the entity generator.

Note:

If an entity is inherited from a business-interaction enabled entity, the entity cannot be defined as business-interaction enabled.

Defining an Entity as Life-Cycle Managed and Business-Interaction Enabled

A business-interaction enabled entity is, by inheritance, automatically a life-cycle managed entity. The presence of the <businessInteractionEnabled> element in the entity definition defines an entity as business-interaction enabled and as life-cycle managed. However, the presence of the <lifecycle> element in the entity definition is still required to specify stateType. Example 5-1, "Entity Definition" showed both the <lifecycle> and <businessInteractionEnabled> elements in the entity definition.

Extending Enumeration Definitions

You can create new enumeration files to address business requirements. New files you create must end with -entities.xml or -types.xsd. New files that follow this naming convention, and that reside the ora_uim_entity_sdk/src/api directory, are picked up by the entity generator.

See "Defining New Enumerations" and "Extending Existing Enumerations" for more information.

Extending Transition Definitions

When extending transitions by either creating new transitions or extending existing transitions, look at the existing uim-*-transitions.xml files for examples. Any new entity files you create that end with -transitionss.xml and that reside in the ora_uim_entity_sdk/src/api directory are picked up by the entity generator

The following transition procedures state how to create a new file, but you do not need to create a new transitions file for each new transition. For example, you can optionally define all new transitions and extending existing transitions in the same file.

Defining New Transitions

To add a new transition to a new *-transitions.xml file:

  1. Create a new XML file.

    The file name must end with -transitions.xml. For example, myNewFile-transitions.xml.

  2. Open an existing uim-*-transitions.xml file.

  3. Copy and paste a transition definition from the existing file to your new file.

  4. Modify the copied transition definition as needed:

    1. Change the name of the transition to reflect the name of your new transition.

    2. Remove or update the tags to reflect the definition of your new transition.

Extending Existing Transitions

To extend an existing transition in a new *-transitions.xml file:

  1. Create a new XML file.

    The file name must end with -transitions.xml. For example, myNewFile-transitions.xml.

  2. Open the existing uim*-transitions.xml file that you plan to extend.

  3. Copy and paste the transition definition from the existing file to your new file.

  4. Modify the copied transition definition as needed:

    1. Add additional <businessState> elements as needed.

    2. Do not change the transition name.

    3. If the copied transition does not define the priority attribute, add it and set the value to 1 (the default is 0). If the copied transition already defines the priority attribute, increase the value. The priority attribute value is used when the transition name is not unique. The higher the value, the higher the priority.

Updating Properties Files

If you extend life cycles, you need to update some properties files that are used to display life-cycle statuses. The following properties files are located in the UIM_Home/config/resources/logging directory:

  • status.properties

    This file defines statuses that are referenced by the UI. If life cycles are extended by introducing new statuses through the metadata transition files, and the statuses are referenced by the UI, the status.properties file must be updated to reflect the new statuses.

  • enum.properties

    This file defines enumerations that are referenced by the UI. If life cycles are extended by introducing new enumerations through the metadata enumeration files, and the enumerations are referenced by the UI, the enum.properties file must be updated to reflect the new enumerations.

Updating Security

If you extend life cycles, you need to update security for any new actions to display in the UIM UI.

To update security:

  1. Log in to the Enterprise Manager Console.

  2. In the navigation panel, expand Application Deployments and click the oracle.communications.inventory (AdminServer) link.

    The oracle.communications.inventory page appears.

  3. From the Application Deployment list menu, select Security, then select Application Policies.

    The Application Policies page appears.

  4. Expand the Search page.

  5. From the Principle Type list, select Application Role and click the search icon.

    The search results display.

  6. Select the uimuser row and click Edit.

    The Edit Application Grant page appears.

  7. Under Permissions, click Add.

    The Add Permission dialog box appears.

  8. Expand the Search page, and choose Permissions.

  9. From the Permission Class list, select oracle.security.jps.ResourcePermission.

  10. From the Resource Name list, select Starts With.

  11. In Resource Name, enter the following text where Entity is any entity such as Service, CustomObject, and so forth, and where BusinessAction is your custom business action:

    resourceType=PAGE_ACTION,resourceName=Entity.BusinessAction

  12. Click the search icon.

    The search results display.

  13. Select the applicable resource name, and click Continue.

  14. In Permission Actions, enter view.

  15. Click Select.

    The Add Permission dialog box closes.

  16. Click OK to grant the permission.

More on Transition Definitions

The following information is provided to help you define *-transitions.xml files. Each transition file can define multiple transition definitions, and each transition definition can define multiple states. Example 5-6, "Transitions Definition" includes all the possible elements and attributes described below.

  • <transition> can be defined multiple times within the same file.

    • name is required and should be unique. If duplicate transition names are found, the one with the higher priority attribute value is used.

    • entityType is optional. If it is not specified, the transition definition is available for all entity types.

    • priority is optional, and has a default value of 0. The higher the value, the higher the priority. The value is used when name is not unique. If the same name and same priority are specified, an error occurs.

  • <specification> is optional. If it is not specified, the transition definition is available for entities with any specification.

  • <businessAction> and <objectActivity> are optional, but one of them must be specified. These values are used by the lookup process to determine the transition definition.

  • <businessState> can be defined multiple times within a transition. This defines the business states that the entity transitions through during its life cycle.

    • <businessState> can be set on an entity's attribute or a custom attribute.

    • type must be a valid enumeration.

    • isCharacteristic indicates whether <businessState> is an attribute or a custom attribute.

    • name is either the attribute name or the custom attribute name.

    • If isCharacteristic is set to true, you can specify the characteristicSpecName attribute. If this attribute is not set, the system uses the name attribute value as the characteristic-specific name.

    • <businessState> can optionally define zero, one, or many <businessInteraction> blocks, or zero or one <live> block, or both.

    • If <businessInteraction> is defined, its <from> state is used to match the entity's current business state if the transition happens within the context of a business interaction. If <from> is not specified, it is considered a wild card and can be matched with any entity's current state.

    • If <live> is defined, its <from> state is used to match the entity's current business state if the transition happens within the context of current inventory.

    • If the transition happens within the context of a business interaction and <businessInteraction> is not defined, the search for a match continues. Similarly, if the transition happens within the context of current inventory and <live> is not defined, the search for a match continues.

  • The <businessInteraction> block and <live> block can define multiple <from> states. This allows matching multiple <from> states without defining them separately in each <businessState> block. If <from> is not specified, it is considered a wild card and can be matched with any entity's current state.

  • There can be only one <to> state defined in the <businessInteraction> and <live> blocks. The value is used to set the entity's business state. If <to> is not specified, the entity's current state is not changed.

  • Only one <objectState> block can be defined for the transition definition.

  • <objectState> can define zero, one, or many <businessInteraction> blocks, and zero or one <live> block, and each can define multiple <from> states.

  • The <dependants> block defines the methods to retrieve the dependent entities and how to transition them. Multiple <dependants> blocks can be defined in a transition definition.

    • attribute is the attribute name of the parent entity and is used to hold the dependent entities by the parent entity.

    • isCollection is a boolean that indicates whether attribute holds a collection (true) or a single dependent entity (false).

    • If the dependent entity is accessed indirectly through the weak reference of the attribute, then weakReference is the name of the access method to resolve the weak reference. For example, the BusinessInteraction entity has an items attribute that holds a collection of BusinessInteractionItem entities, but the BusinessInteractionItem entity has a weak reference that refers to the real dependent entity (TelephoneNumber). The toEntity attribute is specified to resolve the TelephoneNumber entity from the BusinessInteractionItem entity.

    • After the dependent entities have been resolved, the system is ready to transition the dependent entities with the parent's business action and object activity. However, if useDependentObjectActivity is true, the system uses the dependent entity's object activity and parent entity's business action to transition the dependents.

    • If the parent's business action is not valid for transitioning the dependents, you have the option to specify one or more <transitionName> elements in the <dependants> block. TransitionNames retrieves the transitions in sequence, then uses the transition's business action and object activity to look up the matching transition for each dependent. If there is no matching transition by using transitionNames, the action described in the previous bullet is performed.

Example 5-6 Transitions Definition

<transitionGroup name="defaultBusinessInteractionGroup" templateOnly="false">
    <transition name="BusinessInteractionCreate"
    entityType="ocim:BusinessInteraction" assignable="true" priority="0">
        <objectActivity value="CREATE"/>
        <businessState type="ocim:BusinessInteractionState">
            <attribute name="adminState" isCharacteristic="false"/>
            <businessInteraction>
                <from/>
                <to>CREATED</to>
            </businessInteraction>
            <live>
                <from/>
                <to>CREATED</to>
            </live>
        </businessState>
        <objectState>
            <businessInteraction>
                <from/>
                <to>ACTIVE</to>
            </businessInteraction>
            <live>
                <from/>
                <to>ACTIVE</to>
            </live>
        </objectState>
    </transition>
    <transition name="BusinessInteractionComplete"
    entityType="ocim:BusinessInteraction" assignable="true" priority="0">
        <businessAction type="ocim:BusinessInteractionAction" value="COMPLETE"/>
        <businessState type="ocim:BusinessInteractionState">
            <attribute name="adminState" isCharacteristic="false"/>
            <businessInteraction>
                <from>CREATED</from>
                <from>IN_PROGRESS</from>
                <to>COMPLETED</to>
            </businessInteraction>
        <businessState>
        <objectState>
            <businessInteraction>
                <from>ACTIVE</from>
                <to>INACTIVE</to>
            </businessInteraction>
        </objectState>
        <dependants attribute="items" isCollection="true" weakReference="toEntity"
             useDependentObjectActivity="true">
        </dependants>
    </transition>
</transitionGroup>

About Life Cycle Management Interfaces

The following sections describe life cycle management interfaces. For information on the methods defined by any of these interfaces, see the Javadoc. For instructions on how to access the Javadoc, see "Javadoc Documentation".

LifeCycleManaged

An entity that is defined as life-cycle managed in the metadata automatically implements the LifeCycleManaged interface. It is not necessary to include the tag:

<implements interface="oracle.communications.inventory.api.LifeCycleManaged"/>

The LifeCycleManaged interface:

  • Defines a business state for the entity

    A business state represents the current state as a result of a business action such as validate, approve, issue, complete, or cancel.

  • Defines an object state for the entity

    An object state represents the current state as a result of an object activity such as create, update, or delete.

TransitionManager

An entity that is defined as life-cycle managed in the metadata automatically implements the LifeCycleManaged interface. This enables you to call methods on the oracle.communications.inventory.api.common.TransitionManager interface, which takes in a LifeCycleManaged entity as an input parameter.

The TransitionManager interface:

  • Defines methods that take in a business action and appropriately transition the business and object states

  • Automatically updates the business state and object state of any life-cycle managed dependent entities when the parent life-cycle managed entity business state or object state is updated

  • Provides the ability to associate or disassociate a specification with a transition group

Transition Definition Search

The transition() method provides the ability to transition through the defined business states and object states. To do this, it must first determine the transition definitions for business state and object state that apply to the entity. This is accomplished through a search that takes place within the transition() method.

The transition() method input parameters are the life-cycle managed entity, business action, and object activity. The life-cycle managed entity parameter contains entity type and specification, which are used in the transition definition search. If no match is found, a less relevant search is performed until a transition definition is found. The following lists the search criteria in the most-significant to least-significant order. The least-relevant transition definition returned would be the default transition definition.

  1. Business action, object activity, entity type, specification

  2. Business action, object activity, entity type

  3. Business action, object activity

At this point, the search has returned one or more transition definitions that matched the criteria. This list of transition definitions is now interrogated to find one that defines a <from> business state that matches the entity's current business state. Whether the entity is within the context of a business interaction determines which <from> business state is interrogated: Business interaction or current (live).