CFS represents the commercial view of the services that you provide to your customer that is, the way that a product is realized and delivered to a customer. In the Mobile Service example, Mobile CFS is the CFS in the PSR model for the Mobile Service. You can use the same CFS to fulfill different but similar product offers. For example, the same Mobile CFS can be used for Mobile Service and Wireless service. See "Service Models Example" for more information.

You define the design parameters for the CFS. Additionally, you associate CFSs with RFSs. For example, you can associate the resource facing services 5G Profile RFS and 4G Profile RFS with Mobile CFS to fulfill the service.

Use the following set of guidelines when creating CFSs:

• Define CFSs to be customer centric to support multiple products. A CFS can support multiple products if it is not defined for a specific technology.
• Define CFS's design parameters that are important, and hide technology details that are not relevant to a customer.
• Define CFSs to represent domains. For example, the Mobile CFS represents the Mobile domain and Wireless domain.
• Define relationships to RFS, Resources and Locations from CFS. You cannot create a relationship between a CFS and another CFS

An RFS describes how CFSs are configured. For example, you can fulfill a CFS named Mobile CFS using multiple modes of delivery, each represented by an RFS, such as 4G or 5G. You determine the RFS that is used to provide the requested services during the service design.

RFSs are technology-specific but not vendor-specific. They have hierarchical structure and have associations with resources or with other, finer-granulated RFSs. In the Mobile Service example, the 5G Profile RFS and 4G Profile RFS have a child RFS Mobile Identity RFS which in turn has an association with the SIM Card and TN resources to provision the SIM card and telephone number resources from an inventory management systems such Oracle Communications Unified Inventory Management (UIM). See "Service Models Example" for more information.

Resources are entities that are required to provision a service. 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 an RFS. Resources can be physical, such as a port, or logical, such as bandwidth. Examples of resources include IP addresses, VoIP phones, and DSLAM ports. In the Mobile Service example, the TN, SIM Card, and UDR are the resources required to fulfill the service.

Resources have associations with other resources. Additionally, you can define resources that you intend to realize in external systems such as supply chain management, activation and so on.

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.

In Solution Designer, two locations Customer Site and Service Location are pre-loaded. You can use the pre-loaded locations in the PSR models but cannot create new locations. For example, in a Fixed line service, a customer premise equipment that is, a telephone instrument must be installed at that customer location. Use the Customer Site location in the PSR model to represent the customer location where the CPE must be installed.

A component represents a specific element needed to complete the entity. You define relationships between the specifications by adding components. When defining a CFS, RFS, or resource, you can add one or more components that reference another entity. This sets a relationship between the entities such that they are associated with each other in your system's processes.

To create a CFS using the Specifications application:

Service specialists or network specialists create and manage RFSs. You can relate an RFS to locations, resources, or another RFS.

To create an RFS using the Specifications application:

Network specialists create and manage the resources. You can relate a resource to location, another resource, or RFSs.

To create a resource using the Specifications application:

You can add Advanced policy implementation assets by clicking Add in the General Information tab of a specification.

You can define the relationships between specifications in the Configuration tab in the Specifications page.

You define relationships between specifications by adding components to the specification configuration. A component represents a specific entity that is needed to complete the specification. Each specification requires at least one component to relate the other specifications. For example, a CFS requires at least one component to relate to RFS, resource, or location specification.

To configure the relationships between specifications:

1. In the Solution Designer landing page, click the Specifications application.

2. In the Specifications application, select a specification by searching for it.

   The corresponding specification page opens.

3. Click the Configuration tab.

4. Do one of the following:

   • Click Edit Configuration button if no configuration exists.

   • Click the Edit button on the top right to update the existing specification configuration.

   The Edit Configuration page opens.

