6 Managing Service Specifications

Use Service Specifications in Solution Designer to define your services. The service specifications include Customer Facing Services (CFS) and Resource Facing Services (RFS).

Topics in this document:

About Service Specifications

A specification is a blueprint that determines the information that you store about a service. The purpose of a specification is to provide a description of the requirements of a service, components of a service, the capability or performance of a service or work to be performed to fulfill a service. In Solution Designer, there are two types of specifications:

  • Service Specifications that include CFS and RFS.

  • Resource Specifications that include resources and locations.

Service specialists manage the service specifications in Solution Designer. Specifications are the basis for PSR Models you create in Solution Designer to model your network solution. Table 6-1 shows the different types of service specifications and who manages them in Solution Designer:

Table 6-1 Service Specification Types

Service Specification Managed by Description
Customer facing service (CFS) Service Specialist

CFS represent services from a customer perspective. See "About Customer Facing Services" for more information.

Resource facing service (RFS) Network Specialist

RFS represent a technical view of a service. See "About Resource Facing Services" for more information.

About Customer Facing Services

CFS represents the commercial view of the services that you provide to your customer which means 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 "Mobile Service Example of Service Models" 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 other CFSs, RFSs, resources and locations from CFS.

About Resource Facing Services

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 "Mobile Service Example of Service Models" for more information in Mobile Service example.

About Components

A component represents a specific element needed to complete the entity. You define relationships between the specifications by adding components. When defining a CFSs, RFSs, or resources, 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.

Relationship Types

Each component associated with a specification is defined with a specific relationship type as follows:

  • Exclusive: At run time, the component can't be shared with other service instances. For example, telephone numbers cannot be used by multiple instances of a mobile service. In Mobile Service example, a Mobile Identity RFS might have an exclusive component for a telephone number. There's an exclusive relationship between the Mobile Identity RFS and the TelephoneNumber resource. The Exclusive type defines relationships among CFSs, RFSs, and resources.

  • Shared: At run time, the component can be shared with other service instances. In Mobile Service example, because the UDR can store several subscription data simultaneously (and is not exclusive to any one service), there is a shared relationship between the 5G Profile RFS and the UDR resource. The Shared type defines relationships among CFSs, RFSs, and resources.

  • Reference: At run time, a target entity references a source entity. For example, in a fixed line service, a fixed voice CFS might have a reference component for a service location, which is a physical address.

  • Config hierarchy: In Oracle Communications Unified Inventory Management (UIM), an intermediate hierarchical structure is referenced at run time. This creates a configuration for the RFS. You can use this for a relationship between an RFS and a resource. The Config hierarchy type indicates that a UIM realization of a resource component should result in a hierarchy of configuration items and should not generate a UIM entity.

Cardinality

Cardinality determines how many instances of the component that can appear at runtime. In the Mobile Service example, there can be multiple telephone numbers required for an enterprise, so the cardinality of TN component can be a minimum of 1 and a maximum of 10.

Creating Service Specifications

A service specialist creates and manages the service specifications. You create the service specifications using the Service Specifications application or in the Build Model step, when creating PSR Models in the guided mode. See "About Solution Designer Applications" for more information on Solution Designer applications and "Creating PSR Models using Guided Process" for more information on the guided process.

To create the specifications:

Creating Customer Facing Services

You must have the service specialist role to create and manage the CFS. A CFS can have CFSs, RFSs, resources, and locations as its children. For creating and configuring a CFS specification, you must have the following in Solution Designer:

  • An initiative. See "Creating Initiatives" for more details.

  • Domains. See "Creating Domains" for more details.

  • RFS, resource, another CFS, or locations. To configure a CFS, you must create RFS, resource, another CFS, and locations within the same initiative so they are available for the CFS to build the hierarchical relationship between them.

