Glossary
activation
The enabling, disabling or changing of a network resource; for example, creating a local loop for a DSL service. Activation is preceded by provisioning. Activation is typically initiated in a technical order run by OSM in the technical order management (TOM) role.
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.
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.
ASAP
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 operations. 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. OSM provides several predefined plug-ins. You can also develop your own plug-ins.
behaviors
OSM behaviors allow you to control the validation and presentation of data elements in the OSM Task web client. 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.
In addition to customizing the Task web client, you can also use the Data Instance behavior to retrieve data by using data providers. See data provider.
cartridge
A collection of entities and data defined in Design Studio and packaged in an archive file for deployment to a runtime server. In Design Studio, you build cartridges in cartridge projects. You can create your own custom cartridges to extend Oracle Communications applications. Additionally, you can obtain from Oracle customized cartridges that support integration with other common applications, and cartridge packs that bundle cartridges containing metadata for particular technology domains; for example, order specifications, recognition rules, processes, behaviors, and so on.
central order management (COM)
The OSM role that receives orders from one or more order-source systems such as Siebel CRM, creates an OSM customer order, and manages the fulfillment of the order across other enterprise systems including billing and OSM in the service order management (SOM) role. OSM operating in the COM role also receives status information from these systems and provides visibility of an order's status back to the order-source system.
common fulfillment state
A fulfillment state that can be assigned to an order item, order component, or order. Common fulfillment states are user-defined values that provide consistent state definitions for various entities. Common fulfillment states are available for the entire workspace. To define a common fulfillment state, you define its name, and then apply either a mapped fulfillment state or a composite fulfillment state to it. For example, a common fulfillment state named Failed could be used for a fulfillment state mapped from Error, or a composite state of Error + Unsuccessful.
See mapped fulfillment state and composite fulfillment state.
compensation
The process of comparing the requirements in a revision order to the requirements in the base in-flight order, and making the changes. 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.
compensation plan
An internal process that OSM defines and runs to process a revision order. The compensation plan defines which tasks need to be done, redone, or undone.
composite fulfillment state
The fulfillment state that results from combining the fulfillment states from order items into a single fulfillment state.
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 generate 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. It is used by OSM in the order process; for example, when an order is canceled, the order is returned to the creation task. A creation task is defined in the order specification.
CRM
Customer relationship management. A system for managing a company's interactions with customers, clients and sales prospects; for example, Oracle's Siebel CRM.
customer-facing service (CFS)
A service that implements what the customer ordered, independent from how the order is implemented on the network. A CFS is typically the service as the customer would recognize it; for example, Internet service. By contrast, a resource-facing service (RFS) is the service as implemented on the network; for example ADSL or VDSL.
customer order
An order processed by OSM in the central order management (COM) role. OSM creates a customer order from the order received from the CRM system. The customer order typically fulfills billing functions and calculates the requirements for a service order that is sent to OSM in the service order management (SOM).
Data Dictionary
A logical collection of data elements and data types in a workspace, enabling you to leverage common definitions across an entire Oracle Communications solution. For example, the Data Dictionary enables you to create order templates, atomic actions, and service specifications, and share the data defined for those entities across your OSM, ASAP, and Inventory applications. Entities in a workspace contribute data types to the Data Dictionary, and data schemas in a workspace (which are accessible across all projects) contribute data elements to the Data Dictionary.
The Data Dictionary enables you to integrate and correlate data models for multiple applications, reduce the size and complexity of a solution model, simplify the application integration by eliminating data translation among applications, and validate data model integrity. See also data schema.
data element
A structured or simple type data definition. When modeling data for a project, you create data elements that you can reuse throughout your model. There are two types of data elements: simple data elements and 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.
data schema
An XML schema that provides a formal description of a data model, expressed in terms of constraints and data types governing the content of elements and attributes. All data elements are created and saved in data schemas, which are accessible across all projects in a workspace. Design Studio automatically creates a project-specific data schema when you create a new project. You can use this default schema to contain the data you require to model the project, you can create multiple schemas in the same project, or you can create schemas in common projects. You can model your projects using data from any combination of these data schemas.
decomposition
The process by which order line items in a sales order are transformed into order items, which are then organized into order components. For example, OSM can use the following algorithm to achieve decomposition:
-
Map order items to functions (fulfillment function order components)
-
Map function order items to fulfillment systems (fulfillment system order components)
-
Map fulfillment system order items to processing granularity (granular order components)
See also order component, executable order component, orchestration stage.
decomposition rule
Rules that determine the order items in each order component during decomposition. OSM evaluates every order item in the source order component against the conditions that you define for the decomposition rule.
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.
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:
-
Between different order components for the same order item.
-
Between different order components for different order items.
-
Between order items across orders.
-
Time-based dependencies.
See also inter-order dependency, intra-order dependency.
design and assign
The process of determining the resources required to implement a service, and assigning the resources based on the available inventory. For example, the design for a DSL service might specify a port and a local loop, which would be assigned based on the inventory. Design and assign is typically initiated in a service order run by OSM in the service order management (SOM) role.
Design Studio
An integrated design environment for the development of solutions based on the Oracle Communications OSS Applications. Design Studio enables solution designers to configure application-specific and multi-application solutions by leveraging application-specific concepts. Design Studio is built on an open architecture based on the Eclipse framework, and it uses a wide variety of innovative technologies.
entity
A functional unit created and edited in Design Studio; for example, tasks, processes, physical and logical resources, and order specifications. Entities are collected in projects and deployed to runtime environments to support your business processes.
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 decomposition.
expected duration
The amount of time an order, or some part of the order, (for example an order component, fulfillment pattern or task), is expected to take to complete processing. OSM uses the expected duration to calculate the expected start date and the expected completion date.
expected start date
The date on which an order is expected to start being processed. Expected start date is determined 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 fulfillment state.
fallout
The failure of an order or task during processing. Fallout occurs whenever an order or task encounters a situation that prevents it from processing normally. Causes for fallout include missing data or the inability to access a fulfillment system. Fallout management includes detecting, investigating, resolving, or escalating failed orders and tasks.
fallout exception
A mechanism initiated from the OSM Task Client or from an automated task automation plug-in to interrupt or stop an order or task, to redirect it to any task in the same process or any other process, or to transition a task into a fallout execution mode.
fallout management
A process that includes detecting, investigating, resolving, and escalating failed orders and tasks. Administrators perform fallout management with the OSM web clients. The clients allow them to search for failed orders and tasks, identify the reason for the failure by viewing order and task details, and resolve errors and dependencies to allow order processing to proceed. In cases where the fallout scenarios 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, such as providing, modifying, resuming, or canceling a customer's requested products and services.
fulfillment function
An operation that must be performed to process an order; for example, initiating billing, shipping a modem, or activating a service.
fulfillment mode
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.
fulfillment pattern
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 fulfillment pattern. OSM uses the fulfillment pattern to determine the necessary fulfillment functions, order components, and dependencies to generate an orchestration plan.
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, 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 system that carries out the actions necessary to complete the order; for example, activate services on the network, ship equipment, or run billing. To process an order, OSM sends commands to fulfillment systems to carry out their functions and return the status of the fulfillment action.
fulfillment topology
The fulfillment systems required to fulfill orders. For example, a fulfillment topology might include a CRM system, OSM running in the COM role, multiple instances of OSM running in the SOM and TOM roles, a billing system, a shipping system, and so on. The fulfillment topology also defines the relationships between the fulfillment systems; for example, the activation systems and shipping systems that OSM in the TOM role interacts with.
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-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.
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.
lifecycle policy
An order attribute that defines the states that an order can have; for example, In Progress and Suspended, and the rules governing transitions between states.
JMS queue
A method used by systems to communicate with each other. To communicate with external systems, the OSM server uses mostly Java Message Service (JMS) queues. JMS is part of the standard Java platform. A JMS queue is a staging area that you configure when you install OSM. Systems communicate via JMS queues by publishing messages to them and receiving messages from them.
manual task
Tasks performed manually by OSM operations personnel using the Task web client. See also automated task.
metadata
The data that you create when modeling OSM in Design Studio. Metadata is data about data, that is, metadata defines how data is created and used in the OSM system. OSM uses metadata to determine how to process order data. For example, OSM uses metadata from the order specification as a template to create orders at runtime.
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 inbound order.
namespace
A method for uniquely naming elements and attributes in an XML document. Design Studio supports entity and cartridge namespaces. You pair the entity or cartridge name with a namespace name to create a fully qualified namespace. For example, you can pair entity names with a namespace name to enable different groups of Design Studio users to create different entities without concern for naming conflicts. Services can be implemented independently by different teams and then deployed into a single runtime 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.
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 Application Integration Architecture (Oracle AIA)
Integrates business processes across multiple applications. OSM integrates with Oracle AIA for Communications. Oracle AIA runs on top of Oracle Fusion Middleware.
Oracle Application Integration Architecture (Oracle 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 covers the entire order-to-activate process from order creation to service activation.
Oracle Configure, Price, and Quote Cloud (Oracle CPQ Cloud)
Oracle's order capture software that enables companies to select products, assign pricing, create quotes, and submit orders.
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 an order across many fulfillment systems. 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. Most orders are orchestration orders. 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 generate 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.
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 decompose an order by using decomposition rules or by using the component IDs.
order data
The data that is used for fulfilling an order; for example, the customer name and address, required bandwidth, and so on.
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 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.
See fulfillment state.
order header
The part of an incoming sales order that contains information applicable to the entire order such as the sales order number, the order action (Add, Cancel, Delete, and so forth), and the customer name and address. An order in the OSM format does not have a header; only orders received from external order source systems.
order item
An order line item transformed so that it can be processed in OSM. Order item properties include the action required to implement it, such as Add, Suspend, and Delete. Order items are decomposed into order components during orchestration.
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.
See fulfillment state.
order item transformation
The process of using rules to derive one set of order items from another set of order items.
order key
A 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 Lifecycle Management UI
A user interface that enables you to view the progress of an order that is being managed by an OSM system.
order lifecycle policy
A set of policies that controls the states in which an order can be, and the transactions allowed in those states. The order lifecycle 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 lifecycle policy.
order line item
Specific items such as individual products, services, and offers on an incoming 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 dependencies, order components, and order items. 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. The Order Management web client also has an Administration area used to manage user workgroups, calendars and schedules, email notifications, and system errors.
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 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.
See recognition rule.
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, (defined in the 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
The condition of the order. For example:
-
An order is created in the Not Started state.
-
When processing begins on the order, the state changes to the In Progress state.
-
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. You 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 an order through a set of rules. Transformation rules are applied to an incoming sales order in a recognition rule.
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 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.
OSM order management web services API
The primary interface for external systems to OSM. The OSM order management web services provide for inbound 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 runtime functionality, including inbound 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.
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.
processing state
Processing states are a predefined set of states that an order item can enter. OSM aggregates the values returned from external systems in each order component for the order item to determine the overall processing state of the effected order item.
product
A conceptual model entity that represents something that your business sells. Because Design Studio is primarily used for service fulfillment rather than sales, products are often identifiers associated with information from other systems.
product catalog
The complete collection of your products, offers, and bundles. A product catalog is typically stored as a data repository on the CRM or other order-source system; for example, the Siebel Sales Catalog or Oracle Product Information Management Data Hub. Sometimes called the master product catalog.
product specification
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-specification to fulfillment-pattern mapping can be used for all of them.
The use of OSM product specifications has been deprecated, and new OSM product specifications cannot be created in Design Studio 7.2.4 and later. Conceptual model products, customer-facing service (CFS), resource-facing service (RFS), resources, and actions should be used instead.
project
An entity that contains artifacts (entities, data, rules, code, and so forth) that you use to model and deploy Design Studio cartridges. Your solution uses various types of projects. For example, you use projects for version management, for single sourcing data, for resource organization, and to build cartridges that can be deployed to a server. You can create various types of projects and you can extend cartridges that you purchase with your own projects. Oracle Communications supports a library of extensible cartridges that are fully compatible with Design Studio and provide a basis from which to assemble solutions.
provisioning
Identifying the network resources required to enable a service. For example, to provision a phone service, the service and resource management (SRM) system finds a phone number. The provisioning data is used during activation to enable the service on the network.
recognition rule
Rules that enable OSM to validate an incoming order and transform it into an OSM order format.
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.
resource-facing service (RFS)
A service as it is implemented on the network; for example, an ADSL service. By contrast, a customer-facing service (CFS) is the service that the customer purchased and would recognize; for example, Internet service.
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 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 by using Design Studio. The Administration area of the Order Management web client 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
An OSM processing component 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.
sales order
An order received by OSM to obtain a product or products, typically generated by a CRM system or other order-source system. OSM converts the sales order to OSM format after which it is referred to as a customer order or as an order.
A sales order is sometimes called an inbound order.
service order
An order processed by an OSM instance acting in the service order management (SOM) role. Service orders work with service and resource management (SRM) systems to design services and assign resources.
service order management (SOM)
The OSM system role that processes the service orders. Service orders work with service and resource management (SRM) systems to design services and assign resources. OSM in the SOM role receives orders from OSM in the central order management (COM) role, and sends orders to OSM in the technical order management (TOM) role.
simple data element
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).
specification
A blueprint that defines the composition of an entity, including the attributes and relationships between an entity and other objects. There are different types of specifications for different types of entities, such as telephone numbers, networks, customer-facing services, and resources. Specifications are defined in Design Studio and deployed into runtime environments, where entities can be created based on them.
In OSM, this may refer specifically to an order specification.
structured data element
Reusable data types that include embedded data types and are containers of simple data elements and other structured data elements.
subprocess
A process started by another process. A subprocess is used to organize any large process into smaller more re-usable pieces.
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).
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 state 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.
technical order
An order processed by OSM in the technical order management (TOM) role. Technical orders work with external systems to implement activation, shipping, installation, and other fulfillment actions.
technical order management (TOM)
The OSM role that processes technical orders. Technical orders work with external systems to implement activation, shipping, installation, and other fulfillment actions. OSM in the TOM role receives orders from OSM in the service order management (SOM) role.
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.
workgroup
A group of users with assigned permissions to access 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 Design Studio and managed using the Administration area of the Order Management web client. 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.