5. In the Edit Configuration page, click the + symbol to add a component to the configuration. You can create a new component only; you cannot search for any existing components.

   To create a new component:

   1. Click New component to create a new component.

      The New Component drawer opens. You can create a new component that relates to the selected specification. For example, if the selected specification is Mobile CFS, you can create a Subscriber Profile RFS component and then relate the 4G Profile RFS and 5G Profile RFS to the component. For each specification that you relate, you must create a corresponding component.

   2. Enter the following details:

      Table 5-5 New Component Fields

      Name	Required or Optional	Description
      Name	Required	Name of the component.
      Type	Required	Type of the component such as resource facing service component, resource component, location component.
      Minimum Cardinality	Required	The minimum number of instances of the component that can appear at runtime.
      Maximum Cardinality	Required	The maximum number of instances of the component that can appear at runtime.
      Relationship Type	Required	The relationship type of the component. See "Relationship Types" for the details on relationship types.
      Description	Optional	The description of the component.

   3. Click Create.

      The component is created and added to the Edit Configuration page or to the canvas of the service model or the technology model in the guided process.

      The component is added as a child of the selected specification in the configuration.

      To update the component, click the component and update the details. If you are updating a relationship type, update it first and save the changes in the components page and click Done in the Edit Configuration page. Reopen the Edit Configuration page to update the other details.

   See "About Components" for more information on components.
6. After you add a component, click the + symbol on the component and select an existing specification that matches the type of the component.

7. Repeat the steps 5 and 6 for associating more components and specifications.

8. Click Done.

When you hover over the entities in the configuration, Solution Designer highlights the complete relationship hierarchy for that entity.

To remove an entity in the configuration, click the entity and in the entity details drawer, click the Remove button. The entity and its children are deleted from the configuration canvas if all the validations are successful.

To delete a component in the configuration, click the component and then click Delete. After confirmation, the component and its children are deleted if all the validations are successful.

To delete a relationship between a component and specification, click the three dots on the component and select Remove link to child specifications where child specifications are the specifications that are related to the selected component. The Remove link to child specifications option is available only for its components. For example, if you have selected CFS, then the option is available only for its child RFSs.

You define the design parameters that are passed from the upstream order management systems to the specifications in Solution Designer. A design parameter identifies the data elements or features that apply to CFSs, RFSs, or resources. Data elements define the data that is necessary to fulfill your service. Feature group is a group of data elements that you want to use together. In the Mobile Service example, in Mobile CFS, the design parameter Service Address can be created as a feature group which has city and state as its data elements.

You also define the design action mapping for the design parameter. Design action mappings identify which of the design parameters on the specification are exposed in the signatures of operations acting on the entity. For example, the set of design parameters identified as inputs on the Add action will be part of the request to create an instance of the entity.

Entity characteristics are specific types of data with particular properties that you can use in a service in Solution Designer. For example, a characteristic can be an ID, a feature, or a telephone number. You can define data elements or feature groups that are entity characteristics within the CFSs, RFSs, resources, and locations.

You map the design parameters of a specification to the specification's entity characteristics and the design parameters of its child specification. When mapping parameters, the data elements and feature groups must be of the same type. For example, you must map a design parameter of boolean type to an entity characteristic of boolean type only. When you map design parameters to entity characteristics in Solution Designer, at runtime the value for the mapped parameter is passed from the order management system to the inventory management system to provision the services.

You define the delivery policies in Solution Designer. Delivery policies are a set of delivery actions that communicate to a delivery system. For example, an activation system performs delivery actions to configure a network; a shipping system performs delivery actions to pick, pack, and ship physical goods; and a workforce management system performs delivery actions to dispatch work to a field technician.

When you define a resource, you can specify that it is a delivery action target. Only those resources which are defined as delivery action targets can be delivery targets in delivery policies. You define a delivery policy for an RFS or a resource that includes a set of delivery parameters, to indicate the parameters that are involved along with the type of delivery action. With multiple delivery policies, you can have delivery actions destined for different types of delivery systems defined against a single specification.

During service order fulfillment, a design and assign process defined by the design policies produces a service configuration that defines the delivery actions that must be run to fulfill the requested service.

A delivery action represents a unit of work that is performed to realize a resource in a network. A delivery action also defines delivery parameters that describe the work to be done, and these delivery parameters also map to properties of a resource assigned to or referenced by the service configuration. You define the delivery action in Solution Designer by mapping the delivery parameter to the delivery action code and its value. For each delivery action operation, you can select the Value field as required or optional, inputs, outputs, or both.

After you define the delivery action mapping in the Delivery Parameter in Solution Designer, you can override the existing implementation with your custom implementation using the extended class. To write the implementation code for delivery action mapping, see "Extending Solution Designer" in Developer's Guide.