To create a CFS using the Service Specifications application:

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

  2. In the Service Specifications application, click Create Customer Facing Service.

    The Create Customer Facing Specification page opens.

  3. Enter the following fields:

    Table 6-2 New CFS Fields

    Field Name Required or Optional Description
    Name Required Unique name of the CFS. In the Mobile Service example, Mobile CFS is the CFS name.
    ID Required Unique Id of the CFS.
    Initiative Required The initiative that the CFS belongs to. This CFS is available only for the selected initiative until the initiative is released. Specifications from the released initiative are available system-wide.
    Primary Domain Required The primary service domain. Only one primary domain can be selected for the CFS.
    Secondary Domains Optional

    The secondary service domains that are associated with a CFS. Multiple secondary domains can be associated with a CFS. The secondary domains must have the same domain type as of the selected primary domain.
    Start Date Optional The starting date of the CFS.
    End Date Optional The ending date of the CFS.
    Description Optional The description of CFS.

    Note:

    The CFS must have unique ID and follow the naming rules. See "About Naming Rules" for more information on naming rules.

  4. Click Create and Continue.

    The Customer Facing Service editor page opens.

  5. You use the following tabs to define the CFS:

    • General Information: Provides the general information for the CFS. You can add advanced policy implementation assets to a specification. See "Adding Advanced Policy Implementation Assets" for information on how to add advanced policy implementation assets.

    • Configuration: Configure the relationship between a CFS specification and the other specifications such as RFSs, resources, other CFSs, and locations. This builds a hierarchy between the CFSs, RFSs, resources, and locations. See "Configuring Relationships between Specifications" for details on how to configure the relationships between specifications.

    • Design Parameters: Configure the design parameters for the CFS using the existing data elements or create new data elements. Design parameters are carried from the upstream order management systems and you define them in the CFS. See "Defining Design Parameters" for details on how to define design parameters.

    • Characteristics: Configure the characteristics for the CFS using the existing data elements or create new data elements. Data elements are added as characteristics to realize them in UIM run-time environment. See "Defining Characteristics" for details on how to define entity characteristics.

    • Parameter Mapping: Configure the mapping of the design parameters to characteristics of the specification and also the mapping between the design parameters of the specification and the design parameters of its child specifications. See "Mapping Design Parameters" for details on parameter mapping.

    • Design Policies: Define the design policies to provision the services in UIM. UIM provisions the service based on the defined design policies. See "Defining Design Policies" for details on defining design policies.

    • Used by: Lists all the PSR Models and product specifications that use the CFS.

  6. Click Go to Service Specifications at the top left to return to the Service Specifications page.

Creating Resource Facing Services

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

For creating and configuring an RFS, you must have the following in Solution Designer:

  • An initiative. See "Creating Initiatives" for more details.

  • Domains. See "Creating Domains" for more details.

  • Resource, Locations, or another RFS. To configure an RFS, you must create the resources, locations, and another RFSs within the same initiative so they are available for the RFS to build the hierarchical relationship between them.

To create an RFS using the Service Specifications application:

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

  2. In the Service Specifications application, select Create Resource Facing Service.

    The Create Resource Facing Specification page opens.

  3. Enter the following fields:

    Table 6-3 New RFS Fields

    Field Name Required or Optional Description

    Name

    Required

    Unique name of an RFS. In the Mobile Service example, 4G Profile RFS, 5G Profile RFS, and Mobile Identity RFS are the RFS names. See "Mobile Service Example of Service Models" for more details.

    ID

    Required

    Unique Id of an RFS.

    Initiative

    Required

    The initiative that the RFS belongs to. This RFS is available only for the selected initiative across the application until the initiative is released. Service Specifications from the released initiative are available system-wide.

    Primary Domain

    Required

    The primary service domain or the technology domain. Only one primary domain can be selected for the RFS.

    Secondary Domains

    Optional

    The secondary domains that are associated with the RFS. Multiple secondary domains can be associated with the RFS. The secondary domains must have the same domain type as that of the selected primary domain.

    Start Date

    Optional

    The starting date of an RFS.

    End Date

    Optional

    The ending date of an RFS.

    Description

    Optional

    The description of the RFS.

    Note:

    The RFS must have unique ID and must follow the naming rules. See "About Naming Rules" for more information on naming rules.

  4. Click Create and Continue.

    The Resource Facing Service editor page opens.

  5. You use the following tabs to define the RFS:

    • General Information: Provides the general information for the RFS. You can add advanced policy implementation assets to a specification. See "Adding Advanced Policy Implementation Assets" for information on how to add advanced policy implementation assets.

    • Configuration: Configure the relationship between the RFS and the other entities such as RFSs, resources, and locations. This builds a hierarchy between the RFSs, resources, and locations. See "Configuring Relationships between Specifications" for details on how to configure the relationships between specifications.

    • Design Parameters: Configure the design parameters for the RFS using the existing data elements or create new data elements. Design parameters are carried from the upstream order management systems and you define them in the RFS. See "Defining Design Parameters" for details on how to define design parameters.

    • Characteristics: Configure the characteristics for the RFS using the existing data elements or create new data elements. Data elements are added as characteristics to realize them in UIM run-time environment. See "Defining Characteristics" for details on how to define entity characteristics.

    • Parameter Mapping: Configure the mapping of the design parameters to characteristics of the specification and also the mapping between the design parameters of the specification and the design parameters of its child specifications. See "Mapping Design Parameters" for details on parameter mapping.

    • Design Policies: Configure the design policies to provision the services in UIM. UIM provisions the service based on the defined design policies. See "Defining Design Policies" for details on defining design policies.

    • Delivery Policies: Configure the delivery policies which are requests to downstream delivery systems such as activation, supply chain management, and so on, to make changes in the network. See "Defining Delivery Policies" for details on defining delivery policies.

    • Used by: Lists all the entities such as PSR models, specifications and so on that use the RFS.

  6. lick Go to Service Specifications on the top left to return to the Service Specifications page.

