A conceptual model includes the following entities that you configure to support the behavior for a specific domain:
Customer facing services, which represent your services from a customer perspective. See "About Customer Facing Services" for more information.
Resource facing services, which represent a technical view of a service. See "About Resource Facing Services" for more information.
Resources, which represent the entities that are required to configure the service. See "About Resources" for more information.
Products, which represent your commercial products. See "About Products" for more information.
Locations, which represent physical locations. For example, in a Broadband service, the DSL RFS for a DSL service can be associated with a location to represent the address of the customer.
Service actions, which are requests to update the design of a customer facing service, a resource facing service, or a resource. See "About Conceptual Model Actions" for more information.
Technical actions, which are requests to downstream delivery systems to make changes in the network (the downstream delivery systems are represented by an application role). Technical actions are associated with resource facing services or resources. See "About Conceptual Model Actions" for more information.
Action parameter bindings, which enable you to:
Identify the conceptual model entities, such as a resource or a resource facing service, that contribute to the creation of technical actions.
Bind the attributes defined for a conceptual model entity or the entity itself (the source data) to parameters defined for technical actions (the target data).
See "About Action Parameter Bindings" for more information.
Domains, which are groups of entities and actions that you can use to organize and filter conceptual models. See "About Domains" for more information.
The following conceptual model entities help to define the model infrastructure and rarely require updates. You can extend these entities to meet the requirements of a specific deployment:
Application roles, which represent types of downstream delivery systems that are responsible for specific types of delivery, such as activation, supply chain management, work force management, and so forth.
See "About Application Roles" for more information.
Functional areas, which are the logical layers of an installation and can be commercial, service, and technical layers. These layers are supported by an Order and Service Management order type or by an external order management system. See "About Functional Areas" for more information.
Provider functions, which are processing components that perform a defined set of tasks based on their role in a solution. Design Studio includes the configuration for some provider functions, such as Calculate Service Order, Design and Assign, Calculate Technical Order, and Activation. See "About Provider Functions" for more information.
Fulfillment patterns, which determine the high-level functions that are required to process an action or conceptual model entities. Fulfillment patterns include any number of fulfillment functions. See "About Fulfillment Patterns" for more information.
Fulfillment functions, which represent the work to be performed against an action. Fulfillment functions can be augmented with conditions to determine whether the function is to be performed against an action. See "About Fulfillment Functions" for more information.
Customer facing services represent the commercial view of the services that you provide to your customer (a service represents the way that a product is realized and delivered to a customer).
You can use the same customer facing service to fulfill different but similar product offers. For example, the same Broadband_Internet_Access service can be used to fulfill a Broadband product and a Broadband_Bandwidth product. You map the data elements defined for customer facing services to data elements defined on products. Additionally, you associate customer facing services with resource facing services (as components). For example, you can associate with a CFS the resource facing services available to fulfill the service, such as DSL or DOCSIS.
See Design Studio Concepts for more information about customer facing services.
Realizing Conceptual Model Entities into Application Entities
Resource facing services describe how customer facing services are configured. For example, you can provision a customer facing service named Broadband_Internet_Access using multiple resource facing services, such as DSL, Fiber, or DOCSIS. You determine the resource facing service used to provide the commercial-level services during service design.
Resource facing services are technology-specific; however, resource facing services are not specific to a vendor. They can include resources or finer-granulated resource facing services. Resource facing services are represented in Design Studio for Inventory as Service specifications and as Service Configuration specifications.
See Design Studio Concepts for more information about resource facing services.
Realizing Conceptual Model Entities into Application Entities
Resources define the technical components of a solution. A resource is a specific object in the network and in the inventory that can be consumed, referenced, or shared by a service when provisioning a resource facing service. Resources can be physical, such as a port, or logical, such as bandwidth. Examples of resources include IP addresses, VoIP phones, and DSLAM ports.
Resources are realized as Design Studio for Inventory resource entities. See Design Studio Concepts for more information about resources.
Realizing Conceptual Model Entities into Application Entities
Products are entities that represent something that your business sells. A product type defines a set of product characteristics, validation rules, and relationships. For example, you might create products for Broadband, Broadband_Bandwidth, and Email products.
You can create products in Design Studio or (if your products exist in a separate product catalog) you can import products into Design Studio. After you create or import products, you can create or review the associated attributes in the Product editor.
See Design Studio Concepts for more information about products.
When working with products, see the following topics:
Locations define geographic references that are relevant to services or resources. Locations can be specific places, such as a residence or a business, or more general places, such as a city. Locations are realized as Design Studio for Inventory Place specifications.
See Design Studio Concepts for more information about locations.
Realizing Conceptual Model Entities into Application Entities
Design Studio includes the definitions for two action families, service and technical:
Service Actions are the signatures of design operations that apply to customer facing services, resource facing services, or to resources. Actions are executed at run-time to initiate design and assign activities. Service actions are grouped into families that represent the range of operations that can be invoked on the entity, and each action consists of a specific set of parameters.
Technical actions are requests to downstream delivery systems to make changes in the network (the downstream delivery systems are represented by an application role). Technical actions are associated with resource facing services or with resources.
Conceptual model entities are the targets, or subjects, of actions. You associate actions with entities to indicate that the action or group of actions can be performed against the associated entity.
You can create your own actions, or your can configure Design Studio to create actions automatically when you create new conceptual model entities. Actions that Design Studio create automatically are considered mandatory.
Customer facing services are associated with service actions only. When you create customer facing services, Design Studio automatically creates a mandatory service action and associates the service action with the customer facing service. The service action inherits all of the data elements defined on the customer facing service. Also, the service action includes a set of default data elements that are inherited from the associated functional area. These default data elements are associated with the Implicit Parameter tag (in the Functional Area editor) and they are not editable.
You can associate resource facing services and resources with one service action or with multiple technical actions.
Conceptual model service actions are realized in Design Studio for Inventory projects as rulesets. Conceptual model technical actions are realized in Design Studio for ASAP project as service actions (CSDLs) or in Design Studio for Network Integrity projects as scan actions.
See Design Studio Concepts for more information about actions.
Realizing Conceptual Model Entities into Application Entities
An application role represents a type of downstream delivery system that is responsible for a specific type of delivery, such as activation, supply chain management, work force management, and so forth. Design Studio includes a set of predefined application roles. You can create your own application roles using the Application Role editor.
When you create a new technical action, Design Studio prompts you to select an action type (service or technical) and an application role. Design Studio populates the Action editor Action Codes tab with the specialized action code names defined for the application role. A specialized action code is an action code that you rename to align a technical action with a downstream fulfilment system.
For example, you may need to rename the Create action code to Activate to better align with code defined in a downstream activation system. For a supply chain management system, you may need to rename the Create action code to Ship. You may need to rename the Remove action code to Uninstall to better align with a downstream workforce management system.
Additionally, the Application Role editor enables you to define multiple specialized action code names for each default action code. For example, a downstream fulfillment system may require multiple versions of the Modify action code. You can differentiate between these versions by defining two unique specialized action code names, such as Change and Revise.
Action parameter bindings represent the aggregate of an entity and its parameters in the context of an application role. Action parameter bindings enable you to map source data (a conceptual model entity, attributes defined for a conceptual model entity, and components defined for a conceptual model entity) to target data (parameters defined for technical actions).
The mapping information, or binding, is contained in an Action Parameter Binding (APB) entity. APB entities enable you to identify source data elements in a conceptual model and define how they contribute to the generation of technical action data elements.
For example, you may have a Network Address Template Resource entity defined with multiple technical actions. You can create an action parameter binding to map the source data from the conceptual model (data defined on Network Address Template Resource entity or elsewhere in the conceptual model) to the data that is required by a set of technical actions.
At run-time, action parameter binding configuration facilitates the analysis required during the Calculate Technical Actions (CTA) provider function, enabling CTA to determine the differences between a requested service configuration and the current service configuration. After the delta is determined, CTA can identify the technical actions required to affect the necessary changes in the network.
See Design Studio Concepts for more information about how action parameter bindings contribute to the Calculate Technical Actions provider function. See the Oracle Communications RSDOD Reference Solution Developers Guide for more information about generating CTA metadata.
A conceptual model domain is a group of entities and actions that you can use to organize and filter conceptual models. For example, you can create a domain called Alcatel DSLAMs that contains the resources (the Alcatel devices) that can be used as a DSLAM. You can include conceptual model entities in multiple domains, and you can create a hierarchy of domains that include subdomains. Subdomains can decompose into smaller groupings (for example, into broadband products and broadband services). Domains can be used as subdomains, and subdomains can be shared across multiple domains.
You can filter the Solution view to display domains and view and navigate among only those entities that are associated with domains.
You do not convert Domain entities into application entities in Design Studio. Rather, Domain entities help you organize, filter, and navigate conceptual models.
See Design Studio Concepts for more information about domains.
Functional areas are the logical layers of an installation and can be commercial, service, and technical layers. These layers are supported by an Order and Service Management order type or by an external order management system.
When configuring functional areas, you specify whether the functional area supports actions. If it does, you indicate which conceptual model entities support the type of actions defined by the functional area and whether these actions are multi-instance. For example, the Service functional area supports actions, but only on customer facing services, resource facing services, and resources. The Technical functional area supports actions also, but those actions can be associated only to resource facing services and resources.
You can define default data elements for service actions associated with a functional area. These elements are automatically tagged with the Implicit Parameter tag, which cannot be removed. When a service action is created, the default data elements defined in the Functional Area editor appear as read-only on the Service Action editor Data Elements page.
Functional areas are associated with a list of action codes. Each action code, such as Remove, Modify, Add, and so forth, represents an action that can be performed on a conceptual model entity. When a new action of the type defined by the functional area is created, all of the action codes defined in the functional area are added to the new action. You can define the applicability of each default data element to the service action codes associated the functional area.
Realizing Conceptual Model Entities into Application Entities
About the Service Functional Area
The Service functional area includes default data elements that are inherited by associated service actions. These default data elements are tagged with the Implicit Parameter tag, which cannot be removed. When a service action is created, the default data elements defined in the Service Functional Area editor appear as read-only on the Service Action editor Data Elements page. You can change the action code applicability settings on the Action editor Data Map tab.
The following data elements are defined on the Service Functional Area entity:
Subject_ID: Defines the customer facing service or resource facing service instance. The value of this data element originates as an internal instance ID in the Unified Inventory Management.
ServiceAddress: Defines where the service instance is geographically located. This structured data element contains string values that originate in the CRM system.
Customer_ID: Defines the service instance. This value originates in the CRM system and is used to look up or create a corresponding subscriber instance (a UIM party).
Commercial_ID: Defines the product or asset instance related to the service instance. This value originates in the CRM system as an Asset ID.
Provider functions are processing components that perform a defined set of tasks based on its role in a solution. Design Studio includes the configuration for some provider functions, such as Calculate Service Order, Design and Assign, Calculate Technical Order, and Activation.
Provider functions accept conceptual model entities or the actions that are associated with those entities as input and generate conceptual model entities or their actions as output. The output that provider functions generate is used as input by other, downstream provider functions. Calculate Service Order accepts Product entities as input and generates the service actions associated with customer facing service entities as output. This output is required as input by the Design and Assign provider function, which will generate output that is required by the Calculate Technical Actions provider function.
The types of components that you can define for a conceptual model entity are determined by the input and output types defined in all of the provider function definitions in a workspace.
See Design Studio Concepts for more information about provider functions.
Fulfillment patterns define a set of high-level functions that can be performed to process an action or conceptual model entity. For example, a fulfillment pattern can define the functions that are required to process conceptual model entities and actions for provisioning, billing, or installation. In OSM, you associate fulfillment patterns with the processes that execute the order items.
You can associate any conceptual model entity or action to a fulfillment pattern. For example, you can associate multiple products to one fulfillment pattern, which enables you to introduce new products with minimal configuration in Design Studio. Fulfillment patterns realize as OSM fulfillment patterns.
Fulfillment patterns contain any number of fulfillment functions, which are functional-level order components.
Realizing Conceptual Model Entities into Application Entities
Fulfillment functions are operations that can be performed to process an order item. In the context of the conceptual model, the line item is an action or a product. After you create fulfillment functions, you associate them with fulfillment patterns. You also associate actions with fulfillment patterns, and the fulfillment pattern associated with any action determines which fulfillment functions can be associated with the action.
Fulfillment functions can be realized as OSM Order Component specifications. In OSM, line items are sent to a fulfillment pattern, which includes a set of order components that can be used to process the line item. The order components represent work that needs to be done against the line item. The fulfillment pattern determines which order components are to be used based on the conditions and dependencies defined in OSM. Each order component can have dependencies to other components (for example, one component may require that another be completed first).