Skip Headers
Oracle® Communications Order and Service Management Concepts
Release 7.2.2

E35415-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
PDF · Mobi · ePub

Glossary

activation

The enabling, disabling or changing of a service or network feature.

activation task

A type of automated task designed specifically to interact with the Oracle Communications ASAP product or the Oracle Communications IP Service Activator product.

Administrator application

An OSM application used to manage user workgroups, calendars and schedules, email notifications, and system events.

amend and amendment processing

A generic term that refers to making changes to in-flight orders. Amendments are typically made when processing a revision order, or managing an order cancellation or order failure. The amendment usually performs compensation; such as redoing or undoing tasks.

Application Integration Architecture (AIA)

The Oracle Application Integration Architecture. A set of Oracle products that enable you to set up and orchestrate cross-application business processes so that multiple applications can work together. OSM integrates with Oracle AIA for Communications. Oracle AIA runs on top of Oracle Fusion Middleware.

Application Integration Architecture (AIA) Order-to-Activate Cartridges

A set of OSM cartridges that integrate with the Oracle Communications Order to Cash Integration Pack for Oracle Communications Order and Service Management (Order to Cash Integration Pack for OSM). The Order-to-Activate cartridges and the integration pack enable OSM to be part of an order fulfillment solution that cover the entire order-to-activate process from order creation to service activation.

ASAP

Automated Service Activation Program. An Oracle product used by communication service providers to activate operational support systems equipment across multiple technology domains. ASAP supports many hardware vendor's network systems, and is integrated with OSM using activation tasks.

automated task

A task that does not require manual activity. Automated tasks handle interactions with external systems such as billing systems, shipping systems, and activation systems. They can also perform custom calculations and other tasks. Automated tasks are implemented using automation plug-ins. See manual task.

automation framework

An interface that enables the integration of OSM with external applications. It is used to automate tasks and notifications to other systems. It can also be used to perform business logic (such as performing complex calculations) without interacting with an external system. The automation framework is an OSM server component that performs the work required by automation plug-ins.

automation plug-in

An OSM component that performs the operation specified by an automated task. For example, you can create automation plug-ins to update order data, complete order tasks with appropriate statuses, set process exceptions, react to system notifications and events, send requests to external systems, and process responses from external systems. These operations can involve communication with external systems. OSM provides several predefined plug-ins. You can also develop your own plug-ins using a custom template.

behaviors

OSM behaviors allow you to control the validation and presentation of data elements in the OSM Web clients and data providers. For example, you can use the Calculate behavior to derive the value of the data in a field by adding the values in two other fields. You could use the Information behavior to present a tool tip for a field in the Task Web client.

cartridge

A software package created in Design Studio to deploy functionality to an OSM run-time system. Cartridges contain order metadata such as recognition rules, processes, order states, behaviors, specification, and other entities used for order processing.

Cartridges are created with Design Studio, but Oracle also offers customized cartridges that support integration with other common applications (for example, the Oracle Communications Order to Cash Integration Pack for Oracle Communications Order and Service Management). Oracle also offers pre-configured cartridges that demonstrate the capabilities of OSM.

central order management

The OSM system role that receives customer orders from one or more order-source systems such as Siebel CRM, creates an OSM order, and manages the fulfillment of the order across other enterprise systems including billing, shipping, and service fulfillment systems. OSM operating in the central order management role also receives status information from these systems and provides visibility of an order's status back to the order-source system. The central order management role is sometimes called central fulfillment.

An OSM instance can operate in a central order management role or in a service order management role.

common fulfillment state

The fulfillment state list that is defined on the States tab of the fulfillment state map entity. The common fulfillment state list provides the values that can be used for both mapped fulfillment states and composite fulfillment states.

compensation

Changes that are made to accommodate revisions to in-flight orders (orders still being processed). For example, if a customer initially orders Bronze-level DSL service but upgrades to Gold-level service while the original order is in place, tasks may need to be done, redone, or undone. OSM automatically calculates the compensation required to accommodate the changes to orders.