Adding Advanced Policy Implementation Assets

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

Note:

You must add an advanced policy implementation asset information when you define advanced policies for that specification. You can add only one advanced policy implementation assets for multiple advanced policies for that specification.
To add advanced policy implementation assets:

  1. In the specification editor page, click the General Information tab.

  2. Click Add in the Advanced policy implementation assets section.

    The Advanced policy implementation assets page opens.

  3. Enter Link. This is the relative path of the S3-compatible object store. For example, 
    /bucket/restOfPath.java
    The object store is the location where the advanced policy implementation class is placed. When you publish an initiative that has a PSR model, the DevOps engine generates the Design Studio workspace and requested cartridges. You can download the Design Studio workspace and import it into Design Studio Eclipse environment. The Design Studio workspace contains a base class and an implementation class named extended designer class. The extended designer class contains the implementation for the advanced policy. After you complete your customized implementation, you must place it in the object store. Then, this relative path is entered in Link.

  4. Enter Relates to. Select the advanced policies for which the implementation code is written.

  5. Click Add.

    The implementation assets details are added to the General Information tab. After you add the implementation asset details, the status of the advanced policy moves from In Progress to Ready. You can add only one advanced policy implementation assets information. You can update or delete the advanced policy implementation assets information.

Viewing Service Specifications

You can view the specifications from the Service Specifications application or from the Initiative Items tab in the Initiatives application.

To view the service specifications:

  1. In the Solution Designer landing page, click the application that you want to work with.

  2. Do one of the following:

    • In the Service Specifications application, search for a specification using the following criteria:

      • Specification name
      • Status
      • Initiatives
      • Domain
      • Type
      • Last Updated
      The service specification result is filtered based on the search criteria.

      Note:

      In the service specifications results page, click View Errors to view the validation errors if any.

    • In the Initiatives application, search for an initiative and click the Initiative Items tab in the initiative editor page.

  3. Select a service specification to view the details.

    The service specification editor page opens.

  4. You can view the service specification details such as configuration, design parameters, characteristics, design policies, delivery policies, used by, and general information for the respective specifications in different tabs.
  5. Do one of the following:

    • Click the Go to Service Specifications link on the top left to return to the Service Specifications page.

    • Click the Go to previous page link on the top left to return to the Initiatives Items tab in the initiatives editor page.

Updating Service Specifications

You can update the configuration, design parameters, characteristics, parameter mapping, design policies, delivery policies and general information. You can update the primary domain and the secondary domains if the specification does not have any components or any child specifications associated with it.

Note:

You can update a service specification only if the associated initiative is in Definition and Advanced Configuration status.
To update a specification:

  1. In the Solution Designer landing page, click the application that you want to work with.

  2. Do one of the following:

    • In the Service Specifications application, search for a specification and open the specification.

    • In the Initiatives application, search for an initiative and click the Initiative Items tab in the initiatives editor page. Select a specification to update the details.

    The specifications editor page opens.

  3. You can update the specification configuration, design parameters, characteristics, parameter mappings, design policies, delivery policies, and general information for the respective specifications.

    • General Information: View or update the general information for the selected specification. You can add Advanced policy implementation assets by clicking Add in the General Information tab. See "Adding Advanced Policy Implementation Assets" for information on how to add advanced policy implementation assets.

    • Configuration: View or update the relationship between the specification entities. This builds a hierarchy between the specification entities. See "Configuring Relationships between Specifications" for details on configuring specifications.

    • Design Parameters: View or update the design parameters for the specifications. See "Defining Design Parameters" for details on defining design parameters.

    • Entity Characteristics: View or update the characteristics for the specifications. See "Defining Characteristics" for details on defining entity characteristics.

    • Parameter Mapping: View or update the parameter mapping. See "Mapping Design Parameters" for details on parameter mapping.

    • Design Policies: View or update the design policies to provision the services. See "Defining Design Policies" for details on defining design policies.

    • Delivery Policies: View or update the delivery policies. Delivery policies are available for RFSs and Resource specifications only. See "Defining Delivery Policies" for details on defining delivery policies.

    • Used by: Lists all the PSR Models and specifications that use the selected specification. Click the entity name to the view the general information of the entity.

  4. Do one of the following:

    • Click the Go to Service Specifications link on the top left to return to the Service Specifications page.

    • Click the Go to previous page link on the top left to return to the Initiatives Items tab in the initiatives editor page or the parent specification page from where this specification is opened.

Cloning Service Specifications

You can clone the existing service specifications to create a copy and update the details as necessary. See "About Cloning Entities" for information on the cloning process.

To clone a specification:

  1. In the Solution Designer landing page, click the application that you want to work with.

  2. Do one of the following:

    • In the Service Specifications application, search for a specification.

      In the specifications result list page, click Clone.

      The Clone Specification pop-up appears. Specification includes CFS and RFS.

    • In the Service Specifications application, search and open the specification.

      The specifications editor page opens. Click the Clone in the specifications editor page.

      The Clone Specification pop-up appears. Specification includes CFS and RFS.

    • In the Initiatives application, search and select an initiative. Click the specification in the Initiative Items tab in the initiatives editor page.

      In the Specifications editor page, click Clone.

      The Clone Specification pop-up appears. Specification includes CFS and RFS.

  3. Update the name, ID, and description as necessary. See "About Naming Rules" for more information on naming rules for ID.

    Note:

    • You can't select a new initiative when you clone a specification in Definition and Advanced Configuration status.
    • You must select a new initiative that is in Definition status when you clone a specification in Released status.

  4. Click Continue.

    The specification editor page opens with all the details.

    You can update the configuration, design parameters, characteristics, and general information. You may configure parameter mapping, design policies, and delivery policies after cloning, as those are not copied when cloning a specification.

Revising Service Specifications

A service specialist revises a CFS whereas a network specialist revises a RFS. See "About Revising Entities" for information on revising an entity. In the Mobile Service example, you are revising the Mobile CFS in the Released status to add a new design parameter Closed User Group (CUG). When revising, select a different initiative in Definition status, Mobile Upgrade. The original specification is associated with Mobile initiative and the revised specification is associated with Mobile Upgrade initiative. See "Mobile Service Example of Service Models" for more information on the Mobile Service example.

To revise a service specification:

  1. In the Solution Designer landing page, click the application that you want to work with.

  2. Do one of the following:

    • In the Service Specifications application, search a specification.

      The specification is listed in the results section.

    • In the Service Specifications application, search and open a specification.

    • In the Initiatives application, search for an initiative and click the Initiative Items tab in the initiatives editor page. Select a specification.

      The specification editor page opens.

  3. Click Revise.

    The Revise Specification dialog box opens. Specification includes CFSs and RFSs.

  4. Select an initiative that is in the Definition status and click Continue.

    The corresponding specification editor page opens.

  5. The configuration, design parameters, characteristics, parameter mapping, design policies, delivery policies, and general information can be modified for the revised specification. See "Updating Service Specifications" for more information on modifying specification details.

Deleting Service Specifications

You delete a service specification from the Service Specifications application or from the Initiative Items tab in the initiatives editor page in the Initiatives application.

To delete a specification:

  1. In the Solution Designer landing page, click the application that you want to work with.

  2. Do one of the following:

    • In the Service Specifications application, search a specification.

      The specification is listed in the results section.

    • In the Service Specifications application, search and open a specification.

      The specification editor page opens.

    • In the Initiatives application, search for an initiative and click the Initiative Items tab in the initiatives editor page. Open a specification.

      The specification editor page opens.

  3. Click Delete.

    A confirmation dialog box appears.

  4. Click Delete in the confirmation dialog box.

    The specification is deleted if it is not associated with any other specifications or PSR models. If you are deleting a revised specification, only the current revision is deleted and the specification is reverted to the previously released version.

Note:

You can't delete a service specification after you complete the Advanced Configuration phase of the associated initiative.