OSM uses these types of compensation: Do, which is a change that needs to be made in addition to the original tasks. Redo, which is a change that needs to be made to redo work that was already performed by the order. Undo, which is a change that needs to be made to undo work that has already been done by the order. Amend Do, which is the same as Do, but performed during amendment processing.

composite fulfillment state

The fulfillment state that results from an order fulfillment state composition rule set or an order item fulfillment state composition rule set.

control data

Metadata in an orchestration order that is used to manage the execution of the orchestration plan. OSM extracts control data from an order. Control data provides information about order items, order components and dependencies required to create the orchestration plan. This includes status and timestamps for its order items and components. During the execution of an orchestration plan, the order data, including control data, can be updated as transactions are completed.

Design Studio automatically generates control data for order components. You manually model control data for order items.

creation task

The task that contains data required for the order. The creation task specifies what information must be provided to the order before it can start processing. This applies equally to manual order entry through the Task Web client as well as through OSM WS or XML APIs. A creation task is defined in the order specification.

In OSM Web clients, the creation task represents the step that creates and submits an order instance that starts the order workflow.

CRM

Customer relationship management. A system for managing a company's interactions with customers, clients and sales prospects; for example, Oracle's Siebel CRM. When used in OSM documentation, CRM refers to sales and order capture activities.

customer order

An order request received by OSM to obtain a product or products, typically generated by the CRM or some other order-source system. OSM converts the customer order to OSM format after which it is referred to as an order. Sometimes called an in-bound order.

Data Dictionary

The logical repository of data elements used in Design Studio. The Data Dictionary defines data types and structures that can be used within OSM orders. For example, you can define a simple type that represents an IP address or a phone number, or more complex types representing addresses, product attributes and so on. Data elements in a Data Dictionary are used as building blocks of an OSM order.The data elements within a Data Dictionary project can be referenced by other projects in a work space. Multiple data dictionaries can be used to contribute data structures to a single order definition. A single Data Dictionary can also contribute to multiple order definitions.

data element

An entity viewable in Design Studio. When you model simple and structured data elements in the Data Dictionary, you can create new data elements that inherit their attributes from other existing data elements.The new data element can extend the information configured in the parent data element (also referred to as the base data element). For example, if you have a structured data element called person with first name, last name, and social security number child elements. You can extend the person structured data element by using it as a base for a new structured data element called employee, to which you add the employee number, hire date, and department child elements.

Simple data elements are reusable data types that contain no child dependencies. A simple data element has no structure, and is associated—directly or indirectly—to a primitive type (int, boolean, char, and so forth). Structured data elements are reusable data types and are containers of simple data elements and other structured data elements.

data provider

An adapter that can retrieve order data from external systems in an XML format. Design Studio provides several built-in data providers to retrieve external XML instances from specific sources such as a JDBC database or a SOAP Web service. Additionally, you can create your own custom data provider. Data providers are used when defining Data Instance behaviors.

decomposition

The process by which a customer order is broken into constituent order items, which are then organized into order components. For example, OSM can use the following algorithm to achieve decomposition:

The example above is representative of what OSM is normally configured to do for decomposition, but OSM is not restricted to these three stages. Decomposition is specified through configuration and can have any number of stages through which the order is decomposed.

See also order component, executable order component, orchestration stage.

decomposition rule

Rules that determine the order items in each order component. Decomposition rules specify the conditions in which OSM decomposes one or more order components into another order component. OSM evaluates every order item in the source order component against the conditions that you define for the decomposition rule. If an order item passes all specified conditions, OSM includes the order item in the target order component.

Unlike many other OSM modeling entities, decomposition rules are not directly referenced by other parts of the model. OSM selects decomposition rules by matching the source and target order components of the decomposition rule to the order components in the orchestration stages in the orchestration sequence.

See also executable order component.

default process

The first process that runs after an order is created. A default process can either be an orchestration process (which will be backed by a dynamically generated orchestration plan) or a workflow or workstream process.

delay

A process activity that specifies that a process stops until a condition evaluates as true. In OSM there are two types of delays, timer delays and event delays. A timer delay retries the evaluation of the rule at a fixed time interval. An event delay retries the evaluation of the rule only when order data changes.

dependency

A relationship in which a condition related to one order component or order item must be satisfied before another order item can be processed. For example, it may be necessary to perform provisioning before billing can occur for the same order item. Dependencies can have the following relationships:

See also inter-order dependency, intra-order dependency.

Design Studio

The software application used to design, configure, and deploy OSM Order Management cartridges into OSM environments. Design Studio is based on the Eclipse Integrated Design Environment (IDE). OSM plug-ins provide the specific screens (editors), validation logic, and cartridge-build functionality that allow users to create and configure OSM cartridges.

entity

A functional unit created and edited in Design Studio; for example, tasks, processes, behaviors, projects, and notifications. Entities are collected in a cartridge to deploy in a run-time environment to support your business processes (for example, you deploy cartridges to OSM run-time environments.

Entity names must be unique by entity type. For example, you cannot name two task entities with the same name. However, you can create identical names for different entity types. For example, you can model a task entity and a process entity with the name AddDS.

Entity names are sometimes defined just by a simple name (the filename of the entity), and sometimes by a simple name and a namespace URI. In the case where a namespace URI is provided, it is the combination of the URI plus the simple name that gives the entity its unique name.

See also data element.

event delay

See delay.

executable order component

An order component with an associated process. Typically this is a component decomposed to its final level of granularity. Executable order components are generated during the last orchestration stage in an order.

See also order component and decomposition.

expected duration

The amount of time an order, or some part of the order (order component, product specification or task), is expected to take to complete processing.

expected start date

The date on which an order is expected to start being processed. Expected start date is determined for orchestration orders by calculating the expected order duration and factoring this in with the requested delivery date for order items on the order.

external fulfillment state

The status returned from a fulfillment system to an order component. This may be the exact status returned by the system, or automation may be used to translate the status before it is put on the order. It is a key input into a fulfillment state mapping.See also fulfillment state.

fallout

The failure of an order during processing. Fallout occurs whenever an order encounters a situation that prevents it from being processed. Causes for fallout include missing data or the inability to access a fulfillment system. Fallout management includes detecting, investigating, and resolving failed orders.

fallout exception

A mechanism initiated from the OSM Task Client to interrupt or stop an order, or to redirect it to any task in the same process or any other process. A fallout exception halts an order at a particular task in order to correct an error caused by a previous task.

fallout management

A process that includes detecting, investigating, and resolving failed orders. Administrators perform fallout management with the OSM Web clients. The clients allow them to search for failed orders, identify the reason for the failure by viewing order details, and resolve dependencies to allow order processing to proceed. In cases where the dependency cannot be resolved, you can cancel or terminate the order.

follow-on order

An order that is submitted to modify a completed order. Follow-on orders are not processed until their order-item dependencies on the in-flight orders allow them to proceed.

fulfillment

Operations that fulfill a customer's order. This may be providing, modifying, resuming or canceling a customer's requested products and services.

fulfillment function

Fulfillment functions are operations that must be performed to process an order item; for example, initiating billing, shipping, or performing installation. Fulfillment functions are defined in order component specifications created in Design Studio.

fulfillment modes

An entity that represents the intent of an order. For example, the fulfillment mode could indicate whether the order is intended for qualification, delivery to fulfillment systems, testing and so on. Every customer order can specify a fulfillment mode.

Different fulfillment modes will have different orchestration sequences. If OSM receives two identical incoming customer orders with different fulfillment modes, it generates a different orchestration plan for each order. The two plans include different executable order components with different dependencies among order items.

fulfillment state

The state of an order or order item aggregated and translated from status values returned by external systems. This state can be used to provide status visibility to upstream systems and to users by using the Order Management Web client.See also common fulfillment state, composite fulfillment state, external fulfillment state, and mapped fulfillment state.

fulfillment state map

The Design Studio entity that contains both the definition of common fulfillment states and fulfillment state mappings. A common fulfillment state defined on one fulfillment state map is available to all fulfillment state mappings in the workspace.

fulfillment state mapping

The Design Studio entity that maps external fulfillment states to values from the common fulfillment state list. The resulting fulfillment state is referred to as a mapped fulfillment state.

fulfillment system

A participating system in an order management solution. Fulfillment systems can include billing, provisioning, activation, shipping and workforce management systems, among others. OSM interacts with fulfillment systems when processing orders.

fulfillment topology

The arrangement of network elements, processes, systems, and software used to fulfill a customer order. The fulfillment topology represents the types and instances of fulfillment systems involved in fulfilling an order. For example, all of the Business Support Systems (BSS) and Operational Support Systems (OSS) that participate in order capture and order fulfillment represent the fulfillment topology.

future-dated order

An order that has a requested delivery date that is later than the current date and time. For example, a customer order to have a new VoIP service added at the beginning of the next month is a future-dated order. OSM uses the order orchestration plan to calculate the order start date of future-dated orders so the order can be completed by the time the customer wants it.

See also expected duration and expected start date.

in-bound order

See customer order.

in-flight changes

Changes that are made to an order that is being processed.

in-flight order

Any order that is not in a closed state (Closed or Aborted). An in-flight order still has the potential for further work to be performed on it.

inter-order dependency

A dependency between order items in different orders.

intra-order dependency

A dependency between order items in the same order. An intra-order dependency can refer to external information, but not to data in other orders.

IP Service Activator

Internet Provider Service Activator. An Oracle product used by communication service providers to define and fully automate the activation of services on large-scale multi-vendor IP networks. IP Service Activator delivers end-to-end network control and enables real time reaction to new service and customer demands.

line item

See order line item.

manual task

Tasks performed by OSM operations personnel using the Task Web client. See also automated task.

mapped fulfillment state

The fulfillment state that results from a fulfillment state mapping.

metadata

Data definitions for entities such as processes, states, and rules modeled in Design Studio. OSM uses metadata to determine how to process order data. For example, OSM uses metadata from the product specification to determine how order items are to be grouped into order components in an orchestration plan.

mnemonic

A synonym for an entity name. Mnemonic is a legacy term for OSM. The proper name is entity name.

multi-instance data element

A data element that is permitted to have more than one instance. For example, you configure the ControlData/OrderItem structure as a multi-instance data element so that OSM can create an instance of the structure for every order line item extracted off the in-bound customer order.

namespace

1. An XML namespace is a method for uniquely naming elements and attributes in an XML document. Attributes and elements are identified by a fully qualified name that consists of a namespace name paired with the local attribute or element name.

2. An OSM entity namespace is a method for uniquely naming OSM entities across projects. Fully qualified OSM entity names consists of a namespace name paired with the local entity name. OSM entity namespaces allow different work groups of Design Studio users to create different entities without concern for name contention. Services can be implemented independently by a different teams, then deployed into a single OSM run-time environment.

Not every OSM entity has a separate namespace (example: tasks and processes). For these types of entities, a unique name is created by attaching the cartridge name and version number to the entity name.

3. An OSM cartridge namespace is a method for uniquely naming OSM cartridges. This allows you to identify what cartridge is deployed in an environment. For example, if you are diagnosing an order failure, it's useful to know the logic and configuration of the cartridge that processed that order. Fully qualified cartridge names consist of a namespace name paired with the cartridge name.

You can view namespaces and other details about an entity or cartridge through Design Studio.

notification

Messages sent by OSM to alert users of order problems (jeopardy notifications) or changes to an order's state, status or data (event notifications). By default, OSM sends most types of notifications to the Task Web client Notifications page. You can also specify that notifications be sent by e-mail.

Oracle WebLogic Server

Oracle's application server for building and deploying enterprise Java EE applications. The Oracle WebLogic Server hosts the OSM server, OSM integration, and related interfaces.

orchestration

The process OSM uses to manage the fulfillment of a complex order. Order fulfillment often requires interaction with many fulfillment systems. Various dependencies may require that these interactions be run in a specific order to ensure that order items are sent to the proper systems, and that the required steps, in the proper sequence are run.

orchestration order

An order that requires an orchestration plan for fulfillment. Orchestration orders contain control data for an orchestration plan. The default process for an orchestration order is an orchestration process. See process-based order.

orchestration plan

A dynamically generated plan that is used to manage the fulfillment of an order. Order fulfillment often requires interaction with many fulfillment systems, and various dependencies may require that these interactions be run in a specific order. The orchestration plan includes the order, order component, and the type and the sequence of order component execution. An orchestration plan is generated for each order based on the metadata defined for the type of order being processed.

For example, an order is captured by Siebel CRM and is sent to OSM for processing. Using the recognition rules and other entities provided by the OSM cartridges in the Order to Cash Integration Pack for OSM, OSM decomposes the order and dynamically generates an orchestration plan that is used to manage the fulfillment of the customer's order across other enterprise systems.

orchestration sequence

A set of orchestration stages for an order. Orchestration sequences specify the set of orchestration stages for an order. Orchestration stages and sequences together define how an order is decomposed.

See also decomposition, orchestration stage.

orchestration stage

A step in an orchestration sequence used to decompose an order and create an orchestration plan.

See also decomposition, order.

order

An order in the OSM format. You model orders by creating order specifications in Design Studio.

There are many order variants including:

order component

A collection of order items that can be processed together because they meet some common criteria as determined by an orchestration stage. Order components are modeled in Design Studio, based on factors such as a function that needs to be performed, the systems that need to perform that function, and what other items can be processed in the same group.

See also decomposition, executable order component, orchestration stage.

order component ID

An ID associated with an order component that can be used in decomposition. When implementing fulfillment systems; for example, you can configure OSM to achieve decomposition by using decomposition rules or by using the component IDs of the order items. For example, a decomposition rule can select order items from fulfillment system order components and group them into an order component to create a single bundle. OSM can then use an order component ID calculation to generate distinct bundle instances.

order data

The data that is used for fulfilling an order; for example, a customer name and address.

order data key

Uniquely identifies a data element or structure in an order by differentiating the data element or structure based on a data element value. Order data keys are important when identifying order data changes during compensation and for multi-instance data elements.

order definition

See order specification.

order duration

See expected duration.

order entity

See order specification.

order fallout

See fallout.

order fulfillment state composition rule set

The Design Studio entity used to aggregate and evaluate the fulfillment states of root-level order items and compose them into a single composite fulfillment state for the entire order.

order header

Orders typically consist of two parts: an order headers containing information that is applicable to the entire order such as the customer name and address, and order line items such as the products, services, and offers requested by the customer and the action to be performed on them (Add, Suspend, Delete, Move, and so on).

order item

An order line item transformed so that it can be processed in OSM. Each order item includes the action required to implement it, such as Add, Suspend, and Delete. Order items are decomposed into order components based on shared characteristics defined in a product specification.

See also order component.

order item fulfillment state composition rule set

The Design Studio entity used to aggregate and evaluate the fulfillment states of order component order items and child order items and compose them into a single composite fulfillment state for the entire order item.

order key

Unique value that enables the system to match incoming revision orders to the corresponding OSM order. If the order key matches an order that is currently in progress, the order is considered to be a revision that amends a base order. For example, you can specify to use the customer reference ID as the order key. In that case, when OSM processes an order, it looks for previous orders that have the same customer reference ID, and amends it.

The order key can be any data or combination of data associated with the order. It is configured in Design Studio as an XPath expression to a data element that will uniquely match an amended order to its corresponding OSM order. For example, you might specify a customer reference ID as the following Xpath expression: root/Cust_Ref_ID

order life cycle

The sequential states through which an order passes and the transactions it undergoes from the time it is received in OSM until the time it is resolved. States include Not Started, In-progress, Suspended, and Completed. Each order state is associated with a set of transactions that can be performed while the order is in that particular state. Transactions include Update Order, Cancel Order, Complete Task, and Raise Exception. The life cycle of an OSM order is governed by the order state model and order life cycle.

order life-cycle policy

A set of policies that controls the states in which an order can be, and the transactions allowed in those states. The order life-cycle policy also determines which roles can perform which transactions. For example, while an order is in the In Progress state, you might want your Customer Service role to be able to perform the Update Order, Cancel Order, and Suspend Order transactions, while your Fallout role is able to perform the Raise Exceptions transaction. Every order type you create must be associated with an order life-cycle policy.

order line item

Specific items such as individual products, services, and offers on an incoming customer order. OSM transforms order line items into order items.

Order Management Web client

An OSM web application that displays an order's orchestration plan, including dependency, orchestration stages, order components, order items, and processes. The Order Management Web client is used by fallout administrators responsible for locating orders with errors, determining the causes of failures, and taking the necessary corrective actions; operations and management personnel who monitor the progress of orders; and orchestration plan designers who can use this application to test and validate orchestration-based orders during the modeling and implementation of OSM solutions.

order priority

A value that OSM uses to determine which orders should be given more processing resources. OSM uses order priority to determine the next thing to be done. Orders with higher priority will be processed before orders with lower priority. In situations where resources are constrained (for example, the system is using all available CPU, memory, or other resources to process orders), orders with higher priority will process faster than orders with lower priority.

order recognition

The process of determining the type of an incoming customer order so it can be mapped to an order specification in OSM. During order recognition, OSM steps through an ordered list of recognition rules to determine which rule applies to the customer order. Each rule is associated with an order specification.

order reference number

A value associated with an order specified in one of the OSM Web clients or OSM APIs. OSM uses an order reference number as an identifier to external systems. Reference numbers can be used as keys to correlate orders between systems.

order specification

An order entity defined in Design Studio. The order specification is the central entity in OSM. It defines the basic information OSM requires for it to be able to process orders. It specifies such things as what data is allowed in an order (order template), what are the range of order priorities, whether amendments are allowed and how they are processed, how to handle jeopardy, fallout, permissions and so on.

Other entities such as tasks, processes, and notifications require that you specify an order specification to which it relates. Order specifications can inherit from other order specifications, and multiple order specifications can be modeled and can exist simultaneously. Also known as an order definition and order entity.

order state

OSM processes each order within a set of order states. A state is the condition of the order. For example:

  1. An order is created in the Not Started state.

  2. When processing begins on the order, the state changes to the In Progress state.

  3. When the order is complete, it transitions to the Completed state.

See order life cycle.

order state transition

Changes from one order state to another order state as a result of a transaction. Each order state has a set of allowable transitions. For example, when an order is completed, it transitions from the In Progress state to the Completed state.

order template

A part of an order specification that defines what order data OSM will use to process and fulfill the order. For example, the order template defines the data required for order items as well as the data required in an order header. Create or modify order templates by adding data elements from one or more data dictionaries.

order transformation

The manipulation and enrichment of the structure and contents of a customer order through a set of rules. Transformation rules are defined as part of recognition rules, and are based on applying a series of XQueries to the in-bound order.

Three types of transformation rules are available: order priority rules, which define the priority of the order in relation to others; order reference rules, which define the order reference number; and order data rules, which add to or modify incoming customer order data.

order validation

A process that occurs during order recognition that validates that an order is syntactically correct. When an inbound order is recognized, OSM validates it based on validation rules defined in the order recognition rule.

For example, a validation rule can determine that all mandatory fields are populated, that valid characters (numeric or alphanumeric) are used for fields, and that the order has a valid status code such as Open. Validation rules are implemented as XQuery expressions. Each node in the expression must evaluate to true for validation to pass.

OSM order management Web services API

The primary interface for external systems to OSM. The OSM order management Web services provide for in-bound order operations such as creating, managing, retrieving, updating, or canceling an order. Web services are Web APIs that support interoperable machine-to-machine interaction over a network such as the Internet. Web services run on a remote system hosting the requested services such as OSM. Web service interfaces are described by the Web service definition language (WSDL).

OSM security callback

A callback interface that allows you to generate an audit trail log of users before they gain access to order data that is considered sensitive. The security callback interface is designed to intercept order access from defined functions such as GetOrder, XML API WorkList.Request, and Task Web client Order Data History page.

OSM server

The server that manages OSM run-time functionality, including in-bound order operations and outbound communications with external systems. The OSM server is deployed on Oracle WebLogic Server.

OSM Web clients

The two OSM GUI applications called the Order Management Web client and the Task Web client. The Order Management Web client displays an order's orchestration plan, including dependency, orchestration stages, order components, order items, and processes. The Task Web client is used for monitoring and managing the tasks in an order.

point of no return

The point in the orchestration of an order item after which revisions can no longer be accepted.

process

A sequence of tasks and subprocesses that need to be carried out to fulfill all or part of an order. For example, an ADSL fulfillment process could include the following tasks that can take place over a number of days: assign a port, ship modem to customer, activate DSLAM, send customer survey, and verify order. The process includes definitions of the relationships between tasks and the sequence in which they are run.

process-based order

An order that does not include an orchestration plan. A process-based order typically handles a provisioning process. See orchestration order.

processing granularity

Decomposition groups order items into optimally executable order components. For example, if monthly fees, VoIP adapter, and VoIP phone are all billed by the same billing system, they can be grouped into a single executable order component. This is called processing granularity. See decomposition.

product catalog

A data repository that stores and retrieves information about your products including price lists, discount lists, and unit groups. The product catalog is used to create customer orders. Sometimes called the master product catalog. The product catalog exists on the CRM or other order-source system. An example of a product catalog is the Siebel Sales Catalog or Oracle Product Information Management Data Hub for Telco.

product class

Groups of related products that share common attributes. For example, suppose you sell products for three levels of DSL service. Though there are different values to differentiate the service levels, the products are structurally identical and provisioned by the same system; they are variations of the basic DSL service. As a result, a single product-class to product-specification mapping can be used for all of them.

Product classes are defined in a product catalog such as the Siebel Sales Catalog or Oracle Product Information Management Data Hub for Telco.

product specification

An entity that includes the fulfillment function order components and dependencies required to fulfill a product order. Each order item in an order is mapped to a product specification. OSM uses the product specification to determine the necessary fulfillment functions, order components, the dependencies that exist between them, and dependencies on other product specifications to generate an orchestration plan.

provisioning

Providing the data necessary for enabling a service, with the actual enabling done by activation.

recognition rule

Rules that enable OSM to validate a customer order and transform it into an OSM order format.

related order

An order that contains order items that depend on another order.

reporting interface

A tool for generating reports about OSM orders, tasks, and notifications. The Reporting Interface augments the reports that are available through the OSM Web clients. See OSM Reporting Interface Guide for more information.

requested delivery date

The date on which an order is requested to be delivered.

revision order

An order that modifies a previously submitted order that is still being processed. For example, a customer may want to switch to a higher level of service before an order is completed. Revision orders may require compensation. The system can process revision orders until the original order reaches its point of no return. A revision order is sometimes called a supplemental order.

See also follow-on order.

role

A set of permissions to access to functions in the Task Web client and Order Management Web client that can be assigned to users. Functions include viewing reports, assigning tasks, and querying orders. In addition to granting OSM Web client permissions, you can also grant permissions at the order and task levels. Roles are created with the OSM Administrator application or Design Studio. The Administrator application refers to roles as workgroups, although they are both the same thing.

rule

Rules are defined as part of an order specification to work on data in the order. Rules are used in many OSM activities to evaluate conditions and determine next process steps. For example, you can specify to delay the next task in a process until a specified data element includes a certain value.

rule engine

A processing component of OSM that evaluates rule and timer delays for transition to the next task. The engine is implemented as one or more Oracle database jobs. The rule engine is configured as one or multiple jobs to improve performance.

security callback interface

See OSM security callback.

service order

An order received by an OSM instance acting in the service order management role.

service order management

The OSM system role that serves as part of a service fulfillment stack, working with inventory and activation systems to fulfill services in one or more network domains. An OSM instance can operate in a service order management role or in a central order management role. Sometimes called local fulfillment.

specification

See order specification.

subprocess

A process started by another process. A subprocess is used to organize any large process into smaller more re-usable pieces. It includes one or more tasks and realizes an executable order component.

task

An individual step that is required for the processing of an order. Tasks are defined by the order specification in Design Studio, and can be either a manual task (performed by human action) or automated task (performed by an automation plug-in).

Tasks are run as part of any process-based order. For example, a completely process-based order consists of a series of steps which are defined by tasks. By contrast, an orchestration order starts out as orchestration plan. Each order component within the orchestration plan is implemented by a subprocess which in turn contains tasks and other subprocesses.

task state

A state describing the milestones of a task in a process. The task state also determines how it can be worked on. OSM provides the following task states: Received, Assigned, and Accepted. You can, however, create your own task states. For example, you can define a Suspended task state to indicate the progress of automated tasks, or you can define a Completed task to indicate that user is finished with the task and the order is ready to move to the next task in the process.

task status

A representation of how a task can transition to the next step in a process. The task status shows how the task transitions in a process; for example, if the task transitioned the process to the next task, or if it caused the process to fail. Changing the status of the task determines the next step in the order process. The statuses that you define appear as task transition options in the OSM Web clients.

For example, if you have a task called Assign Port, and the two statuses are Port Available and Port Unavailable, the status determines whether the process can proceed to the next task. Task status also controls notifications, so when the status is Port Available, OSM can send a message saying Successful.

Task Web client

An OSM GUI application used for monitoring and managing the tasks in an order. This application is typically used by order processing personnel to ensure that all the tasks are completed. It is also used by order fallout managers. You can also suspend and resume orders, cancel orders, and create orders manually.

timer delay

See delay.

transaction

An action taken by the OSM system on an order. For example, the Suspend Order transaction stops all processing on the order and transitions the order to the Suspended state. Also called an order state transaction

Some other transactions are Abort Order, Complete Task, Process Amendment and Raise Exception. Most transactions perform transitions that change the state of the order to a different state. However, some transactions do not perform a transition to another state. For example, the Update Order transaction can make changes to an order without changing the order's state.

trouble ticket (TT)

A request to the trouble ticketing system indicating that an error occurred during the processing of an order. Different from a fallout task in that trouble tickets come from front-end systems such as Siebel CRM.

unresolved dependency

A dependency with at least one unmet condition.

WebLogic Server

See Oracle WebLogic Server.

workgroup

A group of users with assigned permissions to access to functions in the Task Web client and Order Management Web client. Functions include viewing reports, assigning tasks, and querying orders. In addition to granting OSM Web client permissions, you can also grant permissions at the order and task levels. Workgroups are created with the OSM Administrator application or Design Studio. Design Studio refers to workgroups as roles, although they are the same thing.

worklist

A list of manual tasks assigned to OSM operations personnel who use the Task Web client to manage orders. When an order arrives at a task, it is added to the worklist of all the members of all the workgroups assigned to work on that task. Users can select a task from their worklist to view the assigned task in the order process. Worklist also refers to the main page in the Task Web client used for managing orders.